Re: [gentoo-dev] Re: What are eblits?

[Kent Fredric]

On 28 May 2016 at 05:35, rindeal  wrote:
> This whole concept, however, raises the question (as suggested by
> Ciaran McCreesh and Duncan) if it's allowed to split ebuilds to
> several bash scripts and what have QA and dev-manual got to say in
> this regard?


Personally I'd say the biggest risk from a QA perspective of this
approach is important changes shared amongst ebuilds might require the
change be done in an eblit, but the change itself may require all
existing users of the ebuilds perform a reinstall.

This is already a problem with eclasses where eclass changes might
necessitate all dependent ebuilds being rebuilt in some way, but we
fence that out of existence with QA policies against such changes. ( A
popular fencing mechanism is via EAPI conditionals and ENV vars which
require the end ebuild to explicitly opt in to the change for it to
take affect, thus, causing the propagation to occur explicitly )

Under eblits, the same sorts of logic can occur, but the temptation to
change the eblit and not the ebuild is substantially greater.

But the necessity to bump the ebuild to cascade the rebuild is still
there ( and greater )

Which means in practice, eblits can make cascades harder, and
encourage devs not to perform ...

Which is a rather bad  combination of pressures.

Hence, eblits as they currently exist are experts-only and a big
danger ground for QA violations *to occur within*, even under the
presumption that they're not inherently a QA violation in themselves.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 06:05 PM, Daniel Campbell wrote:
> On 05/27/2016 02:45 PM, NP-Hardass wrote:
>> Not on hand, but as the MATE maintainer, I can tell you that starting
>> with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
>> more are.
>>

> 
> Aha, thanks for offering that info. Which ones if you don't mind?
> 
in 1.14 x11-misc/mozo and mate-extra/mate-system-monitor.  Don't have
the 1.16 ones handy as I haven't been able to work on it the last week
(more hw issues)

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Daniel Campbell]

On 05/27/2016 02:45 PM, NP-Hardass wrote:
> On 05/27/2016 02:57 PM, Daniel Campbell wrote:
>> As far as I'm concerned, if any package I maintain offers both gtk2 and
>> gtk3 support, it would be irresponsible for me to *not* offer that
>> choice. Gentoo is about flexibility and giving power to the user. Choice
>> is a central part of that, and basically *the* reason I switched to
>> Gentoo or bothered to become a developer.
> 
> +1
> 
>> You also mentioned that Mate and XFCE won't be supporting GTK2. Got any
>> links there?
> 
> Not on hand, but as the MATE maintainer, I can tell you that starting
> with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
> more are.
> 
>> Just my two cents.
>>
>> ~zlg
>>
> 

Aha, thanks for offering that info. Which ones if you don't mind?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 02:57 PM, Daniel Campbell wrote:
> As far as I'm concerned, if any package I maintain offers both gtk2 and
> gtk3 support, it would be irresponsible for me to *not* offer that
> choice. Gentoo is about flexibility and giving power to the user. Choice
> is a central part of that, and basically *the* reason I switched to
> Gentoo or bothered to become a developer.

+1

> You also mentioned that Mate and XFCE won't be supporting GTK2. Got any
> links there?

Not on hand, but as the MATE maintainer, I can tell you that starting
with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
more are.

> Just my two cents.
> 
> ~zlg
> 

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 11:40 AM, William Hubbs wrote:
> On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote:
>> Hello,
>>
>> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
>> upstream, many applications still support only gtk2, have subtle issues
>> with their gtk3 port, or support both, with some of our userbase
>> clinging to gtk2 for dubious political or aesthetical reasons.
>>
>> For the latter cases, despite GNOME teams policy and strong preference
>> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
>> working as good as gtk2), some cases exist where the maintainers want
>> to provide such choice. In some cases it is understandable for a short
>> while during transition, e.g firefox. In other cases, it is purely for
>> the sake of providing the choice of working with a deprecated toolkit,
>> apparently.
>>
>> My highly biased essay aside, we need to finally globally agree on what
>> we do in this situation. If we allow this choice at all, only for
>> special cases, or widespread. And if this choice is provided, how do we
>> name the USE flag.
> 
> (qa hat in place)
> 
> There is a qa policy about this. All packages in the tree should
> move away from the non-versioned gtk use flag to versioned use flags,
> like the ones the qt team uses [1] [2].
> 
> This seems to be the best compromise. It allows the maintainers of the
> packages to decide which toolkit they want to support. If there is too
> much work involved in maintaining a package with dual support, don't do
> the work, just make it support the appropriate toolkit version.
> 
> I have not seen any reason why something like this couldn't work. After
> all, it seems to work for the qt team.
> 
> William
> 
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
> [2]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation
> 

Explicit gtk version flags is fine by me:
REQUIRED_USE=" || ( gtk2 gtk3 ) ^^ ( gtk2 gtk3 ) ?? ( gtk2 gtk3 )"

I think an unversioned gtk flag semantically makes and simplifies some
ebuild logic in cases where gtk support is completely optional.
DEPEND="
gtk? (
cat/foo
cat/gorp[gtk2=,gtk3=]
gtk2? (
cat/bar:2
cat/baz[gtk2]
x11-misc/gtk:2
)
gtk3? (
cat/bar:3
x11-misc/gtk:3
)
)
"

So, in summary, I'm content to move away from unversioned gtk flags in
all cases except when using it to describe "optional gtk support" which
is then backed up with versioned gtk flags.

Also, regardless of the decision, I'd be happy to help refactor the tree
to conform with the decision.
-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 10:21 AM, Mart Raudsepp wrote:
> Hello,
> 
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
> 
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
> 
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
> 
I don't see the benefit of forcing people off of gtk2 to gtk3 when gtk2
is working just fine.  gtk2 is entrenched, and will take a while to
migrate apps from.  A parallel, why don't we just drop python2.7?  It's
old, superseded, and plenty of things support python3.x.  I disagree
with this logic.  In my opinion, we should remove support for them when
it seems that it has been dropped by a majority of packages or unfixed
security issues make it not worth keeping around.  I don't think we are
anywhere near that point.

[...]

> Thoughts? Agreements? Suggestions?
> I'm particularly interested in QA opinion here. I believe WilliamH
> wanted to spearhead this from their side.
> 
> 
> Regards,
> Mart Raudsepp
> Gentoo developer, GNOME team
> 

Flag specific comments to follow in WilliamH's reply.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[William Hubbs]

On Fri, May 27, 2016 at 01:55:41PM -0400, Anthony G. Basile wrote:
> On 5/27/16 1:44 PM, William Hubbs wrote:
> > On Fri, May 27, 2016 at 01:14:17PM -0400, Anthony G. Basile wrote:
> >> On 5/27/16 12:59 PM, rindeal wrote:
> >>> On 27 May 2016 at 18:54, landis blackwell  
> >>> wrote:
>  I stopped reading after you reminded me it was 2016
> >>>
> >>> Good to know, thanks for stopping by.
> >>>
> >>
> >> Yeah the "its  year" meme has been making its rounds of the
> >> internet.
> >>
> >> anyhow, my 2017 question is about avahi.  right now i have USE=gtk and
> >> gtk3, where gtk really means gtk2.  i'm not going to change that because
> >> it fits QA's specs.  but i could remove it altogether and just drop gtk2
> >> support for the next release.  good idea?  bad idea?  i guess i'm asking
> >> whats the status of gtk2 in gentoo seeing as its dead upstream.
> > 
> > From QA's pov, the gtk2 support is up to you, but I also would recommend
> > adding a gtk2 use flag if you keep it around. The idea is to eventually
> > get away from the non-versioned use flag.
> 
> It wouldn't be adding, it would be renaming a flag which is possible but
> annoying.  Anyhow I'll cross that bridge after the next release of avahi.

Ok, I did mis-speak a bit here. You can keep the gtk use flag, but it
refers to gtk2 only.

The gtk3 use flag should be used for gtk3.

Thanks,

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Support EGIT_SUBMODULES to filter used submodules, #497164

[Daniel Campbell]

On 05/23/2016 12:54 PM, Michał Górny wrote:
> ---
>  eclass/git-r3.eclass | 53 
> +++-
>  1 file changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 957ff08..61218a8 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -165,6 +165,36 @@ fi
>  #
>  # EGIT_CHECKOUT_DIR=${WORKDIR}/${P}
>  
> +# @ECLASS-VARIABLE: EGIT_SUBMODULES
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# An array of inclusive and exclusive wildcards on submodule names,
> +# stating which submodules are fetched and checked out. Exclusions
> +# start with '-', and exclude previously matched submodules.
> +#
> +# If unset, all submodules are enabled. Empty list disables all
> +# submodules. In order to use an exclude-only list, start the array
> +# with '*'.
> +#
> +# Remember that wildcards need to be quoted in order to prevent filename
> +# expansion.
> +#
> +# Examples:
> +# @CODE
> +# # Disable all submodules
> +# EGIT_SUBMODULES=()
> +#
> +# # Include only foo and bar
> +# EGIT_SUBMODULES=( foo bar )
> +#
> +# # Use all submodules except for test-* but include test-lib
> +# EGIT_SUBMODULES=( '*' '-test-*' test-lib )
> +# @CODE
> +if [[ ${EGIT_SUBMODULES[@]+1} && $(declare -p EGIT_SUBMODULES) != "declare 
> -a"* ]]
> +then
> + die 'EGIT_SUBMODULES must be an array.'
> +fi
> +
>  # @FUNCTION: _git-r3_env_setup
>  # @INTERNAL
>  # @DESCRIPTION:
> @@ -243,7 +273,8 @@ _git-r3_env_setup() {
>   if [[ ${EGIT_HAS_SUBMODULES} ]]; then
>   eerror "EGIT_HAS_SUBMODULES has been removed. The eclass no 
> longer needs"
>   eerror "to switch the clone type in order to support submodules 
> and therefore"
> - eerror "submodules are detected and fetched automatically."
> + eerror "submodules are detected and fetched automatically. If 
> you need to"
> + eerror "disable or filter submodules, see EGIT_SUBMODULES."
>   die "EGIT_HAS_SUBMODULES is no longer necessary."
>   fi
>  
> @@ -357,6 +388,26 @@ _git-r3_set_submodules() {
>   l=${l#submodule.}
>   local subname=${l%%.url=*}
>  
> + # filter out on EGIT_SUBMODULES
> + if declare -p EGIT_SUBMODULES &>/dev/null; then
> + local p res= l_res
> + for p in "${EGIT_SUBMODULES[@]}"; do
> + if [[ ${p} == -* ]]; then
> + p=${p#-}
> + l_res=
> + else
> + l_res=1
> + fi
> +
> + [[ ${subname} == ${p} ]] && res=${l_res}
> + done
> +
> + if [[ ! ${res} ]]; then
> + einfo "Skipping submodule \e[1m${subname}\e[22m"
> + continue
> + fi
> + fi
> +
>   # skip modules that have 'update = none', bug #487262.
>   local upd=$(echo "${data}" | git config -f /dev/fd/0 \
>   submodule."${subname}".update)
> 
Looks good to me. Great idea actually, since some projects like
app-text/pelican ship with submodules and I just wrote a live ebuild for it.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Daniel Campbell]

On 05/27/2016 10:14 AM, Anthony G. Basile wrote:
> On 5/27/16 12:59 PM, rindeal wrote:
>> On 27 May 2016 at 18:54, landis blackwell  wrote:
>>> I stopped reading after you reminded me it was 2016
>>
>> Good to know, thanks for stopping by.
>>
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk and
> gtk3, where gtk really means gtk2.  i'm not going to change that because
> it fits QA's specs.  but i could remove it altogether and just drop gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.
> 
I use GTK2 whenever possible. I gave 3 a chance, mostly during testing
of my packages and to really see what the big deal was, and was left
wanting. None of the toolkits are really that great, but GTK3 in
particular feels wrong on a desktop computer. It's probably great on a
phone or tablet, like GNOME itself.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Daniel Campbell]

On 05/27/2016 07:21 AM, Mart Raudsepp wrote:
> Hello,
> 
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
> 
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
> 
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
> 
> Historically, for very good reasons in past and present GNOME team
> members opinion, USE=gtk has always meant to mean to provide support
> for gtk in general, not any particular version. This is opposite to
> what the Qt team has been doing.
> In our opinion, in a perfect world, only USE=gtk would exist, and no
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
> perfect world, we have made use of USE=gtk3 for providing gtk3 support
> from library packages to mean to build gtk3 support. Sadly that
> overloads USE=gtk in many cases to then mean to build gtk2 support.
> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not live
> in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
> split up into separate SLOTs. In some cases it might have been meant as
> a transitional thing, until all consumers are ported to gtk3, but it
> has been lingering on due to consumer apps not being ported or we
> haven't yet noticed to remove the gtk2 support in the library package.
> 
> Now these are libraries, and despite some USE flag confusion, it's not
> a huge issue, because consumers are USE depending on what is required.
> This all is written out in
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
> since the GNOME project pages moving to wiki, and also long before that
> in GuideXML era, and we've pointed people towards that.
> 
> And then we have applications that support building against either gtk2
> or gtk3.
> In most cases, any requests to provide the choice to have an
> application use gtk2 instead of gtk3 gets instantly marked as duplicate
> of https://bugs.gentoo.org/374057 but in some cases the maintainer has
> chosen to provide this choice for now, and here is the problem - we
> don't really have a good agreed on way to name such a choice in USE
> flags, if we should provide such a choice at all.
> 
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
> USE=gtk and it being problematic. The GNOME team shall probably veto
> such USE flag usage if we are deemed to have such an authority as gtk+
> maintainers, unless we rework it all in expectations of gtk2 corpse
> being carried around for a decade as well... I have quite a few bugs
> against packages to file already for this, afair.
> 
> I kind of like what firefox did there, going in the spirit of the
> force-openrc flag we have for avoiding systemd dependency, even if it
> currently means worse user experience. So if we provide such a choice
> for apps at all, I might agree to USE=force-gtk2 for this for apps. And
> we would like to eventually (or immediately) p.use.mask this and once
> it's 2017 and gtk2 truly dead and buried and full of known security
> holes, get rid of it again.
> But this highlighted the inconsistency we are having, ending up with QA
> initiated bug https://bugs.gentoo.org/581662
> 
> tl;dr and my proposal would be the following:
> 
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.
> 
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until gtk2
> support can be dropped and it will only ship gtk3 version of the
> library. This gives 

Re: [gentoo-dev] [RFC] improper use of X

[Ian Stakenvicius]

On 27/05/16 02:44 PM, rindeal wrote:
> 
> It also clearly shows how is this flag misused:
> 
> dev-python/PyQt4:X - Build bindings for the QtGui module
> dev-python/pyside:X - Build QtGui and QtTest modules
> media-gfx/fbida:X - Install the Motif based image viewer "ida"
> media-video/aravis:X - Build the GTK+-based video viewer for aravis.
> This requires GStreamer and a few plugins but technically not the GST
> plugin for aravis.
> net-irc/quassel:X - Build the Qt 4 GUI client for quassel. If this USE
> flag is disabled, the GUI is not built, and cannot be used. You might
> want to disable this on the server, but you need it enabled on the
> client.
> 

Some of those date back rather far, to when IUSE="X" was effectively
the same as the proposed IUSE="gui".





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[rindeal]

On 27 May 2016 at 20:26, Mart Raudsepp  wrote:
> Ühel kenal päeval, R, 27.05.2016 kell 14:10, kirjutas
> waltd...@waltdnes.org:
>>   While we're at it, why are there 23 occurences of the "X" useflag
>> in
>> /usr/portage/profiles/use.local.desc when it exists in
>> /usr/portage/profiles/use.desc ???  I'm talking about stuff like...
>>
>> app-misc/vifm:X - Add support for X11
>> dev-libs/m17n-lib:X - Builds the Graphical User Interface API and
>> utilities for the package.
>> dev-libs/wlc:X - Enable X11 backend and XWayland support.
>> dev-python/PyQt4:X - Build bindings for the QtGui module
>> dev-python/pyside:X - Build QtGui and QtTest modules
>
> Because they specify in more details what the USE flag does
> specifically, in the context of that package.
> Such more exact local descriptions are something I at least personally
> strongly advocate in favour of.
> app-misc/vifm local desc seems redundant though, but the rest listed
> here seem useful and necessary.
>

It also clearly shows how is this flag misused:

dev-python/PyQt4:X - Build bindings for the QtGui module
dev-python/pyside:X - Build QtGui and QtTest modules
media-gfx/fbida:X - Install the Motif based image viewer "ida"
media-video/aravis:X - Build the GTK+-based video viewer for aravis.
This requires GStreamer and a few plugins but technically not the GST
plugin for aravis.
net-irc/quassel:X - Build the Qt 4 GUI client for quassel. If this USE
flag is disabled, the GUI is not built, and cannot be used. You might
want to disable this on the server, but you need it enabled on the
client.

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Ian Stakenvicius]

On 27/05/16 02:23 PM, Mart Raudsepp wrote:
> If gtk2 support is removed though, then per gnome policy gtk3 component
> should come with USE=gtk and per QA policy USE=gtk3.
> 
> The QA policy is not finalized and completely contradicts our side of
> things, hence discussions are needed, but did not conclude.
> This is a thread to continue this discussion, I suppose.
> 

Agreed -- it sounds like gnome and QA need to sit down and come to
concensus, and then we can work out the plan to move forward.

I think as long as the rest of us aren't bound to using only gtk3 if
our packages support gtk2 and we want to maintain said gtk2 support,
we should be fine with whatever decision you two groups come up with.








signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 14:10, kirjutas
waltd...@waltdnes.org:
>   While we're at it, why are there 23 occurences of the "X" useflag
> in
> /usr/portage/profiles/use.local.desc when it exists in
> /usr/portage/profiles/use.desc ???  I'm talking about stuff like...
> 
> app-misc/vifm:X - Add support for X11
> dev-libs/m17n-lib:X - Builds the Graphical User Interface API and
> utilities for the package.
> dev-libs/wlc:X - Enable X11 backend and XWayland support.
> dev-python/PyQt4:X - Build bindings for the QtGui module
> dev-python/pyside:X - Build QtGui and QtTest modules

Because they specify in more details what the USE flag does
specifically, in the context of that package.
Such more exact local descriptions are something I at least personally
strongly advocate in favour of.
app-misc/vifm local desc seems redundant though, but the rest listed
here seem useful and necessary.


Mart

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 13:14, kirjutas Anthony G.
Basile:
> On 5/27/16 12:59 PM, rindeal wrote:
> > On 27 May 2016 at 18:54, landis blackwell  > m> wrote:
> > > I stopped reading after you reminded me it was 2016
> > 
> > Good to know, thanks for stopping by.
> > 
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk
> and
> gtk3, where gtk really means gtk2.  i'm not going to change that
> because
> it fits QA's specs.  but i could remove it altogether and just drop
> gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm
> asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.

I don't see a strong reason to have gtk2 support if there are no gtk2
consumers remaining in the tree. I somehow doubt that's the case for
avahi, though?
If gtk2 support is removed though, then per gnome policy gtk3 component
should come with USE=gtk and per QA policy USE=gtk3.

The QA policy is not finalized and completely contradicts our side of
things, hence discussions are needed, but did not conclude.
This is a thread to continue this discussion, I suppose.

I wouldn't change anything till then really, especially for libraries,
where it's mostly handled by USE depends anyway.

One thing is USE flag naming for gtk2 and gtk3, another thing is if
apps should provide support on building against either.
I strongly disagree with using the same flag names for "provide gtk2
linking higher level library" and "Build this GUI application against
gtk version 2". QA proposed policy has this regression.
Also for libraries it is a "either or both" situation, for apps it's a
"one or the other" situation. This gets awful very quick if any
application maintainer decides to express it with a
REQUIRED_USE="^^ ( gtk2 gtk3 )", combined with the libraries in tree
that then would have REQUIRED_USE="|| ( gtk2 gtk3 )" + libraries in
tree where gtk component is optional, and if available both gtk2 and
gtk3 versions are available with
REQUIRED_USE="gtk? ( || ( gtk2 gtk3 ))".

This would be clean with only libraries using gtk2/gtk3 as is GNOME
teams current policy. Then the natural thing would be to have a
different USE flag to mean to prefer gtk2 for user facing applications
when possible instead of gtk3 (USE="force-gtk2" being suggested here
for that)
With this approach we can cleanly handle any upcoming gtk4 as well,
while naturally moving users who don't care into using the latest
version.

I also strongly believe that USE flags should be first and foremost
about features, not an expression of the name of an external
dependency.

Gilles did a huge start of work on mapping gtk* use flag usages in a
spreadsheet, but given the volume, got distracted before finished.
I pointed this out to the QA team to look at, but have not heard
anything back.
The point of the exercise was, that it turns out half of the tree seem
to mis-use USE=gtk in some way, and QA should really concentrate on
helping with that first. Then the situation would be much clearer, as
there wouldn't be all that many USE=gtk's remaining.
Anyhow, this is where the discussions stalled last time around.

I think we should first figure out about the USE flag usages (naming +
library only or not).
We can bikeshed if gtk2 version for applications should be provided
more liberally in addition to gtk3 as a one or the other choice later
on. I don't feel too strongly about making that hard if it doesn't step
on our library USE flag namespace.


Mart

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[M. J. Everitt]

On 27/05/16 16:40, William Hubbs wrote:
> On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote:
>> Hello,
>>
>> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
>> upstream, many applications still support only gtk2, have subtle issues
>> with their gtk3 port, or support both, with some of our userbase
>> clinging to gtk2 for dubious political or aesthetical reasons.
>>
>> For the latter cases, despite GNOME teams policy and strong preference
>> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
>> working as good as gtk2), some cases exist where the maintainers want
>> to provide such choice. In some cases it is understandable for a short
>> while during transition, e.g firefox. In other cases, it is purely for
>> the sake of providing the choice of working with a deprecated toolkit,
>> apparently.
>>
>> My highly biased essay aside, we need to finally globally agree on what
>> we do in this situation. If we allow this choice at all, only for
>> special cases, or widespread. And if this choice is provided, how do we
>> name the USE flag.
> (qa hat in place)
>
> There is a qa policy about this. All packages in the tree should
> move away from the non-versioned gtk use flag to versioned use flags,
> like the ones the qt team uses [1] [2].
>
> This seems to be the best compromise. It allows the maintainers of the
> packages to decide which toolkit they want to support. If there is too
> much work involved in maintaining a package with dual support, don't do
> the work, just make it support the appropriate toolkit version.
>
> I have not seen any reason why something like this couldn't work. After
> all, it seems to work for the qt team.
>
> William
>
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
> [2]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation
Having read the QA policies, surely the route forwards is fairly obvious
thus:-

- gtk is deprecated and discouraged for any new ebuilds
- we add a QA check to repoman to ensure that the 'gtk' use flag is not
used in any new ebuilds
- existing packages using 'gtk' will get updated to use 'gtk2' or 'gkt3'
in the normal cycle

Any edge cases here, or is this something that could be workable?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[waltdnes]

On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote

> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not live
> in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.

  What at the original gtk+, for which the "gtk" flag was probably
originally invented?

[i3][waltdnes][~] ls /usr/portage/x11-libs/gtk+/*.ebuild
/usr/portage/x11-libs/gtk+/gtk+-1.2.10-r13.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.28-r1.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.29.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.30.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.16.7.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.18.7.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.18.9.ebuild

> tl;dr and my proposal would be the following:
> 
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.

  There is a way to specify a GUI...

[i3][waltdnes][~] grep "^\(X \|wayland \)" /usr/portage/profiles/use.desc
X - Add support for X11
wayland - Enable dev-libs/wayland backend

  If overloading the meaning of USE="gtk" is the problem, the better
solution would be to use "X" or "wayland" or whatever to indicate the
GUI you need.  "gtk" is a relic from the days of gtk+-1.x, when there
were no other versions of gtk.  With the advent of multiple versions, we
arguably need "gtkn" useflags for every version in the tree, where "n"
is the major version #.

  While we're at it, why are there 23 occurences of the "X" useflag in
/usr/portage/profiles/use.local.desc when it exists in
/usr/portage/profiles/use.desc ???  I'm talking about stuff like...

app-misc/vifm:X - Add support for X11
dev-libs/m17n-lib:X - Builds the Graphical User Interface API and
utilities for the package.
dev-libs/wlc:X - Enable X11 backend and XWayland support.
dev-python/PyQt4:X - Build bindings for the QtGui module
dev-python/pyside:X - Build QtGui and QtTest modules

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Anthony G. Basile]

On 5/27/16 1:44 PM, William Hubbs wrote:
> On Fri, May 27, 2016 at 01:14:17PM -0400, Anthony G. Basile wrote:
>> On 5/27/16 12:59 PM, rindeal wrote:
>>> On 27 May 2016 at 18:54, landis blackwell  wrote:
 I stopped reading after you reminded me it was 2016
>>>
>>> Good to know, thanks for stopping by.
>>>
>>
>> Yeah the "its  year" meme has been making its rounds of the
>> internet.
>>
>> anyhow, my 2017 question is about avahi.  right now i have USE=gtk and
>> gtk3, where gtk really means gtk2.  i'm not going to change that because
>> it fits QA's specs.  but i could remove it altogether and just drop gtk2
>> support for the next release.  good idea?  bad idea?  i guess i'm asking
>> whats the status of gtk2 in gentoo seeing as its dead upstream.
> 
> From QA's pov, the gtk2 support is up to you, but I also would recommend
> adding a gtk2 use flag if you keep it around. The idea is to eventually
> get away from the non-versioned use flag.

It wouldn't be adding, it would be renaming a flag which is possible but
annoying.  Anyhow I'll cross that bridge after the next release of avahi.

> 
> Thanks,
> 
> William
> 


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

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[William Hubbs]

On Fri, May 27, 2016 at 01:14:17PM -0400, Anthony G. Basile wrote:
> On 5/27/16 12:59 PM, rindeal wrote:
> > On 27 May 2016 at 18:54, landis blackwell  wrote:
> >> I stopped reading after you reminded me it was 2016
> > 
> > Good to know, thanks for stopping by.
> > 
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk and
> gtk3, where gtk really means gtk2.  i'm not going to change that because
> it fits QA's specs.  but i could remove it altogether and just drop gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.

From QA's pov, the gtk2 support is up to you, but I also would recommend
adding a gtk2 use flag if you keep it around. The idea is to eventually
get away from the non-versioned use flag.

Thanks,

William



signature.asc
Description: Digital signature

[gentoo-dev] Re: What are eblits?

[rindeal]

I've found some more info on this topic from the internet archive.

- "[gentoo-dev] RFC: eblits.eclass"
http://news.gmane.org/find-root.php?message_id=4BC0F659.7000506%40gentoo.org
- https://github.com/transtone/zm-overlay/blob/master/eclass/eblits.eclass
- https://wiki.gentoo.org/wiki/GLEP:33
- "RFC: Reviving GLEP33" http://thread.gmane.org/gmane.linux.gentoo.devel/67451

It seems that "eblits" is a relative to yet another concept called
"elibs", which was proposed back in 2005 as GLEP33, but was never
completed. As opposed to "elibs", "eblits" do not require any special
EAPI or portage support and thus they're living and are tolerated to
these days, as they do not interact with anything outside of their
lawn.

Based on the explanation given by Kent Frederic and Duncan, I'd sum it up as:

"a way to share code between ebuilds of a certain package, living
concurrently in different slots"

Which can be abstracted as "isolated package-specific eclasses".

Inter-ebuild code sharing really seems like a problem for maintainers
of certain packages and eblits seem to provide a quick solution, so
that answers the "why".

This whole concept, however, raises the question (as suggested by
Ciaran McCreesh and Duncan) if it's allowed to split ebuilds to
several bash scripts and what have QA and dev-manual got to say in
this regard?

It's always better to have some official material rather than an oral tradition.

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[rindeal]

> (qa hat in place)
>
> There is a qa policy about this. All packages in the tree should
> move away from the non-versioned gtk use flag to versioned use flags,
> like the ones the qt team uses [1] [2].
>
> This seems to be the best compromise. It allows the maintainers of the
> packages to decide which toolkit they want to support. If there is too
> much work involved in maintaining a package with dual support, don't do
> the work, just make it support the appropriate toolkit version.
>
> I have not seen any reason why something like this couldn't work. After
> all, it seems to work for the qt team.
>
> William
>
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
> [2]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation

Shouldn't this rule be generalized? Eg. sqlite will relatively soon
face a similar issue with SQLite4 and there are certainly more
examples.

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Brian Dolbec]

On Fri, 27 May 2016 11:35:01 -0500
Canek Peláez Valdés  wrote:

> On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec 
> wrote: [snip]
> > I'll be really sad when gtk2 is totally abolished in Gentoo. :(
> > I suppose I'll have to break down and switch to KDE maybe.
> >
> > In my opinion the upstream gtk developers have gone somewhat bonkers
> > with their cartoonish changes to the look, feel and generally
> > un-intuitive user interface.  The new file selector is irritating
> > to use despite getting all the old behaviour settings I know of
> > set, the lack of the ability to paste a path into it, forcing you
> > to navigate directory by directory, and other BS behaviour...  
> 
> What's wrong with Ctrl-L to open the "Enter location or URL" text
> field and pasting the path there?
> 
> Regards.

The unintuitive knowledge that that even existed for one.

I have been informed in IRC about this and tried it.  I also found out
that you can just paste it without opening that box (haven't tried
that yet) . Also typing / will bring it up.  Without a / will start a
search...

All unintuitive changes since gtk2.  I admit I don't know all the in's
and out's of gtk2 either, but in gtk2 there was a small icon to open
the text/paste box if it wasn't already a default.

Also what is intuitive about special keystrokes in a gui?  After all
gui stands for Graphical User Interface.  Keyboard shortcuts are one
thing, totally hiding them from the interface quite another.  There is
a reason I tend to prefer __GOOD__ gui apps over command line ones
in most cases.  I hate trying/needing to memorize 100+ special
keystrokes and/or commands and/or options for apps.  It's more I know
what I want to do, so do the few clicks/done, not spend half my time
trying to read man pages/learn/memorize _some_app_ special keystrokes
and/or command option in order to do it.

-- 
Brian Dolbec 

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Anthony G. Basile]

On 5/27/16 12:59 PM, rindeal wrote:
> On 27 May 2016 at 18:54, landis blackwell  wrote:
>> I stopped reading after you reminded me it was 2016
> 
> Good to know, thanks for stopping by.
> 

Yeah the "its  year" meme has been making its rounds of the
internet.

anyhow, my 2017 question is about avahi.  right now i have USE=gtk and
gtk3, where gtk really means gtk2.  i'm not going to change that because
it fits QA's specs.  but i could remove it altogether and just drop gtk2
support for the next release.  good idea?  bad idea?  i guess i'm asking
whats the status of gtk2 in gentoo seeing as its dead upstream.

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

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[rindeal]

On 27 May 2016 at 18:54, landis blackwell  wrote:
> I stopped reading after you reminded me it was 2016

Good to know, thanks for stopping by.

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[landis blackwell]

I stopped reading after you reminded me it was 2016
On May 27, 2016 9:21 AM, "Mart Raudsepp"  wrote:

> Hello,
>
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
>
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
>
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
>
> Historically, for very good reasons in past and present GNOME team
> members opinion, USE=gtk has always meant to mean to provide support
> for gtk in general, not any particular version. This is opposite to
> what the Qt team has been doing.
> In our opinion, in a perfect world, only USE=gtk would exist, and no
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
> perfect world, we have made use of USE=gtk3 for providing gtk3 support
> from library packages to mean to build gtk3 support. Sadly that
> overloads USE=gtk in many cases to then mean to build gtk2 support.
> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not live
> in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
> split up into separate SLOTs. In some cases it might have been meant as
> a transitional thing, until all consumers are ported to gtk3, but it
> has been lingering on due to consumer apps not being ported or we
> haven't yet noticed to remove the gtk2 support in the library package.
>
> Now these are libraries, and despite some USE flag confusion, it's not
> a huge issue, because consumers are USE depending on what is required.
> This all is written out in
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
> since the GNOME project pages moving to wiki, and also long before that
> in GuideXML era, and we've pointed people towards that.
>
> And then we have applications that support building against either gtk2
> or gtk3.
> In most cases, any requests to provide the choice to have an
> application use gtk2 instead of gtk3 gets instantly marked as duplicate
> of https://bugs.gentoo.org/374057 but in some cases the maintainer has
> chosen to provide this choice for now, and here is the problem - we
> don't really have a good agreed on way to name such a choice in USE
> flags, if we should provide such a choice at all.
>
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
> USE=gtk and it being problematic. The GNOME team shall probably veto
> such USE flag usage if we are deemed to have such an authority as gtk+
> maintainers, unless we rework it all in expectations of gtk2 corpse
> being carried around for a decade as well... I have quite a few bugs
> against packages to file already for this, afair.
>
> I kind of like what firefox did there, going in the spirit of the
> force-openrc flag we have for avoiding systemd dependency, even if it
> currently means worse user experience. So if we provide such a choice
> for apps at all, I might agree to USE=force-gtk2 for this for apps. And
> we would like to eventually (or immediately) p.use.mask this and once
> it's 2017 and gtk2 truly dead and buried and full of known security
> holes, get rid of it again.
> But this highlighted the inconsistency we are having, ending up with QA
> initiated bug https://bugs.gentoo.org/581662
>
> tl;dr and my proposal would be the following:
>
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.
>
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until gtk2
> support can be dropped 

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Canek Peláez Valdés]

On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec  wrote:
[snip]
> I'll be really sad when gtk2 is totally abolished in Gentoo. :(
> I suppose I'll have to break down and switch to KDE maybe.
>
> In my opinion the upstream gtk developers have gone somewhat bonkers
> with their cartoonish changes to the look, feel and generally
> un-intuitive user interface.  The new file selector is irritating to use
> despite getting all the old behaviour settings I know of set, the lack
> of the ability to paste a path into it, forcing you to navigate
> directory by directory, and other BS behaviour...

What's wrong with Ctrl-L to open the "Enter location or URL" text
field and pasting the path there?

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Austin English]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/27/2016 09:21 AM, Mart Raudsepp wrote:
> Hello,
>
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
>
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
>
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
>
> Historically, for very good reasons in past and present GNOME team
> members opinion, USE=gtk has always meant to mean to provide support
> for gtk in general, not any particular version. This is opposite to
> what the Qt team has been doing.

What are those good reasons? Every discussion I've seen about this has
Gnome team saying "There are good reasons" without actually _listing_
them. It sounds like the 'good reason' is that people will get some sort
of gtk support no matter what the application supports, but as had been
said already, that isn't exactly a good thing.

AFAICT, this only serves to cause more confusion. A user setting USE=gtk
may expect gtk2 (because that's what it provided in the past), then all
of a sudden has their system pulled out from underneath them to get gtk3.

Ignoring that past issue, there's no discussion here of how the
transition to gtk4 would be handled in a situation where gtk=gtk-any,
but not all applications support gtk4. What will you do then, introduce
a force-gtk3 USE flag to work around the problem in the future?

No one is saying cleaning up the mess will be easy, but it is needed to
prevent user confusion and prevent further problems down the road.

I have no political feelings towards gtk2/3, for the record :).

- -Austin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXSHKKAAoJEACzKVe5S/Ph3hcQAKpAHkn3SRrfG4ZiU7Hd2qj8
yOE2lvWAzPUN922uZbhzf1un1GG+xlQ5mgtPoWI/d6LQEjzOIL94gD1GjsEzLn8+
pGjD+dZfyzz1QdyQ6YOm6mbvVrQpNY8m8eZ++Evf7q/zdsYbvmyEu+dnIrcCz6SO
EkCLwKt5BlyyGUiMcgNRoy+SmBbk31YV9VeIkmhv0FC05O1gPZMzaDhCMwPYW8JK
7IBeMn1C2oTno9Pd6C360+xjPsIdtVvUJ9dfebLu1DfOPD+qBzfY69jtMsOFyOIM
xf7L/o/Lmr0JvFqmtX0G3OooglxiMC8yzj7xhuNADDERh1mjVWo0ktfPKOCVRFU9
LqeJr4uZneuezXbP1LVb44vGWyiMSCZYuM7sXfVSn1dbtBvgb932A7sud1NSTVmQ
TMyLUAGVNXlOXNbMcFPnXBcMLzy/fTNYDclpc8cwHD5Pyq8WR0MybS141jD7Z55F
J1RRSPETKyq8WxSwCNjDYgguJmY0HrFFlfa7P45EHzhKktcPacCE3bOg5joNPsTM
aMREjMtb4zG0tWRdJ4JaSGFCHcrK709I/ED0v1qr378Rgu8+OJxU+f/IWFh7NRZY
auefisbLU9LRcMQUbn07t2GQTREFjgahM/8a2WhcQgV7qIc01ih6I2o7jQgO6SfN
ob/dqOl8/yVzbfAVA14m
=dD1I
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Patrick Lauer]

On 05/27/2016 04:21 PM, Mart Raudsepp wrote:
> Hello,
>
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
>
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
>
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
Looking at the gtk-apps I use ...


Firefox with gtk3 is TOFU. UI elements are invisible, Scrollbars are
broken, etc.
The font rendering is hilariously wrong, even more so than gtk2. I'd
call this "late alpha" if I'm in a good mood.
("wrong" ? well, everything else at fontsize ~8-9 is the same as gtk2 at
fontsize 24, and gtk3 at ~32. Which means that the defaults are
literally unreadable because text ends up 3 pixels high. I have no idea
why everything else understands config, and special snowflake has to
guess instead...)

Thunderbird ... oy vey. The new new theme in 45.1 after a new theme in
45 repeats all the problems with font rendering, and it's "flat" because
who needs to know where UI elements are, where they end, or if they are
active/usable. Also fun that *now* it is 'catching up' with the UI
stupidity of Android-4, which is abandoned. Change to have change ... :\

I think Chromium uses their own layer of madness on top of gtk.
Chromium-51 has a tiny URL bar which is not resizable (sizing only
affects the html viewport). It is proportionally smaller than
Chromium-50, so I guess they switched to gtk3 too.


All in all: GTK+-3 looks substantially worse, has wrong font rendering
(which gtk2 already got wrong), and I consider it a strict downgrade
from gtk2. So where I can, when I can, I will aim to keep gtk2 until I
can switch to something that isn't dead upstream or just braindead.

So while I understand that you don't want to support a toolkit that has
no or little support (like qt4, btw, which is abandoned but only about
half the things have been ported to qt5) ... as long as it's not at
feature-parity some users like me will fight for the option to have
usable software. And that means, for now, requiring gtk2 / gtk3 useflags
to allow us to choose the correct version where possible. I don't care
much how it is exposed, I don't consider "force-gtk2" worse than "gtk2"
or "partial-sanity". But it'll take a lot of improvement before you can
consider deprecating gtk2, and crude methods like the suggested
package.use.mask will motivate me to fix the mistake by reverting it.

(I remember fighting with ssuominen over guvcview, he always tried to
remove the last gtk2 version of it, I readded it because otherwise
there's a whole pile of new bad dependencies, he'd remove it again, I
readded it, lots of fun. Let's not play that game too much please ...)


Thanks,

Patrick

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[William Hubbs]

On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote:
> Hello,
> 
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
> 
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
> 
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.

(qa hat in place)

There is a qa policy about this. All packages in the tree should
move away from the non-versioned gtk use flag to versioned use flags,
like the ones the qt team uses [1] [2].

This seems to be the best compromise. It allows the maintainers of the
packages to decide which toolkit they want to support. If there is too
much work involved in maintaining a package with dual support, don't do
the work, just make it support the appropriate toolkit version.

I have not seen any reason why something like this couldn't work. After
all, it seems to work for the qt team.

William

[1]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
[2]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Ian Stakenvicius]

On 27/05/16 10:21 AM, Mart Raudsepp wrote:
> [ Snip! ]


Agree on all other portions above; its the Applications part below
that is most contentious though and is also what I care most about:


> * Applications may only use a gtk2 based stack or gtk3 based stack in a
> given version/revision. gtk3 is strongly preferred when it is deemed to
> not have any regressions compared to gtk2 build, but the choice is
> ultimately with the maintainer. Once the application converts to using
> gtk3 in our distribution, it should try hard to stay that way in
> upcoming versions as well.
> 
> * Some exceptions to the above may exist under heavy consideration,
> especially in cases where the toolkit usage is complex and may have
> some issues for some, but in general gtk3 support is deemed good by
> upstream. Most notable here would be browsers like firefox and
> chromium, which are using gtk dependency more for emulating the theme
> it uses, rather than using it as its real toolkit. If such exceptions
> are allowed, the USE flag naming here must be consistent amongst the
> exceptions. My proposal would be USE=force-gtk2 then, as I have no
> better ideas without stomping on the USE=gtk{2,3} historical meaning.


Personally I don't see an issue at all with maintainers of
applications allowing a package to be built against gtk2 instead of
gtk3 even if gtk3 is deemed "good enough" by upstream.  There are a
number of end-users (myself included) that prefer the gtk2 experience
over gtk3, and so to me I'd like to not limit what app maintainers
want to do, but rather just limit the way they can do it.  The
'force-gtk2' flag to me seems appropriate for this, especially since
this type of choice should explicitly not be linked to a flag in any
profiles (and i believe both gtk2 and gtk3 exist in some profile or
another).


> When arguing in favor of supporting gtk2 builds more for apps, please
> do keep in mind that gtk2 really is pretty much dead. And no, MATE,
> XFCE and others are NOT continuing its support; they are just slow in
> fully converting to gtk3, but they are doing so and I expect both of
> those to be fully done this year, around autumn.
> If the issue is political or just a general gnome3 or gtk3 hate, then I
> would ask you to keep your political opinions or hate outside this
> thread and go contemplate on more important life issues.
> If the issue is lack of themes, then I would like you to help package
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
> themes shouldn't be breaking anymore beyond this point, theoretically.
> And gtk3 theme packages should pretty much just be CSS files and some
> metadata. Though we have yet to get over that bumpy thing yet (a main
> reason gtk3.20 isn't in main tree yet).


As to the death of gtk2, well, despite firefox officially adopting
gtk3 as the default in 46.0 there's still a lot of open bugs, some of
which have been around for years, and the other mozilla products have
barely tried to port their UIs over.  I expect it will be 2018 at
least before mozilla doesn't officially need gtk2 anymore.  Dead
upstream or not, I expect there will still be consumers of gtk2 for a
few years yet.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 2/2] pym/portage/util/locale.py: add a C module to help check locale

[Brian Dolbec]

On Fri, 27 May 2016 10:40:46 -0400
"Anthony G. Basile"  wrote:

> On 5/23/16 10:25 AM, Michał Górny wrote:
> > On Mon, 23 May 2016 08:08:18 -0400
> > "Anthony G. Basile"  wrote:
> >   
> >> On 5/23/16 2:44 AM, Michał Górny wrote:  
> >>> On Sun, 22 May 2016 13:04:40 -0400
> >>> "Anthony G. Basile"  wrote:
> >>> 

> > 
> > 1. I think old versions of Python did not support named properties
> > in sys.version_info, back when Portage was written.  
> 
> I didn't need this because I found _unicode_decode() which does what I
> want.  Thanks for the clue.  BTW, why are those functions/classes in
> pym/portage/__init__.py?  All that code in there is just cluttering
> __init__.py.  Shouldn't that stuff be pulled into a separate file and
> imported cleanly?
> 

Yes, there is generally far too much code in many of the __init__.py's.
There are many with over 1K LOC

-- 
Brian Dolbec 

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Brian Dolbec]

On Fri, 27 May 2016 17:21:06 +0300
Mart Raudsepp  wrote:

> Hello,
> 
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle
> issues with their gtk3 port, or support both, with some of our
> userbase clinging to gtk2 for dubious political or aesthetical
> reasons.
> 
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
> 
> My highly biased essay aside, we need to finally globally agree on
> what we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do
> we name the USE flag.
> 
> Historically, for very good reasons in past and present GNOME team
> members opinion, USE=gtk has always meant to mean to provide support
> for gtk in general, not any particular version. This is opposite to
> what the Qt team has been doing.
> In our opinion, in a perfect world, only USE=gtk would exist, and no
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
> perfect world, we have made use of USE=gtk3 for providing gtk3 support
> from library packages to mean to build gtk3 support. Sadly that
> overloads USE=gtk in many cases to then mean to build gtk2 support.
> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not
> live in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
> split up into separate SLOTs. In some cases it might have been meant
> as a transitional thing, until all consumers are ported to gtk3, but
> it has been lingering on due to consumer apps not being ported or we
> haven't yet noticed to remove the gtk2 support in the library package.
> 
> Now these are libraries, and despite some USE flag confusion, it's not
> a huge issue, because consumers are USE depending on what is required.
> This all is written out in
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
> since the GNOME project pages moving to wiki, and also long before
> that in GuideXML era, and we've pointed people towards that.
> 
> And then we have applications that support building against either
> gtk2 or gtk3.
> In most cases, any requests to provide the choice to have an
> application use gtk2 instead of gtk3 gets instantly marked as
> duplicate of https://bugs.gentoo.org/374057 but in some cases the
> maintainer has chosen to provide this choice for now, and here is the
> problem - we don't really have a good agreed on way to name such a
> choice in USE flags, if we should provide such a choice at all.
> 
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
> USE=gtk and it being problematic. The GNOME team shall probably veto
> such USE flag usage if we are deemed to have such an authority as gtk+
> maintainers, unless we rework it all in expectations of gtk2 corpse
> being carried around for a decade as well... I have quite a few bugs
> against packages to file already for this, afair.
> 
> I kind of like what firefox did there, going in the spirit of the
> force-openrc flag we have for avoiding systemd dependency, even if it
> currently means worse user experience. So if we provide such a choice
> for apps at all, I might agree to USE=force-gtk2 for this for apps.
> And we would like to eventually (or immediately) p.use.mask this and
> once it's 2017 and gtk2 truly dead and buried and full of known
> security holes, get rid of it again.
> But this highlighted the inconsistency we are having, ending up with
> QA initiated bug https://bugs.gentoo.org/581662
> 
> tl;dr and my proposal would be the following:
> 
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.
> 
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until
> gtk2 support can be dropped and it will only ship gtk3 

Re: [gentoo-portage-dev] [PATCH 2/2] pym/portage/util/locale.py: add a C module to help check locale

[Anthony G. Basile]

On 5/23/16 10:25 AM, Michał Górny wrote:
> On Mon, 23 May 2016 08:08:18 -0400
> "Anthony G. Basile"  wrote:
> 
>> On 5/23/16 2:44 AM, Michał Górny wrote:
>>> On Sun, 22 May 2016 13:04:40 -0400
>>> "Anthony G. Basile"  wrote:
>>>   
 From: "Anthony G. Basile" 

 The current method to check for a sane system locale is to use python's
 ctypes.util.find_library() to construct a full library path to the
 system libc.so and pass that path to ctypes.CDLL() so we can call
 toupper() and tolower() directly.  However, this gets bogged down in
 implementation details and fails with musl.

 We work around this design flaw in ctypes with a small python module
 written in C which provides thin wrappers to toupper() and tolower(),
 and only fall back on the current ctypes-based check when this module
 is not available.

 This has been tested on glibc, uClibc and musl systems.

 X-Gentoo-bug: 571444
 X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444

 Signed-off-by: Anthony G. Basile 
 ---
  pym/portage/util/locale.py   | 32 ++-
  setup.py |  6 ++-
  src/portage_c_convert_case.c | 94 
 
  3 files changed, 121 insertions(+), 11 deletions(-)
  create mode 100644 src/portage_c_convert_case.c

 diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
 index 2a15ea1..85ddd2b 100644
 --- a/pym/portage/util/locale.py
 +++ b/pym/portage/util/locale.py
 @@ -11,6 +11,7 @@ from __future__ import absolute_import, unicode_literals
  import locale
  import logging
  import os
 +import sys
  import textwrap
  import traceback
  
 @@ -34,18 +35,26 @@ def _check_locale(silent):
"""
The inner locale check function.
"""
 -
 -  libc_fn = find_library("c")
 -  if libc_fn is None:
 -  return None
 -  libc = LoadLibrary(libc_fn)
 -  if libc is None:
 -  return None
 +  try:
 +  from portage_c_convert_case import _c_toupper, _c_tolower
 +  libc_tolower = _c_tolower
 +  libc_toupper = _c_toupper  
>>>
>>> Now I'm being picky... but if you named the functions toupper()
>>> and tolower(), you could actually import the whole module as 'libc'
>>> and have less code!  
>>
>> I see what you're saying, and its tempting because its elegant, but I'm
>> afraid of a clash of names.  I've got a bad feeling this will get us
>> into trouble later.
>>
>> Let me play with this and see what happens.
> 
> I don't think this will be problematic since things like this happen
> in Python all the time ;-). And after all, C function names can be
> different than Python function names.

It works fine so my last set of patches adopts this approach.

> 
>>> Also it would be nice to actually make the module more generic. There
>>> are more places where we use CDLL, and all of them could eventually be
>>> supported by the module (unshare() would be much better done in C, for
>>> example).  
>>
>> Yeah I get your point here.  Let me convince myself first.
> 
> I've got a killer argument: right now we hardcode constants from Linux
> headers in the Python code!
> 
> Not that I'm asking you to actually add code for that as well. Just
> rename the module to something more generic like portage.util.libc ;-).

Well you might as well point me in this direction since I'm working on
this now.

> 
 +  except ImportError:
 +  writemsg_level("!!! Unable to import 
 portage_c_convert_case\n!!!\n",
 +  level=logging.WARNING, noiselevel=-1)  
>>>
>>> Do we really want to warn verbosely about this? I think it'd be
>>> a pretty common case for people running the git checkout.  
>>
>> This should stay.  Its good to know that the module is not being
>> imported and silently falling back on the ctypes stuff.
>>
>> 1) its only going to happen in the rare occasion that you're using
>> something like a turkish locale and can't import the module.
> 
> Wrong. This happens before the check is done, so it will be output
> every time Portage is started, also with good locale.

Right I dropped it.

> 
>> 2) people who do a git checkout should add
>> PYTHONPATH=build/lib.linux-x86_64-3.4 to their env to test the module.
>> I can add something to testpath.  Users will have to be instructed to
>> run `./setup build` and then the script shoudl read something like this
>>
>> unamem=$(uname -m)
>>
>> pythonversion=$(python --version 2>&1 | cut -c8-)
>> pythonversion=${pythonversion%\.*}
>>
>> portagedir=$(dirname ${BASH_SOURCE[0]})
>>
>> export PATH="${portagedir}/bin:${PATH}"
>>
>> export
>> PYTHONPATH="${portagedir}/build/lib.linux-${unamem}-${pythonversion}:${portagedir}/pym:${PYTHONPATH:+:}${PYTHONPATH}"
>>

Re: [gentoo-dev] What are eblits?

[konsolebox]

On Fri, May 27, 2016 at 9:28 AM, Kent Fredric  wrote:
> That said, its a very confusing system to get your head around,
> because its *basically* yet another "mixin" system like "inherit", but
> done in bash, which itself is a rather strange language to be doing
> something as complicated as mixins.

This concept is new to me as well, but after seeing the code with `cat
/usr/portage/sys-libs/glibc/glibc-2.17.ebuild` it didn't even take me
5 or 10 minutes to understand it.  I find the implementation safe
enough if used properly.  The core functions also seem stable, besides
some parts which aren't quoted, although commonly normal in ebuilds.
This is all about loading common functions to your ebuilds, and
there's nothing really dangerous in it.

-- 
konsolebox

[gentoo-portage-dev] [PATCH 1/3] pym/portage/util/locale.py: fix decoding for python2 with some locales

[Anthony G. Basile]

From: "Anthony G. Basile" 

When using python2 with some locales, like turkish, chr() is passed values not 
in
range(128) which cannot be decoded as ASCII, thus throwing a UnicodeDecodeError
exception.  We use _unicode_decode() from portage.util to address this.

Signed-off-by: Anthony G. Basile 
---
 pym/portage/util/locale.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
index 2a15ea1..093eb86 100644
--- a/pym/portage/util/locale.py
+++ b/pym/portage/util/locale.py
@@ -15,7 +15,7 @@ import textwrap
 import traceback
 
 import portage
-from portage.util import writemsg_level
+from portage.util import _unicode_decode, writemsg_level
 from portage.util._ctypes import find_library, LoadLibrary
 
 
@@ -62,7 +62,7 @@ def _check_locale(silent):
"as LC_CTYPE in make.conf.")
msg = [l for l in textwrap.wrap(msg, 70)]
msg.append("")
-   chars = lambda l: ''.join(chr(x) for x in l)
+   chars = lambda l: ''.join(_unicode_decode(chr(x)) for x in l)
if uc != ruc:
msg.extend([
"  %s -> %s" % (chars(lc), chars(ruc)),
-- 
2.7.3

[gentoo-portage-dev] [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check locale

[Anthony G. Basile]

From: "Anthony G. Basile" 

The current method to check for a sane system locale is to use python's
ctypes.util.find_library() to construct a full library path to the
system libc.so and pass that path to ctypes.CDLL() so we can call
toupper() and tolower() directly.  However, this gets bogged down in
implementation details and fails with musl.

We work around this design flaw in ctypes with a small python module
written in C which provides thin wrappers to toupper() and tolower(),
and only fall back on the current ctypes-based check when this module
is not available.

This has been tested on glibc, uClibc and musl systems.

X-Gentoo-bug: 571444
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444

Signed-off-by: Anthony G. Basile 
---
 pym/portage/util/locale.py | 16 ++-
 setup.py   |  6 +++-
 src/portage_util_libc.c| 70 ++
 3 files changed, 84 insertions(+), 8 deletions(-)
 create mode 100644 src/portage_util_libc.c

diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
index 093eb86..5b09945 100644
--- a/pym/portage/util/locale.py
+++ b/pym/portage/util/locale.py
@@ -34,13 +34,15 @@ def _check_locale(silent):
"""
The inner locale check function.
"""
-
-   libc_fn = find_library("c")
-   if libc_fn is None:
-   return None
-   libc = LoadLibrary(libc_fn)
-   if libc is None:
-   return None
+   try:
+   from portage.util import libc
+   except ImportError:
+   libc_fn = find_library("c")
+   if libc_fn is None:
+   return None
+   libc = LoadLibrary(libc_fn)
+   if libc is None:
+   return None
 
lc = list(range(ord('a'), ord('z')+1))
uc = list(range(ord('A'), ord('Z')+1))
diff --git a/setup.py b/setup.py
index 25429bc..5ca8156 100755
--- a/setup.py
+++ b/setup.py
@@ -47,7 +47,11 @@ x_scripts = {
 # Dictionary custom modules written in C/C++ here.  The structure is
 #   key   = module name
 #   value = list of C/C++ source code, path relative to top source directory
-x_c_helpers = {}
+x_c_helpers = {
+   'portage.util.libc' : [
+   'src/portage_util_libc.c',
+   ],
+}
 
 class x_build(build):
""" Build command with extra build_man call. """
diff --git a/src/portage_util_libc.c b/src/portage_util_libc.c
new file mode 100644
index 000..00b09c2
--- /dev/null
+++ b/src/portage_util_libc.c
@@ -0,0 +1,70 @@
+/* Copyright 2005-2016 Gentoo Foundation
+ * Distributed under the terms of the GNU General Public License v2
+ */
+
+#include 
+#include 
+#include 
+
+static PyObject * _libc_tolower(PyObject *, PyObject *);
+static PyObject * _libc_toupper(PyObject *, PyObject *);
+
+static PyMethodDef LibcMethods[] = {
+   {"tolower", _libc_tolower, METH_VARARGS, "Convert to lower case using 
system locale."},
+   {"toupper", _libc_toupper, METH_VARARGS, "Convert to upper case using 
system locale."},
+   {NULL, NULL, 0, NULL}
+};
+
+#if PY_MAJOR_VERSION >= 3
+static struct PyModuleDef moduledef = {
+   PyModuleDef_HEAD_INIT,
+   "libc", /* 
m_name */
+   "Module for converting case using the system locale",   /* 
m_doc */
+   -1, /* 
m_size */
+   LibcMethods,/* 
m_methods */
+   NULL,   /* 
m_reload */
+   NULL,   /* 
m_traverse */
+   NULL,   /* 
m_clear */
+   NULL,   /* 
m_free */
+};
+#endif
+
+PyMODINIT_FUNC
+
+#if PY_MAJOR_VERSION >= 3
+PyInit_libc(void)
+{
+   PyObject *m;
+   m = PyModule_Create();
+   return m;
+}
+#else
+initlibc(void)
+{
+   Py_InitModule("libc", LibcMethods);
+}
+#endif
+
+
+static PyObject *
+_libc_tolower(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", tolower(c));
+}
+
+
+static PyObject *
+_libc_toupper(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", toupper(c));
+}
-- 
2.7.3

[gentoo-portage-dev] [PATCH 2/3] setup.py: add stub for building custom modules in C/C++

[Anthony G. Basile]

From: "Anthony G. Basile" 

Currently portage doesn't include any custom modules written in C/C++.
This commit introduces stub code for building such modules in setup.py.

Signed-off-by: Anthony G. Basile 
---
 setup.py | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/setup.py b/setup.py
index 75c4bcb..25429bc 100755
--- a/setup.py
+++ b/setup.py
@@ -4,7 +4,7 @@
 
 from __future__ import print_function
 
-from distutils.core import setup, Command
+from distutils.core import setup, Command, Extension
 from distutils.command.build import build
 from distutils.command.build_scripts import build_scripts
 from distutils.command.clean import clean
@@ -30,6 +30,9 @@ import sys
 # TODO:
 # - smarter rebuilds of docs w/ 'install_docbook' and 'install_epydoc'.
 
+# Dictionary of scripts.  The structure is
+#   key   = location in filesystem to install the scripts
+#   value = list of scripts, path relative to top source directory
 x_scripts = {
'bin': [
'bin/ebuild', 'bin/egencache', 'bin/emerge', 
'bin/emerge-webrsync',
@@ -41,6 +44,10 @@ x_scripts = {
],
 }
 
+# Dictionary custom modules written in C/C++ here.  The structure is
+#   key   = module name
+#   value = list of C/C++ source code, path relative to top source directory
+x_c_helpers = {}
 
 class x_build(build):
""" Build command with extra build_man call. """
@@ -636,6 +643,8 @@ setup(
['$sysconfdir/portage/repo.postsync.d', 
['cnf/repo.postsync.d/example']],
],
 
+   ext_modules = [Extension(name=n, sources=m) for n, m in 
x_c_helpers.items()],
+
cmdclass = {
'build': x_build,
'build_man': build_man,
-- 
2.7.3

[gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Hello,

Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
upstream, many applications still support only gtk2, have subtle issues
with their gtk3 port, or support both, with some of our userbase
clinging to gtk2 for dubious political or aesthetical reasons.

For the latter cases, despite GNOME teams policy and strong preference
on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
working as good as gtk2), some cases exist where the maintainers want
to provide such choice. In some cases it is understandable for a short
while during transition, e.g firefox. In other cases, it is purely for
the sake of providing the choice of working with a deprecated toolkit,
apparently.

My highly biased essay aside, we need to finally globally agree on what
we do in this situation. If we allow this choice at all, only for
special cases, or widespread. And if this choice is provided, how do we
name the USE flag.

Historically, for very good reasons in past and present GNOME team
members opinion, USE=gtk has always meant to mean to provide support
for gtk in general, not any particular version. This is opposite to
what the Qt team has been doing.
In our opinion, in a perfect world, only USE=gtk would exist, and no
USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
perfect world, we have made use of USE=gtk3 for providing gtk3 support
from library packages to mean to build gtk3 support. Sadly that
overloads USE=gtk in many cases to then mean to build gtk2 support.
This would ideally not be needed, as the package would instead be
slotted and parallel installable for gtk2 and gtk3, which should be
theoretically possible in all cases, because gtk2 and gtk3 may not live
in the same process, so not the same library either.
Due to some packages needing too much manpower effort to do such a
split, USE flags are used in such a case.
Good examples of such slot splits existing are for example the
libappindicator stack. This used to be the case with almost all GNOME
libraries as well, but most of them only provide gtk3 now, as gtk2 is,
well, dead.
Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
split up into separate SLOTs. In some cases it might have been meant as
a transitional thing, until all consumers are ported to gtk3, but it
has been lingering on due to consumer apps not being ported or we
haven't yet noticed to remove the gtk2 support in the library package.

Now these are libraries, and despite some USE flag confusion, it's not
a huge issue, because consumers are USE depending on what is required.
This all is written out in
https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
since the GNOME project pages moving to wiki, and also long before that
in GuideXML era, and we've pointed people towards that.

And then we have applications that support building against either gtk2
or gtk3.
In most cases, any requests to provide the choice to have an
application use gtk2 instead of gtk3 gets instantly marked as duplicate
of https://bugs.gentoo.org/374057 but in some cases the maintainer has
chosen to provide this choice for now, and here is the problem - we
don't really have a good agreed on way to name such a choice in USE
flags, if we should provide such a choice at all.

USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
USE=gtk and it being problematic. The GNOME team shall probably veto
such USE flag usage if we are deemed to have such an authority as gtk+
maintainers, unless we rework it all in expectations of gtk2 corpse
being carried around for a decade as well... I have quite a few bugs
against packages to file already for this, afair.

I kind of like what firefox did there, going in the spirit of the
force-openrc flag we have for avoiding systemd dependency, even if it
currently means worse user experience. So if we provide such a choice
for apps at all, I might agree to USE=force-gtk2 for this for apps. And
we would like to eventually (or immediately) p.use.mask this and once
it's 2017 and gtk2 truly dead and buried and full of known security
holes, get rid of it again.
But this highlighted the inconsistency we are having, ending up with QA
initiated bug https://bugs.gentoo.org/581662

tl;dr and my proposal would be the following:

* USE=gtk means providing support for GTK+; because we don't have a
USE=gui, this also means "provide a GUI version built on top of gtk+"
for packages where a GUI is optional.

* USE=gtk3 may be used only for controlling extra libraries to be
shipped for gtk3 support (the extra library file will link to gtk3),
_in addition_ to gtk2 version. This is a temporarily measure until gtk2
support can be dropped and it will only ship gtk3 version of the
library. This gives a flag to be able to USE depend on by gtk3 apps.
This leaves the question about the opposite open, however. This is why
USE=gtk2 would be bad for apps, maybe we need to use it for this
library case, when gtk3 version is 

Re: [gentoo-dev] What are eblits?

[Ciaran McCreesh]

On Fri, 27 May 2016 00:28:35 +0200
rindeal  wrote:
> 1) what are they?

A horrible QA violation.

> 2) why are they used?

Because some people like to feel special...

-- 
Ciaran McCreesh

[gentoo-portage-dev] New meeting

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Brian approached me a while back saying we need a new meeting. So
let's do that. Sorry for taking so long.

So set your availability[0], and add your items to the agenda[1].


[0]  
[1]  
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXSAlcAAoJENQqWdRUGk8BXxIQAPLvut/67z3uzKqHhP0aE3+R
YIPymDjKWwU6NYbRNDIhhhGNCJnDuHAjX6oEay17Li0yxlqajKqcZwoxDLjlmHyL
+oZh/oIHEesbjFY2F3awiyWlT2NYfkqvTqaliejB8iy21t1qHRFayvSUhTvh8VZm
6i6Z4zYbbFz7hU2c1utdMlfvBx0sPUS5bsKluJYexsTyLp6K8KYfx8WDOJ2efTdv
aoSrhoyEB6hMFmEUxQJdbdnSKhvNoMCnlE+fBN6/xpx3p/FnbBzQ9tNBZqhWWIwL
iQz1WyHhn+uhXyoad+4795exBb+YQen32djIyISAcCH4+kPdiWF7+XQSMZvyexFf
smZnZWwQYIr5prxqIit63yGyICFaLjqMIeas5MA0v6M0SKsAZnsRxj66eE5e6Jut
oaj9Od3RWyjuHuhsnqu2QbSyRe5DsWfKVwC8YGe64oRzFHgc2wlSZlTn0QIFtITB
XeOvKMopvHocUSF/UMgdcvmbbXROVzlOpJFB168YeMHINMffzxaGGHkY64Zg6+3o
AgWlL3vWIsBv9v0AlOn+b7ydopP6CqMeEn/ezRpmvAzRyaHpY925MvJg/b9eIh4V
asasfhkm++5ktwN5jR8dmi8d0sE6J8VTi6anLkJwNOudrW28IHIv/PO2LPfCcc5P
a+2LVaqVB0goSFCJ5PoE
=aM7+
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH v2 2/2] Colorize packages in world_sets (bug 583164)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 26/05/16 17:29, Zac Medico wrote:
> Looks good to me. ACK.
Thank you. Pushed as 40cdc1c3f467ac94d3a966777eb6a0907c269550.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXSAZlAAoJENQqWdRUGk8BEOoQAKKrF/Bl/DpEE/7Svd8NgQVv
XJFFW6Da8zeKoJYsms3kAELaRl4UCmxrIPvfrZWpPcX7+CWtwxTf/i35agdCzo+l
u7NlVDjWuHYxydAjN9E5IWi+ds4xUU7xy4i8Vlpcawdv3R3lDmpkv59mfuDa
2ZhwC6oSi8IvqeokblafJNvn7+nvjGxl3qr+6Q2GeJEutrelf7q0/k9qfXldRYMG
PDJdYfUdNCfs9HgnCOud+LRlcAq6Qp17qFnKwQm2ODjGPigvM+87cq7wqiv1iEg0
FwMVvz1LQZGRmRQI7liRGqw5vZ3f5yZEjG0wX1hFoJU5CxsUgAQItHmtKLsjM7Vn
1+Jmi+8C7QV86lIdUJgEdFcvWBZrl1cyYH2vxzs0GZcA5lZ2+ivnMKwyUtrv7714
bvR4W5Rc/Y6laz9eNtvJ3AtIneXm73hGSwGJQbVw66J5GdRMKdXEG/Krr9HPpGdg
E8IR/6AH8r4MHZAGw49TtUzhYmexdazs4auyF05wtLMUdCccVuIY4p/tGCiOpBUL
+jR9RpfZ9LgNcegArzsygAsr8qIQxAm3BTfVajtYKz3whg48xvXmErW7+wZHXvgl
XyQsGTzVnjIPuUswUcR3l4XDikMZJ54+/M+2q/p0LaCZlOiDIYag2d91GCc+jXwm
B7pFObxaargOfPJ9I/nf
=X651
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Mart Raudsepp]

Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas
waltd...@waltdnes.org:
> On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote
> > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds
> > have
> > a good reason to use flags for localization, we introduce a new,
> > non-colliding USE_EXPAND for that. We also ask users to replace
> > LINGUAS
> > with the new flag in their make.conf files. LINGUAS gets the
> > original
> > upstream behavior back, and we eventually discourage it in favor of
> > new
> > INSTALL_MASK features (WiP) [2].

Short of making an exception to LINGUAS in the USE_EXPAND rules, I
think this is the only way.

> 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
> LOCALE_ALLOW="foo bar fubar"
> 
> 6. Integrate localepurge into Portage, and run it post install
> 
>   There are some lazy programmers out there who *DO NOT* respect the
> LINGUAS setting, and splatter files throughout /usr/share/locale/*
> and
> /usr/share/man/* regardless.  That's the reason "localepurge" was
> written in the first place.  Any proposed solution should take that
> problem into consideration, and handle it too.

For both of these cases, I have to point out that e.g
LINGUAS="en et pl"
does not mean "keep only /usr/share/locale/{en,et,pl}/*", it means have
support for only these languages. This means for example that *.desktop
files will have translations in them only for those language. Same for
dconf schema files. Same for many other things. MO Translation files
and manuals aren't the only thing here, especially with intltool (and
many of these intltool features are now part of gettext proper).
In short, LINGUAS affects the content of files too, not only the
existence of files. See any file in /usr/share/applications/ for
example.
I always put "en" as my first in LINGUAS, due to historical abuse of
the first value there, I think e.g mplayer or vlc used to do this.
LINGUAS is an unordered list, but some packages used to took the first
value as meaning the default and switch the UI to that by default,
instead of honoring LC_* variables. Another reason I put "en" there, is
because of IUSE_EXPAND and packages that might not be natively english,
but do have english translations (I think I've seen some french ones
like that :D)


And no, localepurge is not capable of stripping these translations out
of existing files. To my knowledge at least. Though it could be
improved to do so in some cases.


Mart