Hello, all.
So considering the previous thread, the Council and QA discussions, I
have prepared a new version of the metadata.xml update. To hopefully
make everyone happy, I come with this three-step process:
1. Add type="" attribute to tag (see attached patch),
2. Convert to ,
3. Eventually
Il 08/12/2014 01:05, Gordon Pettey ha scritto:
> On Sun, Dec 7, 2014 at 3:21 PM, Kristian Fiskers
>
>
> By all means, thanks for informing about an alternative, but I
> personally believe that it is important for the overall distribution
> to keep a wider perspective than personal non-f
Il 08/12/2014 00:17, Martin Vaeth ha scritto:
> Michał Górny wrote:
>> Have you tried mcpdf?
> I heard about it now for the first time.
>
> If I understand correctly, it uses the same library
> as pdfTK, only a somewhat later version
> (e.g. with improved unicode handling).
>
> The main difference
On Wed, 03 Dec 2014 14:07:24 -0500
Michael Orlitzky wrote:
> On 12/03/2014 07:28 AM, Diamond wrote:
> > On Mon, 01 Dec 2014 11:38:44 +0100
> > Pacho Ramos wrote:
> >
> >>
> >> # Pacho Ramos (01 Dec 2014)
> >> # Upstream dead for a long time, use sys-power/cpupower
> >> # instead. Removal in a
On Wed, Dec 3, 2014 at 2:07 PM, Michael Orlitzky wrote:
>
> It doesn't look like it's going to work so well without cpufrequtils.
> There's a new homepage with a few new releases at:
>
Are there any actual issues with cpufrequtils, beyond having a dead upstream?
I've been maintaining cpufreqd in
On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner wrote:
> eclasses are pretty great for sharing code akin to a library, but when
> *all* of your ebuild's logic is in the eclass, well, that's not really
> the intended use case as far as I can tell.
It works well in cases like KDE where you have 300 eb
On Sun, Dec 7, 2014 at 5:05 AM, Anthony G. Basile
wrote:
> 0) This reduces code reusability. The eclass is used by sys-devel/kgcc64 in
> the tree and (at least) the hardened-dev::musl overlay outside.
Yes, but while your claim that it reduces reusability is true, I think
that's potentially a goo
On Mon, Dec 8, 2014 at 9:00 AM, Anthony G. Basile wrote:
>
> Forking code does not address the QA issues currently against
> toolchain.eclass. The two issues are orthogonal and I don't think I
> connected them in my emails. I disagree with forking but have no right to
> obstruct it and would not
On 12/08/14 07:32, Rich Freeman wrote:
On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile wrote:
On 12/07/14 08:18, Michał Górny wrote:
I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.
Let's
On 12/07/14 13:54, Michał Górny wrote:
Hello, developers.
A quick sit: right now toolchain.eclass is a big blocker for multilib
that doesn't seem to want to fix itself. Considering the complexity of
the eclass, the amount of automagic dependencies and the size of
resulting patches ([1] for a sta
On 12/07/14 17:41, William Hubbs wrote:
On Sun, Dec 07, 2014 at 08:32:57AM -0500, Rich Freeman wrote:
On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
wrote:
On 12/07/14 05:37, Michał Górny wrote:
If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug report
On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile wrote:
> On 12/07/14 08:18, Michał Górny wrote:
I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.
>>> Let's get the list
On 12/07/14 08:18, Michał Górny wrote:
I will also be happy to work on replacing
the new versions of original sys-devel/gcc completely. With QA process
against toolchain.eclass if necessary.
Let's get the list of QA issues so I at least can work towards a
toolchain-r1.eclass if you're not inter
On Sun, 7 Dec 2014 11:37:57 +0100
Michał Górny wrote:
> 1. No cross-compilation support. If the project proves being a success
> it will be readded at some point. However, I will likely fork glibc
> first and work on a sane crossdev alternative.
Could you please elaborate on this ?
How and why t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'd just like to take a few seconds to say "thank you, Brian"!
- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
15 matches
Mail list logo
