Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver

[Davide Pesavento]

On Thu, Dec 17, 2020 at 1:12 PM Mike Gilbert  wrote:
>
> Signed-off-by: Mike Gilbert 
> ---
>
> v2: Added "This upload is required in addition to uploading the SKS pool."
>
>  glep-0063.rst | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 82541bd..ec465db 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -7,10 +7,10 @@ Author: Robin H. Johnson ,
>  Michał Górny 
>  Type: Standards Track
>  Status: Final
> -Version: 2.1
> +Version: 2.2
>  Created: 2013-02-18
> -Last-Modified: 2019-11-07
> -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24
> +Last-Modified: 2020-12-17
> +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17
>  Content-Type: text/x-rst
>  ---
>
> @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux 
> distribution.
>  Changes
>  ===
>
> +v2.2
> +  Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter.
> +
>  v2.1
>A requirement for an encryption key has been added, in order to extend
>the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev
> @@ -135,8 +138,11 @@ their primary key).
>
>  5. Encrypted backup of your secret keys.
>
> +Gentoo Infrstructure

Typo.

> +
> +
>  Gentoo LDAP
> -===
> +---
>
>  All Gentoo developers must list the complete fingerprint for their primary
>  keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex 
> digits,
> @@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently 
> displays
>  the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
>  be displayed instead.
>
> +Gentoo Keyserver
> +
> +
> +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool.
> +This keyserver is restricted to accepting uploads from authorized Gentoo 
> hosts.
> +A script is provided on dev.gentoo.org to allow developers to upload their
> +keys. This upload is required in addition to uploading to the SKS pool.
> +
> +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload``
> +
>  Backwards Compatibility
>  ===
>
> --
> 2.30.0.rc0
>
>

The rest LGTM.

Thanks,
Davide

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Davide Pesavento]

On Tue, Aug 21, 2018 at 11:57 AM Davide Pesavento  wrote:
>
> On Tue, Aug 21, 2018 at 2:46 AM Michał Górny  wrote:
> >
> > On Tue, 2018-08-21 at 01:54 -0400, Davide Pesavento wrote:
> > > On Mon, Aug 20, 2018 at 11:00 AM Michał Górny  wrote:
> > > >
> > > > Improve the description of USE=test to clearly indicate what the flag
> > > > does instead of claiming it workaround for Portage.
> > > > ---
> > > >  profiles/use.desc | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Changed in v2: added description of FEATURES=test relevance
> > > >
> > > > diff --git a/profiles/use.desc b/profiles/use.desc
> > > > index 078226b92250..bd360194a09b 100644
> > > > --- a/profiles/use.desc
> > > > +++ b/profiles/use.desc
> > > > @@ -338,7 +338,7 @@ taglib - Enable tagging support with taglib
> > > >  tcl - Add support the Tcl language
> > > >  tcmalloc - Use the dev-util/google-perftools libraries to replace the 
> > > > malloc() implementation with a possibly faster one
> > > >  tcpd - Add support for TCP wrappers
> > > > -test - Workaround to pull in packages needed to run with 
> > > > FEATURES=test. Portage-2.1.2 handles this internally, so don't set it 
> > > > in make.conf/package.use anymore
> > > > +test - Enable dependencies and/or preparations necessary to run tests 
> > > > (usually automatically controled by FEATURES=test but can be switched 
> > > > independently)
> > >
> > > s/controled/controlled/
> > > s/switched/enabled/
> >
> > It can also be disabled.  Maybe 'toggled'?
> >
>
> Wait, are you saying that I can set USE=-test while FEATURES=test is
> enabled? Is that a valid combination?

make.conf(5) says the following regarding FEATURES=test:

This feature implies the "test"USE flag if it is a member of IUSE,
either explicitly or implicitly [...]. The "test" USE flag is also
automatically disabled when the "test" feature is disabled.

So, it looks like the whole "independently" part in the use desc is incorrect.

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Davide Pesavento]

On Tue, Aug 21, 2018 at 2:46 AM Michał Górny  wrote:
>
> On Tue, 2018-08-21 at 01:54 -0400, Davide Pesavento wrote:
> > On Mon, Aug 20, 2018 at 11:00 AM Michał Górny  wrote:
> > >
> > > Improve the description of USE=test to clearly indicate what the flag
> > > does instead of claiming it workaround for Portage.
> > > ---
> > >  profiles/use.desc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Changed in v2: added description of FEATURES=test relevance
> > >
> > > diff --git a/profiles/use.desc b/profiles/use.desc
> > > index 078226b92250..bd360194a09b 100644
> > > --- a/profiles/use.desc
> > > +++ b/profiles/use.desc
> > > @@ -338,7 +338,7 @@ taglib - Enable tagging support with taglib
> > >  tcl - Add support the Tcl language
> > >  tcmalloc - Use the dev-util/google-perftools libraries to replace the 
> > > malloc() implementation with a possibly faster one
> > >  tcpd - Add support for TCP wrappers
> > > -test - Workaround to pull in packages needed to run with FEATURES=test. 
> > > Portage-2.1.2 handles this internally, so don't set it in 
> > > make.conf/package.use anymore
> > > +test - Enable dependencies and/or preparations necessary to run tests 
> > > (usually automatically controled by FEATURES=test but can be switched 
> > > independently)
> >
> > s/controled/controlled/
> > s/switched/enabled/
>
> It can also be disabled.  Maybe 'toggled'?
>

Wait, are you saying that I can set USE=-test while FEATURES=test is
enabled? Is that a valid combination?

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Davide Pesavento]

On Mon, Aug 20, 2018 at 11:00 AM Michał Górny  wrote:
>
> Improve the description of USE=test to clearly indicate what the flag
> does instead of claiming it workaround for Portage.
> ---
>  profiles/use.desc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Changed in v2: added description of FEATURES=test relevance
>
> diff --git a/profiles/use.desc b/profiles/use.desc
> index 078226b92250..bd360194a09b 100644
> --- a/profiles/use.desc
> +++ b/profiles/use.desc
> @@ -338,7 +338,7 @@ taglib - Enable tagging support with taglib
>  tcl - Add support the Tcl language
>  tcmalloc - Use the dev-util/google-perftools libraries to replace the 
> malloc() implementation with a possibly faster one
>  tcpd - Add support for TCP wrappers
> -test - Workaround to pull in packages needed to run with FEATURES=test. 
> Portage-2.1.2 handles this internally, so don't set it in 
> make.conf/package.use anymore
> +test - Enable dependencies and/or preparations necessary to run tests 
> (usually automatically controled by FEATURES=test but can be switched 
> independently)

s/controled/controlled/
s/switched/enabled/

>  theora - Add support for the Theora Video Compression Codec
>  threads - Add threads support for various packages. Usually pthreads
>  tidy - Add support for HTML Tidy
> --
> 2.18.0
>

Thanks,
Davide

Re: [gentoo-dev] [PATCH 4/4] package.use.mask: Mask ICU supprt of Qt:4 on 17.0 profiles

[Davide Pesavento]

On Wed, Jun 7, 2017 at 4:48 PM,   wrote:
> From: Andreas K. Hüttel 
>
> ---
>  profiles/releases/17.0/package.use.mask | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/profiles/releases/17.0/package.use.mask 
> b/profiles/releases/17.0/package.use.mask
> index 8eefcfe631ea..9a6609274ad1 100644
> --- a/profiles/releases/17.0/package.use.mask
> +++ b/profiles/releases/17.0/package.use.mask
> @@ -4,3 +4,8 @@
>  # Andreas K. Hüttel  (27 May 2017)
>  # Unmask default-PIE on 17.0 profiles.
>  sys-devel/gcc -pie
> +
> +# Andreas K. Hüttel  (7 June 2017)
> +# Qt-4 will never work with >=icu-59, see bug 618638 and bug 618640
> +dev-qt/qtcore:4 icu
> +dev-qt/qtwebkit:4 icu
> --
> 2.13.1
>
>

ACK

Re: [gentoo-dev] [PATCH] app-portage/eclass-manpages: @DEFAULT_UNSET -> @DEFAULT-UNSET

[Davide Pesavento]

On Sat, Apr 29, 2017 at 1:40 PM, Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 29 kwietnia 2017 19:23:49 CEST, Davide Pesavento <p...@gentoo.org> 
> napisał(a):
>>On Sat, Apr 29, 2017 at 1:57 AM, Michał Górny <mgo...@gentoo.org>
>>wrote:
>>> On sob, 2017-04-29 at 05:41 +0200, Ulrich Mueller wrote:
>>>> > > > > > On Fri, 28 Apr 2017, Michał Górny wrote:
>>>> > (and hyphens do not require holding shift).
>>>>
>>>> So they are awkward to type inside a string that is all-caps?
>>>>
>>>
>>> Funny enough, yes. I naturally let shift go when pushing '-' ;-).
>>> Some habit, probably. And I bet some people might actually use caps
>>> lock.
>>
>>So please remind me why everyone else has to adapt to your habits?
>
> Because I cared enough to do the work. If you want it the other way around, 
> then send the reverse patch instead of giving asshole comments.
>

Fair enough. FTR, I have no preference either way, this is 100%
bikeshedding if you ask me.

Also, I didn't mean to be rude, just wanted to point out that what you
said about being easier to type might not apply to everybody (in fact,
the opposite is probably true for most people). Another point against
hyphens is that all ebuild variables use underscore. But as I said I'm
fine either way.

Re: [gentoo-dev] [PATCH] app-portage/eclass-manpages: @DEFAULT_UNSET -> @DEFAULT-UNSET

[Davide Pesavento]

On Sat, Apr 29, 2017 at 1:57 AM, Michał Górny  wrote:
> On sob, 2017-04-29 at 05:41 +0200, Ulrich Mueller wrote:
>> > > > > > On Fri, 28 Apr 2017, Michał Górny wrote:
>> > (and hyphens do not require holding shift).
>>
>> So they are awkward to type inside a string that is all-caps?
>>
>
> Funny enough, yes. I naturally let shift go when pushing '-' ;-).
> Some habit, probably. And I bet some people might actually use caps
> lock.

So please remind me why everyone else has to adapt to your habits?

Re: [gentoo-dev] Last rites: leechcraft

[Davide Pesavento]

On Tue, Jan 31, 2017 at 9:50 AM, Georg Rudoy <0xd34df...@gmail.com> wrote:
> 2017-01-31 3:22 GMT-05:00 David Seifert :
>> Proxy-maint has always been there, so no real excuse for all those bugs
>> rotting away.
>
> I didn't bother with finding another maint who'd proxy it for me,
> yeah, that's my bad.
>
>
>> Here's the deal: If you fix all those bugs within the 30
>> day time period, we'll keep it in the tree. Please also modernize the
>> eclass a bit, and preferably drop all ebuilds to unstable.
>
> I'll make a new release of leechcraft itself and bump the version to
> that new one, so they'll naturally be dropped to unstable, 0.6.70 and
> earlier (if any) indeed could be removed. Most of the bugs, as I saw
> them, are due to the current last released version being 2.5 years old
> and obviously bitrotten somewhat since then.
>
> The ebuilds I have around use multibuild to build both qt4 and qt5
> versions according to use flags. Is that still relevant, or the world
> has migrated to qt5 and the benefit of still supporting qt4 is not
> worth the effort and clumsiness?

Yeah, drop qt4 please.

Thanks,
Davide

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Davide Pesavento]

On Thu, Jun 16, 2016 at 4:39 PM, Ian Stakenvicius  wrote:
> On 16/06/16 09:47 AM, Michał Górny wrote:
>> On Thu, 16 Jun 2016 16:22:32 +0300
>> Andrew Savchenko  wrote:
>>>
>>> CONFIRMED state is useful, it means that dev or powerful user
>>> confirmed this bug and gives it more value. I'd like to keep it.
>>
>> Are you saying that bugs that haven't been marked as CONFIRMED have
>> less value? Maybe they don't have to be handled at all, unless someone
>> you consider more worthy confirms them?
>>
>
> To me it's not about increased or decreased value per se, it's about
> workflow:
>
> - An UNCONFIRMED bug I have to reproduce myself and diagnose to
> determine if it's really a bug or if it's something else.
>
> - A CONFIRMED bug to me means this has already been done (by myself,
> others in the project, or dev's that should know the difference) and I
> can skip directly to identifying and fixing the issue.
>
> So when I look at the list of bugs for firefox I know what the state
> is more or less for things that are outstanding.  If I have just a
> little bit of time to hack away at things I'd rather try to close a
> CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
> don't have access to my dev system but have plenty of time, I may well
> try and triage UNCONFIRMED bugs.

+1

>
> IN_PROGRESS to me is something that should be reserved for when the
> fix is ready to go and just hasn't been fully applied or is readily
> available to all users (say, the fix is on an overlay for testing) --
> I would prefer not to start using that instead of CONFIRMED, but if
> that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
> merged to OPEN, I guess I could live with it.
>
>
>

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Davide Pesavento]

On Thu, Jun 16, 2016 at 3:02 PM, Michał Górny  wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
>
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
>
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

Agreed. However I don't see a strong reason to remove it, unless its
removal simplifies the introduction of STABILIZED. If it's useful to
some people, let them use it.

>
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
>
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.

Makes sense, although, as you said yourself, if it's not used
consistently it cannot be relied upon. Besides, we already have a
mechanism for expressing this, we make the stable request bug block
the tracker.

Thanks,
Davide

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Davide Pesavento]

On Thu, Jun 16, 2016 at 2:04 PM, Michał Górny  wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
>
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
>
> Revision two:
>
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
>
> Major changes:
>
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
>
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
>
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
>
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
>
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
>
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
>
> Your thoughts about this one?
>

Sounds good to me.

Thanks,
Davide

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Davide Pesavento]

On Wed, Jun 15, 2016 at 9:11 PM, Michał Górny  wrote:
> I would personally go for the following layout:
>
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.
>
[...]
>
> Your thoughts?
>

I'd split "eclasses" from "profiles", as they're not normally related
to each other.

We could also have separate components for "keywording" vs
"stabilization", which would make the use of STABLEREQ/KEYWORDREQ
keywords obsolete at the same time.

Thanks,
Davide

Re: [gentoo-dev] [RFC] New global USE flag: webp

[Davide Pesavento]

On Sat, Jun 4, 2016 at 12:45 PM, Chí-Thanh Christopher Nguyễn
 wrote:
> Suggested description: Add support for the WebP image format
> Currently in use by the following packages:
>
> app-text/tesseract:webp - Enable support for webp image format.
> dev-games/aseprite:webp - Enable webp image format support
> dev-libs/DirectFB:webp - build WebP image provider
> dev-libs/efl:webp - Enable WebP image loader
> dev-python/pillow:webp - Enable support for webp image format.
> dev-qt/qtwebkit:webp - Add support for WebP image format
> media-gfx/darktable:webp - Enable WebP export support
> media-gfx/fbida:webp - Enable support for the WebP image format
> media-gfx/graphicsmagick:webp - Enable support for webp image format
> media-gfx/gthumb:webp - Enable support for webp image format
> media-gfx/imagemagick:webp - Enable webp image format support using
> media-libs/libwebp
> media-gfx/imageworsener:webp - enable webp image format support
> media-gfx/nomacs:webp - Build support for WEBP image format
> media-gfx/qiviewer:webp - Build support for WEBP image format
> media-libs/gd:webp - Enable support for the webp format
> media-libs/gegl:webp - Enable support for media-libs/libwebp
> media-libs/jbig2enc:webp - Add support for WEBP image format
> media-libs/leptonica:webp - Adds support for the WebP image format
> media-libs/opencv:webp - Enable support for webp image format
> media-libs/sdl-image:webp - support loading WEBP images
> media-libs/sdl2-image:webp - support loading WEBP images
> media-video/ffmpeg:webp - Enables WebP encoding with media-libs/libwebp.
> media-video/libav:webp - Enable WebP encoding with media-libs/libwebp.
> www-client/netsurf:webp - WebP image support (media-libs/libwebp)
> x11-wm/windowmaker:webp - Enables WebP image format support using
> media-libs/libwebp
> x11-wm/xpra:webp - Enable webp image format support
>

+1

Re: [gentoo-dev] [PATCH] l10n.eclass: Sort and normalize PLOCALES in l10n_find_plocales_change

[Davide Pesavento]

On Sat, May 7, 2016 at 11:23 PM, James Le Cuirot <ch...@gentoo.org> wrote:
> On Sat, 7 May 2016 23:13:11 +0200
> Davide Pesavento <p...@gentoo.org> wrote:
>
>> On Sat, May 7, 2016 at 10:13 PM, James Le Cuirot <ch...@gentoo.org>
>> wrote:
>> > l10n_find_plocales_change assumes that PLOCALES is sorted
>> > alphanumerically with a single space between each entry and no
>> > surrounding whitespace. This is not a bad assumption but it isn't
>> > documented and it's inconvenient in at least one particular case.
>>
>> Does this also fix bug 513242?
>
> Bonus! I didn't think to check for any existing bug reports but I've
> tested this now and indeed it does. :) Thumbs up from you then?
>

Yep, +1 from me, although I was wondering whether there was a
cleaner/simpler way of writing that function...

Re: [gentoo-dev] [PATCH] l10n.eclass: Sort and normalize PLOCALES in l10n_find_plocales_change

[Davide Pesavento]

On Sat, May 7, 2016 at 10:13 PM, James Le Cuirot  wrote:
> l10n_find_plocales_change assumes that PLOCALES is sorted
> alphanumerically with a single space between each entry and no
> surrounding whitespace. This is not a bad assumption but it isn't
> documented and it's inconvenient in at least one particular case.
>
> MakeMKV uses non-standard locale names and I intend to map these using
> an associative array, which is possible as of EAPI 6. This allows me
> to do the following, though only with the above change as associative
> arrays are not ordered.
>
> declare -A MY_LOCALES
> MY_LOCALES=( [zh]=chi [da]=dan … )
> PLOCALES="${!MY_LOCALES[@]}"
> inherit l10n
>
> src_prepare() {
> PLOCALES="${MY_LOCALES[@]}" l10n_find_plocales_changes …
> }
>
> src_install() {
> for locale in $(l10n_get_locales); do
> doins makemkv_${MY_LOCALES[${locale}]}.mo.gz
> done
> }
> ---
>  eclass/l10n.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/l10n.eclass b/eclass/l10n.eclass
> index a7a6a26..26aa864 100644
> --- a/eclass/l10n.eclass
> +++ b/eclass/l10n.eclass
> @@ -86,7 +86,7 @@ l10n_find_plocales_changes() {
> current+="${x} "
> done
> popd >/dev/null
> -   if [[ ${PLOCALES} != ${current%[[:space:]]} ]] ; then
> +   if [[ $(tr -s "[:space:]" "\n" <<< "${PLOCALES}" | sort | xargs echo) 
> != ${current%[[:space:]]} ]] ; then
> einfo "There are changes in locales! This ebuild should be 
> updated to:"
> einfo "PLOCALES=\"${current%[[:space:]]}\""
> else
> --
> 2.7.1

Does this also fix bug 513242?

Thanks,
Davide

Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing

[Davide Pesavento]

On Sun, Mar 6, 2016 at 7:18 PM, Michał Górny <mgo...@gentoo.org> wrote:
> On Sun, 6 Mar 2016 18:12:03 +
> "Justin " <j...@gentoo.org> wrote:
>
>> On 06/03/16 12:24, Davide Pesavento wrote:
>> > On Sun, Mar 6, 2016 at 12:04 PM, Michał Górny <mgo...@gentoo.org> wrote:
>> >> On Sun, 6 Mar 2016 12:01:19 +0100
>> >> Michał Górny <mgo...@gentoo.org> wrote:
>> >>
>> >>> Please test and review. I'm going to reply to this mail with the list
>> >>> of current metadata.xml validation failures (it's quite long).
>> >>
>> >> And here's the list:
>> >>
>> > ...
>> >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: 
>> >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
>> >> 'media-libs/gstreamer:1.0' is not accepted by the pattern 
>> >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
>> >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: 
>> >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not 
>> >> a valid value of the atomic type 'pkgType'.
>> >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: 
>> >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
>> >> 'media-libs/gstreamer:0.10' is not accepted by the pattern 
>> >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
>> >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: 
>> >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is 
>> >> not a valid value of the atomic type 'pkgType'.
>> >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml fails to validate
>> >>
>> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: 
>> >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
>> >> 'media-libs/gstreamer:1.0' is not accepted by the pattern 
>> >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
>> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: 
>> >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not 
>> >> a valid value of the atomic type 'pkgType'.
>> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: 
>> >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
>> >> 'media-libs/gstreamer:0.10' is not accepted by the pattern 
>> >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
>> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: 
>> >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is 
>> >> not a valid value of the atomic type 'pkgType'.
>> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml fails to validate
>> >>
>> >
>> > Slots are not accepted in  elements? Is that intentional? If so,
>> > is there something else we can use?
>> >
>>
>> We should definitely include SLOTs in the allowed syntax.
>
> Why? What's their use? In fact, does  have any use? Because as I
> see it, it's just some fancy feature that could turn package name into
> link to packages.gentoo.org and nothing more...
>

Yeah that's what I thought too. If you really want you could also
check that the referenced package really exists in the tree...

So I guess we could use the following form when SLOTs are needed:
  media-libs/gstreamer:1.0
?

Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing

[Davide Pesavento]

On Sun, Mar 6, 2016 at 12:04 PM, Michał Górny  wrote:
> On Sun, 6 Mar 2016 12:01:19 +0100
> Michał Górny  wrote:
>
>> Please test and review. I'm going to reply to this mail with the list
>> of current metadata.xml validation failures (it's quite long).
>
> And here's the list:
>
...
> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: 
> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
> 'media-libs/gstreamer:1.0' is not accepted by the pattern 
> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: 
> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not a 
> valid value of the atomic type 'pkgType'.
> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: 
> Schemas validity error : Element 'pkg': [facet 'pattern'] The value 
> 'media-libs/gstreamer:0.10' is not accepted by the pattern 
> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: 
> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is not a 
> valid value of the atomic type 'pkgType'.
> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml fails to validate
>
> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: Schemas 
> validity error : Element 'pkg': [facet 'pattern'] The value 
> 'media-libs/gstreamer:1.0' is not accepted by the pattern 
> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: Schemas 
> validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not a valid 
> value of the atomic type 'pkgType'.
> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: Schemas 
> validity error : Element 'pkg': [facet 'pattern'] The value 
> 'media-libs/gstreamer:0.10' is not accepted by the pattern 
> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: Schemas 
> validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is not a valid 
> value of the atomic type 'pkgType'.
> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml fails to validate
>

Slots are not accepted in  elements? Is that intentional? If so,
is there something else we can use?

Thanks,
Davide

[gentoo-dev] Last rites: dev-python/PyQtMobility

[Davide Pesavento]

# Davide Pesavento <p...@gentoo.org> (06 Feb 2016)
# Masked for removal in 30 days. Doesn't build against recent PyQt4
# versions, bug 527572, not trivial to fix. Upstream doesn't seem to
# care anymore, last release was in 2012. Zero reverse deps.
dev-python/PyQtMobility

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Davide Pesavento]

On Tue, Jan 26, 2016 at 1:50 PM, Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 26 stycznia 2016 13:36:00 CET, Davide Pesavento <p...@gentoo.org> 
> napisał(a):
>>On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher <j...@gentoo.org> wrote:
>>> Signed-off-by: Justin Lecher <j...@gentoo.org>
>>> ---
>>>  eclass/cmake-utils.eclass | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>>> index 01de9a5..23339ab 100644
>>> --- a/eclass/cmake-utils.eclass
>>> +++ b/eclass/cmake-utils.eclass
>>> @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
>>>  # for econf and is needed to pass TRY_RUN results when
>>cross-compiling.
>>>  # Should be set by user in a per-package basis in
>>/etc/portage/package.env.
>>>
>>> -case ${EAPI} in
>>> +case ${EAPI:-0} in
>>> 2|3|4|5|6) : ;;
>>> *) die "EAPI=${EAPI:-0} is not supported" ;;
>>>  esac
>>> --
>>> 2.7.0
>>>
>>
>>Why?
>
> Indeed, why? I think it would be cleaner to simply quote the parameter to 
> case.
>

AFAIK even quoting would be unnecessary in this context (assuming bash).

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Davide Pesavento]

On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher  wrote:
> Signed-off-by: Justin Lecher 
> ---
>  eclass/cmake-utils.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 01de9a5..23339ab 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
>  # for econf and is needed to pass TRY_RUN results when cross-compiling.
>  # Should be set by user in a per-package basis in /etc/portage/package.env.
>
> -case ${EAPI} in
> +case ${EAPI:-0} in
> 2|3|4|5|6) : ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> --
> 2.7.0
>

Why?

Re: [gentoo-dev] [PATCH] eutils.eclass: In EAPI conditionals, replace "has" by case statements.

[Davide Pesavento]

On Mon, Nov 30, 2015 at 7:52 AM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Mon, 30 Nov 2015, Davide Pesavento wrote:
>
>>> The patch below replaces them by case statements. (Unfortunately we
>>> cannot use fall-through (&;) because it is a bash 4 feature.)
>
>> Sounds reasonable, although I'd find an 'if' clause slightly more
>> readable, since there wouldn't be an 'else' branch in 2 out of 3
>> cases.
>
> It is slightly more complicated to match multiple patterns with [[ ]]
> because it requires multiple conditions, regexps, or extglob. We could
> of course use a bracket expression like [[ ${EAPI:-0} = [012345] ]]
> but I find it ugly in this context (and it won't be able to check for
> EAPI 10 ;) ).

Yeah I had a bracket expression in mind... which I find less ugly than
a case/esac in this context. And I agree with mgorny that the EAPI=10
argument is kinda moot. Anyway, this is really not important, feel
free to ignore my comment.

Thanks,
Davide

Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()

[Davide Pesavento]

On Sat, Nov 28, 2015 at 4:50 PM, Justin Lecher (jlec) <j...@gentoo.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 28/11/15 16:28, Davide Pesavento wrote:
>>> else -   nonfatal ${VIRTUALX_COMMAND} "$@" +
>>> nonfatal "$@"
>>
>> Please take the opportunity to clean this up, possibly only in
>> EAPI=6 if you don't want to risk breaking existing ebuilds. See bug
>> 517976 for details.
>>
>>> retval=$?
>
> The return value is recorded and gets evaluated correctly.
>
> src_test() {
> virtx false
> }
>
[...]
>
> Am I missing something?

The scenario of bug 517976 is different. I think a minimized test case
is the following (untested):

foo() {
die "meh"
return 0
}

src_test() {
virtx foo
}

Re: [gentoo-dev] [PATCH] eutils.eclass: In EAPI conditionals, replace "has" by case statements.

[Davide Pesavento]

On Sun, Nov 29, 2015 at 5:48 PM, Ulrich Mueller  wrote:
> As suggested by mgorny, we could use bash internals instead of the
> "has" function calls in global scope.
>
> The patch below replaces them by case statements. (Unfortunately we
> cannot use fall-through (&;) because it is a bash 4 feature.)

Sounds reasonable, although I'd find an 'if' clause slightly more
readable, since there wouldn't be an 'else' branch in 2 out of 3
cases.

Thanks,
Davide

Re: [gentoo-dev] [PATCH 1/8] virtualx.eclass: Use case/esac to handle supported EAPIs

[Davide Pesavento]

On Sat, Nov 28, 2015 at 2:24 PM, Justin Lecher  wrote:
> Signed-off-by: Justin Lecher 
> ---
>  eclass/virtualx.eclass | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> index 5d27ed9..584fb29 100644
> --- a/eclass/virtualx.eclass
> +++ b/eclass/virtualx.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2012 Gentoo Foundation
> +# Copyright 1999-2015 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  # $Id$
>
> @@ -9,6 +9,17 @@
>  # Original author: Martin Schlemmer 
>  # @BLURB: This eclass can be used for packages that needs a working X 
> environment to build.
>
> +case "${EAPI:-0}" in
> +   0|1)
> +   die "virtualx eclass require EAPI=2 or newer."

require -> requires

[nitpicking, feel free to ignore] Technically "2 or newer" is not
correct and not future-proof. You can rephrase to something like
"virtualx.eclass: EAPI ${EAPI} is too old".

Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()

[Davide Pesavento]

On Sat, Nov 28, 2015 at 2:24 PM, Justin Lecher  wrote:
> The new API runs all specified arguments to virtx() inside an XFVB,
> instead of defining VIRTUALX_COMMAND and running that in virtualmake.
>
> Xemake and Xeconf should be replaced by "virtx emake" and "virtx econf".
>
> Signed-off-by: Justin Lecher 
> ---
>  eclass/virtualx.eclass | 42 --
>  1 file changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> index f9fa879..ca6a1f9 100644
> --- a/eclass/virtualx.eclass
> +++ b/eclass/virtualx.eclass
> @@ -90,22 +90,38 @@ esac
>  virtualmake() {
> debug-print-function ${FUNCNAME} "$@"
>
> -   local i=0
> -   local retval=0
> -   local OLD_SANDBOX_ON="${SANDBOX_ON}"
> -   local XVFB XHOST XDISPLAY
> -   local xvfbargs="-screen 0 1280x1024x24"
> -   XVFB=$(type -p Xvfb) || die
> -   XHOST=$(type -p xhost) || die
> +   [[ ${EAPI} == [2345] ]] || die "${FUNCNAME} is unsupported in EAPI > 
> 5, please use virtx"
>
> # backcompat for maketype
> if [[ -n ${maketype} ]]; then
> +   [[ ${EAPI} == [2345] ]] || die "maketype is banned in EAPI > 
> 5"
> eqawarn "ebuild is exporting \$maketype=${maketype}"
> eqawarn "Ebuild should be migrated to use 
> VIRTUALX_COMMAND=${maketype} instead."
> eqawarn "Setting VIRTUALX_COMMAND to \$maketype conveniently 
> for now."
> VIRTUALX_COMMAND=${maketype}
> fi
>
> +   virtx "${VIRTUALX_COMMAND}" "${@}"
> +}
> +
> +
> +# @FUNCTION: virtx
> +# @USAGE:  [comman arguments]

typo comman -> command

> +# @DESCRIPTION:
> +# Function which start new Xvfb session where the command gets executed.

I'd drop "Function which" from the description.

> +virtx() {
> +   debug-print-function ${FUNCNAME} "$@"
> +
> +   [[ $# -lt 1 ]] && die "${FUNCNAME} needs at least one argument"
> +
> +   local i=0
> +   local retval=0
> +   local OLD_SANDBOX_ON="${SANDBOX_ON}"
> +   local XVFB XHOST XDISPLAY
> +   local xvfbargs="-screen 0 1280x1024x24"
> +   XVFB=$(type -p Xvfb) || die
> +   XHOST=$(type -p xhost) || die
> +
> debug-print "${FUNCNAME}: running Xvfb hack"
> export XAUTHORITY=
> # The following is derived from Mandrake's hack to allow
> @@ -155,10 +171,10 @@ virtualmake() {
> # to kill Xvfb
> debug-print "${FUNCNAME}: ${VIRTUALX_COMMAND} \"$@\""
> if has "${EAPI}" 2 3; then
> -   ${VIRTUALX_COMMAND} "$@"
> +   "$@"
> retval=$?
> else
> -   nonfatal ${VIRTUALX_COMMAND} "$@"
> +   nonfatal "$@"

Please take the opportunity to clean this up, possibly only in EAPI=6
if you don't want to risk breaking existing ebuilds. See bug 517976
for details.

> retval=$?
> fi
>
> @@ -179,7 +195,7 @@ Xmake() {
> debug-print-function ${FUNCNAME} "$@"
>
> [[ ${EAPI} == [2345] ]] \
> -   || die "${FUNCNAME} is removed in EAPI > 5; use Xemake -j1 
> instead"
> +   || die "${FUNCNAME} is unsupported in EAPI > 5, please use 
> 'virtx emake -j1 '"
>
> eqawarn "you should not execute make directly"
> eqawarn "rather execute Xemake -j1 if you have issues with parallel 
> make"
> @@ -192,6 +208,9 @@ Xmake() {
>  Xemake() {
> debug-print-function ${FUNCNAME} "$@"
>
> +   [[ ${EAPI} == [2345] ]] \
> +   || die "${FUNCNAME} is unsupported in EAPI > 5, please use 
> 'virtx emake '"
> +
> VIRTUALX_COMMAND="emake" virtualmake "$@"
>  }
>
> @@ -201,6 +220,9 @@ Xemake() {
>  Xeconf() {
> debug-print-function ${FUNCNAME} "$@"
>
> +   [[ ${EAPI} == [2345] ]] \
> +   || die "${FUNCNAME} is unsupported in EAPI > 5, please use 
> 'virtx econf '"
> +
> VIRTUALX_COMMAND="econf" virtualmake "$@"
>  }
>
> --
> 2.6.3
>
>

Re: [gentoo-dev] [PATCH 11/29] python-utils-r1.eclass: Move ||die out of command substitution subshells

[Davide Pesavento]

On Sun, Nov 22, 2015 at 8:50 PM, Michał Górny  wrote:
> ---
>  eclass/python-utils-r1.eclass | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>

Can't you fold this patch into the previous ones that introduced these
die calls?

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Davide Pesavento]

On Wed, Nov 18, 2015 at 11:53 AM, Michael Palimaka
 wrote:
[...]
>
> What do you think?

+1 for banning them.

Thanks,
Davide

[gentoo-dev] Last rites: qt4-build.eclass

[Davide Pesavento]

Unused since the removal of Qt 4.8.5 a few minutes ago,
qt4-build.eclass will be removed in 30 days, i.e. on 2015-11-30.

Best regards,
Davide Pesavento

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasm/

[Davide Pesavento]

On Fri, Oct 9, 2015 at 5:35 PM, hasufell  wrote:
> On 10/08/2015 11:04 PM, Richard Farina wrote:
>> commit: f05eda22c275381c669e6f2a88dabd1356a3541f
>> Author: Zero_Chaos  gentoo  org>
>> AuthorDate: Thu Oct  8 20:45:33 2015 +
>> Commit: Richard Farina  gentoo  org>
>> CommitDate: Thu Oct  8 21:04:37 2015 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f05eda22
>>
>> dev-ruby/metasm: import from pentoo
>>
>> Package-Manager: portage-2.2.22
>>
>>  dev-ruby/metasm/Manifest   |  1 +
>>  dev-ruby/metasm/metadata.xml   | 10 +++
>>  dev-ruby/metasm/metasm-1.0.2-r1.ebuild | 52 
>> ++
>>  3 files changed, 63 insertions(+)
>>
>
> [...]
>
>> --- /dev/null
>> +++ b/dev-ruby/metasm/metasm-1.0.2-r1.ebuild
>> @@ -0,0 +1,52 @@
>> +# Copyright 1999-2015 Gentoo Foundation
>> +# Distributed under the terms of the GNU General Public License v2
>> +# $Id$
>> +
>> +EAPI=5
>> +USE_RUBY="ruby19 ruby20 ruby21"
>> +
>> +inherit ruby-fakegem
>> +
>> +RUBY_FAKEGEM_EXTRAINSTALL="metasm metasm.rb misc samples"
>> +
>> +DESCRIPTION="cross-architecture assembler, disassembler, linker, and 
>> debugger"
>> +HOMEPAGE="http://metasm.cr0.org/;
>> +SRC_URI="mirror://rubygems/${P}.gem"
>> +
>> +LICENSE="BSD"
>> +SLOT="${PV}"
>> +KEYWORDS="~amd64 ~arm ~x86"
>> +#IUSE="development test"
>> +RESTRICT=test
>> +IUSE=""
>> +
>> +RDEPEND="${RDEPEND} !dev-ruby/metasploit-model:0"
>> +
>> +ruby_add_rdepend ">=dev-ruby/railties-4.0.9:4.0
>> + >=dev-ruby/activesupport-4.0.9:4.0
>> + >=dev-ruby/activemodel-4.0.9:4.0"
>> +ruby_add_bdepend "dev-ruby/bundler"
>> +
>> +all_ruby_prepare() {
>> + [ -f Gemfile.lock ] && rm Gemfile.lock
>
> missing "|| die" afais, should probably be
>
> [ -f Gemfile.lock ] && { rm Gemfile.lock || die ; }
>

Or simply:

rm -f Gemfile.lock || die

>> + #For now, we don't support development or testing at all
>> + #if ! use development; then
>> + sed -i -e "/^group :development do/,/^end$/d" Gemfile || die
>> + sed -i -e "/s.add_development_dependency/d" "${PN}".gemspec || 
>> die
>> + sed -i -e "/spec.add_development_dependency/d" "${PN}".gemspec 
>> || die
>> + #fi
>> + #if ! use test; then
>> + sed -i -e "/^group :test do/,/^end$/d" Gemfile || die
>> + #fi
>> + #if ! use test && ! use development; then
>> + sed -i -e "/^group :development, :test do/,/^end$/d" Gemfile 
>> || die
>> + #fi
>> +}
>> +
>> +each_ruby_prepare() {
>> + if [ -f Gemfile ]
>> + then
>> + BUNDLE_GEMFILE=Gemfile ${RUBY} -S bundle install 
>> --local || die
>> + BUNDLE_GEMFILE=Gemfile ${RUBY} -S bundle check || die
>> + fi
>> +}
>>
>
>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasm/

[Davide Pesavento]

On Fri, Oct 9, 2015 at 5:48 PM, Patrick Lauer <patr...@gentoo.org> wrote:
>
>
> On 10/09/15 17:42, Davide Pesavento wrote:
>> On Fri, Oct 9, 2015 at 5:35 PM, hasufell <hasuf...@gentoo.org> wrote:
>>> On 10/08/2015 11:04 PM, Richard Farina wrote:
>>>
>>> +all_ruby_prepare() {
>>> + [ -f Gemfile.lock ] && rm Gemfile.lock
>>> missing "|| die" afais, should probably be
>>>
>>> [ -f Gemfile.lock ] && { rm Gemfile.lock || die ; }
>>>
>> Or simply:
>>
>> rm -f Gemfile.lock || die
>>
> With -f it always succeeds, so the ||die is redundant  ...
>

No, -f only ignores nonexistent files and doesn't prompt. Other kinds
of error still cause rm to fail.

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Davide Pesavento]

On Sun, Aug 9, 2015 at 8:43 AM, Mike Gilbert flop...@gentoo.org wrote:
 On Sun, Aug 9, 2015 at 11:30 AM, hasufell hasuf...@gentoo.org wrote:
 On 08/09/2015 05:19 PM, Tobias Klausmann wrote:
 Hi!

 On Sun, 09 Aug 2015, Sven Vermeulen wrote:

 On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman wrote:
 I think X-Gentoo-Bug: 557022 also makes the job easier for tools that
 parse commit messages.

 I don't. Just the bug  prefix should be fine for almost all
 purposes, even for tools.

 I'm pretty sure the majority of developers don't care that one developer
 uses X-Gentoo-Bug and another just adds it to the commit title.

 I like /guidelines/ in the sense that, if I don't know something, I can 
 look
 it up. But don't make it mandatory until we start depending on it (for
 instance, when we would automate stuff based on the content of the commit
 message).

 I'd just go with Gentoo-Bug. The X- is pointless since it was
 for eXtending Email-Headers. And what we do is only linked in
 style.


 I'd be fine with that and add a reference to the kernel guideline [0] to
 the wiki as well, so that it is clear that we also allow/use Acked-by,
 Reviewed-by, Suggested-by and whatnot.

 I'll wait for more ++ though.

 I like Gentoo-Bug. Much nicer without the X-.


+1 for Gentoo-Bug (or Gentoo-bug? not sure about the capitalization)

Re: [gentoo-dev] Re: useflag policies

[Davide Pesavento]

On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov pinkb...@gentoo.org wrote:
 qa team lead hat

 In short - apropriate REQUIRED_USE with setting recommended
 USE-flag(e.g. USE=+qt4 qt5 or USE=qt4 +qt5)

 /qa team lead hat

 That's most painless decision for both developers and users. Developers
 do not need to maintain ugly dependencies like

 DEPEND=qt4 ? (
 qt5 ( dev-qt/qtcore:5 )
 !qt5 ( dev-qt/qtcore:4 )
 )
 ...
 
 and other mess.

 /qa team lead hat

 Users will have default behaviour for empty make.conf. If they adjust
 they make.conf to globally include/exclude some Qt-related USEs - they
 are already moving from default and that's why - they can add apropriate
 options to package.use


Sergey,

It seems you completely ignored the discussion that took place in this
thread (and I also think you misunderstood the scenario judging from
the example you gave). Therefore I'm sorry but I will ignore your
opinion as QA team lead.

Thanks,
Davide

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Mon, Aug 3, 2015 at 10:10 PM, Alexandre Rostovtsev
tetrom...@gentoo.org wrote:
 On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote:
 On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote:
  [...]
  Gentoo should be the best of both worlds.  We should give users the
  power to tweak things, but we shouldn't force them to play with config
  files all day long just to have a functional system.  If users want to
  care we let them care instead of telling them don't touch like most
  other distros, but if they don't care we still provide reasonable
  defaults.

 And that is exactly what we do. The kde profile enables qt4, the
 plasma profile enables qt5, the other profiles have no qt* useflags
 enabled. These are reasonable defaults.

 That is not correct. The desktop profile enables qt4, because it is a
 reasonable default (for qt-only packages, USE=-qt4 means don't build
 any gui, but desktop users always expect some kind of a gui by
 default, whether it's gtk or qt*.)

 The result is that qt4 is enabled in child profiles of desktop - gnome
 and kde and plasma. Since plasma enables qt5 and does nothing with qt4,
 you have all qt versions enabled there.

 And when popular qt5-only, gui-optional packages appear in the tree, we
 will need to enable qt5 in desktop profile too.

Exactly, +1.

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot yng...@gentoo.org wrote:
 On 4 August 2015 at 04:20, Rich Freeman ri...@gentoo.org wrote:
 [...]
 Gentoo should be the best of both worlds.  We should give users the
 power to tweak things, but we shouldn't force them to play with config
 files all day long just to have a functional system.  If users want to
 care we let them care instead of telling them don't touch like most
 other distros, but if they don't care we still provide reasonable
 defaults.

 And that is exactly what we do. The kde profile enables qt4, the
 plasma profile enables qt5, the other profiles have no qt* useflags
 enabled. These are reasonable defaults.


As tetromino pointed out, this is very far from the real current situation.

 Of course some users will proceed to enable both qt4 and qt5 globally
 in their make.conf, but I don't think it is unreasonable to expect
 them to then deal with adding exceptions to package.use for those
 packages where exactly-one-of is required.

 In my opinion, this is the way Gentoo has always worked, and we should
 simply recommend users to only set one of the qt* useflags as globally
 enabled, if they want to prevent such micro-management. Hiding the qt4
 option is in my opinion the wrong solution around people complaining
 after they have consciously enabled both flags.

 If this is not acceptable (or absolutely unusable as one dev put
 it), then we need a proper solution, which a) will not hide the qt4
 option, and b) will prevent triggering required_use blockage by
 choosing qt5 over qt4 in case both are enabled, while c) informing the
 user about this. This probably requires new eclass or even EAPI
 functionality.


Please go ahead and design and implement such functionality (a sort of
REQUIRED_USE defaults). In the meantime, we will apply the policies
written in the Qt project wiki page.

 In the meantime, we should stick with the policies adopted at the qt3
 to qt4 transition (explicit versioned useflags) and let the user deal
 with per-package management if they enable both flags.


We didn't have REQUIRED_USE at the time of the qt3-qt4 transition, so
this point is completely moot.

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Sun, Aug 2, 2015 at 10:27 AM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-08-03, o godz. 00:34:51
 Ben de Groot yng...@gentoo.org napisał(a):

 Recently some team members of the Qt project have adopted these ebuild
 policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies

 I have an issue with the policy adopted under Requires one of two Qt
 versions. In my opinion, in the case where a package offers a choice
 between qt4 or qt5, we should express this in explicit useflags and a
 REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice.

 Other developers state that users are not interested in such implementation
 details, or that forced choice through REQUIRED_USE is too much of a
 hassle. This results in current ebuilds such as quassel to not make it
 clear that qt4 is an option.

 This goes against the principle of least surprise, as well as against QA
 recommendations. I would like to hear specifically from QA about how we
 should proceed, but comments from the wider developer community are also
 welcome.

 Long story short, this is USE=gtk once again. GNOME team had a
 policy that handled the case cleanly and QA outvoted it in favor of
 Qt-like policy. Then Qt team figured out their policy was unfriendly,
 and 'fixed' it with this ugly hack...

Except that it's not a ugly hack, but it's in fact recommended by
the devmanual (ulm already quoted the relevant text). I'd agree that
it's not ideal either (but so far I haven't seen any ideal solution
being proposed).

 As I see it, this is a major failure of using toolkit-version oriented
 flags rather than feature-oriented flags. Possibilities compared:

I could agree with this. So, back to USE=gui? A USE_EXPAND maybe?

 What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
 team policy. USE=qt would mean 'any version of Qt, if optional', and
 qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
 obligatory, no USE=qt would apply. If only one Qt version would be
 supported, no USE=qt4/qt5 would apply. Clean, sane and limited
 package.use cruft.


I could agree in principle. However this would be a major tree-wide
change, and should happen as quickly as possible to avoid creating
even more confusion for users. Plus, who is willing to do all the
work? (hint: I'm not) ...so, I don't think this solution is practical.

Re: [gentoo-dev] useflag policies

[Davide Pesavento]

On Sun, Aug 2, 2015 at 12:12 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko birc...@gentoo.org wrote:

 This is a clean solution for developers and maintainers, but not
 for ordinary users — they will confused by qt qt4 qt5: what is
 'qt', how is it different from 'qt4' and 'qt5'. What you are really
 doing is implementing second-level USE flags, while they were
 supposed to be linear.

 No argument that it isn't intuitive, but setting USE=qt and forgetting
 about it certainly seems more user-friendly than setting qt4/qt5 on
 individual packages and worrying about which is better where.  To some
 extent the current qt policy accomplishes this, but it sacrifices
 control when users actually do want it.

No, it does not. You can still control whether you want qt4 or qt5 on
a per-package basis. The difference is that users that don't care
about this level of control are not forced to make a choice for every
package due to REQUIRED_USE conflicts. Unless I'm missing something...

Re: [gentoo-dev] [PATCHSET python-utils-r1] python python-config wrapper cleanup

[Davide Pesavento]

On Sat, Jul 25, 2015 at 2:48 PM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-07-25, o godz. 14:24:27
 Davide Pesavento p...@gentoo.org napisał(a):

 On Sat, Jul 25, 2015 at 2:03 PM, Michał Górny mgo...@gentoo.org wrote:
  Dnia 2015-07-25, o godz. 13:37:03
  Davide Pesavento p...@gentoo.org napisał(a):
 
  On Sat, Jul 25, 2015 at 12:37 PM, Michał Górny mgo...@gentoo.org wrote:
   While at it, I also added some 'unsupported' wrappers to ban trying to
   use pythonY (accidental fallback to system python) when pythonX is
   selected via wrapper, and changed the exit code for unsupp-scripts.
 
  Can you clarify the consequences of this change please? e.g. is it
  still possible to call naked python2 from src_prepare() of a package
  using python-r1.eclass, such as dev-python/sip?
 
  If you call python_setup and ensure python2 is selected beforehand,
  yes. Otherwise, you're doing a QA violation and it never were supported.
 

 Funny. I'm pretty sure you suggested the current implementation
 (directly calling python2) when we first switched to
 python-r1.eclass...

 Nope. I'm pretty sure I never suggested or accepted any kind of direct
 dev-lang/python dependencies or python[23] calls.


Seriously, I'm not blaming you (or anybody else), but please just try
to be a little less arrogant and self-righteous in your emails. If you
don't believe me, look at your #gentoo-python logs around Jan 21,
2013. Also consider that python_setup was only introduced 9 months
after the conversion of dev-python/sip.

Anyway, I guess I have to fix sip-4. then ;)

Thanks,
Davide

Re: [gentoo-dev] [PATCHSET python-utils-r1] python python-config wrapper cleanup

[Davide Pesavento]

On Sat, Jul 25, 2015 at 12:37 PM, Michał Górny mgo...@gentoo.org wrote:
 While at it, I also added some 'unsupported' wrappers to ban trying to
 use pythonY (accidental fallback to system python) when pythonX is
 selected via wrapper, and changed the exit code for unsupp-scripts.

Can you clarify the consequences of this change please? e.g. is it
still possible to call naked python2 from src_prepare() of a package
using python-r1.eclass, such as dev-python/sip?

Thanks,
Davide

Re: [gentoo-dev] [PATCHSET python-utils-r1] python python-config wrapper cleanup

[Davide Pesavento]

On Sat, Jul 25, 2015 at 2:03 PM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-07-25, o godz. 13:37:03
 Davide Pesavento p...@gentoo.org napisał(a):

 On Sat, Jul 25, 2015 at 12:37 PM, Michał Górny mgo...@gentoo.org wrote:
  While at it, I also added some 'unsupported' wrappers to ban trying to
  use pythonY (accidental fallback to system python) when pythonX is
  selected via wrapper, and changed the exit code for unsupp-scripts.

 Can you clarify the consequences of this change please? e.g. is it
 still possible to call naked python2 from src_prepare() of a package
 using python-r1.eclass, such as dev-python/sip?

 If you call python_setup and ensure python2 is selected beforehand,
 yes. Otherwise, you're doing a QA violation and it never were supported.


Funny. I'm pretty sure you suggested the current implementation
(directly calling python2) when we first switched to
python-r1.eclass...

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog qt4-build-multilib.eclass

[Davide Pesavento]

On Fri, Jun 12, 2015 at 6:43 AM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-06-12, o godz. 01:44:17
 Davide Pesavento (pesa) p...@gentoo.org napisał(a):

 pesa15/06/12 01:44:17

   Modified: ChangeLog qt4-build-multilib.eclass
   Log:
   Don't die when trying to rmdir non-existent directory (bug 551676).

 Revision  ChangesPath
 1.1653   eclass/ChangeLog

 file : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.1653view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.1653content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.1652r2=1.1653

 Index: ChangeLog
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v
 retrieving revision 1.1652
 retrieving revision 1.1653
 diff -u -r1.1652 -r1.1653
 --- ChangeLog 11 Jun 2015 18:33:54 -  1.1652
 +++ ChangeLog 12 Jun 2015 01:44:17 -  1.1653
 @@ -1,6 +1,9 @@
  # ChangeLog for eclass directory
  # Copyright 1999-2015 Gentoo Foundation; Distributed under the GPL v2
 -# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.1652 2015/06/11 
 18:33:54 pesa Exp $
 +# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.1653 2015/06/12 
 01:44:17 pesa Exp $
 +
 +  12 Jun 2015; Davide Pesavento p...@gentoo.org qt4-build-multilib.eclass:
 +  Don't die when trying to rmdir non-existent directory (bug 551676).

11 Jun 2015; Davide Pesavento p...@gentoo.org qt4-build-multilib.eclass:
Use usex().



 1.21 eclass/qt4-build-multilib.eclass

 file : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/qt4-build-multilib.eclass?rev=1.21view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/qt4-build-multilib.eclass?rev=1.21content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/qt4-build-multilib.eclass?r1=1.20r2=1.21

 Index: qt4-build-multilib.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/qt4-build-multilib.eclass,v
 retrieving revision 1.20
 retrieving revision 1.21
 diff -u -r1.20 -r1.21
 --- qt4-build-multilib.eclass 11 Jun 2015 18:33:54 -  1.20
 +++ qt4-build-multilib.eclass 12 Jun 2015 01:44:17 -  1.21
 @@ -1,6 +1,6 @@
  # Copyright 1999-2015 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
 -# $Header: /var/cvsroot/gentoo-x86/eclass/qt4-build-multilib.eclass,v 1.20 
 2015/06/11 18:33:54 pesa Exp $
 +# $Header: /var/cvsroot/gentoo-x86/eclass/qt4-build-multilib.eclass,v 1.21 
 2015/06/12 01:44:17 pesa Exp $

  # @ECLASS: qt4-build-multilib.eclass
  # @MAINTAINER:
 @@ -470,7 +470,7 @@
   mv ${pcfile} ${ED}/usr/$(get_libdir)/pkgconfig || die
   done
   eshopts_pop
 - rmdir ${D}/${QT4_LIBDIR}/pkgconfig || die
 + rmdir ${D}/${QT4_LIBDIR}/pkgconfig

   qt4_install_module_qconfigs
   qt4_symlink_framework_headers

 And now you're doing a QA violation. Just don't call rmdir if something
 doesn't exist instead of ignoring the result and letting it spit
 random errors, all into 'did not exist' basket.

Wow. QA violation. Sounds quite exaggerated don't you think?
Especially if you consider that the rmdir without die has been present
in qt4-build.eclass for many years, and got recently copied over to
qt4-build-multilib.eclass, and no one said anything.

Anyway, fear not, I'm going to rewrite that piece of code very soon.
The removal of || die is just supposed to be a quick fix for the
regression, not a long term solution.

Cheers,
Davide

Re: [gentoo-dev] Sparc Arch status

[Davide Pesavento]

On Sun, May 17, 2015 at 5:36 PM, Jack Morgan jmor...@gentoo.org wrote:
 I wanted to send out an update on the Sparc arch team status. My overall
 plan is to reduce the total number of keywords for sparcto a more manageable
 level. I'd like to continue to have sparc be a stable arch for gentoo for as
 long as it makes sense. I'm hoping to get some feedback from the community
 as to what should be supported and what can be reduced.

Well basically what I said for ia64 (see my other email) applies to
sparc too. So definitely let us know if you're interested in changing
Qt4/5 keywording state on sparc.

Thanks,
Davide

Re: [gentoo-dev] IA64 Arch status

[Davide Pesavento]

On Sun, May 17, 2015 at 5:04 PM, Jack Morgan jmor...@gentoo.org wrote:
 I'm hoping to get some feedback from the community as to what should be
 supported and what can be reduced. My overall plan as I mentioned in a
 previous email to reduce the total number of keywords for ia64 to a more
 manageable level. I'd like to continue to have ia64 be a stable arch for
 gentoo for as long as it makes sense.

For example, you could choose to skip keywording Qt5... as more and
more apps and Qt-based libraries transition from Qt4 to Qt5, the
number of keyworded/stable packages will also drop for ia64, since you
will gradually lose all packages that have become Qt5-only.

If you're looking for an immediate reduction of ia64 packages, you can
go a step further and drop Qt4 keywording as well (maybe with the
exception of dev-qt/qtcore which is needed by some non-GUI apps),
especially considering that ia64 is server-oriented, and that all your
machines don't have a video card.

These are just some random suggestions; if the ia64 arch team is
interested, let us (the qt team) know so that we can figure out the
details together.

Thanks,
Davide

Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to full multilib

[Davide Pesavento]

On Mon, Mar 30, 2015 at 1:12 AM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento p...@gentoo.org wrote:
 On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman ri...@gentoo.org wrote:

 qt is a pretty significant package to have break with multilib, and
 trying to run qt-5 on a stable system is already a nightmare with the
 qtchooser switch (in my case I ended up abandoning qt5 as I didn't
 need it that badly).

 I'm not sure how qt5 is relevant to this discussion.


 As I understand it, qt5 cannot be installed side-by-side with the
 current stable qt4, but it can be installed side-by-side with 4.8.6.
 My understanding is that this is the result of the same overall
 ebuild/eclass changes.  Therefore, it is another reason to stabilize
 4.8.6.  You are correct that it has nothing to do with the multilib
 changes otherwise.


Your understanding is correct, and I agree it is indeed another reason
to stabilize 4.8.6. Thanks for clarifying.

Regards,
Davide

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

[Davide Pesavento]

On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott z...@gentoo.org wrote:
 On 29.03.2015 20:58, Matthias Schwarzott wrote:
 Hi there!

 I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
 Since then valgrind did no longer work for 32bit programs because
 -march=native did choose instructions that valgrind does not support
 in 32bit mode (even ld.so was unusable).

 After some research I put this into make.conf and now it works:
 CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
 CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2

 Is this the best solution to the problem?
 If yes, the valgrind ebuild could suggest something like this.
 Either always show it or check cpu-flags first (is this maintainable?).

 I should add, that it seems to break for exactly one package: mariadb


Not only mariadb, there are other known breakages... see
https://bugs.gentoo.org/show_bug.cgi?id=541616#c5

According to mgorny (Cc'ed):
You are not supposed to touch CFLAGS_x86, ever. That's some magic
stuff that's used in profiles  multilib.eclass.

Regards,
Davide

Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to full multilib

[Davide Pesavento]

On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman ri...@gentoo.org wrote:
 I think we really need to either stabilize 4.8.6, or backport
 qtchooser/multilib/etc to the current stable version.


Backporting is not an option. The introduction of multilib support in
qt4 required extensive changes to the eclass (substantial portions of
code were rewritten) and the ebuilds.

Therefore stabilizing 4.8.6-r1 is the way to go. We had surprisingly
few regressions, but the ones that are still unsolved are proving
quite hard to debug. Please help with the blockers of bug #530238.

As usual, at least for me, the problem is the lack of time for gentoo
development, plus the fact that very few people are actively working
on qt{4,5} packaging (kensington, me, and more recently yngwin).

 qt is a pretty significant package to have break with multilib, and
 trying to run qt-5 on a stable system is already a nightmare with the
 qtchooser switch (in my case I ended up abandoning qt5 as I didn't
 need it that badly).


I'm not sure how qt5 is relevant to this discussion.

Thanks,
Davide

[gentoo-dev] Re: [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions

[Davide Pesavento]

On Wed, Feb 18, 2015 at 12:58 PM, Ben de Groot yng...@gentoo.org wrote:
 The attached patch proposes two helper functions to be added to
 qmake-utils.eclass. These functions echo the correct directory where
 qt binaries such as moc and lrelease are located. They can be used in
 ebuilds when such binaries need to be called directly. (Ebuilds should
 not rely on qtchooser for this.)

 Please review before I commit.


Thanks Ben.

The -x test on line 59 should be a -d.

Also, I'd rephrase the description as follows:
Echoes the directory where Qt{4,5} binaries are installed.

And you're missing a colon after @FUNCTION.

Thanks,
Davide

[gentoo-dev] [RFC] qt4-build-multilib.eclass

[Davide Pesavento]

Hello fellow devs,

Please review the attached qt4-build-multilib.eclass ASAP. It's
basically the current qt4-build.eclass with some old cruft removed and
multilib support added.

Given the amount of changes needed for multilib, we chose to introduce
a separate eclass rather than modifying the existing one, to avoid
destabilizing current consumers and to maintain code readability.
While at it, we also refactored the code quite a bit, and rewrote some
functions using a more modern style.

Thanks,
Davide Pesavento


qt4-build-multilib.eclass
Description: Binary data

[gentoo-dev] Re: [PATCH 1/2] multibuild.eclass: make sure BUILD_DIR exists before pushd'ing into it.

[Davide Pesavento]

On Thu, Oct 23, 2014 at 10:30 PM, Davide Pesavento p...@gentoo.org wrote:
 Index: multibuild.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/multibuild.eclass,v
 retrieving revision 1.18
 diff -u -r1.18 multibuild.eclass
 --- multibuild.eclass 10 May 2014 21:36:49 - 1.18
 +++ multibuild.eclass 23 Oct 2014 20:10:21 -
 @@ -237,6 +237,7 @@
   [[ ${#} -ne 0 ]] || die ${FUNCNAME}: no command specified.
   [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.

 + mkdir -p ${BUILD_DIR} || die
   pushd ${BUILD_DIR} /dev/null || die
   ${@}
   ret=${?}

Applied.

Re: [gentoo-dev] [PATCH 2/2] multilib-minimal.eclass: use run_in_build_dir().

[Davide Pesavento]

On Thu, Oct 23, 2014 at 11:08 PM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2014-10-23, o godz. 22:31:39
 Davide Pesavento p...@gentoo.org napisał(a):

 Index: multilib-minimal.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/multilib-minimal.eclass,v
 retrieving revision 1.9
 diff -u -r1.9 multilib-minimal.eclass
 --- multilib-minimal.eclass 2 May 2014 16:16:37 - 1.9
 +++ multilib-minimal.eclass 23 Oct 2014 20:24:23 -
 @@ -30,7 +30,7 @@
  esac


 -inherit eutils multilib-build
 +inherit eutils multibuild multilib-build

  EXPORT_FUNCTIONS src_configure src_compile src_test src_install

 @@ -41,17 +41,14 @@
   multilib-minimal_abi_src_configure() {
   debug-print-function ${FUNCNAME} $@

 - mkdir -p ${BUILD_DIR} || die
 - pushd ${BUILD_DIR} /dev/null || die
   if declare -f multilib_src_configure /dev/null ; then
   multilib_src_configure
   else
   default_src_configure
   fi
 - popd /dev/null || die

 NAK. No real gain in this, while indirection makes the eclass harder to
 read.


run_in_build_dir sounded fairly easy to read and understand imho...
but ok, whatever... I don't really care about this TBH.

Best,
Davide

[gentoo-dev] [PATCH 1/2] multibuild.eclass: make sure BUILD_DIR exists before pushd'ing into it.

[Davide Pesavento]

Index: multibuild.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/multibuild.eclass,v
retrieving revision 1.18
diff -u -r1.18 multibuild.eclass
--- multibuild.eclass 10 May 2014 21:36:49 - 1.18
+++ multibuild.eclass 23 Oct 2014 20:10:21 -
@@ -237,6 +237,7 @@
  [[ ${#} -ne 0 ]] || die ${FUNCNAME}: no command specified.
  [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.

+ mkdir -p ${BUILD_DIR} || die
  pushd ${BUILD_DIR} /dev/null || die
  ${@}
  ret=${?}


multibuild.patch
Description: Binary data

[gentoo-dev] [PATCH 2/2] multilib-minimal.eclass: use run_in_build_dir().

[Davide Pesavento]

Index: multilib-minimal.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/multilib-minimal.eclass,v
retrieving revision 1.9
diff -u -r1.9 multilib-minimal.eclass
--- multilib-minimal.eclass 2 May 2014 16:16:37 - 1.9
+++ multilib-minimal.eclass 23 Oct 2014 20:24:23 -
@@ -30,7 +30,7 @@
 esac


-inherit eutils multilib-build
+inherit eutils multibuild multilib-build

 EXPORT_FUNCTIONS src_configure src_compile src_test src_install

@@ -41,17 +41,14 @@
  multilib-minimal_abi_src_configure() {
  debug-print-function ${FUNCNAME} $@

- mkdir -p ${BUILD_DIR} || die
- pushd ${BUILD_DIR} /dev/null || die
  if declare -f multilib_src_configure /dev/null ; then
  multilib_src_configure
  else
  default_src_configure
  fi
- popd /dev/null || die
  }

- multilib_parallel_foreach_abi multilib-minimal_abi_src_configure
+ multilib_parallel_foreach_abi run_in_build_dir
multilib-minimal_abi_src_configure
 }

 multilib-minimal_src_compile() {
@@ -60,16 +57,14 @@
  multilib-minimal_abi_src_compile() {
  debug-print-function ${FUNCNAME} $@

- pushd ${BUILD_DIR} /dev/null || die
  if declare -f multilib_src_compile /dev/null ; then
  multilib_src_compile
  else
  default_src_compile
  fi
- popd /dev/null || die
  }

- multilib_foreach_abi multilib-minimal_abi_src_compile
+ multilib_foreach_abi run_in_build_dir multilib-minimal_abi_src_compile
 }

 multilib-minimal_src_test() {
@@ -78,16 +73,14 @@
  multilib-minimal_abi_src_test() {
  debug-print-function ${FUNCNAME} $@

- pushd ${BUILD_DIR} /dev/null || die
  if declare -f multilib_src_test /dev/null ; then
  multilib_src_test
  else
  default_src_test
  fi
- popd /dev/null || die
  }

- multilib_foreach_abi multilib-minimal_abi_src_test
+ multilib_foreach_abi run_in_build_dir multilib-minimal_abi_src_test
 }

 multilib-minimal_src_install() {
@@ -96,7 +89,6 @@
  multilib-minimal_abi_src_install() {
  debug-print-function ${FUNCNAME} $@

- pushd ${BUILD_DIR} /dev/null || die
  if declare -f multilib_src_install /dev/null ; then
  multilib_src_install
  else
@@ -111,9 +103,8 @@

  multilib_prepare_wrappers
  multilib_check_headers
- popd /dev/null || die
  }
- multilib_foreach_abi multilib-minimal_abi_src_install
+ multilib_foreach_abi run_in_build_dir multilib-minimal_abi_src_install
  multilib_install_wrappers

  if declare -f multilib_src_install_all /dev/null ; then


multilib-minimal.patch
Description: Binary data

[gentoo-dev] Last rites: net-im/qutim

[Davide Pesavento]

# Davide Pesavento p...@gentoo.org (20 Oct 2014)
# Does not build with any in-tree version of cmake since 20140713 (bug 506614).
# Jabber plugin is broken (bug 464690). Masked for removal in 30 days.
net-im/qutim

Re: [gentoo-dev] RFC: kde5 and kde5-functions eclass

[Davide Pesavento]

kde5.eclass

 case ${KDE_TEST} in
 false) ;;
 *)
 IUSE+= test
 DEPEND+= test? ( dev-qt/qttest:5 )

No =${QT_MINIMAL} in this dep?

 else
 unpack ${A}

I think you can use `default`

 if ! in_iuse examples || ! use examples ; then

if ! use_if_iuse examples ; then

 if ! in_iuse test || ! use test ; then

ditto

 if [ -n ${DBUS_SESSION_BUS_PID} ] ; then

Use [[ ]], and you can also omit quoting.

 dohtml -r ${P}-apidocs/html/*

docinto html
dodoc -r ${P}-apidocs/html/*

Or even shorter, dodoc -r ${P}-apidocs/html (without docinto)

Thanks,
Davide

Re: [gentoo-dev] RFC: kde5 and kde5-functions eclass

[Davide Pesavento]

kde5-functions.eclass

 inherit versionator

versionator doesn't export any phase functions so it can stay inside the
_KDE5_FUNCTIONS_ECLASS conditional block.

 case ${EAPI:-0} in

I believe :-0 is unnecessary here, *) will match anyway, but it doesn't
hurt either.

 *) die EAPI=${EAPI} is not supported ;;

Here ${EAPI:-0} is needed instead.

 if [[ ${CATEGORY} = kde-base ]]; then
 debug-print ${ECLASS}: KDEBASE ebuild recognized
 KDEBASE=kde-base
 elif [[ ${CATEGORY} = kde-frameworks ]]; then
 debug-print ${ECLASS}: KDEFRAMEWORKS ebuild recognized
 KDEBASE=kde-frameworks
 elif [[ ${KMNAME-${PN}} = kdevelop ]]; then
 debug-print ${ECLASS}: KDEVELOP ebuild recognized
 KDEBASE=kdevelop
 fi

Can you move the print after the if-fi block to avoid duplication?
debug-print ${ECLASS}: ${KDEBASE} ebuild recognized

 case ${KDE_SCM} in
 svn|git) ;;

I thought : was necessary for syntax reasons but apparently it's not. You
may want to add it anyway for consistency with the previous case statement.

 if [[ -a CMakeLists.txt ]]; then

Unnecessary quoting. Also, -e is more common than -a

sed -e
/add_subdirectory[[:space:]]*([[:space:]]*${1}[[:space:]]*)/s/^/#DONOTCOMPILE
/ \

What if ${1} contains slashes?

 [[ -z ${1} ]]  die Missing parameter

Sanity checking of arguments should be done at the beginning of the
function body. Also, is $2 allowed to be empty?

 # @FUNCTION: add_frameworks_dep

Add @USAGE eclass doc.

 local ver=${1:-${PV}}
 local major=$(get_major_version ${ver})
 local minor=$(get_version_component_range 2 ${ver})
 local micro=$(get_version_component_range 3 ${ver})
 if [[ ${ver} ==  ]]; then

No wildcard match here? (*)

Thanks,
Davide

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Davide Pesavento]

On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny mgo...@gentoo.org wrote:
 We have main developer repo where developers work  commit and are
 relatively happy. For every push into developer repo, automated magic
 thingie merges stuff into user sync repo and updates the metadata cache
 there.

How long does the md5-cache regeneration process take? Are you sure it
will be able to keep up with the rate of pushes to the repo during
peak hours? If not, maybe we could use a time-based thing similar to
the current cvs-rsync synchronization.

[...]
 Main developer repo
 ---

 I was able to create a start git repository that takes around 66M
 as a git pack (this is how much you will have to fetch to start working
 with it). The repository is stripped clean of history and ChangeLogs,
 and has thin Manifests only.

 This means we don't have to wait till someone figures out the perfect
 way of converting the old CVS repository. You don't need that history
 most of the time, and you can play with CVS to get it if you really do.

+1

 In any case, we would likely strip the history anyway to get a small
 repo to work with.

 I have prepared a basic git update hook that keeps master clean
 and attached it to the bug [1]. It enforces basic policies, prevents
 forced updates and checks GPG signatures on left-most history line. It
 can also be extended to do more extensive tree checks.

Are we going to disallow merge commits and ask devs to rebase local
changes in order to keep the history clean?

Thanks a lot,
Davide

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

[Davide Pesavento]

On Sun, Sep 14, 2014 at 3:55 PM, hasufell hasuf...@gentoo.org wrote:
 Davide Pesavento:
 In any case, we would likely strip the history anyway to get a small
 repo to work with.

 I have prepared a basic git update hook that keeps master clean
 and attached it to the bug [1]. It enforces basic policies, prevents
 forced updates and checks GPG signatures on left-most history line. It
 can also be extended to do more extensive tree checks.

 Are we going to disallow merge commits and ask devs to rebase local
 changes in order to keep the history clean?


 I'd say it doesn't make sense to create merge commits for conflicts that
 arise by someone having pushed earlier than you.

 Merge commits should only be there if they give useful information.


I totally agree. But is there a way to automatically enforce this?

 Also... if you merge from a _user_ who is untrusted and allow a
 fast-forward merge, then the signature verification fails. That means
 for such pull requests you either have to use git am or git merge
 --no-ff.


Right. In that case you can either sign the merge commit or amend the
user's commit and sign it yourself (re-signing could be needed anyway
if you have to rebase).

Thanks,
Davide

[gentoo-dev] Re: [RFC] qt5-build.eclass

[Davide Pesavento]

On Sun, Aug 17, 2014 at 11:38 AM, Davide Pesavento p...@gentoo.org wrote:
 I will commit the eclass in about 7-10 days from now, unless major
 problems are found during the review. The actual Qt5 packages will
 follow soon thereafter, initially under package.mask.


The eclass is now in tree. Thanks to mgorny and hasufell for their comments.

Cheers,
Pesa

Re: [gentoo-dev] [RFC] qt5-build.eclass

[Davide Pesavento]

On Wed, Aug 20, 2014 at 10:07 AM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2014-08-17, o godz. 20:38:18
 Davide Pesavento p...@gentoo.org napisał(a):

 # @FUNCTION: qt5-build_src_unpack
 # @DESCRIPTION:
 # Unpacks the sources.
 qt5-build_src_unpack() {
   if [[ $(gcc-major-version) -lt 4 ]] || [[ $(gcc-major-version) -eq 4 
  $(gcc-minor-version) -lt 5 ]]; then
   ewarn
   ewarn Using a GCC version lower than 4.5 is not supported.
   ewarn
   fi

   if [[ ${PN} == qtwebkit ]]; then
   eshopts_push -s extglob
   if is-flagq '-g?(gdb)?([1-9])'; then

 Wouldn't that be equivalent to '-g[^0]'? And I think this would
 actually work without extglob.

That doesn't match '-g' though, does it?


   ewarn
   ewarn You have enabled debug info (probably have -g 
 or -ggdb in your CFLAGS/CXXFLAGS).
   ewarn You may experience really long compilation 
 times and/or increased memory usage.
   ewarn If compilation fails, please try removing 
 -g/-ggdb before reporting a bug.
   ewarn For more info check out 
 https://bugs.gentoo.org/307861;
   ewarn
   fi
   eshopts_pop
   fi

   case ${QT5_BUILD_TYPE} in
   live)git-r3_src_unpack ;;
   release) default ;;
   esac
 }

 # @FUNCTION: qt5-build_src_prepare
 # @DESCRIPTION:
 # Prepares the sources before the configure phase.
 qt5-build_src_prepare() {
   qt5_prepare_env

   if [[ ${QT5_MODULE} == qtbase ]]; then
   # Avoid unnecessary qmake recompilations
   sed -i -re s|^if true;.*(\[ 
 '\!').*($outpath/bin/qmake\.*)|if \1 -e \2 then| \
   configure || die sed failed (skip qmake bootstrap)

 Any chance for something more readable? :) Like a inline patch.

I think it's a fairly straightforward substitution, not pretty maybe
but... heh ;) Also, it's not something that you have to look at all
the time since the configure line doesn't change often, and the intent
is clear from the comment, so I'm not going to change it.


   # Respect CC, CXX, *FLAGS, MAKEOPTS and EXTRA_EMAKE when 
 bootstrapping qmake
   sed -i -e /outpath\/qmake\.*\\$MAKE\)/ s:): \
   ${MAKEOPTS} ${EXTRA_EMAKE} 'CC=$(tc-getCC)' 
 'CXX=$(tc-getCXX)' \
   'QMAKE_CFLAGS=${CFLAGS}' 'QMAKE_CXXFLAGS=${CXXFLAGS}' 
 'QMAKE_LFLAGS=${LDFLAGS}': \
   -e '/$CFG_RELEASE_QMAKE/,/^\s\+fi$/ d' \
   configure || die sed failed (respect env for qmake 
 build)

 Ditto ;).

ditto ;)


   sed -i -e '/^CPPFLAGS\s*=/ s/-g //' \
   qmake/Makefile.unix || die sed failed (CPPFLAGS for 
 qmake build)

   # Respect CXX in {bsymbolic_functions,fvisibility,precomp}.test
   sed -i -e /^QMAKE_CONF_COMPILER=/ s:=.*:=\$(tc-getCXX)\: \
   configure || die sed failed (QMAKE_CONF_COMPILER)

   # Respect toolchain and flags in config.tests
   find config.tests/unix -name '*.test' -type f -print0 \
   | xargs -0 sed -i -e '/bin\/qmake/ s/-nocache //' \
   || die sed failed (config.tests)

 find ... -exec sed ... {} +

   fi

   if [[ ${PN} != qtcore ]]; then
   qt5_symlink_tools_to_build_dir
   fi

   # apply patches
   [[ ${PATCHES[@]} ]]  epatch ${PATCHES[@]}
   epatch_user
 }

 [...]

 # @FUNCTION: qt5-build_src_install
 # @DESCRIPTION:
 # Performs the actual installation of target directories.
 qt5-build_src_install() {
   qt5_foreach_target_subdir emake INSTALL_ROOT=${D} install

   if [[ ${PN} == qtcore ]]; then
   pushd ${QT5_BUILD_DIR} /dev/null || die
   einfo Running emake INSTALL_ROOT=${D} 
 install_{mkspecs,qmake,syncqt}

 You can put that command-line in an array or set to argv.

   emake INSTALL_ROOT=${D} install_{mkspecs,qmake,syncqt}
   popd /dev/null || die

   # install an empty Gentoo/gentoo-qconfig.h in ${D}
   # so that it's placed under package manager control
${T}/gentoo-qconfig.h
   (
   insinto ${QT5_HEADERDIR#${EPREFIX}}/Gentoo
   doins ${T}/gentoo-qconfig.h
   )

   # include gentoo-qconfig.h at the beginning of QtCore/qconfig.h
   sed -i -e '1a#include Gentoo/gentoo-qconfig.h\n' \
   ${D}${QT5_HEADERDIR}/QtCore/qconfig.h \
   || die sed failed (qconfig.h)
   fi

   qt5_install_module_qconfigs
   prune_libtool_files
 }

 [...]

 # @FUNCTION: qt5_base_configure
 # @INTERNAL
 # @DESCRIPTION:
 # Runs ./configure for modules belonging to qtbase.
 qt5_base_configure() {
   # setup toolchain variables used

[gentoo-dev] [RFC] qt5-build.eclass

[Davide Pesavento]

Hi guys,

In preparation for moving Qt5 to gentoo-x86 (finally!), please review
the attached eclass that is inherited by every Qt5 ebuild.

If you want to get an idea about how the ebuild code looks like, see
any ebuild in the dev-qt category of our overlay that inherits the
eclass:

https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=tree;f=dev-qt;hb=HEAD
or on the github mirror (easier to navigate and nicer looking):
https://github.com/gentoo/qt/tree/master/dev-qt

For reference, the tracker bug is https://bugs.gentoo.org/show_bug.cgi?id=qt5

I will commit the eclass in about 7-10 days from now, unless major
problems are found during the review. The actual Qt5 packages will
follow soon thereafter, initially under package.mask.

Thanks,
Pesa


qt5-build.eclass
Description: Binary data

Re: [gentoo-dev] [RFC] qt5-build.eclass

[Davide Pesavento]

On Sun, Aug 17, 2014 at 8:56 PM, Maxim Koltsov maksbo...@gentoo.org wrote:

 For the record: I /think/ that an eclass for packages supporting both qt4
 and qt5 (using multibuild.eclass) /might/ be useful. Looking forward to
 hearing Qt team opinion.

Maybe. But you'll have to convince me. We aren't planning on writing
the qt5 equivalent of qt4-r2.eclass; qmake-utils.eclass should
suffice. Therefore I don't see much usefulness in a glue eclass such
as the one you're proposing.

In any case, this is completely off-topic. Please start a separate
discussion or open a bug.

Thanks,
Pesa

[gentoo-dev] Re: [PATCH] qt4-r2.eclass: simplify doc handling

[Davide Pesavento]

On Wed, Jun 18, 2014 at 12:43 PM, Sergey Popov pinkb...@gentoo.org wrote:
 As we should not do anything crazy with DOCS and HTML_DOCS, let's
 simplify our eclass


It's not about doing anything crazy... einstalldocs simply didn't
exist at the time.

Anyway, ACK from me. And please remember to update the qt overlay too.

Thanks,
Davide

Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default

[Davide Pesavento]

On Sun, May 11, 2014 at 11:42 PM, Michał Górny mgo...@gentoo.org wrote:
 Hi, everyone.

 Almost 9 months ago I've committed three new FEATURES for portage:
 cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
 enabling at least the latter two by default.


+1

I've been using all three of them since their introduction, without
any problems.

Thanks,
Davide

Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots

[Davide Pesavento]

On Thu, Sep 26, 2013 at 7:39 PM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 26/09/13 11:24 AM, Davide Pesavento wrote:
 On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric
 kentfred...@gmail.com wrote:

 On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org
 wrote:

 How do we handle packages which install multiple libraries? I'm
 afraid forcing such a policy and/or hurrying developers to
 adapt will only cause more of poppler-like issues to occur.


 Can you give a an example package which:

 - installs multiple libraries - has an ABI that may change for
 only one of those libraries - it is sane / plausible to expect
 one downstream dependent *not* to forcibly rebuild as a result of
 a chane in one of those libaries - it is sane / plausible to
 expect a different downstream to forcibly rebuild as a result of
 changes in one of those libraries


 dev-python/PyQt4

 Each module is a separate library, and each has its own ABI that
 can change independently from the others. Downstream projects that
 rely only on PyQt4's python API are not affected by ABI changes,
 but those (very few) that link against one or more modules (e.g.
 kde-base/pykde4 I think) must be rebuilt.


 To better round off this example, I assume that the API itself also
 changes as a whole, and slot-operators are the ideal means to force
 rebuilds on all rdeps when that occurrs?


Not sure what you mean by the API also changes as a whole.

The ABI can change without the API changing, if that's what you're
asking, but I'm sure you already know that...

 Otherwise, I don't see why this example couldn't be satisfied by
 bumping subslot whenever any sub-ABI changes and only using
 slot-operators in *DEPEND atoms on those very few packages that link
 to the modules.


You'd force unnecessary rebuilds for reverse deps not using the
library that changed ABI, just like the poppler case.

And there's an additional problem here: from what I've seen, most
people blindly add subslot operators in *DEPEND when they see that the
dep has gained a subslot, even when it's not needed at all (e.g.
python-only packages in the PyQt4 case).

Thanks,
Davide

Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots

[Davide Pesavento]

On Fri, Sep 27, 2013 at 4:44 PM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-09-26, o godz. 17:24:49
 Davide Pesavento p...@gentoo.org napisał(a):

 On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric kentfred...@gmail.com wrote:
 
  On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org wrote:
 
  How do we handle packages which install multiple libraries? I'm afraid
  forcing such a policy and/or hurrying developers to adapt will only
  cause more of poppler-like issues to occur.
 
 
  Can you give a an example package which:
 
  - installs multiple libraries
  - has an ABI that may change for only one of those libraries
  - it is sane / plausible to expect one downstream dependent *not* to
  forcibly rebuild as a result of a chane in one of those libaries
  - it is sane / plausible to expect a different downstream to forcibly
  rebuild as a result of changes in one of those libraries
 

 dev-python/PyQt4

 Each module is a separate library, and each has its own ABI that can
 change independently from the others. Downstream projects that rely
 only on PyQt4's python API are not affected by ABI changes, but those
 (very few) that link against one or more modules (e.g. kde-base/pykde4
 I think) must be rebuilt.

 How often does ABI of pyqt4 libraries change in such a way that rebuild
 of pykde4 is not required?

Practically never (see below).


 Looking at the dep:

=dev-python/PyQt4-4.9.5[${PYTHON_USEDEP},dbus,declarative,script(+),sql,svg,webkit,X]

 I'd think it's fairly rare when only the libraries not listed above
 change ABI without any of the remaining ones changing it.


Actually, most PyQt4 libraries never changed their ABIs since the
initial 4.0 release, so yes, it's fairly rare :)
That's also one of the reasons why I never bothered to add a subslot to PyQt4.

Thanks,
Davide

Re: [gentoo-dev] [RFC] Policy for migrating library consumers to subslots

[Davide Pesavento]

On Thu, Sep 26, 2013 at 4:04 PM, Kent Fredric kentfred...@gmail.com wrote:

 On 26 September 2013 19:53, Michał Górny mgo...@gentoo.org wrote:

 How do we handle packages which install multiple libraries? I'm afraid
 forcing such a policy and/or hurrying developers to adapt will only
 cause more of poppler-like issues to occur.


 Can you give a an example package which:

 - installs multiple libraries
 - has an ABI that may change for only one of those libraries
 - it is sane / plausible to expect one downstream dependent *not* to
 forcibly rebuild as a result of a chane in one of those libaries
 - it is sane / plausible to expect a different downstream to forcibly
 rebuild as a result of changes in one of those libraries


dev-python/PyQt4

Each module is a separate library, and each has its own ABI that can
change independently from the others. Downstream projects that rely
only on PyQt4's python API are not affected by ABI changes, but those
(very few) that link against one or more modules (e.g. kde-base/pykde4
I think) must be rebuilt.

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Davide Pesavento]

On Wed, Jul 24, 2013 at 9:15 AM, Mike Gilbert flop...@gentoo.org wrote:
 On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wi...@gentoo.org wrote:
 Hello,

 Please revbump an ebuild after changing its USE dependencies.

 Using net-p2p/transmission as an example, it used to depend on
 dev-qt/qtgui:4=[dbus]
 however, qtgui lost the dbus useflag, so the dependency was changed to
 dev-qt/qtgui:4=[dbus(+)]
 without revbumping the transmission ebuild. [0]

 Portage fails to notice this when resolving dependencies if the package was
 installed prior to the change, resulting in errors like the following:
   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
 with dev-qt/qtgui:4/4=[dbus] required by
 (net-p2p/transmission-2.80::gentoo, installed)

 which, I imagine, could be very frustrating for a user who doesn't mess
 with the internals of Gentoo often.

 You might think that such a revbump is overkill, but in reality the user will
 have to re-emerge the package anyway in order to get rid of the error, so 
 there
 is no point in avoiding it, unless portage changes the way it handles these
 changes.

 [0] 
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1r2=1.2


 Actually, Portage normally handles this situation gracefully by using
 the dependencies from the portage tree instead of vdb. However, in the
 case of a slot-operator dep, it always uses vdb.

 See bug 477544.

 https://bugs.gentoo.org/show_bug.cgi?id=477544


Moreover, a slot operator dep on Qt libraries is pointless. Please
remove the '='.

Thanks,
Davide

Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

[Davide Pesavento]

On Thu, Mar 7, 2013 at 10:59 AM, Thomas Sachau to...@gentoo.org wrote:
 Alexis Ballier schrieb:
 On Mon, 04 Mar 2013 21:17:50 +0100
 Thomas Sachau to...@gentoo.org wrote:
 dev-db/mysql abiwrapper
 dev-lang/perl abiwrapper
 dev-lang/python abiwrapper
 dev-lang/ruby abiwrapper
 dev-libs/gobject-introspection abiwrapper
 dev-libs/libIDL abiwrapper
 dev-scheme/guile abiwrapper
 net-libs/courier-authlib abiwrapper
 dev-qt/qtcore abiwrapper
 dev-qt/qtgui abiwrapper
 media-libs/fontconfig abiwrapper
 www-servers/apache abiwrapper
 x11-libs/pango abiwrapper
 x11-libs/gtk+ abiwrapper


 Since you are doing this per-package and not per-binary: Do you happen
 to remember/have a list of the binaries that have abi-specific output?

 Also, for the qmake example, do you have an example of difference
 between qmake32 and qmake64?

 Alexis.


 I dont have a list of binaries, i either noticed myself some
 abi-specific behaviour or got user reports for abi-specific behaviour.
 As an example i remember, dev-libs/libIDL has a config binary not
 matching the usual *-config scheme (libIDL-config-2), so instead of
 adding a random list of patterns, i simply added that package to the
 list of packages with wrapped binaries. The same applies to mysql, which
 has a mysql_config binary.

 I am not sure about the target of your qmake question, so as a general
 answer:

 qmake is something like configure for qmake based build systems. If you
 want to see the difference between qmake (32bit) and qmake (64bit), run
 a 64bit qmake on a qmake based package and do the same with a 32bit
 qmake and check the difference between the 2 runs.


Isn't this solvable by passing the right mkspec to a 64-bit qmake?

Thanks,
Pesa

Re: [gentoo-dev] The Gentoo Qt Project wants your help!

[Davide Pesavento]

On Sat, Mar 2, 2013 at 6:35 AM, Tom Wijsman tom...@gentoo.org wrote:
 On Sat, 02 Mar 2013 15:29:38 +0200
 Samuli Suominen ssuomi...@gentoo.org wrote:

 The embedded FFmpeg in avidemux is only patched to convert UNIX line
 endings to DOS line endings to match rest of the avidemux source tree

 Nope, it does various patches:

  $ ls -1 avidemux_core/ffmpeg_package/patches
 common.mak.diff
 config.mak.diff
 config.mak.mac.diff
 createPatches.sh
 libavcodec_avcodec.h.patch
 libavcodec_ff_spsinfo.h.patch
 libavcodec_golomb.h.patch
 libavcodec_h263dec.c.patch
 libavcodec_h264_parser.c.patch
 libavcodec_libavcodec.v.patch
 libavcodec_mathops.h.patch
 libavcodec_mpeg12enc.c.patch
 libavcodec_mpegvideo_enc.c.patch
 libavcodec_put_bits.h.patch
 libavcodec_vdpau.h.patch
 libavcodec_x86_fmtconvert_init.c.patch
 libavformat_isom.c.patch
 libavformat_matroskaenc.c.patch
 libavformat_mpegtsenc.c.patch
 libavutil_avutil.h.patch
 libavutil_common.h.patch
 libavutil_lfg.c.patch
 libavutil_lfg.h.patch

 I first thought it was a binary, but now that I see it is actually
 compiled from source in the avidemux build process, we have control
 over it. Therefore, I'll step up to be the primary maintainer.

 Do you want me to keep the Qt herd in the metadata.xml as secondary?

No. video or media-video or whatever it's called makes more sense.

And thanks a lot for stepping up to maintain avidemux!

Best,
Pesa

Re: [gentoo-dev] Re: [gentoo-dev-announce] Qt category move

[Davide Pesavento]

On Sun, Feb 17, 2013 at 2:08 PM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 On 17/02/2013 23:04, Markos Chandras wrote:
 
 We will use qt* instead of qt-*[1] to match the way upstream names the
 modules. So that would be dev-qt/qtcore etc

 Thanks, and thanks for the link, as I wouldn't have known how to rename
 the deps myself otherwise...


Three notable exceptions to the general rule of dropping the hyphen
from ${PN} are:

qt-assistant - qthelp (because the lib is actually called
libQtHelp.so, the assistant application will be split into a separate
package later on)

qt-qt3support - qt3support (again, the lib is libQt3Support.so)

qt-meta stays unchanged (not an upstream module, therefore it follows
gentoo *-meta naming convention, nothing should depend on the
meta-package anyway)

Cheers,
Pesa

Re: [gentoo-dev] USE flags dri, cups, pppd

[Davide Pesavento]

On Fri, Jan 18, 2013 at 12:49 PM, Andreas K. Huettel
dilfri...@gentoo.org wrote:

 During the server profile discussion, it became clear that we could clean up
 the base profiles a bit. This is unrelated to the profile versions, as the
 change would affect all versions (well, at least without bigger changes).

 What I suggested and what djc and kensington supported was:

 * move setting USE=dri and USE=cups from default/linux/make.defaults to
 targets/desktop/make.defaults

 * remove setting USE=pppd in default/linux/make.defaults, instead have it
 default to on in net-dialup/capi4k-utils (the only place where it is used)

 Opinions?


+1

Thanks,
Davide

Re: [gentoo-dev] [PATCH 1/2] Set default EGIT_SOURCEDIR to point to standard ${WORKDIR}/${P}. It allows ${S} overriding in user's code as other eclasses do:

[Davide Pesavento]

On Tue, Nov 27, 2012 at 11:22 AM, Sergei Trofimovich sly...@gentoo.org wrote:
 Before the patch I had to move subdir(not very reliable):
 EGIT_REPO_URI=git://github.com/UU-ComputerScience/uhc.git
 src_prepare() {
 mv EHC/* ./ || die
 }

 After the patch i can define it the usual way:
 EGIT_REPO_URI=git://github.com/UU-ComputerScience/uhc.git
 S=${WORKDIR}/${P}/EHC

 Original ebuild: 
 https://github.com/gentoo-haskell/gentoo-haskell/blob/master/dev-lang/uhc/uhc-.ebuild#L27

 Signed-off-by: Sergei Trofimovich sly...@gentoo.org
 ---
  git-2.eclass | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/git-2.eclass b/git-2.eclass
 index 1ecc633..1a96978 100644
 --- a/git-2.eclass
 +++ b/git-2.eclass
 @@ -21,7 +21,7 @@ DEPEND=dev-vcs/git
  # This variable specifies destination where the cloned
  # data are copied to.
  #
 -# EGIT_SOURCEDIR=${S}
 +# EGIT_SOURCEDIR=${WORKDIR}/${P}

  # @ECLASS-VARIABLE: EGIT_STORE_DIR
  # @DESCRIPTION:
 @@ -132,7 +132,7 @@ git-2_init_variables() {
 local esc_pn liverepo livebranch livecommit
 esc_pn=${PN//[-+]/_}

 -   : ${EGIT_SOURCEDIR=${S}}
 +   : ${EGIT_SOURCEDIR=${WORKDIR}/${P}}

 : ${EGIT_STORE_DIR:=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/egit-src}

 --
 1.8.0



While in theory this makes sense, it also has the potential to break
ebuilds setting S=${WORKDIR}/foo and then expecting the sources to
be inside foo. IOW it's not backward compatible, is it?

Thanks,

Davide Pesavento (pesa)

Re: [gentoo-dev] packages which won't support x32

[Davide Pesavento]

On Fri, Oct 5, 2012 at 7:28 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 This is the case with dev-lang/v8: it doesn't build on x32
 (https://bugs.gentoo.org/423815), and upstream said they *won't*
 support x32
 (https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ).

 Note that with v8 it's not just about getting v8 itself to compile, but
 also making it generate correct JIT code on x32, which would require
 substantial changes to v8 code (in fact, a whole new 40K arch port, see
 the discussion linked to above).


Is it possible to disable the JIT engine?

 Should dev-lang/v8 get p.masked on x32 profile, or is there some better
 way to handle it? What are your suggestions?


Qt5 uses a forked version of v8 for QML/QtQuick. So this means that
x11-libs/qt-jsbackend:5 (available in qt overlay) and all the packages
depending on it, including qt-declarative:5 and kde, won't be
available on x32 :-/

 I had a crazy idea to just build v8 and v8-dependent packages using
 non-x32 ABI, but I'm not sure if it's possible and if it would be the
 right thing to do.

 Paweł


Thanks,
Davide

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Davide Pesavento]

On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote:
 On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com wrote:
 On 28/07/12 08:22, Ben de Groot wrote:

 In preparation for that, we want to ask maintainers of all ebuilds in
 the tree with dependencies on Qt4, to make sure that they have the
 proper slot. Otherwise your package may pull in Qt5 while it may not
 in fact support it.


 This can be trouble if the application actually works with Qt5.  It might
 depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is
 mostly compatible with much of existing Qt4 code), needlessly pulling-in
 Qt4.  Many applications simply build and run as-is and no code changes are
 necessary.

 So what would be the methodology of making sure a package has the proper
 slot?

 Obviously you would need to make sure that the package actually does
 support Qt5. Then, as I see it, we could do either:

 || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )


This is wrong because qt4 and qt5 are not binary compatible.

 or:

 qt4? ( x11-libs/qt-gui:4 )
 qt5? ( x11-libs/qt-gui:5 )


This is the only alternative AFAICS.

Thanks,
Pesa

Re: [gentoo-dev] Re: Fwd: Heads up for Qt5

[Davide Pesavento]

On Fri, Jul 27, 2012 at 11:56 PM, Nikos Chantziaras rea...@gmail.com wrote:
 On 28/07/12 09:46, Davide Pesavento wrote:

 On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote:

 On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com wrote:

  [...]

 So what would be the methodology of making sure a package has the proper
 slot?


 Obviously you would need to make sure that the package actually does
 support Qt5. Then, as I see it, we could do either:

 || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 )


 This is wrong because qt4 and qt5 are not binary compatible.

 or:

 qt4? ( x11-libs/qt-gui:4 )
 qt5? ( x11-libs/qt-gui:5 )


 This is the only alternative AFAICS.


 In that case, if Qt5 is installed, the application might depend on Qt4, but
 when building it, might link against Qt5.



No, that would be a bug in the ebuild or somewhere else.

BTW, I'm planning to write a qt5-utils.eclass, which will provide an
eqmake5 function similar to eqmake4 in qt4-r2.eclass.

Cheers,
Pesa

Re: [gentoo-dev] Don't require assignment of empty variables in ebuilds?

[Davide Pesavento]

On Wed, Jul 18, 2012 at 11:02 AM, Robin H. Johnson robb...@gentoo.org wrote:
 On Wed, Jul 18, 2012 at 07:53:37PM +0200, Ulrich Mueller wrote:
 Our current policy [1] requires that ebuilds must assign the seven
 variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, and
 IUSE, even if their value is empty.

 Could we drop this requirement? Repoman already enforces that
 DESCRIPTION, HOMEPAGE, LICENSE, SLOT, and KEYWORDS are non-empty
 (with some exceptions for virtuals). I don't see why we need to
 distinguish the empty value and not assigned cases.

 For example, many live ebuilds already don't define SRC_URI. I'm not
 aware of any problems caused by this.
 +1 from me.


++

Thanks,
Pesa

Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass

[Davide Pesavento]

On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny mgo...@gentoo.org wrote:
 On Sat, 14 Jul 2012 12:29:59 +0200
 Davide Pesavento p...@gentoo.org wrote:

 On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier aball...@gentoo.org
 wrote:
  On Fri, 13 Jul 2012 15:26:58 +0200
  Davide Pesavento p...@gentoo.org wrote:
 
   [...]
   + # backward compatibility for non-array variables
   + if [[ -n ${DOCS} ]]  [[ $(declare -p DOCS 2/dev/null
   21) != declare -a* ]]; then
   + dodoc ${DOCS} || die dodoc failed
   + fi
   + if [[ -n ${HTML_DOCS} ]]  [[ $(declare -p HTML_DOCS
   2/dev/null 21) != declare -a* ]]; then
   + dohtml -r ${HTML_DOCS} || die dohtml failed
   + fi
}
  
   maybe issue an eqawarn in that case telling people to convert to
   arrays; some time later make this an ewarn telling non-array
   support will be removed and again later make this a die :)
   (if you take that route i would expect you to start converting
   packages to use arrays)
  
 
  We have no intention of deprecating non-array variables in qt4-r2
  eclass.
 
  why ? having two codepaths for the same thing, one being inferior,
  sounds like a good reason to deprecate the inferior one :)
 
  A.
 

 Maintaining these two codepaths has practically zero cost, while
 forcing every ebuild using qt4-r2 to switch to arrays would waste
 developers' time which is better spent elsewhere.

 Furthermore, the non-array variant is not necessarily inferior,
 because it allows you to use bash globbing, brace expansion, etc...

 And arrays stopped to allow that overnight?


I mean that the following won't work as you might expect:

DOCS=(*.txt)

Thanks,
Pesa

Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass

[Davide Pesavento]

On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny mgo...@gentoo.org wrote:
 On Sun, 15 Jul 2012 13:00:47 +0200
 Davide Pesavento p...@gentoo.org wrote:

 On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny mgo...@gentoo.org
 wrote:
  On Sat, 14 Jul 2012 12:29:59 +0200
  Davide Pesavento p...@gentoo.org wrote:
 
  On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
  aball...@gentoo.org wrote:
   On Fri, 13 Jul 2012 15:26:58 +0200
   Davide Pesavento p...@gentoo.org wrote:
  
[...]
+ # backward compatibility for non-array variables
+ if [[ -n ${DOCS} ]]  [[ $(declare -p DOCS
2/dev/null
21) != declare -a* ]]; then
+ dodoc ${DOCS} || die dodoc failed
+ fi
+ if [[ -n ${HTML_DOCS} ]]  [[ $(declare -p HTML_DOCS
2/dev/null 21) != declare -a* ]]; then
+ dohtml -r ${HTML_DOCS} || die dohtml failed
+ fi
 }
   
maybe issue an eqawarn in that case telling people to convert
to arrays; some time later make this an ewarn telling
non-array support will be removed and again later make this a
die :) (if you take that route i would expect you to start
converting packages to use arrays)
   
  
   We have no intention of deprecating non-array variables in
   qt4-r2 eclass.
  
   why ? having two codepaths for the same thing, one being
   inferior, sounds like a good reason to deprecate the inferior
   one :)
  
   A.
  
 
  Maintaining these two codepaths has practically zero cost, while
  forcing every ebuild using qt4-r2 to switch to arrays would waste
  developers' time which is better spent elsewhere.
 
  Furthermore, the non-array variant is not necessarily inferior,
  because it allows you to use bash globbing, brace expansion, etc...
 
  And arrays stopped to allow that overnight?
 

 I mean that the following won't work as you might expect:

 DOCS=(*.txt)

 I doubt anyone would expect quoted string to be evaluated as glob.


It depends on when the expansion is performed, although in the
base.eclass case, DOCS=(*.txt) doesn't work either, because the
quoting happens inside the eclass function.

Anyway, I was just explaining why I argued that the non-array variant
is not necessarily inferior. Using DOCS=*.txt is actually a
supported use case and a valid reason not to deprecate non-array
variables.

Regards,
Pesa

Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass

[Davide Pesavento]

On Sun, Jul 15, 2012 at 5:53 PM, Michał Górny mgo...@gentoo.org wrote:
 On Sun, 15 Jul 2012 17:36:05 +0200
 Davide Pesavento p...@gentoo.org wrote:

 On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny mgo...@gentoo.org
 wrote:
  On Sun, 15 Jul 2012 13:00:47 +0200
  Davide Pesavento p...@gentoo.org wrote:
 
  On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny mgo...@gentoo.org
  wrote:
   On Sat, 14 Jul 2012 12:29:59 +0200
   Davide Pesavento p...@gentoo.org wrote:
  
   On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
   aball...@gentoo.org wrote:
On Fri, 13 Jul 2012 15:26:58 +0200
Davide Pesavento p...@gentoo.org wrote:
   
 [...]
 + # backward compatibility for non-array variables
 + if [[ -n ${DOCS} ]]  [[ $(declare -p DOCS
 2/dev/null
 21) != declare -a* ]]; then
 + dodoc ${DOCS} || die dodoc failed
 + fi
 + if [[ -n ${HTML_DOCS} ]]  [[ $(declare -p
 HTML_DOCS
 2/dev/null 21) != declare -a* ]]; then
 + dohtml -r ${HTML_DOCS} || die dohtml
 failed
 + fi
  }

 maybe issue an eqawarn in that case telling people to
 convert to arrays; some time later make this an ewarn
 telling non-array support will be removed and again later
 make this a die :) (if you take that route i would expect
 you to start converting packages to use arrays)

   
We have no intention of deprecating non-array variables in
qt4-r2 eclass.
   
why ? having two codepaths for the same thing, one being
inferior, sounds like a good reason to deprecate the inferior
one :)
   
A.
   
  
   Maintaining these two codepaths has practically zero cost, while
   forcing every ebuild using qt4-r2 to switch to arrays would
   waste developers' time which is better spent elsewhere.
  
   Furthermore, the non-array variant is not necessarily inferior,
   because it allows you to use bash globbing, brace expansion,
   etc...
  
   And arrays stopped to allow that overnight?
  
 
  I mean that the following won't work as you might expect:
 
  DOCS=(*.txt)
 
  I doubt anyone would expect quoted string to be evaluated as glob.
 

 It depends on when the expansion is performed, although in the
 base.eclass case, DOCS=(*.txt) doesn't work either, because the
 quoting happens inside the eclass function.

 Anyway, I was just explaining why I argued that the non-array variant
 is not necessarily inferior. Using DOCS=*.txt is actually a
 supported use case and a valid reason not to deprecate non-array
 variables.

 So, you're saying that you're going to support two different variants
 of the variable which work two different ways?


Basically yes. As yngwin said, we're introducing support for array
variables to be more in line with other eclasses. People do expect
DOCS to be an array variable, and I've already been asked a few times
for this kind of support.

Thanks,
Pesa

Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass

[Davide Pesavento]

On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier aball...@gentoo.org wrote:
 On Fri, 13 Jul 2012 15:26:58 +0200
 Davide Pesavento p...@gentoo.org wrote:

  [...]
  + # backward compatibility for non-array variables
  + if [[ -n ${DOCS} ]]  [[ $(declare -p DOCS 2/dev/null
  21) != declare -a* ]]; then
  + dodoc ${DOCS} || die dodoc failed
  + fi
  + if [[ -n ${HTML_DOCS} ]]  [[ $(declare -p HTML_DOCS
  2/dev/null 21) != declare -a* ]]; then
  + dohtml -r ${HTML_DOCS} || die dohtml failed
  + fi
   }
 
  maybe issue an eqawarn in that case telling people to convert to
  arrays; some time later make this an ewarn telling non-array support
  will be removed and again later make this a die :)
  (if you take that route i would expect you to start converting
  packages to use arrays)
 

 We have no intention of deprecating non-array variables in qt4-r2
 eclass.

 why ? having two codepaths for the same thing, one being inferior,
 sounds like a good reason to deprecate the inferior one :)

 A.


Maintaining these two codepaths has practically zero cost, while
forcing every ebuild using qt4-r2 to switch to arrays would waste
developers' time which is better spent elsewhere.

Furthermore, the non-array variant is not necessarily inferior,
because it allows you to use bash globbing, brace expansion, etc...

Thanks,
Pesa

Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass

[Davide Pesavento]

On Fri, Jul 13, 2012 at 2:34 PM, Alexis Ballier aball...@gentoo.org wrote:
 On Fri, 13 Jul 2012 20:02:19 +0800
 Ben de Groot yng...@gentoo.org wrote:

 --- /usr/portage/eclass/qt4-r2.eclass 2012-04-20
 07:01:13.0 +0800 +++ qt4-r2.eclass.new2012-07-13
 19:45:59.259773917 +0800 @@ -19,6 +19,22 @@

  export XDG_CONFIG_HOME=${T}

 +# @ECLASS-VARIABLE: DOCS
 +# @DEFAULT_UNSET
 +# @DESCRIPTION:
 +# Array containing documents passed to dodoc command.
 +# Paths can be absolute or relative to ${S}.
 +#
 +# Example: DOCS=( ChangeLog README ${WORKDIR}/doc_folder/ )
 +
 +# @ECLASS-VARIABLE: HTML_DOCS
 +# @DEFAULT_UNSET
 +# @DESCRIPTION:
 +# Array containing documents passed to dohtml command.
 +# Paths can be absolute or relative to ${S}.
 +#
 +# Example: HTML_DOCS=( doc/document.html ${WORKDIR}/html_folder/
 ) +
  # @ECLASS-VARIABLE: LANGS
  # @DEFAULT_UNSET
  # @DESCRIPTION:
 @@ -44,6 +60,21 @@
  done
  unset x

 +# @ECLASS-VARIABLE: PATCHES
 +# @DEFAULT_UNSET
 +# @DESCRIPTION:
 +# Array variable containing all the patches to be applied. This
 variable +# is expected to be defined in the global scope of ebuilds.
 Make sure to +# specify the full path. This variable is used in
 src_prepare phase. +#
 +# Example:
 +# @CODE
 +#   PATCHES=(
 +#   ${FILESDIR}/mypatch.patch
 +#   ${FILESDIR}/mypatch2.patch
 +#   )
 +# @CODE
 +

 this sounds like re-ordering and improving comments, no functional
 change, right ?


Correct, no functional changes in this hunk.

 [...]
 + # backward compatibility for non-array variables
 + if [[ -n ${DOCS} ]]  [[ $(declare -p DOCS 2/dev/null
 21) != declare -a* ]]; then
 + dodoc ${DOCS} || die dodoc failed
 + fi
 + if [[ -n ${HTML_DOCS} ]]  [[ $(declare -p HTML_DOCS
 2/dev/null 21) != declare -a* ]]; then
 + dohtml -r ${HTML_DOCS} || die dohtml failed
 + fi
  }

 maybe issue an eqawarn in that case telling people to convert to
 arrays; some time later make this an ewarn telling non-array support
 will be removed and again later make this a die :)
 (if you take that route i would expect you to start converting packages
 to use arrays)


We have no intention of deprecating non-array variables in qt4-r2 eclass.


 +1 for the whole thing btw

 A.


Thanks,
Pesa

[gentoo-dev] Last rites: dev-python/apiextractor, dev-python/generatorrunner

[Davide Pesavento]

# Both have been merged into =dev-python/shiboken-1.1.1.
# Removal in 30 days.
dev-python/apiextractor
dev-python/generatorrunner


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

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Davide Pesavento]

On Sun, Jun 10, 2012 at 2:25 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Sat, 09 Jun 2012 13:55:53 -0700
 Zac Medico zmed...@gentoo.org wrote:
 A dependency atom will have optional SLOT and ABI_SLOT parts. Using
 the dbus-glib depedency on glib:2 as an example [1], the dbus-glib
 dependency will be expressed with an atom such as dev-libs/glib:2:=
 and the package manager will translate that atom to
 dev-libs/glib:2:=2.32 at build time. So, ':' is always used to
 distinguish SLOT deps, and ':=' is always used to distinguish
 ABI_SLOT deps. Is that syntax good?

 Here's a nicer syntax: no ABI_SLOT variable, and SLOT=2/2.32. Then you
 can do explicit :2/2.32 dependencies if you like, or :2 (which would
 match SLOT=2 or SLOT=2/anything), or :2= (which gets rewritten
 to :2/2.32=) or :2*. If an ebuild does SLOT=2, it's treated as 2/2.


I was going to propose a very similar syntax, i.e. using a slash to
separate the regular SLOT part from the new ABI part, so +1 for
Ciaran's proposal.

Thanks,
Pesa

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

[Davide Pesavento]

On Mon, May 28, 2012 at 11:34 PM, Zac Medico zmed...@gentoo.org wrote:
 Hi,

 In case you aren't familiar with FEATURES=userpriv, here's the
 description from the make.conf(5) man page:

  Allow portage to drop root privileges and compile packages as
  portage:portage without a sandbox (unless usersandbox is also used).

 The rationale for having the separate usersandbox setting, to enable
 use of sys-apps/sandbox, is that people who enable userpriv sometimes
 prefer to have sandbox disabled in order to slightly improve
 performance. However, I would recommend to enable usersandbox by
 default, for the purpose of logging sandbox violations.

 Note that ebuilds can set RESTRICT=userpriv if they require superuser
 privileges during any of the src_* phases that userpriv affects.

 I've been using FEATURES=userpriv usersandbox for years, and I don't
 remember experiencing any problems because of it, so I think that it
 would be reasonable to have it enabled by default. Objections?
 --
 Thanks,
 Zac


I've been using both FEATURES for a few years too, seemingly without
adverse effects, so +1 from me.

Thanks,
Pesa

Re: [gentoo-dev] Last rites: media-sound/qsampler

[Davide Pesavento]

On Wed, May 9, 2012 at 11:42 PM, Natanael Olaiz nol...@gmail.com wrote:
 Hi,

 Here I attach a version that removes the eclass use.
 I then replaced a eqmake4 for qmake. I don't know if there is a
 better solution, but at least removes the deprecated eclass and
 hopefully the mask (the live ebuild is newer).


Hi Natanael,

the usage of deprecated qt4.eclass is the least problematic issue with
qsampler. There are more serious issues with the package, especially
the fact that it has been broken for 2 years (bug 380589) and no one
cared. Anyway, see comments #8 and later in that bug, let's continue
the discussion there.

(BTW, invoking qmake directly is not acceptable, you must use eqmake4)

Cheers,
Davide

Re: [gentoo-dev] add global useflag: webkit

[Davide Pesavento]

On Sun, May 6, 2012 at 2:34 AM, hasufell hasuf...@gentoo.org wrote:
 # grep :webkit use.local.desc | wc -l
 33

 I would vote to make this a global useflag:

 webkit - Adds support for the webkit library/module


I suggest the following description:

Add support for the WebKit HTML rendering/layout engine.

Otherwise +1 from me.

Thanks,
Davide

[gentoo-dev] Last rites: media-sound/qsampler

[Davide Pesavento]

# It has been broken for more than 2 years (bug 380589),
# last upstream release in 2009, uses deprecated qt4 eclass,
# long list of QA issues (bug 379663).
# Masked for removal in 30 days.
media-sound/qsampler


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

Re: [gentoo-dev] Add USE_PYTHON to profiles/info_vars

[Davide Pesavento]

On Tue, Apr 3, 2012 at 18:10, Mike Gilbert flop...@gentoo.org wrote:
 python.eclass looks at the USE_PYTHON variable to determine which
 python versions to target when building python packages which support
 installation for multiple python abis. Having it in the emerge --info
 output would be useful for diagnosing python-related bugs.

 Any objections?


+1

[gentoo-dev] Last rites: x11-libs/qt

[Davide Pesavento]

# Ben de Groot yng...@gentoo.org (25 Jun 2009)
# Mask the Qt4 meta ebuild, to prevent devs from being silly and depend on
# the meta ebuild instead of on the specific split Qt ebuilds needed. See
# bug 217161 comment 11. Users may unmask this if they want to pull in all
# Qt modules, but packages in portage (or overlays) will pull in the split
# modules they need as dependency. Unmasking this will most likely pull in
# more than you need.
# Davide Pesavento p...@gentoo.org (08 Dec 2011)
# Now superseded by x11-libs/qt-meta. Removal on 18 Dec 2011.
=x11-libs/qt-4*

(only 10 days of grace period before removal because the package has
been masked for almost 2 years and a half)