Re: [gentoo-dev] [PATCH 03/16] gnome2-utils.eclass: remove redundant @USAGE lines
Looks good.
Le vendredi 06 septembre 2019 à 13:40 -0500, bkoh...@gentoo.org a
écrit :
> From: Ben Kohler
>
> Signed-off-by: Ben Kohler
> ---
> eclass/gnome2-utils.eclass | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
> index 06683a7467f..c9765f6fd91 100644
> --- a/eclass/gnome2-utils.eclass
> +++ b/eclass/gnome2-utils.eclass
> @@ -297,7 +297,6 @@ gnome2_schemas_savelist() {
> }
>
> # @FUNCTION: gnome2_schemas_update
> -# @USAGE: gnome2_schemas_update
> # @DESCRIPTION:
> # Updates GSettings schemas.
> # This function should be called from pkg_postinst and pkg_postrm.
> @@ -328,7 +327,6 @@ gnome2_gdk_pixbuf_savelist() {
> }
>
> # @FUNCTION: gnome2_gdk_pixbuf_update
> -# @USAGE: gnome2_gdk_pixbuf_update
> # @DESCRIPTION:
> # Updates gdk-pixbuf loader cache if
> GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
> # This function should be called from pkg_postinst and pkg_postrm.
> @@ -360,7 +358,6 @@ gnome2_gdk_pixbuf_update() {
> }
>
> # @FUNCTION: gnome2_query_immodules_gtk2
> -# @USAGE: gnome2_query_immodules_gtk2
> # @DESCRIPTION:
> # Updates gtk2 immodules/gdk-pixbuf loaders listing.
> gnome2_query_immodules_gtk2() {
> @@ -374,7 +371,6 @@ gnome2_query_immodules_gtk2() {
> }
>
> # @FUNCTION: gnome2_query_immodules_gtk3
> -# @USAGE: gnome2_query_immodules_gtk3
> # @DESCRIPTION:
> # Updates gtk3 immodules/gdk-pixbuf loaders listing.
> gnome2_query_immodules_gtk3() {
> @@ -388,7 +384,6 @@ gnome2_query_immodules_gtk3() {
> }
>
> # @FUNCTION: gnome2_giomodule_cache_update
> -# @USAGE: gnome2_giomodule_cache_update
> # @DESCRIPTION:
> # Updates glib's gio modules cache.
> # This function should be called from pkg_postinst and pkg_postrm.
--
Gilles Dartiguelongue
Gentoo
[gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
Le lundi 01 octobre 2018 à 07:40 +0200, Rémi Cardona a écrit : > Le 01/10/2018 à 00:50, Mike Gilbert a écrit : > > update-desktop-database and update-mime-database are called from > > ROOT in > > pkg functions, so the related dependenices belong in RDEPEND. > > > > Signed-off-by: Mike Gilbert > > As far as the eclass goes, this is correct. But AFAIR, this was > needed > because some packages look for those tools at build time. It was ages > ago so maybe it no longer applies. > > Rémi > A lot of autotools based packages do explicitly search for it. I don't think they fail if it is missing though but a tinderbox run would be welcome. The reason why it is in DEPEND though is that none of these tools are required at runtime. They are needed at postinst and postrm stages which afaik makes them DEPEND on EAPI previous to EAPI 7 and BDEPEND in EAPI 7 if I'm not mistaken. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag
Le lundi 26 mars 2018 à 13:55 +0200, Michał Górny a écrit : > Dnia 26 marca 2018 10:47:04 CEST, Gilles Dartiguelongue <eva@gentoo.o > rg> napisał(a): > > Le lundi 26 février 2018 à 23:24 +0100, Michał Górny a écrit : > > > 'luajit' is used consistently in 25+ packages. Make it a global > > > flag. > > > > Not that I have a strong opinion about it, but wouldn't it be > > better to > > have USE="lua jit" like libpeas does ? Use flags aren't supposed to > > match library names but features so this would seem more correct. > > LuaJIT is a completely separate implementation of Lua, not a feature. > And it's certainly not a feature of libpeas. My bad, I had memories that recent (masked) lua had jit USE flag but it seems I'm mistaken. Feel free to push these changes then. -- Gilles Dartiguelongue <e...@gentoo.org> signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Repoman to warn about suspicious =-dependencies
Le dimanche 04 mars 2018 à 12:37 +0100, Michał Górny a écrit :
> Hi, everyone.
>
> I have proposed a new check for repoman [1] (with a patch at [2])
> that
> would warn developers about suspicious '=' deps.
>
> By suspicious, I mean dependencies '=foo-1.2.3' which are sometimes
> mistakenly used instead of '~foo-1.2.3', and cause some degree of
> mayhem
> when someone revbumps the package (either by preventing people from
> upgrading or causing depgraph breakage).
>
> The check would trigger whenever '='-class dependency is used without
> a revision specified and without the '*' suffix. It would suggest to
> either use '~' operator when any revision is acceptable, or
> explicitly
> specify '-r0' (which is equivalent to no revision specified).
>
> In other words, repoman would complain at:
>
> =dev-foo/bar-1.2.3
>
> but it will be happy if you used:
>
> ~dev-foo/bar-1-2.3
> =dev-foo/bar-1.2.3-r0
>
> I think this cause the trouble of specifying '-r0' rather rarely, and
> it
> will decrease the number of mistakes, also effectively making Gentoo
> development easier. It is somewhat inspired by the handling of slot
> operators (where repoman explicitly asks you to use ':*' instead
> of no operator when the latter would be ambiguous).
>
> What do you think?
Sounds good. The attached script hopefully gives a good indication of
how much packages would be affected. A local run raises about 92
ebuilds.
#!/usr/bin/env python
from portage import isvalidatom, portdb
for cpv in portdb.cpv_all():
deps = portdb.aux_get(cpv, ['DEPEND', 'RDEPEND', 'PDEPEND'])
atoms = set(' '.join(deps).split(' '))
suspicious = []
for atom in atoms:
if not isvalidatom(atom):
continue
# Drop USE-dependencies and slots
atom_simple = atom.split(':')[0].split('[')[0]
if atom[0] == '=' and atom_simple[-1] != '*' and not atom_simple.endswith(''):
suspicious.append(atom)
if suspicious:
print('%s: %s' % (cpv, suspicious))
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag
Le lundi 26 février 2018 à 23:24 +0100, Michał Górny a écrit : > 'luajit' is used consistently in 25+ packages. Make it a global flag. Not that I have a strong opinion about it, but wouldn't it be better to have USE="lua jit" like libpeas does ? Use flags aren't supposed to match library names but features so this would seem more correct. -- Gilles Dartiguelongue <e...@gentoo.org>
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass: gnome2_query_immodules*, use EROOT, #611030
Le samedi 22 avril 2017 à 23:03 +0200, Michał Górny a écrit :
> On sob, 2017-04-22 at 13:43 -0400, Mike Gilbert wrote:
> >
> > On Sat, Apr 22, 2017 at 4:20 AM, Michał Górny <mgo...@gentoo.org>
> > wrote:
> > >
> > > Respect EROOT when running gtk-query-immodules-* tools, alike
> > > other
> > > updaters in the eclass. This ensures that x11-libs/gtk+ installs
> > > correctly when installing to a ROOT.
> >
> > I'm not an expert on this eclass, but it seems like this may be
> > intentional; calling compiled binaries from $ROOT will break for
> > cross-compiles.
> >
> > Is there some package that installs ${CHOST}-gtk-query-immodules-
> > X.0
> > for ROOT == /? I don't have any such binary on my system.
> >
>
> I was thinking about this possibility too but it doesn't look like
> any
> of the remaining code was done like this, nor the GTK+ ebuild which
> calls this function. But I'll wait for the GNOME team to confirm what
> they want.
>
Looking at the ebuilds, it looks like your patch is correct. I honestly
cannot remember why we used EPREFIX and not EROOT.
--
Gilles Dartiguelongue <e...@gentoo.org>
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/7] gnome2-utils.eclass: Make gnome2_icon_cache_update update all themes
Le lundi 17 avril 2017 à 13:07 +0200, Michał Górny a écrit : > Make the gnome2_icon_cache_update function update all icon themes > rather > than depending on gnome2_icon_savelist to select themes to update. > This > makes the function easier to use whenever the developer needs it > explicitly (i.e. knows that themes are installed), while the overhead > of > regenerating multiple caches is neglible. Looks good. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-dev-announce] rsync.gentoo.org rsync modules: gentoo-repo-changelog added, gentoo-x86-portage & gentoo-sec discontinued.
Hello fellow devs, Le dimanche 30 octobre 2016 à 02:54 +, Robin H. Johnson a écrit : > As part of the upcoming change to no longer distribute ChangeLogs in > the > main tree, Infra would like to announce some updates to the rsync > modules. > > 1. > The following legacy modules are hereby discontinued. > - rsync.gentoo.org::gentoo-sec > - rsync.gentoo.org::gentoo-x86-portage > > 'gentoo-sec' was a 2004-era attempt at distributing Gentoo developer > GPG keyrings. There have been no sync attempts recorded on any of the > rsync.gentoo.org nodes in over 2 years, and the material therein all > dates to 2004 only. > > 'gentoo-x86-portage' was the older name of the 'gentoo-portage' > module, > and was maintained as an alias. For the 2016 calender year to date, > there have been only 11 attempts to fetch the legacy name from any of > the rsync.gentoo.org official nodes. > > Community mirrors (rsyncN.CC.gentoo.org) are encouraged to drop the > old > modules at their convenience. > > 2. > Approximately 2016/Nov/01, a new module will be available: > - rsync.gentoo.org::gentoo-repo-changelog > This module will contain the same directory structure as the > repo/gentoo > tree (gentoo-portage module), but will ONLY contain ChangeLog files. > The update schedule may have gaps exceeding 6 hours initially. > > Community mirrors (rsyncN.CC.gentoo.org) can prepare to mirror the > new > module at their convenience. > > 3. > Not sooner than 2016/Nov/15, ChangeLogs will be removed from the > 'gentoo-portage' rsync module. They may or may not still be > referenced > by the thick Manifests. Since this mail went out, I could not find an explanation of how to get the changelogs back with regular emerge --sync over rsync. Searching the wiki raised no answer or links with outdated information. Playing with repos.conf lead nowhere except to complaints that the gentoo-repo-changelog had the same name than gentoo-portage. I tried asking #gentoo-dev but the best answer I was given was to switch to git clone and to generate the changelogs myself. Problem is, I am not always on a dev machine or on a machine that can spare these CPU cycles so it does not seem appropriate. Is there any way to get this back that doesn't involve extra operations over emerge --sync ? -- Gilles Dartiguelongue <e...@gentoo.org> signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News item review: python-exec 2.3 reclaims python* symlinks
Le samedi 21 janvier 2017 à 10:49 +0100, Michał Górny a écrit : > Please review the following news item. It was requested by users. > Preferably I'd like to commit it today. > > -- > > Title: python-exec 2.3 reclaims python* symlinks > Author: Michał Górny <mgo...@gentoo.org> > Content-Type: text/plain > Posted: 2017-01-21 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: Display-If-Installed: > The new versions of python-exec (2.3 and newer) are reclaiming > multiple > Python-related symlinks in /usr/bin, most notably /usr/bin/python*. > This > may result in your package manager reporting file collisions. > > The respective symlinks were previously either unowned and created > dynamically by app-eselect/eselect-python, or installed by it. From > now > on, all Python-related symlinks are installed and handled > by python-exec. This ensures that they respect the python-exec > configuration files and variables consistently with regular Python > packages, and improves their reliability. > > If you are using FEATURES=collision-protect, Portage will reject > the upgrade. If this is the case, please temporarily switch to > FEATURES=protect-owned for the upgrade. > > If you are using FEATURES=protect-owned, Portage will verbosely warn > about the file collisions but will proceed with the upgrade once > determining no replaced files are owned. Please disregard the > warning. > > The potentially colliding files are: > > * /usr/bin/2to3 > * /usr/bin/pydoc > * /usr/bin/python > * /usr/bin/python2 > * /usr/bin/python3 > * /usr/bin/python-config > > For more information on python-exec, please see: > https://wiki.gentoo.org/wiki/Project:Python/python-exec > reads clearly, +1 for having these files owned by a package. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] MANPATH handling in ebuilds
Le mercredi 04 janvier 2017 à 21:12 +, Wolfgang Mueller a écrit : > is definitely not set when executing cron scripts like that. I > deleted all mandoc.db files and waited for them to be regenerated. > Only > the one in /usr/share/man was generated, which means that makewhatis > fell back to the defaults since MANPATH was empty. > > Just as I am composing this mail, the cron script that had `source > /etc/profile' in it before makewhatis ran, and all the databases are > there. > > Bottom line: MANPATH is not available in cron scripts. Could you open a bug report on https://bugzilla.gentoo.org/, I think this could be a very long standing bug. -- Gilles Dartiguelongue <e...@gentoo.org> signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Revisiting version-related tree policies
Le vendredi 04 novembre 2016 à 10:16 +0100, Ulrich Mueller a écrit : > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote: > > > > > On 11/03/2016 05:11 PM, Michał Górny wrote: > > > > > > == Policy changes? == > > > I think that the following new policies could make sense: > > > > > > 1. Revision number must be no longer than : > > > > > You likely mean "no higher than ", longer than would give large > > values > > The wording would be similar to "no longer than 4 digits". > > > > > > > > > 1a. to make <=X-r reliable, > > > 1b. to prevent pathological uses of revision as date. > > > > > Given revision in most cases is incremental (except for some -r100, > > -r200) cases, some structure here is likely good. I take it we're > > talking about devmanual changes in this case for policy? > > Yes, it would be purely devmanual/tree policy. PMS will still mandate > that the package manager can handle arbitrary long versions. > > Looks like using multiples of 100 is best practice if there is > the same PV in different slots. Not sure if we should codify that > somewhere. (If nobody contradicts, this message could be used as > future policy reference, though. :) There was much contradiction when this was "discovered" being used in webkit-gtk ebuilds back when slot 3 was added. However, I don't remember anyone reaching a solution that would be practical keeping only one cat/pn. -- Gilles Dartiguelongue <e...@gentoo.org> signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Step on my toes, please.
Le jeudi 03 novembre 2016 à 11:15 +0100, Jason A. Donenfeld a écrit : > Hey guys, > > Every other day on IRC, I see people arguing about touching each > others packages, despite our policies against it. (Sometimes it's > even > me who's doing the touching!) My instinctive reaction is always, > "can't everybody calm down and be happy somebody is doing your work > for you?" The answer to this question is, of course, that it depends > who the developer is and how competent you are. > > So, nothing new here. I don't want to bikeshed about it. Business as > usual. > > I thought I'd do something loose and informal to rectify the problem. > See my package-policy.txt on my developer space: > > http://dev.gentoo.org/~zx2c4/package-policy.txt > > Do what this says, and everything will be good. I encourage other > developers to post package-policy.txt with the same URL scheme. This > is a nice loose and informal stopgap solution. If others want to > follow suit, great. If not, welp, there mine is. In the not formal but maybe more discoverable spirit, you could put this on your user page/space/whatever on the wiki, I guess. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-dev-announce] Multiple misc. Python packages for grabs
Le samedi 29 octobre 2016 à 23:21 +0200, Michał Górny a écrit : > Hello, > > The Python team is dropping itself from maintainers of the following > packages. As a result, those packages no longer have any maintainer: > > app-admin/supervisor I'll take this at least to fix its default configuration which is annoying me. PS: re-posting as it went to the wrong ml. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] metadata: add vcs tag
Le mercredi 12 octobre 2016 à 09:44 -0700, Robin H. Johnson a écrit : > > [...] > @@ -52,6 +52,8 @@ > > > module|cpe|cran|ctan|freecode|freshmeat|gentoo|github|gitlab|gitoriou > s|google- > code|launchpad|pear|pecl|pypi|rubyforge|rubygems|sourceforge|sourcefo > rge-jp|vim) #REQUIRED> > + > + I am probably nitpicking here but if you expect this element to contain a valid URL, then maybe using #CDATA makes more sense ? -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: profiles/base/, net-misc/modemmanager/
Le samedi 17 septembre 2016 à 13:51 +, Pacho Ramos a écrit : > diff --git a/profiles/base/package.use.mask > b/profiles/base/package.use.mask > index a999e7e..950d71e 100644 > --- a/profiles/base/package.use.mask > +++ b/profiles/base/package.use.mask > @@ -5,6 +5,10 @@ > # This file requires >=portage-2.1.1 > # New entries go on top. > > +# Pacho Ramos <pa...@gentoo.org> (17 Sep 2016) > +# Unmask when needed versions are in the tree > +>=net-misc/modemmanager-1.6.2 mbim qmi > + did you push a bump request with this ? I had delayed the commit due to this issue. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/gstreamer/
Le jeudi 25 février 2016 à 23:02 +, Andreas Hüttel a écrit : > commit: 684b1b89aeb8dd00b56d2296ddb561308e260041 > Author: Andreas K. Hüttel gentoo org> > AuthorDate: Thu Feb 25 22:53:15 2016 + > Commit: Andreas Hüttel gentoo org> > CommitDate: Thu Feb 25 22:58:27 2016 + > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=684b > 1b89 > > media-libs/gstreamer: Clean up XDG environment, bug 567192 Also, a version bump is absolutely not needed here as gstreamer depends on glib which already depends on tools that would be used (and they are not used in this case anyway). -- Gilles Dartiguelongue <e...@gentoo.org> signature.asc Description: This is a digitally signed message part
[gentoo-dev] Eclass assisted multilib dependent cache updates
Hello all, while working on bug #518422, I found out that while eclass calls the relevant cache updates it has no idea whether or not it is called in a multilib context or not. Imho, this leads to avoidable human errors where one thinks eclass will take care of lib dependent caches, which it does, but not for all enabled ABIs which could lead to reduced functionality for non-native ABIs. While it seems reasonable to call multilib_foreach_abi gnome2_pkg_postinst for multilib enabled ebuilds, it is still not ideal as it will call a lot of functions for no good reason. On the other hand, checking environment variable set by multilib eclasses does not seem like a robust solution. Is there any reasonable way to make phase functions aware of if they are running in a multilib enabled ebuild to adjust their behavior ? -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [RFC] name of smartcard support USE flag
I was trying to cleanup my local USE flag settings and stumbled on the following three: smartcard, pcsc-lite and pkcs11. Knowing all 3 are related, I greped use.local.desc to see what each meant for different packages. To sum up what I found: * pcsc-lite is basically: enable smartcard support through sys- apps/pcsc-lite * pkcs11: enabled PKCS#11 (smartcard) via $pkg These look like the same thing to me so I propose we merge them all into USE=smartcard as this is the feature being enabled, not the lib or the standard being used to access the hardware if any. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] name of smartcard support USE flag
Le dimanche 13 décembre 2015 à 18:25 +0200, Alon Bar-Lev a écrit : > On 13 December 2015 at 18:20, Gilles Dartiguelongue <e...@gentoo.org> > wrote: > > > > I was trying to cleanup my local USE flag settings and stumbled on > > the > > following three: smartcard, pcsc-lite and pkcs11. > > > > Knowing all 3 are related, I greped use.local.desc to see what each > > meant for different packages. To sum up what I found: > > * pcsc-lite is basically: enable smartcard support through > > sys- > > apps/pcsc-lite > > * pkcs11: enabled PKCS#11 (smartcard) via $pkg > > > > These look like the same thing to me so I propose we merge them all > > into USE=smartcard as this is the feature being enabled, not the > > lib or > > the standard being used to access the hardware if any. > > pcsc-lite and PKCS#11 interfaces are both related to smartcards but > different unrelated interfaces. I am unsure merging them will serve > the purpose for applications that are capable of supporting more than > one interface. > also, please notice that PKCS#11 is not all about smartcards, but an > interface to any cryptographic hardware. I agree with your points, my point is that it seems most of the time, both use flags are used in place of smartcard (or another name if this one does not fit in your opinion). According to local description, app-mobilephone/gnoki, net- libs/libosmocore and net-misc/rdesktop at least should be using USE=smartcard instead of USE=pcsc-lite -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-cpp/gtkglextmm/, dev-cpp/gtkglextmm/files/
Le vendredi 11 décembre 2015 à 12:17 +, Andrew Savchenko a écrit :
> commit: fcc5f0fe910ec73b41adf3120255571baf896d4c
> Author: Andrew Savchenko gentoo org>
> AuthorDate: Fri Dec 11 12:17:20 2015 +
> Commit: Andrew Savchenko gentoo org>
> CommitDate: Fri Dec 11 12:17:20 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fcc5
> f0fe
>
> dev-cpp/gtkglextmm: fix bug 552686
>
> Fix underquoted aclocal definition.
>
> Package-Manager: portage-2.2.26
> Signed-off-by: Andrew Savchenko gentoo.org>
>
> .../files/gtkglextmm-1.2.0-aclocal.patch | 11 ++
> dev-cpp/gtkglextmm/gtkglextmm-1.2.0-r2.ebuild | 46
> ++
> 2 files changed, 57 insertions(+)
>
> diff --git a/dev-cpp/gtkglextmm/files/gtkglextmm-1.2.0-aclocal.patch
> b/dev-cpp/gtkglextmm/files/gtkglextmm-1.2.0-aclocal.patch
> new file mode 100644
> index 000..32fa489
> --- /dev/null
> +++ b/dev-cpp/gtkglextmm/files/gtkglextmm-1.2.0-aclocal.patch
> @@ -0,0 +1,11 @@
> +--- gtkglextmm-1.2.0/m4macros/gtkglextmm.m4.orig 2004-05-18
> 10:29:34.0 +0400
> gtkglextmm-1.2.0/m4macros/gtkglextmm.m4 2015-08-07
> 17:02:42.324065008 +0300
> +@@ -222,7 +222,7 @@
> + dnl AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD([ACTION-IF-SUPPORTED [,
> ACTION-IF-NOT-SUPPORTED]])
> + dnl Checks whether gtkglextmm supports multihead.
> + dnl
> +-AC_DEFUN(AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD,
> ++AC_DEFUN([AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD],
> + [ AC_LANG_SAVE
> + AC_LANG_CPLUSPLUS
> + AC_CACHE_CHECK([whether gtkglextmm supports multihead],
>
> diff --git a/dev-cpp/gtkglextmm/gtkglextmm-1.2.0-r2.ebuild b/dev-
> cpp/gtkglextmm/gtkglextmm-1.2.0-r2.ebuild
> new file mode 100644
> index 000..504827e
> --- /dev/null
> +++ b/dev-cpp/gtkglextmm/gtkglextmm-1.2.0-r2.ebuild
> @@ -0,0 +1,46 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=5
> +GCONF_DEBUG="yes"
> +
> +inherit eutils gnome2
> +
> +DESCRIPTION="C++ bindings for gtkglext"
> +HOMEPAGE="https://projects.gnome.org/gtkglext/;
> +SRC_URI="mirror://sourceforge/gtkglext/${P}.tar.bz2"
> +
> +KEYWORDS="~amd64 ~ppc ~x86"
> +IUSE="doc"
> +SLOT="1.0"
> +LICENSE="GPL-2 LGPL-2.1"
> +
> +RDEPEND="
> + >=x11-libs/gtkglext-1
> + >=dev-libs/libsigc++-2.0
> + >=dev-cpp/glibmm-2.4:2
> + >=dev-cpp/gtkmm-2.4:2.4
> + virtual/opengl
> +"
> +DEPEND="${RDEPEND}
> + virtual/pkgconfig"
> +
> +src_prepare() {
> + # fix underquoted definition, bug 552686
> + epatch "${FILESDIR}/${P}-aclocal.patch"
> +
> + # Remove docs from SUBDIRS so that docs are not installed,
> as
> + # we handle it in src_install.
> + sed -i -e 's|^\(SUBDIRS =.*\)docs\(.*\)|\1\2|' Makefile.in
> || \
> + die "sed Makefile.in failed"
> +
> + gnome2_src_prepare
> +}
> +
> +src_install() {
> + gnome2_src_install
> + if use doc; then
> + dohtml -r docs/reference/html/*
> + fi
> +}
Why a revbump for this, it appears to be a build-time fix only. Also it
appears to be missing an autools inherit and eautoreconf call.
--
Gilles Dartiguelongue <e...@gentoo.org>
Gentoo
Re: [gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
Hello all, just a heads up that these eclass were slightly enhanced and pushed to the tree. gnome2.eclass and gstreamer.eclass are now using it. If you need to do any kind of hackery with XDG_* environment variable or are using fdo-mime.eclass, you might want to update to xdg*.eclass. -- Gilles Dartiguelongue <e...@gentoo.org> Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] xdg.eclass: break dependency loop with glib and utility packages
Hello all,
making gnome2.eclass depend on xdg.eclass has the unfortunate
consequence of having xdg utility package in the dependency loop of
glib which uses gnome2.eclass for various features (such as gsettings
schema compilation).
Since there is no other need that I know of to make these dependencies
optional for xdg.eclass, I am proposing to have them skipped for glib
only.
This issue currently breaks stage generation.
--
Gilles Dartiguelongue <e...@gentoo.org>
Gentoo
From 905366a8a5a048a968df485223d47dfe1e50778b Mon Sep 17 00:00:00 2001
From: Gilles Dartiguelongue <e...@gentoo.org>
Date: Wed, 25 Nov 2015 13:15:51 +0100
Subject: [PATCH] xdg.eclass: break dependency loop due to XDG tools using glib
---
eclass/xdg.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/xdg.eclass b/eclass/xdg.eclass
index 2ad0ada..9f10932 100644
--- a/eclass/xdg.eclass
+++ b/eclass/xdg.eclass
@@ -21,10 +21,13 @@ case "${EAPI:-0}" in
*) die "EAPI=${EAPI} is not supported" ;;
esac
+# Avoid dependency loop as both depend on glib-2
+if [[ ${CATEGORY}/${P} != dev-libs/glib-2.* ]] ; then
DEPEND="
dev-util/desktop-file-utils
x11-misc/shared-mime-info
"
+fi
# @FUNCTION: xdg_src_prepare
# @DESCRIPTION:
--
2.6.3
[gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
This is an attempt to fix bug #208047 [1] and bug #444568 [2]
Current fdo-mime eclass is often not used when it should be. I suppose
this is partly because one has to think too much about whether it is
needed or not and what to do with the functions.
The proposed solution is to not have to worry about it and just inherit
it when you have any kind of XDG specifications support and let the
exported phases do their job in a similar fashion to the gnome
eclasses.
For now, this covers .desktop and shared mime-info files and creating
base directory for packages that rely on it one way or another.
This helps solve problems like bug #545128 [3] and others that have
been covered by previous work resulting in gnome2_environment_reset
function and similar in other eclasses (cmake-utils, gstreamer, kde4
-base, mono, mono-env, qt4-*).
[1] [Bug 208047] fdo-mime.eclass should depend on desktop-file-utils
https://bugs.gentoo.org/show_bug.cgi?id=208047
[2] [Bug 444568] [Future EAPI] Export XDG_* variables in ebuild
environment
https://bugs.gentoo.org/show_bug.cgi?id=444568
[3] [Bug 545128] media-sound/pulseaudio-6.0 XDG_RUNTIME_DIR
(/run/user/1000) is not owned by us (uid 0)
https://bugs.gentoo.org/show_bug.cgi?id=545128
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xdg.eclass
# @MAINTAINER:
# freedesktop-b...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue e...@gentoo.org
# @BLURB: Provides phases for XDG compliant packages.
# @DESCRIPTION:
# Utility eclass to update the desktop and shared mime info as laid
# out in the freedesktop specs implementations
inherit xdg-utils
case ${EAPI:-0} in
4|5)
EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst pkg_postrm
;;
*) die EAPI=${EAPI} is not supported ;;
esac
DEPEND=
dev-util/desktop-file-utils
x11-misc/shared-mime-info
# @FUNCTION: xdg_src_prepare
# @DESCRIPTION:
# Prepare sources to work with XDG standards.
xdg_src_prepare() {
# Prepare XDG base directories
export XDG_DATA_HOME=${T}/.local/share
export XDG_CONFIG_HOME=${T}/.config
export XDG_CACHE_HOME=${T}/.cache
export XDG_RUNTIME_DIR=${T}/run
mkdir -p ${XDG_DATA_HOME} ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} \
${XDG_RUNTIME_DIR}
# This directory needs to be owned by the user, and chmod 0700
# http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
chmod 0700 ${XDG_RUNTIME_DIR}
}
# @FUNCTION: xdg_pkg_preinst
# @DESCRIPTION:
# Finds .desktop and mime info files for later handling in pkg_postinst
xdg_pkg_preinst() {
xdg_desktopfiles_savelist
xdg_mimeinfo_savelist
}
# @FUNCTION: xdg_pkg_postinst
# @DESCRIPTION:
# Handle desktop and mime info database updates.
xdg_pkg_postinst() {
xdg_desktop_database_update
xdg_mimeinfo_database_update
}
# @FUNCTION: xdg_pkg_postrm
# @DESCRIPTION:
# Handle desktop and mime info database updates.
xdg_pkg_postrm() {
xdg_desktop_database_update
xdg_mimeinfo_database_update
}
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: xdg-utils.eclass
# @MAINTAINER:
# gn...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue e...@gentoo.org
# @BLURB: Auxiliary functions commonly used by XDG compliant packages.
# @DESCRIPTION:
# This eclass provides a set of auxiliary functions needed by most XDG
# compliant packages.
# It provides XDG stack related functions such as:
# * XDG .desktop files cache management
# * XDG mime information database management
case ${EAPI:-0} in
4|5) ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @ECLASS-VARIABLE: DESKTOP_DATABASE_UPDATE_BIN
# @INTERNAL
# @DESCRIPTION:
# Path to update-desktop-database
: ${DESKTOP_DATABASE_UPDATE_BIN:=/usr/bin/update-desktop-database}
# @ECLASS-VARIABLE: DESKTOP_DATABASE_DIR
# @INTERNAL
# @DESCRIPTION:
# Directory where .desktop files database is stored
: ${DESKTOP_DATABASE_DIR=/usr/share/applications}
# @ECLASS-VARIABLE: MIMEINFO_DATABASE_UPDATE_BIN
# @INTERNAL
# @DESCRIPTION:
# Path to update-desktop-database
: ${MIMEINFO_DATABASE_UPDATE_BIN:=/usr/bin/update-mime-database}
# @ECLASS-VARIABLE: MIMEINFO_DATABASE_DIR
# @INTERNAL
# @DESCRIPTION:
# Directory where .desktop files database is stored
: ${MIMEINFO_DATABASE_DIR:=/usr/share/mime}
# @FUNCTION: xdg_desktopfiles_savelist
# @DESCRIPTION:
# Find the .desktop files about to be installed and save their location
# in the XDG_ECLASS_DESKTOPFILES environment variable.
# This function should be called from pkg_preinst.
xdg_desktopfiles_savelist() {
pushd ${D} /dev/null
export XDG_ECLASS_DESKTOPFILES=$(find 'usr/share/applications' -type f
2 /dev/null)
popd /dev
Re: [gentoo-dev] new eclass: xdg and xdg-utils as a replacement for fdo-mime
Le mercredi 10 juin 2015 à 11:04 -0400, Mike Gilbert a écrit :
On Wed, Jun 10, 2015 at 10:12 AM, Gilles Dartiguelongue
e...@gentoo.org wrote:
This is an attempt to fix bug #208047 [1] and bug #444568 [2]
Current fdo-mime eclass is often not used when it should be. I
suppose
this is partly because one has to think too much about whether it
is
needed or not and what to do with the functions.
The proposed solution is to not have to worry about it and just
inherit
it when you have any kind of XDG specifications support and let the
exported phases do their job in a similar fashion to the gnome
eclasses.
For now, this covers .desktop and shared mime-info files and
creating
base directory for packages that rely on it one way or another.
This helps solve problems like bug #545128 [3] and others that have
been covered by previous work resulting in gnome2_environment_reset
function and similar in other eclasses (cmake-utils, gstreamer,
kde4
-base, mono, mono-env, qt4-*).
xdg_desktopfiles_savelist() {
pushd ${D} /dev/null
export XDG_ECLASS_DESKTOPFILES=$(find 'usr/share/applications'
-type f 2 /dev/null)
popd /dev/null
}
Why are you sending stderr from pushd/popd to /dev/null? If they
fail,
we want to see that in the log. As well, they should probably die, or
at least return from the function with a non-zero status.
This may also need some adjusting to work on prefix, but I will leave
that for someone else to figure out.
This is blind copy-paste from gnome2-utils functions, I will clean that
out.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] distutils-r1: set install paths via setup.cfg rather than argv.
Le 21 août 2014 à 15:20, Michał Górny mgo...@gentoo.org a écrit :
Use generated setup.cfg file to propagate install paths rather than
passing them via command-line arguments whenever possible, making it
possible to call special install commands without forcing the main
'install' command.
For example, if setup.py defines install_doc command that reuses prefix
from install, to use it you'd have to call either:
esetup.py install --root=${D} install_doc
or:
distutils-r1_python_install install_doc
both of them forcing (re-)install of the whole package implicitly.
Instead, we can reuse the setup.cfg file that was added specifically to
solve a similar issue with build paths. Put the default root, byte-
compilation options and script path (if applicable) there.
distutils-r1_python_install still carries --root override for
intermediate root install though.
Thanks to this, you can run the fore-mentioned command like this:
esetup.py install_doc
---
Looks great.
--
Gilles Dartiguelongue e...@gentoo.org
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
Picking a random mail in the thread. Making udev dependency always on is a deliberate choice here, as noted by Alexandre, the library will be most likely useless without it and we simply don't want users to get confused about what might not work in the stack when bluetooth isn't particularly easy to get going already. Anyway if there is a real point in having more possibilities to shoot ourselves in the foot, please file a bug report. This is the usual way to get this sorted out. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Le samedi 01 mars 2014 à 10:06 -0600, William Hubbs a écrit : On Sat, Mar 01, 2014 at 06:48:54AM +, Steven J. Long wrote: On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote: On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. This hasn't changed. The configuration files these packages are putting in /lib are not meant to be edited; they are the package provided defaults. If you want to override one of them, you do that in a file with the same path and name in /etc, like I mentioned in another message in this thread. The problem, as has been explained many many times, is that the rest of the config is somewhere random on the system. But you knew that, right? You were just telling a half-truth, effectively. No sir, I was not telling a half-truth. If the default configuration is stored in /lib/udev/rules.d for example, and you can override that default by dropping files of the same name in /etc/udev/rules.d, I don't see what the concern is. I for one prefer a distro to do a bit of work and make my life easier, since it makes life easier for everyone who uses the distro. Why the hell should I care if some bindist can't etc-update? WTF does that have to do with Gentoo? With this method, you don't need to etc-update, so I would say that in a way this is easier. Your system-admin-provided files in /etc are not owned by the packages, just the files in /lib are. If I wanted a shitty distro that didn't bother to do anything at all, I'd use LFS. At least they don't pretend, then fall over themselves to do a crap load of work rather than admit a mistake; that hey, y'know what? Some of those things from 30 years ago were a damn good idea, and maybe just maybe, they worked some of these issues out back then, so we could stand on their shoulders instead of digging through their garbage. I'm not totally against keeping things from the past. It is just a case of evaluating those things and seeing whether they are still relevant. I think the biggest issue here is that if the filename changes or the setting that is overridden changes, then end-user or sysadmin is the one that will suffer from settings not being applied and not knowing why. This already happened with systemd/udev and net rules for example and I am pretty sure in a couple of other packages but I have no other examples on the top of my head. Sure at some point you have to make things evolve but this upstream solution simply isn't nice for its users. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] February 2014 QA policy updates
Le 19 févr. 2014 à 23:07, Chris Reffett creff...@gentoo.org a écrit : Hello all, The following are the policy changes from this month's QA team meeting: […] -Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk move to versioned USE flags. For simplicity of migration, we will allow USE=gtk to mean depend on gtk2, since there are only a few USE=gtk2 remaining in tree. USE=gtk3 will mean depend on gtk3, and in the future, USE=gtk4 will mean depend on gtk4, and so on. USE=gtk may not be used to mean depend on some version of gtk. -More generally: we recommend that in future situations like this (a package can optionally depend on different versions of a library), we recommend the use of versioned USE flags. It should be discussed with the QA team either way. […] Chris Reffett Gentoo QA Lead I feel this policy is even less precise than what we had written in our wiki page and will in fact bring more confusion. Can we actually get together in the writing of this, I feel a bit unhappy about the process. -- Gilles Dartiguelongue e...@gentoo.org
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mardi 11 février 2014 à 19:33 -0500, Chris Reffett a écrit : This doesn't make sense to me at all. I can't see why slotted libraries can't just use USE flags to specify what toolkit they're built against, just like any other package in the tree (so, for example, a package that needs webkit-gtk built against gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware that there could be limitations I'm unaware of (maybe the package only can build one at a time?), but this is how it looks to me. By switching to versioned gtk flags, this kills two birds with one stone: it makes it obvious to the end user which version they're trying to build their package against, and it gets rid of the need for (ab)using revision numbers to implement slots like that. And here comes the version abuse troll again. This discussion was settled months ago by exhaustion so please do not try to put some gasoline on it. Most packages we have been confronted to chose to only support gtk2 or gtk3 and if in their history the supported gtk2 then gtk3, we need a slot for that because it makes sense. See gnome-desktop, glade, gtkhtml, at-spi, libgda, gucharmap, vte, etc. For those packages that still support both actively, we still want slots because most packages we have seen (webkit-gtk, gtk-vnc, spice and more that since lost their gtk2 support) only allowed building against one toolkit at a time. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mercredi 12 février 2014 à 08:29 +0100, Lars Wendler a écrit : [...] This is a really good idea and I am all in favor of it. gtk+:3 still isn't adopted widely and there are still not many good looking skins available for it. (sorry but I don't want to have all gtk+ apps I am using looking totally ugly again) I doubt gtk+:2 will be deprecated that soon as some of our devs try to imply. We do not pretend anything, we read upstream statements in bug reports and in blogs. I do not keep them bookmarked though but do not get your hopes too high, it will be slow, but as sure as Gnome 2 is going to be removed from the tree, gtk2 is not evolving anymore and receives as little maintenance as possible by upstream (which in software development means it is rusting and the conclusion should be evident to anyone). Of course, just as gtk1 we are not going to remove it right now. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Le mercredi 12 février 2014 à 17:46 -0500, Chris Reffett a écrit : splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). I also fail to see what this has to do with binpkgs: if something needs webkit-gtk[gtk2], you add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if needed, webkit-gtk binpkg gets rebuilt. I see no breakage there Actually changing a USE flag on a package such as webkit-gtk has a huge cost. If say you build with USE=gtk3 then suddenly need gtk2, you not only build what you need, you will also have to rebuild gtk3 support which you already have though. Since this takes a decent amount of time, even on a one year old i7, I don't know about you, but I am pretty sure users will start to complain about this as well. You would have to build, webkit1 for gtk2, webkit1 for gtk3 and webkit2 for gtk3. The story is the same for almost all libs that support both toolkits, you end up rebuilding everything even if you already have one. webkit-gtk is just the best example to prove you this is a bad idea. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Thanks for attaching link to team's policy which tries to lift any kind
of ambiguities people may have for what concerns gnome team's packages,
I hope it proved useful in your discussions.
Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit :
Hello fellow developers,
In the first meeting of the new QA team, we discussed the state of the
gtk{,2,3} USE flags in the main tree. [0]
In its current state, USE=gtk means gtk2. The Gnome team is trying to change
this into the most recent gtk version (it is a work in progress).
Wrong, gtk USE flag means enable gtk support, whether this is gtk 1, 2
or 3 depends on what the package (presumably library) supports and
whether is can be slotted or not and whether current gentoo maintainer
decides what can be reasonably supported.
Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in packages
that
may support either or both the toolkits. To handle this, a few developers have
introduced the gtk3 useflag, that prefers gtk3 over gtk2 when both toolkit
versions are supported. At this point, the Gnome team highly recommends
prefering gtk3 if possible, skipping the useflag altogether. [1]
Wrong, as is written in policy whether to prefer gtk2 or 3 is up to the
maintainer of the package. We point people to the fact that upstream
says gtk2 is a dead end and support will stop (if not in fact already
stopped) in the near future.
We also recommend to have maintainers support slots for their libs where
possible considering man-power and to only choose one toolkit for
applications considering where upstream development is going and
maturity of the port, and again, this is up to package maintainers.
Some developers choose to follow the Gnome team's highlights, while others
choose to go their own way. The QA team would like to establish a guideline
that solves this problem in the best way possible.
During our discussion, it was pointed out that keeping a generic USE=gtk is
sub-optimal. The non-straightforward nature of new toolkit versions makes
transitioning from one to the other a slow, tedius process and we think that a
non-versioned USE flag makes things even worse.
A few of our members recommended a move away from the unversioned USE=gtk to
versioned-only USE flags. Qt managed to do this quite successfully when they
transitioned from the unversioned USE=qt (that actually meant qt3) to
USE=qt4. The benefits can be seen now that qt5 is around the corner.
USE=qt5 is straightforward, does not mess with qt4 packages and was
introduced to the tree without messing with current packages too much - other
than adding a new use flag where appropriate. There is also no need for
USE=qt anymore.
To achieve this, version 3 of gtk should always be enabled by USE=gtk3. At
some point in the future, when gtk2 consumers reach zero, we will retire gtk
for good. Then, if some day gtk4 comes around, we will be able to introduce
support for it in the tree by simply adding USE=gtk4, without having to
re-structure half the tree.
We are reaching out to the developer community to hear your thoughts and ideas
on the matter. We would like to reach a decision that could possibly affect
and
direct the state of whole tree. This decision could then be turned into a
policy, improving Gentoo's consistency across the tree.
Imho the whole discussion stems for packages maintainers which, as you
have written, did not follow our recommendation and tried to provided
application with both gtk2 and gtk3 support.
I agree that Gentoo is about choice... however as a maintainer of a
lot of packages, it is unreasonable to try to support two configuration
where one is dying slowly due to upstream (gtk) maintainer focus being
elsewhere, hence why we wanted maintainers to choose. Instead, it occurs
that some decided not to choose or to stop users from annoying them with
100 of duplicate bugs about not providing the alternative.
Looking at the situation from a gnome team member perspective when Gnome
3 was introduced to the tree, only three packages (providing libs)
needed exception to the rule to avoid unreasonable maintenance overhead:
spice, gtk-vnc and avahi. All of them had proper USE-dependencies in
relevant ebuilds so no confusion would be possible.
Right now, I don't really get the point of this discussion given all the
precedent threads about this, be it 2 years ago and 8-10 years ago.
Anyway, if QA would provide with a list of offenders (this could have
been done on bugzilla btw), we could walk-through the list and verify
what/if/how packages would need extra USE flags or not and not just for
our self-written policy's sake that is.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] waf-utils.eclass: maintainer needed
Hi all, a few years ago, I had to write this eclass because one gnome package started using waf as its build system. I never intended to continue maintaining this eclass unless the package in question would stop working otherwise but at that time, nobody stepped up to help. So here we are nowadays with feature requests and patches stacking up mostly unreviewed, the rest of the gnome team is not interested in waf as well so if anyone is willing to have a better support for this crazy build system please add yourself to eclass meta. I will proceed to re-assigning all open bug reports to maintainer-needed in a week or so. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] Re: New eclass: xdg-basedir
Le mercredi 29 janvier 2014 à 22:37 -0500, Mike Gilbert a écrit :
One difference: it creates 3 of the 4 directories under ${HOME}
instead
of ${T}, just to mimic the default behavior in the XDG basedir spec a
bit more closely.
The thing with ${HOME} is that it should not be a directory where XDG
compliants tools should be able to store anything permanent while
building since this would affect consecutive builds (say
gobject-introspection, gstreamer registry, etc).
This is why it is set to ${T} in gnome2-utils.eclass.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] Re: New eclass: xdg-basedir
Le jeudi 30 janvier 2014 à 09:29 +0100, Ulrich Mueller a écrit :
On Thu, 30 Jan 2014, Gilles Dartiguelongue wrote:
The thing with ${HOME} is that it should not be a directory where
XDG compliants tools should be able to store anything permanent
while building since this would affect consecutive builds (say
gobject-introspection, gstreamer registry, etc).
This is why it is set to ${T} in gnome2-utils.eclass.
HOME is as temporary as T during build time. PMS says: The full path
to an appropriate temporary directory for use by any programs invoked
by the ebuild that may read or modify the home directory.
With Portage, HOME will point to:
${PORTAGE_TMPDIR}/${CATEGORY}/${PF}/homedir/
Very well then.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Dealing with XDG directories in ebuild environment
Le mardi 28 janvier 2014 à 13:11 +, Steven J. Long a écrit : Alec Warner wrote: Sorry, I work on Portage. What I'm saying is that We are free to change the behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is someone else's can of worms. Agreed: portage can clear those vars from the env as mgorny stated on the bug, and an xdg.eclass (or w/e) can setup good defaults for packages which need them. Presumably it'd be inherited by gnome and kde eclasses, for example, so most people wouldn't even see it. Exactly. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
Le lundi 27 janvier 2014 à 02:10 +0100, Peter Stuge a écrit : here any other solution for users than fixing the ebuilds and/or eclass(es)? Any dev is supposed to know if his/her package complies to XDG specifications, easy enough to figure out in most cases. Like other packages affected by environment variables they use (gstreamer, glib, etc), we just need a sane place to properly reset/set those to ensure repeatability of builds. Given current PM behavior, it is not possible to change what is exported to build environment without an EAPI bump because the potential for breakage is huge and you do not want to spend your next month building the tree to build a whitelist of environment variables, right ? Imho, the best course of action is to move that to an eclass for now. People are encouraged to provide a prototype implementation of such eclass in the previously mentioned bug report. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] [PATCH] gst-plugins10.eclass: fix support for 1.2 series
Hi all,
here is a little patch to gst-plugins10.eclass fixing SLOT definition
for the new 1.2 release. Per upstream release mail, 1.* will remain
API/ABI compatible.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Index: gst-plugins10.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gst-plugins10.eclass,v
retrieving revision 1.10
diff -u -B -r1.10 gst-plugins10.eclass
--- gst-plugins10.eclass 31 Jan 2013 19:59:54 - 1.10
+++ gst-plugins10.eclass 29 Sep 2013 14:50:58 -
@@ -102,7 +102,11 @@
SRC_URI=http://gstreamer.freedesktop.org/src/${GST_ORG_MODULE}/${GST_ORG_MODULE}-${PV}.tar.${GST_TARBALL_SUFFIX};
LICENSE=GPL-2
-SLOT=${GST_ORG_PVP}
+case ${GST_ORG_PVP} in
+ 0.10) SLOT=0.10 ;;
+ 1.*) SLOT=1.0 ;;
+ *) die Unkown gstreamer release.
+esac
S=${WORKDIR}/${GST_ORG_MODULE}-${PV}
Re: [gentoo-dev] rfc: status of OpenRC's public API
Le samedi 14 septembre 2013 à 18:07 -0500, William Hubbs a écrit : On Sat, Sep 14, 2013 at 10:59:57PM +0200, Pacho Ramos wrote: openrc-settings will need to be kept if we ever want to implement: https://bugs.gentoo.org/show_bug.cgi?id=480336 There may be other reasons to keep the api, that's why I put out the question. However, I thought the gnome team had agreed that you were going to just mandate systemd for gnome 3.8 and newer since logind is unusable outside of systemd. In that case, can't we just close this bug as wontfix? I'll repeat what I wrote on this list at least 4 times now. The gnome team decided to move forward and use systemd as we have not enough man power to develop our own alternative to logind. If there ever was such alternative, we would most likely drop the systemd requirement and I would, for sure, be the first to try it out since I very much prefer openrc. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] rfc: status of OpenRC's public API
Le samedi 14 septembre 2013 à 00:47 -0400, Alexandre Rostovtsev a écrit : On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote: On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote: app-admin/openrc-settingsd uses various functions (rc_sys(), rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(), rc_service_resolve(), rc_service_mark() etc.) from rc.h Will this still be needed once gnome 3.8 is stable everywhere? It will not be needed for gnome. Possibly another desktop environment might have a use for it. It will be needed if someone manages to implement a logind alternative as well. If that ever happens. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le mardi 10 septembre 2013 à 17:10 +0200, Fabian Groffen a écrit :
On 10-09-2013 06:22:38 -0400, Ian Stakenvicius wrote:
pkg_preinst() {
gnome2_gdk_pixbuf_savelist
+
+ # Make sure loaders.cache belongs to gdk-pixbuf alone
+ local cache=usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache
+
+ if [[ -e ${ROOT}${cache} ]]; then
+ cp ${ROOT}${cache} ${D}/${cache} || die
+ else
+ touch ${D}/${cache} || die
+ fi
}
pkg_postinst() {
shouldn't that be EROOT ?
and ED in that case too
Do we still use that in EAPI 3 ?
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
As a follow up to this discussion, I came with the attached patch. It
appears to work ok for regular merges and binpkg merges with
FEATURES=collision-protect.
Per my reading of PMS it does not appear to violate anything so I guess
it is ok.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
[1;32m===[0;0m
[1;32mRCS file: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
[1;32mretrieving revision 1.3[0;0m
[1;32mdiff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild[0;0m
[1;31m--- gdk-pixbuf-2.28.2.ebuild 3 Sep 2013 21:59:11 - 1.3[0;0m
[1;34m+++ gdk-pixbuf-2.28.2.ebuild 9 Sep 2013 22:28:20 -[0;0m
[1;35m@@ -67,6 +67,15 @@[0;0m
[0;0m [0;0m
[0;0m pkg_preinst() {[0;0m
[0;0m gnome2_gdk_pixbuf_savelist[0;0m
[1;34m+[0;0m
[1;34m+ # Make sure loaders.cache belongs to gdk-pixbuf alone[0;0m
[1;34m+ local cache=usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache[0;0m
[1;34m+[0;0m
[1;34m+ if [[ -e ${ROOT}${cache} ]]; then[0;0m
[1;34m+ cp ${ROOT}${cache} ${D}/${cache} || die[0;0m
[1;34m+ else[0;0m
[1;34m+ touch ${D}/${cache} || die[0;0m
[1;34m+ fi[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m pkg_postinst() {[0;0m
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_install_serviced().
Le dimanche 08 septembre 2013 à 13:12 +0200, Michał Górny a écrit :
This function can be used to install service configuration templates.
Usage:
systemd_install_serviced ${FILESDIR}/foo.service.conf
or:
systemd_install_serviced ${FILESDIR}/barbaz foo.service
with the latter specifying related service name explicitly, former
expecting it to match ${basename%.conf}. The files are installed as:
/etc/systemd/system/foo.service.d/00gentoo.conf
They should be commented out templates that users can use to customize
the service easily.
Looks like a good idea, do you have a few example packages where that
could be used ?
---
gx86/eclass/systemd.eclass | 26 ++
1 file changed, 26 insertions(+)
diff --git a/gx86/eclass/systemd.eclass b/gx86/eclass/systemd.eclass
index 4566631..1575b78 100644
--- a/gx86/eclass/systemd.eclass
+++ b/gx86/eclass/systemd.eclass
@@ -131,6 +131,32 @@ systemd_newunit() {
newins ${@}
}
+# @FUNCTION: systemd_install_serviced
+# @USAGE: conf-file [service.d]
+# @DESCRIPTION:
+# Install the file conf-file as service.d/00gentoo.conf template.
+# The service.d argument specifies the configured service name.
+# If not specified, the configuration file name will be used with .conf
+# suffix stripped (e.g. foo.service.conf - foo.service).
+systemd_install_serviced() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ local src=${1}
+ local service=${2}
+
+ if [[ ! ${service} ]]; then
+ [[ ${src} == *.conf ]] || die Source file needs .conf suffix
+ service=${src##*/}
+ service=${service%.conf}
+ fi
+ # avoid potentially common mistake
+ [[ ${service} != *.d ]] || die Service must not have .d suffix
+
+ local INSDESTTREE
I guess this is a leftover ?
+ insinto /etc/systemd/system/${service}.d
+ newins ${src} 00gentoo.conf
+}
+
# @FUNCTION: systemd_dotmpfilesd
# @USAGE: tmpfilesd1 [...]
# @DESCRIPTION:
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
One last point to handle, how to migrate gdk-pixbuf.cache so that it is owned by the ebuild ? I've discussed this with Michał and it seems two options are possible. 1. rm the file on the filesystem in pkg_preinst in gdk-pixbuf ebuild pros: - works immediately without fiddling with profiles (see 2) cons: - no idea what PMS says about it, Michał told me it shouldn't work yet my testing proves otherwise. - leaves the system with no loaders.cache for a while which could result in apps starting with no lots of missing icons. 2. use COLLISION_IGNORE in profiles/base/make.conf pros: - does not leave the system without the cache file cons: - add a setting to base/make.conf for a long period of time to ensure most of our user have migrated (how long would it be btw, 6 months, 1 year ?) - does not protect other packages from owning the package due to this very solution for the time the setting is left in base/make.conf 3. write a news item and let users handle it Is there any other solution or is there any other point that would move the balance from one solution to another ? This solution would also be applied to a couple of other commonly regenerated files in Gnome ebuilds, like gtk-icon-cache, etc. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le mercredi 04 septembre 2013 à 15:48 -0400, Ian Stakenvicius a écrit : On 04/09/13 03:44 PM, Gilles Dartiguelongue wrote: Le mercredi 04 septembre 2013 à 15:23 -0400, Ian Stakenvicius a écrit : [snip] By gdk-pixbuf.cache , you mean the 'loaders.cache' file that the eclass is now continuously updating? Which ebuild is going to 'own' it? yes, gdk-pixbuf is going to own it since it is the main loader provider and the package that provides the tool to generate the cache. Also, is it owned by anything right now? IIRC we don't try particularly hard to support FEATURES=collision-protect in the tree, but rather FEATURES=protect-owned, and so if the file is currently sitting there unowned by any package, afaik you shouldn't get any collisions by installing over it. it is not owned by any package right now but touching the file in src_install made collision-protect abort the install. You had FEATURES=collision-protect enabled or the default FEATURES=protect-owned ? the default, but since I only touched the file, maybe it's FEATURES=config-protect-if-modified kicking in ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 18:44 +0200, Gilles Dartiguelongue a écrit :
Le samedi 31 août 2013 à 16:49 +0200, Michał Górny a écrit :
Dnia 2013-08-31, o godz. 15:00:43
Gilles Dartiguelongue e...@gentoo.org napisał(a):
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
Thanks for pacho's bugzillafu, we've got the original reports here:
https://bugs.gentoo.org/show_bug.cgi?id=413529
https://bugs.gentoo.org/show_bug.cgi?id=413485
It seems the cat usage was only to avoid handling file permission
issues.
The use of a temporary file itself it to avoid having a corrupted file
if the command fails.
As for immodules I plan to provide patches to fix it after we agree on
this one.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Updated diffs + gdk-pixbuf handling.
Tested with success locally.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Index: gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.122
diff -u -B -r1.122 gnome2.eclass
--- gnome2.eclass 26 May 2013 14:08:21 - 1.122
+++ gnome2.eclass 1 Sep 2013 15:04:58 -
@@ -258,6 +258,7 @@
gnome2_icon_savelist
gnome2_schemas_savelist
gnome2_scrollkeeper_savelist
+ gnome2_gdk_pixbuf_savelist
}
# @FUNCTION: gnome2_pkg_postinst
@@ -271,6 +272,7 @@
gnome2_icon_cache_update
gnome2_schemas_update
gnome2_scrollkeeper_update
+ gnome2_gdk_pixbuf_update
}
# # FIXME Handle GConf schemas removal
Index: gnome2-utils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2-utils.eclass,v
retrieving revision 1.31
diff -u -B -r1.31 gnome2-utils.eclass
--- gnome2-utils.eclass 27 Oct 2012 22:24:10 - 1.31
+++ gnome2-utils.eclass 1 Sep 2013 15:04:58 -
@@ -15,6 +15,8 @@
# * GConf schemas management
# * scrollkeeper (old Gnome help system) management
+inherit multilib
+
case ${EAPI:-0} in
0|1|2|3|4|5) ;;
*) die EAPI=${EAPI} is not supported ;;
@@ -50,6 +52,12 @@
# Path to glib-compile-schemas
: ${GLIB_COMPILE_SCHEMAS:=/usr/bin/glib-compile-schemas}
+# @ECLASS-VARIABLE: GDK_PIXBUF_UPDATE_BIN
+# @INTERNAL
+# @DESCRIPTION:
+# Path to gdk-pixbuf-query-loaders
+: ${GDK_PIXBUF_UPDATE_BIN:=/usr/bin/gdk-pixbuf-query-loaders}
+
# @ECLASS-VARIABLE: GNOME2_ECLASS_SCHEMAS
# @INTERNAL
# @DEFAULT_UNSET
@@ -74,6 +82,12 @@
# @DESCRIPTION:
# List of GSettings schemas provided by the package
+# @ECLASS-VARIABLE: GNOME2_ECLASS_GDK_PIXBUF_LOADERS
+# @INTERNAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of gdk-pixbuf loaders provided by the package
+
DEPEND==sys-apps/sed-4
@@ -387,6 +401,46 @@
eend $?
}
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} 1/dev/null
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd 1/dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file}
+ chmod 0644 ${tmp_file}
+ mv -f ${tmp_file} ${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Index: gdk-pixbuf-2.28.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v
retrieving revision 1.2
diff -u -B -r1.2 gdk-pixbuf-2.28.2.ebuild
--- gdk-pixbuf-2.28.2.ebuild 5 Aug 2013 09:48:12 - 1.2
+++ gdk-pixbuf-2.28.2.ebuild 1 Sep 2013 15:09:12 -
@@ -3,7 +3,8 @@
# $Header: /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v 1.2 2013/08/05 09:48:12 ssuominen Exp $
EAPI=5
-inherit gnome.org multilib libtool
+
+inherit gnome.org gnome2-utils multilib libtool
DESCRIPTION=Image loading library for GTK+
HOMEPAGE=http://www.gtk.org/;
@@ -64,19 +65,15 @@
prune_libtool_files --modules
}
+pkg_preinst() {
+ gnome2_gdk_pixbuf_savelist
+}
+
pkg_postinst() {
# causes segfault if set, see bug 375615
unset __GL_NO_DSO_FINALIZER
- tmp_file=$(mktemp -t tmp_gdk_pixbuf_ebuild.XX)
- # be atomic!
- gdk-pixbuf-query-loaders ${tmp_file}
- if [ ${?} = 0 ]; then
- cat ${tmp_file} ${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
- else
- ewarn Cannot update loaders.cache, gdk-pixbuf-query-loaders failed to run
- fi
- rm ${tmp_file}
+ gnome2_gdk_pixbuf_update
# FIXME: use subslots to get rebuilds when really needed
# Every major version bump???
@@ -86,3 +83,9 @@
elog emerge -va1 \$(qfile -qC ${EPREFIX}/usr/lib/gtk-2.0/2.*/loaders)
fi
}
+
+pkg_postrm() {
+ if [[ -z ${REPLACED_BY_VERSIONS} ]]; then
+ rm -f ${EROOT}usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache
+ fi
+}
[gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
As described here:
https://bugs.gentoo.org/show_bug.cgi?id=483128
This is a very lightweight patch to support the few packages that
provide gdk pixbuf loaders. The ones I know of are: gdk-pixbuf itself,
librsvg and libopenraw and emul-gtklibs but more could be missing simply
because they do not run the command.
Since this patch is quite trivial, I'd like to have it commited by
Sunday. Thanks.
I am attaching the patch here as well for convience.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Index: gnome2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
retrieving revision 1.122
diff -u -B -r1.122 gnome2.eclass
--- gnome2.eclass 26 May 2013 14:08:21 - 1.122
+++ gnome2.eclass 31 Aug 2013 10:56:58 -
@@ -258,6 +258,7 @@
gnome2_icon_savelist
gnome2_schemas_savelist
gnome2_scrollkeeper_savelist
+ gnome2_gdk_pixbuf_savelist
}
# @FUNCTION: gnome2_pkg_postinst
@@ -271,6 +272,7 @@
gnome2_icon_cache_update
gnome2_schemas_update
gnome2_scrollkeeper_update
+ gnome2_gdk_pixbuf_update
}
# # FIXME Handle GConf schemas removal
Index: gnome2-utils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2-utils.eclass,v
retrieving revision 1.31
diff -u -B -r1.31 gnome2-utils.eclass
--- gnome2-utils.eclass 27 Oct 2012 22:24:10 - 1.31
+++ gnome2-utils.eclass 31 Aug 2013 10:56:58 -
@@ -50,6 +50,12 @@
# Path to glib-compile-schemas
: ${GLIB_COMPILE_SCHEMAS:=/usr/bin/glib-compile-schemas}
+# @ECLASS-VARIABLE: GDK_PIXBUF_UPDATE_BIN
+# @INTERNAL
+# @DESCRIPTION:
+# Path to gdk-pixbuf-query-loaders
+: ${GDK_PIXBUF_UPDATE_BIN:=/usr/bin/gdk-pixbuf-query-loaders}
+
# @ECLASS-VARIABLE: GNOME2_ECLASS_SCHEMAS
# @INTERNAL
# @DEFAULT_UNSET
@@ -74,6 +80,12 @@
# @DESCRIPTION:
# List of GSettings schemas provided by the package
+# @ECLASS-VARIABLE: GNOME2_ECLASS_GDK_PIXBUF_LOADERS
+# @INTERNAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of gdk-pixbuf loaders provided by the package
+
DEPEND==sys-apps/sed-4
@@ -387,6 +399,45 @@
eend $?
}
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} /dev/null
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd /dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file} 2/dev/null
+ cat ${tmp_file} ${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
Dnia 2013-08-31, o godz. 13:07:41
Gilles Dartiguelongue e...@gentoo.org napisał(a):
+# @FUNCTION: gnome2_gdk_pixbuf_savelist
+# @DESCRIPTION:
+# Find if there is any gdk-pixbuf loader to install and save the list in
+# GNOME2_ECLASS_GDK_PIXBUF_LOADERS variable.
+# This function should be called from pkg_preinst.
+gnome2_gdk_pixbuf_savelist() {
+ has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
+ pushd ${ED} /dev/null
pushd ${ED} /dev/null || die
(don't hide errors)
ok, I'll check all other usage in gnome eclasses.
+ export GNOME2_ECLASS_GDK_PIXBUF_LOADERS=$(find
usr/$(get_libdir)/gdk-pixbuf-2.0 -type f 2/dev/null)
+ popd /dev/null
+}
+
+# @FUNCTION: gnome2_gdk_pixbuf_update
+# @USAGE: gnome2_gdk_pixbuf_update
+# @DESCRIPTION:
+# Updates gdk-pixbuf loader cache if GNOME2_ECLASS_GDK_PIXBUF_LOADERS has
some.
+# This function should be called from pkg_postinst and pkg_postrm.
+gnome2_gdk_pixbuf_update() {
+ has ${EAPI:-0} 0 1 2 ! use prefix EROOT=${ROOT}
+ local updater=${EROOT}${GDK_PIXBUF_UPDATE_BIN}
+
+ if [[ ! -x ${updater} ]]; then
+ debug-print ${updater} is not executable
+ return
+ fi
+
+ if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then
+ debug-print gdk-pixbuf loader cache does not need an update
+ return
+ fi
+
+ ebegin Updating gdk-pixbuf loader cache
+ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf)
+ ${updater} 1 ${tmp_file} 2/dev/null
Why do you hide errors from user? '[FAIL]' with no explanation doesn't
seem really helpeful.
True.
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
I'd have to look back at the original bug report to get the exact reason
but it seems mv/cp was not atomic enough.
Is it safe to assume constant '2.10.0'?
afaik yes, it's not changed in ages.
+ eend $?
+}
+
+
# @FUNCTION: gnome2_query_immodules_gtk2
# @USAGE: gnome2_query_immodules_gtk2
# @DESCRIPTION:
Also, please make 'loaders.cache' owned by x11-libs/gdk-pixbuf.
Yes, we need to work on that for all other caches as well.
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
I am not clear on this last sentence. Could you reformulate it please ?
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Le samedi 31 août 2013 à 16:49 +0200, Michał Górny a écrit :
Dnia 2013-08-31, o godz. 15:00:43
Gilles Dartiguelongue e...@gentoo.org napisał(a):
Le samedi 31 août 2013 à 13:40 +0200, Michał Górny a écrit :
+ cat ${tmp_file}
${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache
Why not mv or cp? Also you need '|| die' here since 'cat' can fail
writing.
I'd have to look back at the original bug report to get the exact reason
but it seems mv/cp was not atomic enough.
Well, 'cat' is not atomic at all, so definitely not that :). 'mv' is
the only command that you can expect to at least try to be atomic.
It may had something to do with file metadata or symlinks.
I sort of remember there was a bug report but I can find no trace of it.
All I could find was the commit that introduced this logic, by lxnay:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.24.0.ebuild?hideattic=0revision=1.2view=markup
@lxnay, could you please comment on previous question ?
And please ensure to remove it in pkg_postrm() when last version
of gdk-pixbuf is unmerged.
I am not clear on this last sentence. Could you reformulate it please ?
In gdk-pixbuf, something like:
pkg_postrm() {
# TODO: check if i used the correct variable :)
[[ ${REPLACING_VERSIONS} ]] || rm -f ${EROOT}usr/.../loaders.cache
}
ok, will do.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2/gtk3 use flags
Le mercredi 21 août 2013 à 12:15 +0800, Ben de Groot a écrit : On 21 August 2013 07:36, Gilles Dartiguelongue e...@gentoo.org wrote: Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : 16.08.2013 21:15, hasufell пишет: https://bugs.gentoo.org/show_bug.cgi?id=420493 gtk2 and gtk3 useflags are discouraged and should only be used in special cases file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer will quit if i keep things that way :-/ The upstream maintainer is free to support both toolkits if he wishes to do so, but we strongly recommend to only select one slot for applications in gentoo tree, the one which works best for the application. -- Gilles Dartiguelongue e...@gentoo.org Gentoo When upstream supports both, and the maintainer wishes to do so as well, I would strongly recommend to support both, so that end-users can make their own choices. Some may wish to use the applications in a light-weight gtk2-only environment such as LXDE. As long as gtk+:2 is supported in the tree, I don't see why we should artificially restrict such choices for our users. The reasons are enumerated on the wiki and are just a summary of the older thread where this was discussed. Of course, since there is no body to impose such rules, you are free to go against gnome team self imposed policy and recommendation. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] gtk2/gtk3 use flags
Le samedi 17 août 2013 à 15:33 +0300, Samuli Suominen a écrit : On 16/08/13 20:12, Michael Weber wrote: Hello, gtk is a global use flag [1], gtk2 and gtk3 are used in metadata.xml [2]. Is there a consensus how to use these flags if an app provides gtk2 and gtk3 gui in parallel or exclusive? 'gtk' uses best possible version as defined by the package maintainer 'gtk3' is a special flag that is used when package supports both gtk and gtk3 at the same time, and matches the criteria of sanity which is a) it's an library that is used by multiple programs b) is not easy to split, which would otherwise be preferred over using the USE flag 'gtk2' is never required, those matching it down from the list have weak design which goes against every other ebuild in tree, but is still package maintainers decision special flags like 'IUSE=+deprecated' can be used if there is a need to enable the old GTK+ implementation by default, but still provide the new one, in programs. like if enabling GTK+3 instead of GTK+2 would disable you from using flash plug-in in a browser, would qualify in. imho :) Quick read says that it is exactly what the gnome herd said over and over on this list and on IRC. I'll also write it down again for regular applications, having a USE flag for controlling build of your application against gtk+:2 or 3 is not what the gnome team recommends. Either the gtk3 UI is working or it is not satisfying, there is no in the middle. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] gtk2/gtk3 use flags
Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : 16.08.2013 21:15, hasufell пишет: https://bugs.gentoo.org/show_bug.cgi?id=420493 gtk2 and gtk3 useflags are discouraged and should only be used in special cases file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer will quit if i keep things that way :-/ The upstream maintainer is free to support both toolkits if he wishes to do so, but we strongly recommend to only select one slot for applications in gentoo tree, the one which works best for the application. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] systemd team consensus?
Le dimanche 11 août 2013 à 22:09 +0300, Alon Bar-Lev a écrit : On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman tom...@gentoo.org wrote: On Sun, 11 Aug 2013 13:29:16 -0500 William Hubbs willi...@gentoo.org wrote: You may ask why I have offered patches instead of just fixing the ebuild since I am a team member. That is because even team members aren't allowed to touch bugs assigned to syst...@gentoo.org [1], Well, if there are conflicts within a team then I can agree that no member is allowed to touch the bug without a collaborative decision; but from what it appears this bug has been handed in a way that one member appears to take all decisions and the other member has nothing to say. In particular, comments 5 and 11 change the state of the bug without giving any reasoning about why that change in state was made; this is unacceptable, it gives us no reason to believe the state change. This is expected, as it is similar to how systemd/gnome is managed :) I hope you are not talking about the Gentoo Gnome team as this would be very wrong. Every team member is heard on the team. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
Le jeudi 08 août 2013 à 21:03 -0500, William Hubbs a écrit : The decision to depend on systemd for part of its functionality is with gnome upstream, not the gnome team of Gentoo. Pacho wrote a good summary of what is going on. I can see why OpenBSD would provide the missing functionality of systemd for gnome (systemd does not, and will not, exist on the *BSDs). Someone could provide the missing functionality of systemd so that gnome could run without systemd, or they could provide patches to gnome upstream to make sure it works without the need for systemd. I suggest that if you really want to keep this going, convincing gnome upstream that running without systemd is still important is the way to go, not taking it out on the Gentoo gnome team, and the best way to convince gnome would probably be to provide patches. All of the complaining and taking it out on our gnome team is not productive. Asking our gnome team to carry downstream patches is also not productive, because they would end up being forced to update these patches against every new gnome release. It is not a regression if a new version of gnome mrequires systemd and does not work with OpenRc; it is a design choice. The community doesn't need to decide whether systemd can go stable; The community would only need to decide if we switch the default init system to systemd. No one is proposing this. +1 We, the gnome team, did our best to delay this dependency by talking to upstream submitting patches, etc. But as many have written already, not all of gnome upstream cares as they decided Gnome should be monolithic now. This is not our decision but we still have to handle the consequences. For the record we did and still do support setups that upstream does not care about. * In the past, we had policykit/polkit optional, we had to stop that since it is now too tied in to be decently maintained at our level * We had pulseaudio optional, again, this is now over in some of the core components of Gnome, but we do keep it optional were possible * We maintain networkmanager and bluetooth support optional, and this has been the case since 3.2 iirc even though upstream flat out refuses to merge our perfectly fine patches Keeping systemd optional in Gnome cannot be achieved by the Gentoo Gnome team. If someone comes up with a solution to have logind without systemd, we will gladly include it but remember that a few devs (4/5 afaik) already tried and sadly failed. So until there is an alternative, Gnome 3.8 is going stable as the gnome team decided because it provides the best Gnome 3 experience yet. Gnome 3.6 is almost one year old and unsupported, Gnome 2 is over 4 years old and should already have left the tree but we didn't do so because we wanted our users to have a decently stable desktop to work with, whatever it is made of. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Response to a friendly note about changing bug reports
Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. http://permalink.gmane.org/gmane.linux.gentoo.devel/66279 Otherwise, please reimburse the time I've spent reading this useless thread, TIA ;) (For the record, I fully support jer's work, my OCD doesn't look so bad we he gets summaries fixed for me beforehand). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] font.eclass add Xorg FontPath elements for non-standard paths
Le jeudi 04 juillet 2013 à 01:07 +0200, Michael Weber a écrit :
Hello,
as Ondrej Grover pointed out on [1], the font.eclass installs font
files and indexes (font.dir, fonts.scale) into sub-dirs of
/usr/share/fonts/, e.g. /usr/share/fonts/terminus.
These directories are naturally not in the fontpath of Xorg server,
and could not be used without adding these with xset fp+.
As said on the bug, the Xserver itself should be abled to find all
fonts, and it's not the duty of the xinitrc/window-manager to collect
all these paths in the users process.
I'd like to propose a patch to font.eclass to add the newly created
paths to the Xorg server configuration via xorg.conf.d files [2].
I contacted fonts alias and, as mentioned on the bug and irc, Ben de
Groot (yngwin) does not object and says that font team lead Peter
Volkov (pva) is non-active.
Please review for technical problems (esp. for EPREFIX).
Open questions:
- Should the (current) default xorg server paths
/usr/share/fonts/{75dpi,100dpi,misc,TTF,OTF,TYPE1} really be excluded?
How would the startup and font lookup perfomance degrade with
multiple conf.d files, containing the same path multiple times?
- How would already installed font packages see this fix?
Revbump (and stabilize) every one of them?
- Alternative solutions would be installing fonts in xorg-servers
default paths or add one configuration file that gets newly
assembled on every font_pkg_postinst run.
Imho, this should be handled in pkg_postinst generating one Xorg
configuration file at the end of the install, very much like
fdo .desktop or mime cache file.
This solves most of the point raised since any font bump would generate
the file for all fonts.
Also, not sure it is related but, maybe this could be linked to
configuration set by eselect fontconfig in some way ?
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] Introduce global dmalloc USE flag?
Le samedi 22 juin 2013 à 15:48 +0800, Dennis Lan (dlan) a écrit : On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/13 01:05 AM, Michał Górny wrote: Dnia 2013-06-13, o godz. 09:35:54 Dennis Lan (dlan) dennis.y...@gmail.com napisał(a): also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd use dmalloc but controlled under USE=debug Do those use USE=debug solely for dmalloc or does it imply other stuff? Therefore: will it be possible to use USE=dmalloc in those packages? HI mgorny, as I look into those ebuilds all of them use the USE=debug flag for dmalloc only, not for other debugging control so, as your second question, of course it's possible to switch to USE=dmalloc and to follow up, if we assume that USE=debug does more than just build the package against the dmalloc lib (which is likely), is there Yes, if this case exist.. then the separation would be good any particular benefit to USE=debug -dmalloc ? Or USE=dmalloc - -debug ? I'm not sure, probably the befefits would be that we can have more accurate/explicit control, USE=dmalloc is for debugging memory usage stuff (allocation, free, fence-post overwritten control) and USE=debug for other stuff? This is a slightly improvement, but I'm also totally fine to keep current state as it is.. no big deal Reading this thread, looks to me like these dmalloc USE should be moved to debug, unless it has no runtime impact on usual speed, etc. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Introduce global dmalloc USE flag?
Le lundi 24 juin 2013 à 12:05 +0300, Samuli Suominen a écrit : On 24/06/13 11:54, Gilles Dartiguelongue wrote: Le samedi 22 juin 2013 à 15:48 +0800, Dennis Lan (dlan) a écrit : On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/13 01:05 AM, Michał Górny wrote: Dnia 2013-06-13, o godz. 09:35:54 Dennis Lan (dlan) dennis.y...@gmail.com napisał(a): also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd use dmalloc but controlled under USE=debug Do those use USE=debug solely for dmalloc or does it imply other stuff? Therefore: will it be possible to use USE=dmalloc in those packages? HI mgorny, as I look into those ebuilds all of them use the USE=debug flag for dmalloc only, not for other debugging control so, as your second question, of course it's possible to switch to USE=dmalloc and to follow up, if we assume that USE=debug does more than just build the package against the dmalloc lib (which is likely), is there Yes, if this case exist.. then the separation would be good any particular benefit to USE=debug -dmalloc ? Or USE=dmalloc - -debug ? I'm not sure, probably the befefits would be that we can have more accurate/explicit control, USE=dmalloc is for debugging memory usage stuff (allocation, free, fence-post overwritten control) and USE=debug for other stuff? This is a slightly improvement, but I'm also totally fine to keep current state as it is.. no big deal Reading this thread, looks to me like these dmalloc USE should be moved to debug, unless it has no runtime impact on usual speed, etc. It does. In most often cases building against dmalloc makes the application/library completely unusable, and building it against dmalloc is intended for the developer of the application. Separated USE=dmalloc is the only sane way to approach it. To be clear, the justification of USE=dmalloc being separated from USE=debug is that it is so intrusive than anyone excepts a developer would find it too cumbersome to attempt to debug a problem with the application ? If that is the case, maybe the USE flag description should mention that so it is not enabled lightly. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Le mardi 28 mai 2013 à 22:18 +0200, Michał Górny a écrit : On Tue, 28 May 2013 15:22:04 -0400 Anthony G. Basile bluen...@gentoo.org wrote: I thought about ssl but I'm still not sure if USE=ssl means just openssl or any ssl. Eg, with curl, which has a choice of one of six backend ssl providers, I changed USE=ssl to mean that one and only one of the six must be on. Previously though, USE=ssl in curl meant only openssl which was confusing because you could also have USE=nss or gnutls etc provide your ssl. monkey also bounced around its ssl backend from liana_ssl to polarssl which is what made me think of curl. What if in the future there's yet another ssl backend? Although use.desc does say ... ssl - Adds support for Secure Socket Layer connections. Any advice here? Any SSL. If there are multiple backends to support, there are specific flags which affect the choice but USE=ssl means any SSL is suitable. Already explained multiple times on this mailing list, and not only for ssl. Imho this should be part of some QA policy or documentation about writing ebuilds or whatever and not just for ssl. In any case, I wrote this down for the Gnome team at Gentoo wiki [1]. [1] http://wiki.gentoo.org/wiki/Gnome_Team_Policies#ssl -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] robo-stable bugs
Le dimanche 19 mai 2013 à 17:00 -0700, Paweł Hajdan, Jr. a écrit : On 5/19/13 6:40 AM, Jeroen Roovers wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. Hey Jeroen, apologies if I have ignored any of your feedback. I'm indeed behind on bugmail (5000 unread emails, how about that?). That would explain why you're still filling gnome stabilization bugs while we replied many times we don't want them in their current form ? I do read mailing list traffic and direct e-mail though. We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Could you refer me to the part where we agreed and why? I'm actually happy to make changes that are useful for people, but without a good rationale and an _actual_ consensus someone else will inevitably come and says he likes the old way better. This was discussed on the mailing list a couple of times. Last big thread related to this was automatic bug assignment iirc. This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. I'll repeat gnome team position here: We do not want automated stabilization requests. We handle so many packages that having individual bug reports is driving arch teams and us crazy. We have our own set of scripts to do batch stabilization bug reports. They were designed with arch teams so that it does not generate too much load on them. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Global useflags zeroconf and avahi
Le mardi 02 avril 2013 à 09:43 +0200, Michał Górny a écrit : On Tue, 2 Apr 2013 00:43:31 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Dienstag, 2. April 2013, 00:27:59 schrieb Chí-Thanh Christopher Nguyễn: I would like to suggest unifying use-flag usage, and use zeroconf anywhere. Sounds good. Do you think the same should apply to non-mDNS/DNS-SD based zeroconf like UPnP/SSDP? No idea to be honest... :| opinions? The flags should be practical. I have no use for DNS-SD and other magical junk, yet use UPnP/IGD for port forwarding. The flags should let me just enable just that without pulling all other possible variants I won't use. That said, USE=upnp was cleaned up a while ago. I don't think it should be integrated with zeroconf. Yeah I don't think it should be merged into zeroconf even though it shares some of its technical base. Imho, zeroconf == dnssd/mdns ipv4ll and upnp/upnp-av are as described in use.desc -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Global useflags zeroconf and avahi
Le lundi 01 avril 2013 à 23:58 +0200, Andreas K. Huettel a écrit : Hi everyone, first of all, I'm not really an expert in this stuff, so feel free to tell me about any mis-assumptions... As far as I can see, we have two global useflags: avahi - Add avahi/Zeroconf support zeroconf - Support for DNS Service Discovery (DNS-SD) Zeroconf describes a service autodiscovery and autoconfiguration standard, see [1]. Avahi is the implementation of that standard which we have in the portage tree [2]. Other implementations are mDNSResponder (which was in the tree some time ago but got kicked out) and Apple's Bonjour (which never was in the tree and probably never will be). I would like to suggest unifying use-flag usage, and use zeroconf anywhere. Opinions? I thought this discussion was over last time it came around. iirc the conclusion was what you wrote, use zeroconf unless there is a special reason (none afaik in tree). -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Minor change in pkg-config behavior, starting with 0.28, late heads up for maintainers
Le vendredi 29 mars 2013 à 08:30 +0200, Samuli Suominen a écrit : This is from Fedora Devel Mailing List. I found it to be news worthy also for Gentoo maintainers. Thanks for the heads up, it will probably save some time figuring out magic/sudden break up :)
Re: [gentoo-dev] Add HEXCHAT_PLUGINS to USE_EXPAND
Le mercredi 27 mars 2013 à 14:35 +0100, René Neumann a écrit : Also the bug gives no reasoning, why having USE_EXPAND is a good thing here. Maybe IUSE_EXPAND is seen by most as namespaced USE flags ? For example libgphoto2 has used this feature for as long as I can remember it being around, and no package using it rely on them. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Proposed update to pax-utils.eclass
Le dimanche 24 mars 2013 à 20:20 -0400, Anthony G. Basile a écrit : Last call, does anyone have a problem with me updating the pax-utils.eclass? See Ref [3] above for the code. I'll wait a couple more days and then do it. looks like last conditional branch for XT marking in pax-mark function is not using the proper variables (pt_* instead ot xt_*). The PAX_MARKINGS variable is not documented with eclass documentation markup, it should at least get an @INTERNAL if this is not supposed to be modified by eclass users. _pax_list_files can receive documentation this way as well. You should probably try to avoid mixing [[ ]] and [ ] in the eclass. [ ] seems to be less used here so just have everything [[ ]] and drop the useless quoting that came with [ ]. The rest looks fine. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: Add HEXCHAT_PLUGINS to USE_EXPAND
Le mardi 26 mars 2013 à 22:28 +0100, Denis M. a écrit : On 03/21/2013 02:09 PM, Denis M. wrote: Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. HEXCHAT_PLUGINS has been created as a user (and maintainer) request in bug 461972 [1] to handle easily the net-irc/hexchat plugins that this package offers, which are: checksum, doat, fishlim and sysinfo. The purposed ebuild can be found on the bug's attached files list. Regards, Denis M. (Phr33d0m) [1] https://bugs.gentoo.org/show_bug.cgi?id=461972 Bump. Hi again, could I get a decisive answer on this please? That does not sound like a bad idea, however I wonder how this extends exactly if we start to do this for ebuilds which install a couple of plugins behind a few regular USE flags nowadays like rhythmbox, abiword, etc. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Last rites: net-im/kmess
Le samedi 23 mars 2013 à 10:46 +, Markos Chandras a écrit : # Markos Chandras hwoar...@gentoo.org (23 Mar 2013) # MSN service terminated. # You can still use your MSN account in net-im/skype # or switch to an open protocol instead # Removal in 30 days net-im/kmess MSN accounts also work with empathy in 3.6 and up (at least as configured through gnome-online-accounts). Either the xmpp gateway bridges to skype or the it was not shut down yet. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le lundi 18 février 2013 à 01:39 +0100, Diego Elio Pettenò a écrit : On 18/02/2013 00:46, Gilles Dartiguelongue wrote: rethinkdb is a young project and its build system is a 1.5k lines makefile horror. I wouldn't reintroduce stuff that isn't used in tree just for this. I, at least, am not interested in moving this to the tree. I just added it to my overlay for a testing work stuff and that need is gone for now :). It was in my TODO anyway as I was asked about it before. I guess I'll re-introduce it under p.use.mask until it's actually needed. ok then, have fun :) -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le dimanche 17 février 2013 à 21:08 +0200, Leho Kraav a écrit : Hi all I'm taking a look at etherpad-lite ebuild at https://bugs.gentoo.org/show_bug.cgi?id=328897 It's a pretty big of a mess, but as I'm searching around, I can't really find any guidelines on how nodejs / npm stuff is supposed fit in with Portage. dev-nodejs/ doesn't even exist. Is this nodejs beast too new? Anyone care to point me in some direction with this? I have package some nodejs stuff related to rethinkdb in my overlay if you want to have a look. Namely lessc and coffee-script. There is close to no packaging (let alone decent) with nodejs apps but if you are motivated enough, maybe there is something to explore from how npm works and map that to an eclass. Usual disclosure about overlays applies. http://git.overlays.gentoo.org/gitweb/?p=dev/eva.git;a=summary -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Ebuilds for nodejs apps - HOWTO?
Le lundi 18 février 2013 à 00:42 +0100, Diego Elio Pettenò a écrit : On 18/02/2013 00:39, Gilles Dartiguelongue wrote: I have package some nodejs stuff related to rethinkdb in my overlay if you want to have a look. Namely lessc and coffee-script. There is close to no packaging (let alone decent) with nodejs apps but if you are motivated enough, maybe there is something to explore from how npm works and map that to an eclass. Oh god why does it need static-libs on google-perftools? That's calling for trouble. But I guess I have to restore that crap :( No you don't :) rethinkdb is a young project and its build system is a 1.5k lines makefile horror. I wouldn't reintroduce stuff that isn't used in tree just for this. I, at least, am not interested in moving this to the tree. I just added it to my overlay for a testing work stuff and that need is gone for now :). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] Relaying a message from python software foundation
In case you missed it and work in Europe with Python, http://pyfound.blogspot.fr/2013/02/python-trademark-at-risk-in-europe-we.html -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Last time touched bugs by year
Le jeudi 14 février 2013 à 19:19 +0100, Tomáš Chvátal a écrit : Hi, I added the bug queries to http://qa-reports.gentoo.org/ based by year of last being touched. Take look, try to close the oldest ones/invalid ones and so on. I think it is lame we have bugs last touched in 2k5 :-P This is nice. On another note, I just saw a report for EAPI per eclass which is super nice but unfortunately, EAPI=5 is listed but actually unsupported by the result of the scan :) -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
Le lundi 11 février 2013 à 23:48 +0100, Diego Elio Pettenò a écrit : I'd say, Go for it! But on the other hand I wonder if it might make sense to have something more generic, so that one only has to call something in a way such as virtualx_setup run_tests --foo virtualx_cleanup This sounds nice but is imho but can be elaborated later on. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Removals reply
Le lundi 04 février 2013 à 12:08 +0100, Michael Weber a écrit : On 02/03/2013 07:07 AM, Alexandre Rostovtsev wrote: We the Gentoo developers strongly believe that this project is not fun and not important. veto. a) there is no we, b) there are conrary posts on this list. that doesn't mean this is the majority either. In any case, if anyone feels strongly about this, it should probably be discussed on -project and/or brought up to the council. I have absolutely no interest in having Gentoo be some kind of archive distro and will not read any further mail in this thread since it has looped a few times already on the same arguments. Thanks for reading this captain obvious mail. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due lack of time
Le dimanche 03 février 2013 à 12:44 +0100, Pacho Ramos a écrit : Due tester lack of time the following packages are up for grabs: app-dicts/verbiste I am taking this. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
Le samedi 26 janvier 2013 à 02:46 -0500, Mike Frysinger a écrit : On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: It's not like libcap is a big dependency true, but not everyone needs this, nor can everyone leverage it (caps). it's a linux-centric implementation and is dependent upon filesystem support being available enabled. that doesn't entirely justify making it a USE flag (since the code already has runtime fallback logic for when the fs doesn't support things), but since the USE is low overhead and leverages logic that already has to be there, i have no problem keeping it. plus it defaults to on. hum, ok. and it's not like this is an attempt to make the system more secure by according just the privileges needed for apps to work as intended, right ? mmm that's exactly what this is If the USE flag must stay, how is it different that current caps USE flag ? It applies and not just enables support but is that relevant to the purpose at hand ? [...] In summary, USE=caps if for stripping down from all to the bare minimum caps while USE=filecaps should allow us to provide bare minimum required capabilities from the start. If so, maybe this could be the same USE flag ? I would understand if we wanted to keep it separated to avoid potential confusion about the actual impact on packages though. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
This might be a silly question already answered in a previous thread, but why make it filecaps a USE-enable capability at all ? It's not like libcap is a big dependency and it's not like this is an attempt to make the system more secure by according just the privileges needed for apps to work as intended, right ? If the USE flag must stay, how is it different that current caps USE flag ? It applies and not just enables support but is that relevant to the purpose at hand ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] gst-plugins10.eclass support for multiple plugin build directory
Hi all,
this patch adds support for building plugins in different directory.
This has been a long TODO item but there is now a need for it since the
amrnb and amrwb codecs both depend on the same lib and I see no reason
to not have them under the same ebuild.
I am attaching the sample ebuild with it.
AMR* ebuild request is here:
https://bugs.gentoo.org/show_bug.cgi?id=306855
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[1;32mIndex: gst-plugins10.eclass[0;0m
[1;32m===[0;0m
[1;32mRCS file: /var/cvsroot/gentoo-x86/eclass/gst-plugins10.eclass,v[0;0m
[1;32mretrieving revision 1.9[0;0m
[1;32mdiff -u -B -r1.9 gst-plugins10.eclass[0;0m
[1;31m--- gst-plugins10.eclass 16 Jan 2013 22:52:37 - 1.9[0;0m
[1;34m+++ gst-plugins10.eclass 23 Jan 2013 22:56:06 -[0;0m
[1;35m@@ -58,13 +58,13 @@[0;0m
[0;0m # Defines the plugins to be built.[0;0m
[0;0m # May be set by an ebuild and contain more than one indentifier, space[0;0m
[0;0m # seperated (only src_configure can handle mutiple plugins at this time).[0;0m
[1;31m-GST_PLUGINS_BUILD=${PN/gst-plugins-/}[0;0m
[1;34m+: ${GST_PLUGINS_BUILD:=${PN/gst-plugins-/}}[0;0m
[0;0m [0;0m
[0;0m # @ECLASS-VARIABLE: GST_PLUGINS_BUILD_DIR[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Actual build directory of the plugin.[0;0m
[0;0m # Most often the same as the configure switch name.[0;0m
[1;31m-GST_PLUGINS_BUILD_DIR=${PN/gst-plugins-/}[0;0m
[1;34m+: ${GST_PLUGINS_BUILD_DIR:=${PN/gst-plugins-/}}[0;0m
[0;0m [0;0m
[0;0m # @ECLASS-VARIABLE: GST_TARBALL_SUFFIX[0;0m
[0;0m # @DESCRIPTION:[0;0m
[1;35m@@ -142,20 +142,24 @@[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m # @FUNCTION: gst-plugins10_find_plugin_dir[0;0m
[1;34m+# @USAGE: gst-plugins10_find_plugin_dir [build_dir][0;0m
[0;0m # @INTERNAL[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Finds plugin build directory and cd to it.[0;0m
[1;34m+# Defaults to ${GST_PLUGINS_BUILD_DIR} if argument is not provided[0;0m
[0;0m gst-plugins10_find_plugin_dir() {[0;0m
[1;31m- if [[ ! -d ${S}/ext/${GST_PLUGINS_BUILD_DIR} ]]; then[0;0m
[1;31m- if [[ ! -d ${S}/sys/${GST_PLUGINS_BUILD_DIR} ]]; then[0;0m
[1;34m+ local build_dir=${1:-${GST_PLUGINS_BUILD_DIR}}[0;0m
[1;34m+[0;0m
[1;34m+ if [[ ! -d ${S}/ext/${build_dir} ]]; then[0;0m
[1;34m+ if [[ ! -d ${S}/sys/${build_dir} ]]; then[0;0m
[0;0m ewarn No such plugin directory[0;0m
[0;0m die[0;0m
[0;0m fi[0;0m
[1;31m- einfo Building system plugin ${GST_PLUGINS_BUILD_DIR} ...[0;0m
[1;31m- cd ${S}/sys/${GST_PLUGINS_BUILD_DIR}[0;0m
[1;34m+ einfo Building system plugin in ${build_dir}...[0;0m
[1;34m+ cd ${S}/sys/${build_dir}[0;0m
[0;0m else[0;0m
[1;31m- einfo Building external plugin ${GST_PLUGINS_BUILD_DIR} ...[0;0m
[1;31m- cd ${S}/ext/${GST_PLUGINS_BUILD_DIR}[0;0m
[1;34m+ einfo Building external plugin in ${build_dir}...[0;0m
[1;34m+ cd ${S}/ext/${build_dir}[0;0m
[0;0m fi[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[1;35m@@ -171,15 +175,16 @@[0;0m
[0;0m local directory libs pkgconfig pc tuple[0;0m
[0;0m pkgconfig=$(tc-getPKG_CONFIG)[0;0m
[0;0m [0;0m
[1;31m- gst-plugins10_find_plugin_dir[0;0m
[1;31m-[0;0m
[1;31m- for tuple in $@ ; do[0;0m
[1;31m- directory=$(echo ${tuple} | cut -f1 -d':')[0;0m
[1;31m- pc=$(echo ${tuple} | cut -f2 -d':')-${SLOT}[0;0m
[1;31m- libs=$(${pkgconfig} --libs-only-l ${pc})[0;0m
[1;34m+ for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do[0;0m
[1;34m+ gst-plugins10_find_plugin_dir ${plugin_dir}[0;0m
[0;0m [0;0m
[1;31m- sed -e s:\$(top_builddir)/${directory}/.*\.la:${libs}: \[0;0m
[1;31m- -i Makefile.am Makefile.in || die[0;0m
[1;34m+ for tuple in $@ ; do[0;0m
[1;34m+ directory=$(echo ${tuple} | cut -f1 -d':')[0;0m
[1;34m+ pc=$(echo ${tuple} | cut -f2 -d':')-${SLOT}[0;0m
[1;34m+ libs=$(${pkgconfig} --libs-only-l ${pc})[0;0m
[1;34m+ sed -e s:\$(top_builddir)/${directory}/.*\.la:${libs}: \[0;0m
[1;34m+-i Makefile.am Makefile.in || die[0;0m
[1;34m+ done[0;0m
[0;0m done[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[1;35m@@ -253,29 +258,37 @@[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Compiles requested gstreamer plugin.[0;0m
[0;0m gst-plugins10_src_compile() {[0;0m
[1;34m+ local plugin_dir[0;0m
[1;34m+ [0;0m
[0;0m has ${EAPI:-0} 0 1 gst-plugins10_src_configure $@[0;0m
[0;0m [0;0m
[1;31m- gst-plugins10_find_plugin_dir[0;0m
[1;34m+ for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do[0;0m
[1;34m+ gst-plugins10_find_plugin_dir ${plugin_dir}[0;0m
[0;0m [0;0m
[1;31m- if has ${EAPI:-0} 0 1 2 3 ; then[0;0m
[1;31m- emake || die[0;0m
[1;31m- else[0;0m
[1;31m- default[0;0m
[1;31m- fi[0;0m
[1;34m+ if has ${EAPI:-0} 0 1 2 3 ; then[0;0m
[1;34m+ emake || die[0;0m
[1;34m+ else[0;0m
[1;34m+ default[0;0m
[1;34m+ fi[0;0m
[1;34m+ done[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m # @FUNCTION: gst-plugins10_src_install[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit : Michał Górny schrieb: Hello, There is a fair interest in multilib and while still early, it would be a good moment to decide on how USE flags to use for it. The current attempts are mostly using USE=multilib which is not really expressive and poor. What I would go for is a clear variable specifying which targets package is built for. This raises the following questions: 1) do we want the default ABI to be switchable? 2) do we want irrelevant ABIs to be visible to emerge users? By 2) I mean: do we want the users to see stuff like: MULTILIB_ABIS=amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) (-ppc64_abi2) (-ppc64_abi3) ... or just the relevant part. To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. What are your thoughts? Which arches would like to use multilib? What names for ABIs do you suggest? So you want to re-implement multilib-portage in an eclass without the additional benefits a package-manager level implementation has? Well that's the point of the eclass that was proposed a few days ago allow building multiple ABIs. Having clear USE-dep like python-r1.eclass is imho the way to go. As said in another reply of this thread, USE=multilib really is a solution that has its problems (no fine PM control for ABIs, slow updates of emul-pkgs) to the current problem and portage-multilib, well it's a subject that pops up from time to time I have no idea how and will it will come nor do I have time to help on that front. However this eclass would enable quick and easy per-ebuild support for multiple ABIs just like python-r1 and friends, and this is a good thing for every maintainer that wants to provide this kind of support. I know I would, at least to get rid of the always lagging emul packages. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
Le dimanche 13 janvier 2013 à 16:08 +0100, Michał Górny a écrit :
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
with python_foreach_impl setting BUILD_DIR.
FTR, this function is used as-is in quite a few gnome ebuilds that use
python-r1 eclass. We thought that it could probably be used in other
places but it would be nice if we could have changes to would make it
not suitable for this purpose.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
Le dimanche 13 janvier 2013 à 09:52 -0600, William Hubbs a écrit :
On Sun, Jan 13, 2013 at 04:08:18PM +0100, Michał Górny wrote:
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
Can you not change the logic so it doesn't die if build_dir isn't set,
but uses the value of $1 and calls shift?
I guess an explicit option would be less error prone, eg. :
run_in_dir -d foodir barfunc arg1 arg2
or
run_in_dir --directory foodir barfunc arg1 arg2
documentation could then mention that the function defaults to BUILD_DIR
if this option is not set and fails if nothing is set.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[gentoo-dev] [PATCH 0/4] gnome2.eclass updates
Hi list, here are a couple of patches to fix some bad behavior of the gnome2.eclass. They have been sitting in the overlay for a while and I don't expect them to cause any problem so I will commit then later today if nobody objects. Gilles Dartiguelongue (4): eclass/gnome2.eclass: switch IUSE tests to in_iuse, bug #383901 eclass/gnome2.eclass: drop deprecated SCROLLKEEPER_UPDATE eclass/gnome2.eclass: allow ebuild override of eclass generated econf eclass/gnome2.eclass: update wrt comment on bug #383901 eclass/gnome2.eclass | 28 +++- 1 file changed, 11 insertions(+), 17 deletions(-) -- 1.8.1 -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
has bla ${IUSE} is standardized through in_iuse. Make use of this function.
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 70eb491..e263232 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -158,7 +158,7 @@ gnome2_src_configure() {
# rebuild docs.
# Preserve old behavior for older EAPI.
if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
G2CONF=${G2CONF} $(use_enable doc gtk-doc)
else
G2CONF=${G2CONF} --disable-gtk-doc
@@ -266,7 +266,7 @@ gnome2_src_install() {
if has ${EAPI:-0} 0 1 2 3 4; then
if [[ ${GNOME2_LA_PUNT} != no ]]; then
ebegin Removing .la files
- if ! { has static-libs ${IUSE//+} use static-libs;
}; then
+ if ! { in_iuse static-libs use static-libs; }; then
find ${D} -name '*.la' -exec rm -f {} + ||
die la file removal failed
fi
eend
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/4] drop deprecated SCROLLKEEPER_UPDATE
SCROLLKEEPER_UPDATE variable was deprecated long ago. It is no longer needed
and no longer in use in tree.
---
eclass/gnome2.eclass | 6 --
1 file changed, 6 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index e263232..e2540d1 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -68,12 +68,6 @@ ELTCONF=${ELTCONF:-}
# Should we use EINSTALL instead of DESTDIR
USE_EINSTALL=${USE_EINSTALL:-}
-# @ECLASS-VARIABLE: SCROLLKEEPER_UPDATE
-# @DEPRECATED
-# @DESCRIPTION:
-# Whether to run scrollkeeper for this package or not.
-SCROLLKEEPER_UPDATE=${SCROLLKEEPER_UPDATE:-1}
-
# @ECLASS-VARIABLE: DOCS
# @DEFAULT-UNSET
# @DESCRIPTION:
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/4] allow ebuild override of eclass generated econf
gnome2.eclass appends configure switches to user arguments.
Change logic so that it prepends values to G2CONF and pass extra args
of
gnome2_src_configure after G2CONF so that ebuilds can indeed override
eclass
settings.
---
eclass/gnome2.eclass | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index e2540d1..750f20b 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -140,7 +140,7 @@ gnome2_src_configure() {
# Update the GNOME configuration options
if [[ ${GCONF_DEBUG} != 'no' ]] ; then
if use debug ; then
- G2CONF=${G2CONF} --enable-debug=yes
+ G2CONF=--enable-debug=yes ${G2CONF}
fi
fi
@@ -153,44 +153,44 @@ gnome2_src_configure() {
# Preserve old behavior for older EAPI.
if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
- G2CONF=${G2CONF} $(use_enable doc gtk-doc)
+ G2CONF=$(use_enable doc gtk-doc) ${G2CONF}
else
- G2CONF=${G2CONF} --disable-gtk-doc
+ G2CONF=--disable-gtk-doc ${G2CONF}
fi
fi
# Pass --disable-maintainer-mode when needed
if grep -q ^[[:space:]]*AM_MAINTAINER_MODE(\[enable\]) \
${ECONF_SOURCE:-.}/configure.*; then
- G2CONF=${G2CONF} --disable-maintainer-mode
+ G2CONF=--disable-maintainer-mode ${G2CONF}
fi
# Pass --disable-scrollkeeper when possible
if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure; then
- G2CONF=${G2CONF} --disable-scrollkeeper
+ G2CONF=--disable-scrollkeeper ${G2CONF}
fi
# Pass --disable-silent-rules when possible (not needed for eapi5),
bug #429308
if has ${EAPI:-0} 0 1 2 3 4; then
if grep -q disable-silent-rules ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-silent-rules
+ G2CONF=--disable-silent-rules ${G2CONF}
fi
fi
# Pass --disable-schemas-install when possible
if grep -q disable-schemas-install ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-schemas-install
+ G2CONF=--disable-schemas-install ${G2CONF}
fi
# Pass --disable-schemas-compile when possible
if grep -q disable-schemas-compile ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-schemas-compile
+ G2CONF=--disable-schemas-compile ${G2CONF}
fi
# Avoid sandbox violations caused by gnome-vfs (bug #128289 and
#345659)
addwrite $(unset HOME; echo ~)/.gnome2
- econf $@ ${G2CONF}
+ econf ${G2CONF} $@
}
# @FUNCTION: gnome2_src_compile
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 4/4] update wrt comment on bug #383901
Update previous patch fixing bug #383901 with comments on this bug.
---
eclass/gnome2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 750f20b..592585c 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -260,7 +260,7 @@ gnome2_src_install() {
if has ${EAPI:-0} 0 1 2 3 4; then
if [[ ${GNOME2_LA_PUNT} != no ]]; then
ebegin Removing .la files
- if ! { in_iuse static-libs use static-libs; }; then
+ if ! use_if_iuse static-libs ; then
find ${D} -name '*.la' -exec rm -f {} + ||
die la file removal failed
fi
eend
--
1.8.1
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
Le dimanche 13 janvier 2013 à 19:09 +, Ciaran McCreesh a écrit :
On Sun, 13 Jan 2013 20:03:20 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
This is still wrong... You can't use IUSE like that.
I think this debate has already happened on this very list.
I don't presently want to fix your particular issues with that solution
but at the very least we can use the same hack (if you will)
everywhere so it is more easy to search for and eventually fix later on.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] Handy pybugz wrappers
Le samedi 12 janvier 2013 à 12:03 +0100, Michał Górny a écrit : On Fri, 11 Jan 2013 23:56:17 -0600 Doug Goldstein car...@gentoo.org wrote: Anyone have handy pybugz wrappers for bumping ebuilds and fixing bugs? I'm so used to the environment at work where a post-commit hook parses specifically formatted commit messages to take several actions on commits. I figure before I hack on any I'd ask if someone has some that could be shared with the community. Really just looking to combine steps like echangelog and repoman commit with pybugz. Here is my dummy wrapper for that. I wrote a variation of that as a git hooks for overlays if that is what you are really after. -- Gilles Dartiguelongue e...@gentoo.org Gentoo ecommit.sh Description: application/shellscript
Re: [gentoo-dev] gstreamer eclass review
Le jeudi 06 décembre 2012 à 06:01 +0200, Maxim Kammerer a écrit :
Hi, after the commit 3 days ago all kinds of plugins suddenly depend
on gst-plugins-bad. E.g.: gst-plugins-{dts,faad,libmms,resindvd,xvid}.
Is gst-plugins-bad eclass the wrong one to inherit in their case?
Also, vp8 plugin both inherits from the eclas, and has an explicit
dependency on media-libs/gst-plugins-bad — perhaps one or the other
should be removed.
Please open bug reports at gentoo's bugzilla if you have problem with
the ebuilds.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
Le mercredi 05 décembre 2012 à 17:02 -0600, Doug Goldstein a écrit : class checks the configure script for certain items and adjusts the arguments to econf based on those checks. Unfortunately when checking the configure script it did not respect ECONF_SOURCE. Looks good. Might need to apply these fixes to gstreamer eclasses as well. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : Currently we have an eselect module to switch between different implementations by setting /usr/lib/lib[blas,lapack].so to the selected implementation. This has two drawbacks, which some of you might already of hit: 1. They seem to be not completely API/ABI compatible (I don't which one is correct here. And please don't be nitpicking on this point). So switching would mean recompilation of all packages linked against it before, otherwise you might get runtime errors. This takes time and triggers point 2. 2. As andy showed we should stick with specific implementations for specific tasks. The current way flattens this out to be optimal for some and suboptimal for others. Now, there has been a lot of effort around Andy and Sebastien to solve this problem. The solution is simple: don't install any libblas.so or liblapack.so in libdir, but instead make the pkg-config module eselectable and force packages to used pkg-config. Nearly (I think its 100%) of the packages in the tree already use pkg-config to detect blas/lapack. I think I understand the problem now. You should not patch/generate .pc files but install them to an implementation specific subdirectory. That way, you just have to append that path to PKGCONFIG_PATH when configuring your package using blas and you should be able to transparently select which implementation to get without further patching of either upstream or downstream packages. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 4/4] Example conversion of pygobject to python-r1 + autotools-utils.
First, thanks for this patch, I was planning on converting it but did
not have to do it.
Le jeudi 29 novembre 2012 à 14:40 +0100, Michał Górny a écrit :
---
.../dev-python/pygobject/pygobject-3.2.2-r1.ebuild | 106
+
1 file changed, 106 insertions(+)
create mode 100644 gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
diff --git a/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
new file mode 100644
index 000..289eace
--- /dev/null
+++ b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
@@ -0,0 +1,106 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header:
/var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5
2012/09/28 05:45:45 mattst88 Exp $
+
+EAPI=4
+GCONF_DEBUG=no
+PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
+AUTOTOOLS_AUTORECONF=1
+
+inherit autotools-utils eutils gnome2 python-r1 virtualx
Please do not mix autotools utils with gnome2 eclass. gnome team does
not support out of tree builds for now. I have plans to integrate this
in the eclass but we found that upstream generally does not test this so
we want to test it more extensively before making this available.
+# FIXME: With python multiple ABI support, tests return 1 even when they pass
+src_test() {
+ local DBUS_SESSION_BUS_ADDRESS
+ local GIO_USE_VFS='local' # prevents odd issues with deleting ${T}/.gvfs
+ local VIRTUALX_COMMAND=python_test
+
+ export GIO_USE_VFS
+
+ python_foreach_impl virtualmake
+
+ python_execute_function -s testing
+}
+
dbus variables needs to be unset for tests to work when you do your
builds from a terminal started from your desktop, is that really
equivalent ?
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Le jeudi 29 novembre 2012 à 10:07 +0100, justin a écrit : On 29/11/12 09:48, Gilles Dartiguelongue wrote: Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : Currently we have an eselect module to switch between different implementations by setting /usr/lib/lib[blas,lapack].so to the selected implementation. This has two drawbacks, which some of you might already of hit: 1. They seem to be not completely API/ABI compatible (I don't which one is correct here. And please don't be nitpicking on this point). So switching would mean recompilation of all packages linked against it before, otherwise you might get runtime errors. This takes time and triggers point 2. 2. As andy showed we should stick with specific implementations for specific tasks. The current way flattens this out to be optimal for some and suboptimal for others. Now, there has been a lot of effort around Andy and Sebastien to solve this problem. The solution is simple: don't install any libblas.so or liblapack.so in libdir, but instead make the pkg-config module eselectable and force packages to used pkg-config. Nearly (I think its 100%) of the packages in the tree already use pkg-config to detect blas/lapack. I think I understand the problem now. You should not patch/generate .pc files but install them to an implementation specific subdirectory. If I get you correctly you are assuming that we have pkgconfig files for all implementations coming from upstreams. That's not correct, we have nearly none. So we need to generate them our own. And yes this need to be sent upstream. That's the reason for the eclass. That way, you just have to append that path to PKGCONFIG_PATH when configuring your package using blas and you should be able to transparently select which implementation to get without further patching of either upstream or downstream packages. This would mean that the pkg maintainer decides the implementation. But we leave this choice to the user which works fine. And we have a working eselect based solution. No, this means you can then use USE flags to select it which is package manager controlled and usually easier to deal with than eselected stuff. For example, if you know some packages have to be built with the same blas implementation to work properly together, you can do USE deps which is not possible with eselect and I am sure this is not the only case. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] New global useflag proposals
Le vendredi 23 novembre 2012 à 15:03 +0100, Tomáš Chvátal a écrit : Hi guys, wayland: Enable dev-libs/wayland backend vdpau: Enable the Video Decode and Presentation API for Unix acceleration interface. While at it, I'd like to finally have USE=introspection a global USE flag. The gnome team had to stay with local flags because we are not willing to change ebuilds (114 by use.local.desc count) using it and we've always had an argument that maybe someday, somebody else will do introspection and that would confuse people. Well it's been a few years now (at least 2 by gnome release count), and nothing comparable has emerged in gentoo (at least). So, can we go forward with this now ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [python-single-r1 1/3] A conceptual eclass for packages not supporting multiple Python impls.
Le mercredi 21 novembre 2012 à 23:19 +0100, Michał Górny a écrit :
diff --git a/gx86/eclass/python-single-r1.eclass
b/gx86/eclass/python-single-r1.eclass
new file mode 100644
index 000..3d21ea8
--- /dev/null
+++ b/gx86/eclass/python-single-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/eclass/python-r1.eclass,v 1.20 2012/11/21
09:04:14 mgorny Exp $
+
+# @ECLASS: python-single-r1
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# Python herd pyt...@gentoo.org
+# @AUTHOR:
+# Author: Michał Górny mgo...@gentoo.org
+# Based on work of: Krzysztof Pawlik nelch...@gentoo.org
+# @BLURB: An eclass for Python packages not installed for multiple
implementations.
+# @DESCRIPTION:
+# An extension of the python-r1 eclass suite for packages which
+# don't support being installed for multiple Python implementations.
+# This mostly includes tools embedding Python.
+#
+# This eclass extends the IUSE and REQUIRED_USE set by python-r1
+# to request correct PYTHON_SINGLE_TARGET. It also replaces
+# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
+#
+# Please note that packages support multiple Python implementations
+# (using python-r1 eclass) can not depend on packages not supporting
+# them (using this eclass).
+#
+# Also, please note that python-single-r1 will always inherit python-r1
+# as well. Thus, all the variables defined and documented there are
+# relevant to the packages using python-single-r1.
+
+case ${EAPI} in
you are missing the default EAPI value for EAPI=0 usually this is
written: case ${EAPI:-0}
+ 0|1|2|3)
+ die Unsupported EAPI=${EAPI} (too old) for ${ECLASS}
+ ;;
+ 4|5)
+ # EAPI=4 needed by python-r1
+ ;;
+ *)
+ die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
+ ;;
+esac
+
The rest looks fine.
Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.
Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a écrit : On 21/11/12 04:43 AM, Michał Górny wrote: Moved: python_export, getters, python_domodule, python_doscript and the necessary internal functions. No global-scope variables, no phase functions. [ Snip! ] So remind me again, in 10 words or less, why these shouldn't all stay in python-r1.eclass? ie, what use case do we have for using python-utils-r1 but not python-r1 (or vice-versa, depending on which one inherits the other)? From [gentoo-dev] python-r1.eclass: the masterplan (dirty RFC) email: Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit : 1) splitting common functions into python-utils-r1. The python-utils-r1 eclass would provide means to work with specific Python packages like portage. Unlike python-r1, it would not export IUSE or require any specific USE flags. I'm not insisting on this nor giving it a very high priority. It is a straightforward change since python-r1 will inherit the new eclass anyway.
Re: [gentoo-dev] gstreamer eclass review
Le mercredi 21 novembre 2012 à 16:27 +0100, Tomáš Chvátal a écrit : Hi Gilles, The eclass itself looks fine, I would just ask if you would not mind to use the bash += syntax rather than VAR=VAR something as it is shorter and easier to read. Sure, I'm not a fan of +=, it seems alien to shell for me, but if this is preferred, I have no problem changing it. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Reminder: open season on robbat2's packages
Le dimanche 18 novembre 2012 à 11:11 +, Robin H. Johnson a écrit : net-nds/nsscache sys-auth/nss_ldap If nobody else want them and I don't forget about them, I'll take care of these. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] gstreamer eclass review
Hi list,
gstreamer-1 has been around for some time now and it is needed for gnome
3.6 to enter the tree. Since gstreamer devs have been a bit busy irl, a
few guys from gnome herd decided to take a look at it and try to bump
everything. I had an itch to scratch wrt current eclass writing so I
decided to start with that and bump all plugins using these new eclasses
to see how they fare. The results seems to be a lot more pleasant to
read and easier to understand.
Since this is basically a rewrite, I'll attach the full files for review
and three ebuilds using it (one regular plugin, one plugin linking to
installed gstreamer libs and one of the ebuilds with no external
dependency.
The goal of these new eclasses is mainly to drop all revision dependent
code while maintaining (to some extent) backward compatibility with 0.10
slot ebuilds.
We are currently not planning on dropping the mostly empty eclasses just
in case there is a need for pack specific changes in the future.
The eclasses were already overlooked by gstreamer herd but I'd like more
eyes to go over them beforing pushing this to the tree.
Since this is mostly privates eclasses, I'd like to proceed to tree
inclusion by next week. There should be little to no breakage and this
would help bump last 0.10 releases as well.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: gst-plugins10.eclass
# @MAINTAINER:
# gstrea...@gentoo.org
# @AUTHOR:
# Gilles Dartiguelongue e...@gentoo.org
# Saleem Abdulrasool compn...@gentoo.org
# foser fo...@gentoo.org
# zaheerm zahe...@gentoo.org
# @BLURB: Manages build for invididual ebuild for gst-plugins.
# @DESCRIPTION:
# Eclass to make external gst-plugins emergable on a per-plugin basis and
# to solve the problem with gst-plugins generating far too much unneeded
# dependancies.
#
# GStreamer consuming applications should depend on the specific plugins they
# need as defined in their source code.
#
# In case of spider usage, obtain recommended plugins to use from Gentoo
# developers responsible for gstreamer gstrea...@gentoo.org or the application
# developer.
# XXX: what was GST_ORC intended for. Isn't it better to leave it to the
# ebuild reponsability ?
inherit eutils multilib toolchain-funcs versionator
GST_EXPF=
case ${EAPI:-0} in
1|2|3|4|5)
GST_EXPF=${GST_EXPF} src_configure src_compile src_install
;;
0)
die EAPI=\${EAPI}\ is not supported anymore
;;
*)
die EAPI=\${EAPI}\ is not supported yet
;;
esac
EXPORT_FUNCTIONS ${GST_EXPF}
# @ECLASS-VARIABLE: GST_LA_PUNT
# @DESCRIPTION:
# Should we delete all the .la files?
# NOT to be used without due consideration.
if has ${EAPI:-0} 0 1 2 3; then
: ${GST_LA_PUNT:=no}
else
: ${GST_LA_PUNT:=yes}
fi
# @ECLASS-VARIABLE: GST_ORC
# @DESCRIPTION:
# Ebuild supports dev-lang/orc.
: ${GST_ORC:=no}
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD
# @DESCRIPTION:
# Defines the plugins to be built.
# May be set by an ebuild and contain more than one indentifier, space
# seperated (only src_configure can handle mutiple plugins at this time).
GST_PLUGINS_BUILD=${PN/gst-plugins-/}
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD_DIR
# @DESCRIPTION:
# Actual build directory of the plugin.
# Most often the same as the configure switch name.
GST_PLUGINS_BUILD_DIR=${PN/gst-plugins-/}
# @ECLASS-VARIABLE: GST_TARBALL_SUFFIX
# @DESCRIPTION:
# Most projects hosted on gstreamer.freedesktop.org mirrors provide tarballs as
# tar.bz2 or tar.xz. This eclass defaults to bz2 for EAPI 0, 1, 2, 3 and
# defaults to xz for everything else. This is because the gstreamer mirrors
# are moving to only have xz tarballs for new releases.
if has ${EAPI:-0} 0 1 2 3; then
: ${GST_TARBALL_SUFFIX:=bz2}
else
: ${GST_TARBALL_SUFFIX:=xz}
fi
# Even though xz-utils are in @system, they must still be added to DEPEND; see
# http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
if [[ ${GST_TARBALL_SUFFIX} == xz ]]; then
DEPEND=${DEPEND} app-arch/xz-utils
fi
# @ECLASS-VARIABLE: GST_ORG_MODULE
# @DESCRIPTION:
# Name of the module as hosted on gstreamer.freedesktop.org mirrors.
# Leave unset if package name matches module name.
: ${GST_ORG_MODULE:=$PN}
# @ECLASS-VARIABLE: GST_ORG_PVP
# @INTERNAL
# @DESCRIPTION:
# Major and minor numbers of the version number.
: ${GST_ORG_PVP:=$(get_version_component_range 1-2)}
DESCRIPTION=${BUILD_GST_PLUGINS} plugin for gstreamer
HOMEPAGE=http://gstreamer.freedesktop.org/;
SRC_URI=http://gstreamer.freedesktop.org/src/${GST_ORG_MODULE}/${GST_ORG_MODULE}-${PV}.tar.${GST_TARBALL_SUFFIX};
LICENSE=GPL-2
SLOT=${GST_ORG_PVP}
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
# Do not run test phase for invididual plugin ebuilds.
RESTRICT=test
fi
RDEPEND=${RDEPEND}
=dev-libs
