Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Ben de Groot]

On 23 September 2012 18:40, Michał Górny  wrote:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos  wrote:
>
>> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>> > On Sun, 23 Sep 2012 11:07:30 +0200
>> > Thomas Sachau  wrote:
>> >
>> > > Matt Turner schrieb:
>> > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  
>> > > > wrote:
>> > > >> It is a simple eclass using autotools out-of-source builds to build
>> > > >> packages for multiple ABIs when multilib is supported.
>> > > >
>> > > > Thanks a lot, Michał! This looks good to me.
>> > > >
>> > > >> Use case: xorg packages, ask Matt.
>> > > >
>> > > > So the idea is that users want up-to-date 32-bit drivers for games and
>> > > > WINE. The emul- packages aren't a very good solution for a number of
>> > > > reasons.
>> > > >
>> > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> > > > I realized that almost everything in x11-libs/ could be converted very
>> > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> > > > addition to emul-linux-x86-opengl.
>> > > >
>> > > >
>> > >
>> > > This looks like a shortened duplication of a subset of multilib-portage
>> > > features. While this wont hurt multilib-portage (since it does exclude
>> > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
>> > > many ebuilds, which then again need another rewrite (or more likely
>> > > revert), when multilib-portage is accepted in a future EAPI.
>> >
>> > s/when/if/
>> >
>> > > So i would prefer some help/support with multilib-portage to get it
>> > > accepted sooner, instead of this additional workaround for a subset of
>> > > packages.
>> >
>> > I prefer the simpler solution.
>> >
>> > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
>> > > and wine do use multilib-portage, so we already have a working solution
>> > > for this issue.
>> >
>> > They will no longer have to do that.
>> >
>>
>> I would prefer if eclass way could be extended to packages not using
>> autotools too, otherwise, we will still need emul packages for, for
>> example, qt libs. If that would be possible via eclass, maybe
>> multilib-portage wouldn't be needed but, if not, we will still need it
>> and, then, would be nice if this inclussion for autotools packages
>> wouldn't cause more problems to get the "strong" solution land in the
>> "near" future :/
>>
>> The simpler solution (eclass) looks fine to me, but it would need to be
>> extended to more packages than autotools based ones to let it replace
>> portage-multilib/emul packages
>
> Qt uses cmake, doesn't it?

No, it uses qmake, its own make tool. See qt4-build and qt4-r2 eclasses.
KDE and a number of other reverse dependencies of the Qt libs do use cmake.

> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
>
> --
> Best regards,
> Michał Górny



-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Clarify the "as-is" license?

[Alexandre Rostovtsev]

On Sun, 2012-09-23 at 23:37 +0200, Ulrich Mueller wrote:
> - net-wireless/zd1201-firmware: No license in tarball or on homepage.

Ubuntu distributes it in their linux-firmware package with the following
LICENCE.zd1201 file:

  The firmware was originally distributed by Zydas in their original driver 
package.
  
  (You can still find it at http://linux-lc100020.sourceforge.net/ )
  This package was distributed under both the GPL and MPL.
  The firmware was in it in the form of a large array in a header file.

More precisely, if you download the old Zydas driver source from
http://sourceforge.net/projects/linux-lc100020/files/%28OLD%29%20wlan-ng%20based%20driver/
the license terms are

  The contents of this file are subject to the Mozilla Public
  License Version 1.1 (the "License"); you may not use this file
  except in compliance with the License. You may obtain a copy of
  the License at http://www.mozilla.org/MPL/

  Software distributed under the License is distributed on an "AS
  IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  implied. See the License for the specific language governing
  rights and limitations under the License.

  Alternatively, the contents of this file may be used under the
  terms of the GNU Public License version 2 (the "GPL"), in which
  case the provisions of the GPL are applicable instead of the
  above.  If you wish to allow the use of your version of this file
  only under the terms of the GPL and not to allow others to use
  your version of this file under the MPL, indicate your decision
  by deleting the provisions above and replace them with the notice
  and other provisions required by the GPL.  If you do not delete
  the provisions above, a recipient may use your version of this
  file under either the MPL or the GPL.

tl;dr: LICENSE="|| ( MPL-1.1 GPL-2 )"

-Alexandre.

Re: [gentoo-dev] Clarify the "as-is" license?

[Rich Freeman]

On Sun, Sep 23, 2012 at 5:37 PM, Ulrich Mueller  wrote:
> - net-misc/ntp: "as-is" looks fine as main license, although some
>   parts of the code are under different licenses like GPL (but I
>   haven't checked in detail what gets installed).

Uh, if we're distributing the sources, and they contain GPL content,
then the only valid answer is GPL, or nomirror.

> While the above are at least free software (mostly BSD/MIT like),
> I think that as-is is completely wrong for the following:
>
> - app-admin/passook: Seems to have no license at all.
>
> - net-wireless/zd1201-firmware: No license in tarball or on homepage.
>
> - net-wireless/prism54-firmware: Ditto, and package is mirror
>   restricted. (How can it be on our install media then?)
>

No license, no distribution, unless there is a declaration that it is
in the public domain, in which case that is the "license."

Thanks for checking!

Rich

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-23 23h59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-09-23 23h59 UTC.

Removals:

Additions:
media-fonts/oxygen-fonts2012-09-18 07:22:02 johu
media-libs/glu  2012-09-18 23:24:45 chithanh
games-fps/serious-sam-tse   2012-09-19 17:41:37 pinkbyte
www-misc/profile-sync-daemon2012-09-19 18:52:56 hasufell
sci-mathematics/gsl-shell   2012-09-20 16:09:24 grozin
dev-python/pyfire   2012-09-21 08:20:23 pinkbyte
games-fps/serious-sam-tfe   2012-09-22 01:59:43 pinkbyte
sec-policy/selinux-flash2012-09-22 09:26:57 swift
sec-policy/selinux-devicekit2012-09-22 09:26:59 swift
sec-policy/selinux-vdagent  2012-09-22 09:27:09 swift
sec-policy/selinux-chromium 2012-09-22 09:27:10 swift
net-analyzer/nagios-check_rbl   2012-09-23 03:12:27 flameeyes
media-sound/redoflacs   2012-09-23 04:06:03 yngwin
net-misc/gvrpcd 2012-09-23 12:52:23 pinkbyte
net-libs/libqmi 2012-09-23 21:28:19 vapier

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
Added Packages:
media-fonts/oxygen-fonts,added,johu,2012-09-18 07:22:02
media-libs/glu,added,chithanh,2012-09-18 23:24:45
games-fps/serious-sam-tse,added,pinkbyte,2012-09-19 17:41:37
www-misc/profile-sync-daemon,added,hasufell,2012-09-19 18:52:56
sci-mathematics/gsl-shell,added,grozin,2012-09-20 16:09:24
dev-python/pyfire,added,pinkbyte,2012-09-21 08:20:23
games-fps/serious-sam-tfe,added,pinkbyte,2012-09-22 01:59:43
sec-policy/selinux-flash,added,swift,2012-09-22 09:26:57
sec-policy/selinux-devicekit,added,swift,2012-09-22 09:26:59
sec-policy/selinux-vdagent,added,swift,2012-09-22 09:27:09
sec-policy/selinux-chromium,added,swift,2012-09-22 09:27:10
net-analyzer/nagios-check_rbl,added,flameeyes,2012-09-23 03:12:27
media-sound/redoflacs,added,yngwin,2012-09-23 04:06:03
net-misc/gvrpcd,added,pinkbyte,2012-09-23 12:52:23
net-libs/libqmi,added,vapier,2012-09-23 21:28:19

Done.

[gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal

[Michał Górny]

Hello,

Since my previous idea of DYNAMIC_SLOTS proved too complex to design
and implement, I would like to offer an another idea, based partially
on what Ciaran mentioned. Before I start getting into details, I'd like
to know your opinions, and what possible problems am I missing. To keep
it clean, I will focus on Python ABIs but other languages and multilib
could be handled in a similar manner.


The problem
===

Right now, building packages for multiple Python ABIs is done using
USE_EXPAND-based useflags. This is a working solution but it requires
rebuilding the package for all ABIs whenever the chosen ABI list
changes.

While it may be not that important for most of the Python packages, it
becomes such when it comes to things like boost or -- if we'd extend
that to multilib -- say, llvm. In that case, whenever a newly-installed
package requests a specific ABI, user has to spend twice as much time
to rebuild the same version.


The general idea


While not getting too deep into ebuild syntax, the core part
of the idea is to mark some of the USE_EXPAND variables 'special'.
In this particular example, such a special flag group would be
'PYTHON_TARGETS'.

Now, let's consider user installs a new package with one
python_targets_python2_7 enabled. The package is built and installed
like usual but aside to regular vdb files an additional file
is introduced, listing all the installed files as 'belonging'
to python_targets_python2_7.

If user enables python_targets_python3_2 on the same package, the PM
doesn't trigger a full rebuild. Instead, it builds the package with
the new flag being the only flag in PYTHON_TARGETS. The new files are
installed over the installed package (and added to CONTENTS in vdb),
and the files in install image are listed in vdb as 'belonging'
to python_targets_python3_2.

Whenever files from two ABIs collide, package manager either replaces
the installed files if the 'new' ABI is considered 'better' than
the old one or preserves it. This follows the current behavior when
multiple ABIs are built, and later builds overwrite files from earlier
ones.

At the point, the additional file contains something like
(ugly pseudo-syntax):

  /usr/lib64/python2.7/foo.py python_targets_python2_7
  /usr/lib64/python3.2/foo.py python_targets_python3_2
  /usr/share/doc/foo-1.2.3/README.bz2 python_targets_python2_7 \
  python_targets_python3_2

Now, if user requests disabling python_targets_python2_7
on the package, the package manager may not rebuild it as well.
Instead, it removes python_targets_python2_7 from the above list,
and unmerges the files which don't belong into any other ABI.

Sadly, this will not 'downgrade' common files to another ABI
but I believe that it is not really a killer-feature.


Installing new packages and upgrading existing
==

Whenever a new package is to be built and multiple ABIs are requested,
the package manager should split the build process between particular
ABIs. Preferably, it should build all of them one-by-one, recording
the 'belongs' entries from the image and then install them as a single
package.

Whenever a package is to be upgraded, all ABIs have to rebuilt.
The package manager can handle it as a regular package upgrade, not
considering 'belongs' entries more than in a fresh package install.

Whenever a package is removed completely, the 'belongs' entries need
not to be considered at all.


Backwards compatibility
===

The solution aims to be fully compatible with package managers
not supporting it. They should see it as a regular package with
selected useflags, and an additional opaque vdb file.

When such a package manager attempts to rebuild or upgrade such
package, the vdb file should be removed, thus not introducing any
ambiguity for PMs supporting it. The package removal is unaffected
at all.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Clarify the "as-is" license?

[Ulrich Mueller]

> On Sun, 23 Sep 2012, hasufell  wrote:

>> If we really decide to move things to a new license file, then I'd
>> rather avoid the name "as-is" because it is partly the reason for
>> the confusion.

> I agree on that. I saw it more than once that people use "as-is" for
> the license, just because there is an "as is" clause.

Right. Here's a small (but prominent) sample, namely all "as-is"
packages from the amd64 livecd and stage3:

- net-misc/ntp: "as-is" looks fine as main license, although some
  parts of the code are under different licenses like GPL (but I
  haven't checked in detail what gets installed).

- sys-apps/hdparm: "as-is" approximates it (but different wording).
  Debian lists this package as "BSD".

- dev-util/yacc: "public-domain" according to README.

- media-libs/libpng: Comes with its own license. Free.

- media-libs/portaudio: "MIT"

- net-misc/openssh: BSD-ish, something like "BSD BSD-2 as-is BEER-WARE
  public-domain" would be close.

- net-wireless/rfkill: "ISC"

- sys-apps/man-pages: Patchwork of files with different free
  licenses. "as-is GPL-2+ BSD MIT LDP-1 public-domain" would cover
  most of it.

While the above are at least free software (mostly BSD/MIT like),
I think that as-is is completely wrong for the following:

- app-admin/passook: Seems to have no license at all.

- net-wireless/zd1201-firmware: No license in tarball or on homepage.

- net-wireless/prism54-firmware: Ditto, and package is mirror
  restricted. (How can it be on our install media then?)

Ulrich

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Zac Medico]

On 09/23/2012 03:02 AM, hasufell wrote:
> On 09/23/2012 11:56 AM, Michał Górny wrote:
>>> So i would prefer some help/support with multilib-portage to get
>>> it accepted sooner, instead of this additional workaround for a
>>> subset of packages.
> 
>> I prefer the simpler solution.
> 
> 
> I prefer the stronger solution. This is just a quick workaround.
> 
> -1
> 

I'm in favor of adding multilib functions to the package manager in a
future EAPI, but I'm not convinced that the current multilib-portage
branch is using the best design. For example, it recently came to my
attention that it calls pkg_preinst in a loop for each multilib-ABI.
This seems like a bad idea to me, since pkg_preinst often contains stuff
that only needs to run once, rather than for each multilib-ABI. I would
prefer that such loops be coded explicitly in pkg_preinst whenever they
are needed, and approach taken by the proposed autotools-multilib.eclass
is more in alignment with this preference.
-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 5:30 AM, Pacho Ramos  wrote:
> One problem that I remembered now:
> If every ebuild inheritting this eclass (either this one or similar)
> will add a "multilib" USE, people running multilib profiles will get it
> enabled for ALL packages inheritting it, causing them to see how their
> systems grow a lot because they will have 32bits libs for all packages,
> even when not needed. For example, in my systems I need gtk+ 32 bits
> libs, but not qt ones as I don't have any qt based app requiring 32bits
> installed.

Currently, yes, that is the case.

The fix is pretty simple though, and is in progress:
https://bugs.gentoo.org/show_bug.cgi?id=435094 (previously mentioned
in this thread...)

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 2:07 AM, Thomas Sachau  wrote:
> Matt Turner schrieb:
>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
>>> It is a simple eclass using autotools out-of-source builds to build
>>> packages for multiple ABIs when multilib is supported.
>>
>> Thanks a lot, Michał! This looks good to me.
>>
>>> Use case: xorg packages, ask Matt.
>>
>> So the idea is that users want up-to-date 32-bit drivers for games and
>> WINE. The emul- packages aren't a very good solution for a number of
>> reasons.
>>
>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> I realized that almost everything in x11-libs/ could be converted very
>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> addition to emul-linux-x86-opengl.
>>
>>
>
> This looks like a shortened duplication of a subset of multilib-portage
> features. While this wont hurt multilib-portage (since it does exclude
> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> many ebuilds, which then again need another rewrite (or more likely
> revert), when multilib-portage is accepted in a future EAPI.

I'd much rather have portage handle this for me as well.
Unfortunately, the last mail I see about multilib-portage is from two
months ago. If it were in EAPI 5, I'd be happy to wait for it. If it
even looked like it were progressing, I might wait. But, as you know,
gentoo-dev is where ideas go to die.

As far as ebuild conversions go, this is really simple.

> So i would prefer some help/support with multilib-portage to get it
> accepted sooner, instead of this additional workaround for a subset of
> packages.

That seems like a reasonable request. Let me re-read the previously
mentioned thread and get back to you.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 3:02 AM, hasufell  wrote:
> I prefer the stronger solution. This is just a quick workaround.

And I'd prefer if people who aren't involved with what I'm working on
don't try to block my progress.

I appreciate your opinion, and truthfully I'd just rather have portage
handle this for me but until that time comes I'm going to use Michal's
eclass.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 9:07 AM, Diego Elio Pettenò
 wrote:
> On 22/09/2012 20:42, Matt Turner wrote:
>> I think this means "make 32-bit binary packages' dependencies on amd64
>> not use the emul- packages"? If so, that'd certainly be a component of
>> getting rid of emul-linux-x86-xlibs. It's not in the scope of my
>> project to get rid of /all/ of the emul- packages, but I agree that
>> that is a worthwhile goal.
>
> Mostly I don't want to have to build Xaw in both variants given I use
> neither.. but that would happen if you just made the emul depend on the
> packages that are converted...

Ahh, indeed. You mean that existing dependencies on
emul-linux-x86-xlibs should be converted into finer-grained
dependencies on individual libraries. Of course, that is a very good
idea.

In the case of Xaw, I added a deprecated USE flag recently that
controls the building of the old Xaw6, so we're already working toward
trimming Xaw from users' systems. :)

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 16:26:55 +0200
Peter Stuge  wrote:

> Michał, Pacho, and everyone else who suck epically at this:
> 
> CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS!

I've trimmed them in the next e-mail to the one you replied to :P.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 12:47:44 -0300
Alexis Ballier  wrote:

> On Sun, 23 Sep 2012 09:21:20 +0200
> Michał Górny  wrote:
> 
> > On Sat, 22 Sep 2012 21:46:02 -0300
> > Alexis Ballier  wrote:
> > 
> > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > Michał Górny  wrote:
> > > 
> > > > It is a simple eclass using autotools out-of-source builds to
> > > > build packages for multiple ABIs when multilib is supported.
> > > >
> > > 
> > > to some extent, can't you do the same by unpacking twice to
> > > different $S and calling src_prepare/compile/install instead of
> > > their autotools-utils counterpart with tweaked $S so that it works
> > > with almost every ebuild ?
> > 
> > That would make this solution inefficient.
> 
> Why ?

Because it introduces unnecessarily copying files around.

> > The good solutions should
> > not be made ugly to support corner cases.
> 
> You are tying support to one specific build system, and one specific
> usage within ebuilds. That is what I would call a corner case :)
> Ebuilds already define a standardized way of building packages, why not
> use this directly ?
> I'm not saying your proposal is useless, it is indeed more efficient
> than a generic one, but rather that a generic solution is neither much
> more complicated nor that inefficient in comparison.

It's a common case.

A generic solution is more complicated if it is supposed to use phase
functions exported by some eclass. By using a generic solution you lose
the ability to 'automagically' use last exported function.

Some time ago I suggested replacing 'default' with something like
'next' (which would allow one exported phase function to call the one
from next inherited eclass) but I don't think I got any response.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Diego Elio Pettenò]

On 22/09/2012 20:42, Matt Turner wrote:
> I think this means "make 32-bit binary packages' dependencies on amd64
> not use the emul- packages"? If so, that'd certainly be a component of
> getting rid of emul-linux-x86-xlibs. It's not in the scope of my
> project to get rid of /all/ of the emul- packages, but I agree that
> that is a worthwhile goal.

Mostly I don't want to have to build Xaw in both variants given I use
neither.. but that would happen if you just made the emul depend on the
packages that are converted...

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Sun, 23 Sep 2012 09:21:20 +0200
Michał Górny  wrote:

> On Sat, 22 Sep 2012 21:46:02 -0300
> Alexis Ballier  wrote:
> 
> > On Sat, 22 Sep 2012 23:24:46 +0200
> > Michał Górny  wrote:
> > 
> > > It is a simple eclass using autotools out-of-source builds to
> > > build packages for multiple ABIs when multilib is supported.
> > >
> > 
> > to some extent, can't you do the same by unpacking twice to
> > different $S and calling src_prepare/compile/install instead of
> > their autotools-utils counterpart with tweaked $S so that it works
> > with almost every ebuild ?
> 
> That would make this solution inefficient.

Why ?

> The good solutions should
> not be made ugly to support corner cases.

You are tying support to one specific build system, and one specific
usage within ebuilds. That is what I would call a corner case :)
Ebuilds already define a standardized way of building packages, why not
use this directly ?
I'm not saying your proposal is useless, it is indeed more efficient
than a generic one, but rather that a generic solution is neither much
more complicated nor that inefficient in comparison.


> > -- this really starts to resemble multilib portage :)
> 
> I've said already that multilib is a thing which could be done by
> eclasses and doesn't need making PM scary. And Tommy says that
> multilib-portage handles packages having IUSE=multilib fine.

I agree with that, it also has two main advantages over multilib
portage: it can be used right now and ensures that packages have their
multilib builds tested before exposing it to users.

A.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

Pacho Ramos schrieb:
> El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
 On Sun, 23 Sep 2012 11:07:30 +0200
 Thomas Sachau  wrote:

> Matt Turner schrieb:
>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
>>> It is a simple eclass using autotools out-of-source builds to build
>>> packages for multiple ABIs when multilib is supported.
>>
>> Thanks a lot, Michał! This looks good to me.
>>
>>> Use case: xorg packages, ask Matt.
>>
>> So the idea is that users want up-to-date 32-bit drivers for games and
>> WINE. The emul- packages aren't a very good solution for a number of
>> reasons.
>>
>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> I realized that almost everything in x11-libs/ could be converted very
>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> addition to emul-linux-x86-opengl.
>>
>>
>
> This looks like a shortened duplication of a subset of multilib-portage
> features. While this wont hurt multilib-portage (since it does exclude
> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> many ebuilds, which then again need another rewrite (or more likely
> revert), when multilib-portage is accepted in a future EAPI.

 s/when/if/

> So i would prefer some help/support with multilib-portage to get it
> accepted sooner, instead of this additional workaround for a subset of
> packages.

 I prefer the simpler solution.

> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> and wine do use multilib-portage, so we already have a working solution
> for this issue.

 They will no longer have to do that.

>>>
>>> I would prefer if eclass way could be extended to packages not using
>>> autotools too, otherwise, we will still need emul packages for, for
>>> example, qt libs. If that would be possible via eclass, maybe
>>> multilib-portage wouldn't be needed but, if not, we will still need it
>>> and, then, would be nice if this inclussion for autotools packages
>>> wouldn't cause more problems to get the "strong" solution land in the
>>> "near" future :/
>>>
>>> The simpler solution (eclass) looks fine to me, but it would need to be
>>> extended to more packages than autotools based ones to let it replace
>>> portage-multilib/emul packages
>>>
>>
>> you mean something like this one?
>>
>> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass
>>
>> That was the original eclass allowing cross-compile support, but
>> required ebuilds to inherit it. multilib-portage is based on this, but
>> does not require to modify the ebuilds themselves.
>>
> 
> Yes, that is what I meant... but I don't find hard to modify ebuilds to
> inherit it :/
> 

It is not hard by itself to inherit an eclass. There is just the
limitation, that occurs with an eclass, e.g.:

-the one from mgorny only does it for autotools based ebuilds only and
even there only for libraries, headers and binaries are not done. While
one may create the same for cmake based ones, those are still only for a
subset of packages, since not all do use autotools/cmake or are
satisfied with a libs only solution
-the multilib-native eclass does extend it way more, but still has its
limitations, e.g. what happens with a new target ABI (like x32 on the
amd64 profile) or how are dependencies handled?

multilib-portage is the answer to those limitations, since it does work
for any target with multilib cross-compile support, can handle things
like the dependencies internally and can even work on not
prepared/modified ebuilds.

So before i invest even more time in getting this official, we should
better get to some conclusion, if we either go the route with eclass
based multilib cross-compile support with its limitations or if we move
this up to the package manager level.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Peter Stuge]

Michał, Pacho, and everyone else who suck epically at this:

CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS!


Thank you

//Peter


pgpJmV3IkjFsp.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El sáb, 22-09-2012 a las 23:24 +0200, Michał Górny escribió:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
> 
> Use case: xorg packages, ask Matt.
> ---
>  gx86/eclass/autotools-multilib.eclass | 72 
> +++
>  1 file changed, 72 insertions(+)
>  create mode 100644 gx86/eclass/autotools-multilib.eclass
> 
> diff --git a/gx86/eclass/autotools-multilib.eclass 
> b/gx86/eclass/autotools-multilib.eclass
> new file mode 100644
> index 000..1a345a1
> --- /dev/null
> +++ b/gx86/eclass/autotools-multilib.eclass
> @@ -0,0 +1,72 @@
> +# Copyright 1999-2012 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: $
> +
> +# @ECLASS: autotools-multilib.eclass
> +# @MAINTAINER:
> +# Michał Górny 
> +# @BLURB: autotools-utils wrapper for multilib builds
> +# @DESCRIPTION:
> +# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper
> +# introducing support for building for more than one ABI (multilib).
> +#
> +# Inheriting this eclass sets IUSE=multilib and exports autotools-utils
> +# phase function wrappers which build the package for each supported ABI
> +# if the flag is enabled. Otherwise, it works like regular
> +# autotools-utils.
[...]

One problem that I remembered now:
If every ebuild inheritting this eclass (either this one or similar)
will add a "multilib" USE, people running multilib profiles will get it
enabled for ALL packages inheritting it, causing them to see how their
systems grow a lot because they will have 32bits libs for all packages,
even when not needed. For example, in my systems I need gtk+ 32 bits
libs, but not qt ones as I don't have any qt based app requiring 32bits
installed.

Maybe the way to workaround this would be to rename it to something like
"32bits", that way if, for example, acroread RDEPENDs on gtk+[32bits],
it would only be enabled for needed packages not all


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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 14:05:58 +0200
hasufell  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 09/23/2012 12:40 PM, Michał Górny wrote:
> > On Sun, 23 Sep 2012 12:02:01 +0200 hasufell 
> > wrote:
> > 
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >> 
> >> On 09/23/2012 11:56 AM, Michał Górny wrote:
>  So i would prefer some help/support with multilib-portage to
>  get it accepted sooner, instead of this additional workaround
>  for a subset of packages.
> >>> 
> >>> I prefer the simpler solution.
> >>> 
> >> 
> >> I prefer the stronger solution. This is just a quick workaround.
> > 
> > How is it stronger? By doing implicit magic on every ebuild?
> > 
> 
> a) does not involve modifying ebuilds

How can you tell whether a particular ebuild does install libraries
which are suitable for multilib? Or are we enforcing multilib for every
single program now?

> c) is tested and developed for quite some time

Building packages on two ABIs was developed quite a long time ago,
and was tested since.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> >> On Sun, 23 Sep 2012 11:07:30 +0200
> >> Thomas Sachau  wrote:
> >>
> >>> Matt Turner schrieb:
>  On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> 
>  Thanks a lot, Michał! This looks good to me.
> 
> > Use case: xorg packages, ask Matt.
> 
>  So the idea is that users want up-to-date 32-bit drivers for games and
>  WINE. The emul- packages aren't a very good solution for a number of
>  reasons.
> 
>  I'd like to add multilib USE flags to Mesa and thus its dependencies.
>  I realized that almost everything in x11-libs/ could be converted very
>  easily, which would allow us to get rid of emul-linux-x86-xlibs in
>  addition to emul-linux-x86-opengl.
> 
> 
> >>>
> >>> This looks like a shortened duplication of a subset of multilib-portage
> >>> features. While this wont hurt multilib-portage (since it does exclude
> >>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> >>> many ebuilds, which then again need another rewrite (or more likely
> >>> revert), when multilib-portage is accepted in a future EAPI.
> >>
> >> s/when/if/
> >>
> >>> So i would prefer some help/support with multilib-portage to get it
> >>> accepted sooner, instead of this additional workaround for a subset of
> >>> packages.
> >>
> >> I prefer the simpler solution.
> >>
> >>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> >>> and wine do use multilib-portage, so we already have a working solution
> >>> for this issue.
> >>
> >> They will no longer have to do that.
> >>
> > 
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> > 
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
> > 
> 
> you mean something like this one?
> 
> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass
> 
> That was the original eclass allowing cross-compile support, but
> required ebuilds to inherit it. multilib-portage is based on this, but
> does not require to modify the ebuilds themselves.
> 

Yes, that is what I meant... but I don't find hard to modify ebuilds to
inherit it :/


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

Re: [gentoo-dev] Clarify the "as-is" license?

[hasufell]

On 09/23/2012 02:04 PM, Ulrich Mueller wrote:
> If we really decide to move things to a new license file, then I'd
> rather avoid the name "as-is" because it is partly the reason for the
> confusion.

I agree on that. I saw it more than once that people use "as-is" for the
license, just because there is an "as is" clause.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/23/2012 12:40 PM, Michał Górny wrote:
> On Sun, 23 Sep 2012 12:02:01 +0200 hasufell 
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 09/23/2012 11:56 AM, Michał Górny wrote:
 So i would prefer some help/support with multilib-portage to
 get it accepted sooner, instead of this additional workaround
 for a subset of packages.
>>> 
>>> I prefer the simpler solution.
>>> 
>> 
>> I prefer the stronger solution. This is just a quick workaround.
> 
> How is it stronger? By doing implicit magic on every ebuild?
> 

a) does not involve modifying ebuilds
b) works in a larger scale
c) is tested and developed for quite some time
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXvsmAAoJEFpvPKfnPDWzZAcH/11b4Wng7f+nyDpbFQhanpLW
56mQy4IGmEvmEqgrYyBPLtnXWh+BtNu+j0ogS8hNMxsVXvDw6HvJGbeXwebcQ6VY
OQS5l0IZvK9Zz+H4wm+ACv1i6fWPG9nRuMg8phRwfnq0jMIIF2lP1nll5T/2QYU/
fvPxiweKca9id4hozc0C0319vpVjEoX9a8/dBh6JXGNlzPq54bf7+6qep8O7mWGo
9bKXkoobwd22wUnBajcOFg4mbMu7cnKsTn0PhQBXo2+tEV5MhgugGe8USq99u8xA
CQVVRcdbjyQZW90W8c0/Dniq8LMcTY6xoKmH5a2vG0dpHahYtKtCZ2sTruxgppc=
=KNcl
-END PGP SIGNATURE-

Re: [gentoo-dev] Clarify the "as-is" license?

[Ulrich Mueller]

> On Sun, 23 Sep 2012, Rich Freeman wrote:

> Well, I can see legal problems any time you take a thousand things
> that all have a bunch of non-identical, informal licenses and treat
> them as the same.  However, I don't think it is practical to do
> otherwise.

I agree. Creating hundreds of license files because of minor
variations in wording isn't useful.

> How about having an as-is-free and an as-is-nonfree. The easier
> thing on maintainers is to make one of those just "as-is," and if we
> want to make sure we check them all the better thing is to not do
> that. However, making a new as-is-free and treating anything as-is
> as not free is probably good enough. I don't think it is wise to do
> the reverse, even though that involves the least amount of work.

If we really decide to move things to a new license file, then I'd
rather avoid the name "as-is" because it is partly the reason for the
confusion. We should follow the OSI and SPDX [1] naming, unless there
are good reasons against it.

Concerning "as-is-nonfree", we already have the slightly more specific 
"freedist" and "free-noncomm".

Ulrich

[1] 

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 13:30:41 +0200
Pacho Ramos  wrote:

> El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 13:03:56 +0200
> > Pacho Ramos  wrote:
> > 
> > > That would be better as there are a ton of ebuilds not inheritting
> > > autotools-utils.eclass even being autotools based (think for example in
> > > gnome packages or many others)
> > 
> > You could fix those ebuilds to inherit it too ;). autotools-utils was
> > especially designed to use out-of-source builds for multilib
> > in the future.
> > 
> > I'm afraid the 'upper level' is technically impossible without either
> > going into PM itself (which means waiting for EAPI 6 at least
> > and getting some scary logic into it) or reinventing the phases alike
> > ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> > degree; still, it would require each ebuild to redefine all phases.
> > 
> 
> Then, I think that main blocker to use autotools-utils.eclass more
> widely is that it needs at least eapi2, then, I am unsure if all
> packages currently shipped in emul packages could bump their eapi due
> compat with old systems.

I doubt that is an important problem anymore, considering that portage
requires at least EAPI 2 (and some ebuilds use EAPI 3 already).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

Pacho Ramos schrieb:
> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>> On Sun, 23 Sep 2012 11:07:30 +0200
>> Thomas Sachau  wrote:
>>
>>> Matt Turner schrieb:
 On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.

 Thanks a lot, Michał! This looks good to me.

> Use case: xorg packages, ask Matt.

 So the idea is that users want up-to-date 32-bit drivers for games and
 WINE. The emul- packages aren't a very good solution for a number of
 reasons.

 I'd like to add multilib USE flags to Mesa and thus its dependencies.
 I realized that almost everything in x11-libs/ could be converted very
 easily, which would allow us to get rid of emul-linux-x86-xlibs in
 addition to emul-linux-x86-opengl.


>>>
>>> This looks like a shortened duplication of a subset of multilib-portage
>>> features. While this wont hurt multilib-portage (since it does exclude
>>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
>>> many ebuilds, which then again need another rewrite (or more likely
>>> revert), when multilib-portage is accepted in a future EAPI.
>>
>> s/when/if/
>>
>>> So i would prefer some help/support with multilib-portage to get it
>>> accepted sooner, instead of this additional workaround for a subset of
>>> packages.
>>
>> I prefer the simpler solution.
>>
>>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
>>> and wine do use multilib-portage, so we already have a working solution
>>> for this issue.
>>
>> They will no longer have to do that.
>>
> 
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
> 
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages
> 

you mean something like this one?

https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass

That was the original eclass allowing cross-compile support, but
required ebuilds to inherit it. multilib-portage is based on this, but
does not require to modify the ebuilds themselves.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 13:03:56 +0200
> Pacho Ramos  wrote:
> 
> > El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 12:33:58 +0200
> > > Pacho Ramos  wrote:
> > > 
> > > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > > Thomas Sachau  wrote:
> > > > > 
> > > > > > Matt Turner schrieb:
> > > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  
> > > > > > > wrote:
> > > > > > >> It is a simple eclass using autotools out-of-source builds to 
> > > > > > >> build
> > > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > > > 
> > > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > > > 
> > > > > > >> Use case: xorg packages, ask Matt.
> > > > > > > 
> > > > > > > So the idea is that users want up-to-date 32-bit drivers for 
> > > > > > > games and
> > > > > > > WINE. The emul- packages aren't a very good solution for a number 
> > > > > > > of
> > > > > > > reasons.
> > > > > > > 
> > > > > > > I'd like to add multilib USE flags to Mesa and thus its 
> > > > > > > dependencies.
> > > > > > > I realized that almost everything in x11-libs/ could be converted 
> > > > > > > very
> > > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > > addition to emul-linux-x86-opengl.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > This looks like a shortened duplication of a subset of 
> > > > > > multilib-portage
> > > > > > features. While this wont hurt multilib-portage (since it does 
> > > > > > exclude
> > > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite 
> > > > > > for
> > > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > > > 
> > > > > s/when/if/
> > > > > 
> > > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > > accepted sooner, instead of this additional workaround for a subset 
> > > > > > of
> > > > > > packages.
> > > > > 
> > > > > I prefer the simpler solution.
> > > > > 
> > > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for 
> > > > > > games
> > > > > > and wine do use multilib-portage, so we already have a working 
> > > > > > solution
> > > > > > for this issue.
> > > > > 
> > > > > They will no longer have to do that.
> > > > > 
> > > > 
> > > > I would prefer if eclass way could be extended to packages not using
> > > > autotools too, otherwise, we will still need emul packages for, for
> > > > example, qt libs. If that would be possible via eclass, maybe
> > > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > > and, then, would be nice if this inclussion for autotools packages
> > > > wouldn't cause more problems to get the "strong" solution land in the
> > > > "near" future :/
> > > > 
> > > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > > extended to more packages than autotools based ones to let it replace
> > > > portage-multilib/emul packages
> > > 
> > > Qt uses cmake, doesn't it?
> > > 
> > > I don't mind having cmake-multilib as well? We could probably move
> > > the foreach_abi() function to some more common eclass, like multilib
> > > eclass.
> > > 
> > 
> > Looks interesting, yes, it uses cmake. I guess we would need to move all
> > packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> > better to try to go to an "upper" level like Alexis Ballier suggested
> > some messages ago?:
> > "On Sat, 22 Sep 2012 23:24:46 +0200
> > Michał Górny  wrote:
> > 
> > > It is a simple eclass using autotools out-of-source builds to build
> > > packages for multiple ABIs when multilib is supported.
> > >
> > 
> > to some extent, can't you do the same by unpacking twice to different
> > $S and calling src_prepare/compile/install instead of their
> > autotools-utils counterpart with tweaked $S so that it works with almost
> > every ebuild ?
> > 
> > -- this really starts to resemble multilib portage :)"
> > 
> > That would be better as there are a ton of ebuilds not inheritting
> > autotools-utils.eclass even being autotools based (think for example in
> > gnome packages or many others)
> 
> You could fix those ebuilds to inherit it too ;). autotools-utils was
> especially designed to use out-of-source builds for multilib
> in the future.
> 
> I'm afraid the 'upper level' is technically impossible without either
> going into PM itself (which means waiting for EAPI 6 at least
> and getting some scary logic into it) or reinventing the phases alike
> ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> degree; still, it would require each ebuild to redefine all phases.
> 

Then, I think that main blocker to use autotools-utils.eclass more
widely is that it needs at least eapi2, then, I am un

Re: [gentoo-dev] Clarify the "as-is" license?

[Rich Freeman]

On Sun, Sep 23, 2012 at 6:56 AM, Ulrich Mueller  wrote:
> So, either we should only mark free software with the as-is label.
> Then it might help if the text was clarified as in the patch below.
>
> Or we continue marking random non-free stuff with as-is. Then we
> should IMHO remove as-is from our free license groups, create a
> licenses/HPND file (text as in [1]), and move the free packages to it.

Well, I can see legal problems any time you take a thousand things
that all have a bunch of non-identical, informal licenses and treat
them as the same.  However, I don't think it is practical to do
otherwise.

How about having an as-is-free and an as-is-nonfree.  The easier thing
on maintainers is to make one of those just "as-is," and if we want to
make sure we check them all the better thing is to not do that.
However, making a new as-is-free and treating anything as-is as not
free is probably good enough.  I don't think it is wise to do the
reverse, even though that involves the least amount of work.

Rich

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 13:03:56 +0200
Pacho Ramos  wrote:

> El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 12:33:58 +0200
> > Pacho Ramos  wrote:
> > 
> > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > Thomas Sachau  wrote:
> > > > 
> > > > > Matt Turner schrieb:
> > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  
> > > > > > wrote:
> > > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > > 
> > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > > 
> > > > > >> Use case: xorg packages, ask Matt.
> > > > > > 
> > > > > > So the idea is that users want up-to-date 32-bit drivers for games 
> > > > > > and
> > > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > > reasons.
> > > > > > 
> > > > > > I'd like to add multilib USE flags to Mesa and thus its 
> > > > > > dependencies.
> > > > > > I realized that almost everything in x11-libs/ could be converted 
> > > > > > very
> > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > addition to emul-linux-x86-opengl.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > This looks like a shortened duplication of a subset of 
> > > > > multilib-portage
> > > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > > 
> > > > s/when/if/
> > > > 
> > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > accepted sooner, instead of this additional workaround for a subset of
> > > > > packages.
> > > > 
> > > > I prefer the simpler solution.
> > > > 
> > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > > and wine do use multilib-portage, so we already have a working 
> > > > > solution
> > > > > for this issue.
> > > > 
> > > > They will no longer have to do that.
> > > > 
> > > 
> > > I would prefer if eclass way could be extended to packages not using
> > > autotools too, otherwise, we will still need emul packages for, for
> > > example, qt libs. If that would be possible via eclass, maybe
> > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > and, then, would be nice if this inclussion for autotools packages
> > > wouldn't cause more problems to get the "strong" solution land in the
> > > "near" future :/
> > > 
> > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > extended to more packages than autotools based ones to let it replace
> > > portage-multilib/emul packages
> > 
> > Qt uses cmake, doesn't it?
> > 
> > I don't mind having cmake-multilib as well? We could probably move
> > the foreach_abi() function to some more common eclass, like multilib
> > eclass.
> > 
> 
> Looks interesting, yes, it uses cmake. I guess we would need to move all
> packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> better to try to go to an "upper" level like Alexis Ballier suggested
> some messages ago?:
> "On Sat, 22 Sep 2012 23:24:46 +0200
> Michał Górny  wrote:
> 
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> >
> 
> to some extent, can't you do the same by unpacking twice to different
> $S and calling src_prepare/compile/install instead of their
> autotools-utils counterpart with tweaked $S so that it works with almost
> every ebuild ?
> 
> -- this really starts to resemble multilib portage :)"
> 
> That would be better as there are a ton of ebuilds not inheritting
> autotools-utils.eclass even being autotools based (think for example in
> gnome packages or many others)

You could fix those ebuilds to inherit it too ;). autotools-utils was
especially designed to use out-of-source builds for multilib
in the future.

I'm afraid the 'upper level' is technically impossible without either
going into PM itself (which means waiting for EAPI 6 at least
and getting some scary logic into it) or reinventing the phases alike
ruby-ng/python-distutils-ng. Well, the latter may be useful to some
degree; still, it would require each ebuild to redefine all phases.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos  wrote:
> 
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > Thomas Sachau  wrote:
> > > 
> > > > Matt Turner schrieb:
> > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  
> > > > > wrote:
> > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > >> packages for multiple ABIs when multilib is supported.
> > > > > 
> > > > > Thanks a lot, Michał! This looks good to me.
> > > > > 
> > > > >> Use case: xorg packages, ask Matt.
> > > > > 
> > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > reasons.
> > > > > 
> > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > addition to emul-linux-x86-opengl.
> > > > > 
> > > > > 
> > > > 
> > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > many ebuilds, which then again need another rewrite (or more likely
> > > > revert), when multilib-portage is accepted in a future EAPI.
> > > 
> > > s/when/if/
> > > 
> > > > So i would prefer some help/support with multilib-portage to get it
> > > > accepted sooner, instead of this additional workaround for a subset of
> > > > packages.
> > > 
> > > I prefer the simpler solution.
> > > 
> > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > and wine do use multilib-portage, so we already have a working solution
> > > > for this issue.
> > > 
> > > They will no longer have to do that.
> > > 
> > 
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> > 
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
> 
> Qt uses cmake, doesn't it?
> 
> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
> 

Looks interesting, yes, it uses cmake. I guess we would need to move all
packages needing 32bits libs to this eclasses. Are you sure wouldn't be
better to try to go to an "upper" level like Alexis Ballier suggested
some messages ago?:
"On Sat, 22 Sep 2012 23:24:46 +0200
Michał Górny  wrote:

> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
>

to some extent, can't you do the same by unpacking twice to different
$S and calling src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that it works with almost
every ebuild ?

-- this really starts to resemble multilib portage :)"

That would be better as there are a ton of ebuilds not inheritting
autotools-utils.eclass even being autotools based (think for example in
gnome packages or many others)



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

[gentoo-dev] Clarify the "as-is" license?

[Ulrich Mueller]

>From time to time cases like the following are brought up to
licen...@gentoo.org, for a package that is labelled with
LICENSE="as-is":

| Permission to use, copy, modify and/or distribute this software in
| both binary and source form, for non-commercial purposes, is hereby
| granted [...]

This is clearly not free/open-source software because of the
non-commercial restriction.

In my understanding, our "as-is" really is what opensource.org lists
as "Historical Permission Notice and Disclaimer" [1]. Obviously it's
very permissive (comparable to MIT or BSD-2). It is also included in
our @OSI-APPROVED license group.

So, either we should only mark free software with the as-is label.
Then it might help if the text was clarified as in the patch below.

Or we continue marking random non-free stuff with as-is. Then we
should IMHO remove as-is from our free license groups, create a
licenses/HPND file (text as in [1]), and move the free packages to it.

Currently, 679 packages have as-is in their LICENSE.

Ulrich

[1] 

--- as-is   12 Jan 2012 19:03:23 -  1.3
+++ as-is   23 Sep 2012 09:43:19 -
@@ -1,5 +1,5 @@
-This is a generic place holder for a class of licenses that boil down to do
-no guarantees and all you get is what you have. The language is usually
+This is a generic place holder for a class of licenses that allow you to
+do most anything you want with the software. The language is usually
 similar to:
 
   Permission to use, copy, modify, and distribute this software and its
@@ -12,13 +12,11 @@
   suitability of this software for any purpose. It is provided "as is"
   without express or implied warranty.
 
-
-You will need to check the license that came with the software for the exact
-specifics. Generally you are free to do most anything you want with "as is"
-software but you should not take this license as legal advice.
+You will need to check the license that came with the software (usually as
+permission notice in the source files themselves) for the exact wording.
 
 Note: Most all license have an "as is" clause. For our purposes this does
-not make all software in this category. This category is for software with
-very little restrictions.
+not make all software in this category. This category is for software that
+complies with the Open Source Definition and has very little restrictions.
 
 The information in this license about licenses is presented "as is". :-P

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 12:02:01 +0200
hasufell  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 09/23/2012 11:56 AM, Michał Górny wrote:
> >> So i would prefer some help/support with multilib-portage to get
> >> it accepted sooner, instead of this additional workaround for a
> >> subset of packages.
> > 
> > I prefer the simpler solution.
> > 
> 
> I prefer the stronger solution. This is just a quick workaround.

How is it stronger? By doing implicit magic on every ebuild?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 12:33:58 +0200
Pacho Ramos  wrote:

> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 11:07:30 +0200
> > Thomas Sachau  wrote:
> > 
> > > Matt Turner schrieb:
> > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
> > > >> It is a simple eclass using autotools out-of-source builds to build
> > > >> packages for multiple ABIs when multilib is supported.
> > > > 
> > > > Thanks a lot, Michał! This looks good to me.
> > > > 
> > > >> Use case: xorg packages, ask Matt.
> > > > 
> > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > reasons.
> > > > 
> > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > I realized that almost everything in x11-libs/ could be converted very
> > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > addition to emul-linux-x86-opengl.
> > > > 
> > > > 
> > > 
> > > This looks like a shortened duplication of a subset of multilib-portage
> > > features. While this wont hurt multilib-portage (since it does exclude
> > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > many ebuilds, which then again need another rewrite (or more likely
> > > revert), when multilib-portage is accepted in a future EAPI.
> > 
> > s/when/if/
> > 
> > > So i would prefer some help/support with multilib-portage to get it
> > > accepted sooner, instead of this additional workaround for a subset of
> > > packages.
> > 
> > I prefer the simpler solution.
> > 
> > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > and wine do use multilib-portage, so we already have a working solution
> > > for this issue.
> > 
> > They will no longer have to do that.
> > 
> 
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
> 
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages

Qt uses cmake, doesn't it?

I don't mind having cmake-multilib as well? We could probably move
the foreach_abi() function to some more common eclass, like multilib
eclass.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 11:07:30 +0200
> Thomas Sachau  wrote:
> 
> > Matt Turner schrieb:
> > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
> > >> It is a simple eclass using autotools out-of-source builds to build
> > >> packages for multiple ABIs when multilib is supported.
> > > 
> > > Thanks a lot, Michał! This looks good to me.
> > > 
> > >> Use case: xorg packages, ask Matt.
> > > 
> > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > WINE. The emul- packages aren't a very good solution for a number of
> > > reasons.
> > > 
> > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > I realized that almost everything in x11-libs/ could be converted very
> > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > addition to emul-linux-x86-opengl.
> > > 
> > > 
> > 
> > This looks like a shortened duplication of a subset of multilib-portage
> > features. While this wont hurt multilib-portage (since it does exclude
> > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > many ebuilds, which then again need another rewrite (or more likely
> > revert), when multilib-portage is accepted in a future EAPI.
> 
> s/when/if/
> 
> > So i would prefer some help/support with multilib-portage to get it
> > accepted sooner, instead of this additional workaround for a subset of
> > packages.
> 
> I prefer the simpler solution.
> 
> > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > and wine do use multilib-portage, so we already have a working solution
> > for this issue.
> 
> They will no longer have to do that.
> 

I would prefer if eclass way could be extended to packages not using
autotools too, otherwise, we will still need emul packages for, for
example, qt libs. If that would be possible via eclass, maybe
multilib-portage wouldn't be needed but, if not, we will still need it
and, then, would be nice if this inclussion for autotools packages
wouldn't cause more problems to get the "strong" solution land in the
"near" future :/

The simpler solution (eclass) looks fine to me, but it would need to be
extended to more packages than autotools based ones to let it replace
portage-multilib/emul packages


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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/23/2012 11:56 AM, Michał Górny wrote:
>> So i would prefer some help/support with multilib-portage to get
>> it accepted sooner, instead of this additional workaround for a
>> subset of packages.
> 
> I prefer the simpler solution.
> 

I prefer the stronger solution. This is just a quick workaround.

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

iQEcBAEBAgAGBQJQXt4ZAAoJEFpvPKfnPDWzuaUH/0EfL7BxiHQo+E1KvUHNrqlX
YD1bt5c/TU82XMAQ4axqYDXSYHE8o/WYJPNFJy2ZZhseFlG1lOo9DxOd+zVIf7JE
JqbIWbgJ6r+POKWREDTH8ZWQaq3r1G4BeOH7IbxwuGrLmTUp36oSpVRYX5XnXyl0
3MvRe9bXpih8exwOJudncc/4NFtX9c12wO6CifH0xKwcr7lu7k6jpRyfD3dIpXXq
QQlY4MjuCfy6aHxp+4+CvL9WEZ4cmkXxoi/EZCsMZYb+jBQ1NF0Jxr6tULX575vz
Vvm+n3sdTPMkh863vrAmglwFYtDgucmp/OeYZD03g3Ef52x1/NefkIGcwXGUjlY=
=FXgk
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 11:07:30 +0200
Thomas Sachau  wrote:

> Matt Turner schrieb:
> > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
> >> It is a simple eclass using autotools out-of-source builds to build
> >> packages for multiple ABIs when multilib is supported.
> > 
> > Thanks a lot, Michał! This looks good to me.
> > 
> >> Use case: xorg packages, ask Matt.
> > 
> > So the idea is that users want up-to-date 32-bit drivers for games and
> > WINE. The emul- packages aren't a very good solution for a number of
> > reasons.
> > 
> > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > I realized that almost everything in x11-libs/ could be converted very
> > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > addition to emul-linux-x86-opengl.
> > 
> > 
> 
> This looks like a shortened duplication of a subset of multilib-portage
> features. While this wont hurt multilib-portage (since it does exclude
> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> many ebuilds, which then again need another rewrite (or more likely
> revert), when multilib-portage is accepted in a future EAPI.

s/when/if/

> So i would prefer some help/support with multilib-portage to get it
> accepted sooner, instead of this additional workaround for a subset of
> packages.

I prefer the simpler solution.

> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> and wine do use multilib-portage, so we already have a working solution
> for this issue.

They will no longer have to do that.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] media-video/vlc looking for a new maintainer

[Luca Barbato]

On 09/19/2012 04:00 PM, Ben de Groot wrote:
> Thanks for all you have done maintaining VLC all those years. It is
> undoubtedly one of the most popular and versatile video players out
> there. I really hope someone steps up to become its new dedicated
> maintainer.

Given I'm in contact with upstream I might cover the interim since a
release is impelling, I prefer shared maintainership though.

lu

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

Matt Turner schrieb:
> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny  wrote:
>> It is a simple eclass using autotools out-of-source builds to build
>> packages for multiple ABIs when multilib is supported.
> 
> Thanks a lot, Michał! This looks good to me.
> 
>> Use case: xorg packages, ask Matt.
> 
> So the idea is that users want up-to-date 32-bit drivers for games and
> WINE. The emul- packages aren't a very good solution for a number of
> reasons.
> 
> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> I realized that almost everything in x11-libs/ could be converted very
> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> addition to emul-linux-x86-opengl.
> 
> 

This looks like a shortened duplication of a subset of multilib-portage
features. While this wont hurt multilib-portage (since it does exclude
most actions on ebuilds with USE=multilib), it will mean a rewrite for
many ebuilds, which then again need another rewrite (or more likely
revert), when multilib-portage is accepted in a future EAPI.

So i would prefer some help/support with multilib-portage to get it
accepted sooner, instead of this additional workaround for a subset of
packages.

P.S.: I know, that users, who want up-to-date 32bit drivers for games
and wine do use multilib-portage, so we already have a working solution
for this issue.

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Suggest to specify a way to query for USEs in next council

[Pacho Ramos]

El sáb, 22-09-2012 a las 22:37 +0200, Michał Górny escribió:
> On Sat, 22 Sep 2012 21:41:24 +0200
> Pacho Ramos  wrote:
> 
> > Hello
> > 
> > This comes from:
> > http://www.gossamer-threads.com/lists/gentoo/dev/260536
> > 
> > In that one, we try to use the following:
> > has vala ${IUSE//+/} && ! use vala && return 0 
> 
> Just please stop repeating the random broken snippet and use `in_iuse`
> from eutils.eclass. That one is correct at least.
> 

Sorry, I forget about it when I sent the message (was thinking most on
specifying the way to catch USEs by PMs and I referred to the command
used in some eclasses). Obviously, I would try to use function from
eutils.eclass :)


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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sat, 22 Sep 2012 21:46:02 -0300
Alexis Ballier  wrote:

> On Sat, 22 Sep 2012 23:24:46 +0200
> Michał Górny  wrote:
> 
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> >
> 
> to some extent, can't you do the same by unpacking twice to different
> $S and calling src_prepare/compile/install instead of their
> autotools-utils counterpart with tweaked $S so that it works with
> almost every ebuild ?

That would make this solution inefficient. The good solutions should
not be made ugly to support corner cases.

> -- this really starts to resemble multilib portage :)

I've said already that multilib is a thing which could be done by
eclasses and doesn't need making PM scary. And Tommy says that
multilib-portage handles packages having IUSE=multilib fine.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature