[gentoo-dev] sys-devel/gcc::mgorny up for testing

[gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

Hello, developers and users.

As some of you know, the toolchain packages in Gentoo suffer from
lack-of-sanity issues and their maintainers are completely unwilling to
improve things. I have finally decided to start working on a fork of
the sys-devel/gcc ebuilds, and I have some bits ready for initial
testing in 'mgorny' repo, so I would like to know your opinion.


Before you start, the shortcomings are:

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.

2. No gcj support. Since the ebuild has been forked out of
toolchain.eclass, and the gcj support suffers a lot of issues there, I
decided there's no point in copying the code. Not sure if anybody
actually uses it, and if it is actually useful for anything but will
probably get reintroduced one day [above 'if' applies too].

3. No bootstrapping, fallbacks and possible some other random feature
support. The goal was pretty much to get gcc compiling first, and avoid
awful lot of effort if things prove to have no future.

4. Hardened is not tested. I think I have copied all the needed code
and fixed some stuff but I have no clue if it still works ;).


Now, the major changes are:

1. Most of the insanity removed. No more toolchain.eclass. The ebuild
has just the code for the current gcc version. You can read it and know
what it does, you don't have to parse a few dozen version conditionals,
runtime conditionals and random crap code that doesn't do anything in
some gcc versions. In fact, I think I removed most of the no-op code.
And now you can actually change something in the ebuild without caring
for gcc3.4, or without breaking stuff for stable ebuilds.

2. USE flags are supposed to work. I've replaced the cases when they
were silently ignored with REQUIRED_USE. I've also removed the silent
removals when they didn't work -- so if your current toolchain is
broken, things may actually fail instead of giving your different gcc
than you wanted. Probably deserves explanatory pkg_pretend() at some
point, with messages like 'disable USE=-foo because your toolchain is
broken'.

3. Things simplified where they could have been simplified. For
example, I removed the big gcc executable moving function and replaced
it with --enable-version-specific-runtime-libs. It was enabled in
toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
up the behaviour this eclass relies on.' So yep, precious cargo cult --
why enable something that would require you to remove your useless
complex function?!

4. Added gx86-multilib love. Now you have abi_* flags to control
the compiler runtime. Of course, since gcc is a pile of random modules
not fit for one another it has different code for different targets. In
particular, on mips you can't do two ABIs -- either single one
(non-multilib) or all three of them (--enable-multilib).

5. Added multilib gcc wrappers. Long story short, multilib gcc now
shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
doesn't screw up your system! Of course, the final implementation may
differ since it's an early idea but it works. Now distcc happily builds
stuff for your x86 clients.

6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
rather than silently skipping doc build when it's not installed...

7. Disabled bootstrap by default (and in fact completely for now). It
is not *that* useful, and means time savings (and distcc support):

     Thu Nov  6 20:39:31 2014 >>> sys-devel/gcc-4.9.2
       merge time: 1 hour, 56 minutes and 43 seconds.

     Sun Dec  7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100
       merge time: 34 minutes and 55 seconds.


If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
appreciate any bug reports, except for those covering things i've
already listed as missing :). Any further comments will be very helpful
in deciding on the way forward.

If there is a real interest in my fork, I will probably move it to gx86
as sys-devel/gcc-mgorny. 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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/07/2014 04:37 AM, Michał Górny wrote:
> Hello, developers and users.
> 
> As some of you know, the toolchain packages in Gentoo suffer from 
> lack-of-sanity issues and their maintainers are completely 
> unwilling to improve things. I have finally decided to start 
> working on a fork of the sys-devel/gcc ebuilds, and I have some 
> bits ready for initial testing in 'mgorny' repo, so I would like
> to know your opinion.
> 
> 
> Before you start, the shortcomings are:
> 
> 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.
> 
> 2. No gcj support. Since the ebuild has been forked out of 
> toolchain.eclass, and the gcj support suffers a lot of issues 
> there, I decided there's no point in copying the code. Not sure if 
> anybody actually uses it, and if it is actually useful for
> anything but will probably get reintroduced one day [above 'if'
> applies too].
> 
> 3. No bootstrapping, fallbacks and possible some other random 
> feature support. The goal was pretty much to get gcc compiling 
> first, and avoid awful lot of effort if things prove to have no 
> future.
> 
> 4. Hardened is not tested. I think I have copied all the needed 
> code and fixed some stuff but I have no clue if it still works ;).
> 
> 
> Now, the major changes are:
> 
> 1. Most of the insanity removed. No more toolchain.eclass. The 
> ebuild has just the code for the current gcc version. You can read 
> it and know what it does, you don't have to parse a few dozen 
> version conditionals, runtime conditionals and random crap code 
> that doesn't do anything in some gcc versions. In fact, I think I 
> removed most of the no-op code. And now you can actually change 
> something in the ebuild without caring for gcc3.4, or without 
> breaking stuff for stable ebuilds.
> 
> 2. USE flags are supposed to work. I've replaced the cases when 
> they were silently ignored with REQUIRED_USE. I've also removed
> the silent removals when they didn't work -- so if your current 
> toolchain is broken, things may actually fail instead of giving 
> your different gcc than you wanted. Probably deserves explanatory 
> pkg_pretend() at some point, with messages like 'disable USE=-foo 
> because your toolchain is broken'.
> 
> 3. Things simplified where they could have been simplified. For 
> example, I removed the big gcc executable moving function and 
> replaced it with --enable-version-specific-runtime-libs. It was 
> enabled in toolchain.eclass with a comment 'If we enable it on 
> non-Darwin we screw up the behaviour this eclass relies on.' So 
> yep, precious cargo cult -- why enable something that would
> require you to remove your useless complex function?!
> 
> 4. Added gx86-multilib love. Now you have abi_* flags to control 
> the compiler runtime. Of course, since gcc is a pile of random 
> modules not fit for one another it has different code for
> different targets. In particular, on mips you can't do two ABIs --
> either single one (non-multilib) or all three of them 
> (--enable-multilib).
> 
> 5. Added multilib gcc wrappers. Long story short, multilib gcc now
>  shows up in gcc-config alike crossdev -- but unlike i686
> crossdev, it doesn't screw up your system! Of course, the final 
> implementation may differ since it's an early idea but it works. 
> Now distcc happily builds stuff for your x86 clients.
> 
> 6. Added missing dependencies. Yep, USE flags now, say, pull in 
> doxygen rather than silently skipping doc build when it's not 
> installed...
> 
> 7. Disabled bootstrap by default (and in fact completely for now). 
> It is not *that* useful, and means time savings (and distcc 
> support):
> 
> Thu Nov  6 20:39:31 2014 >>> sys-devel/gcc-4.9.2 merge time: 1 
> hour, 56 minutes and 43 seconds.
> 
> Sun Dec  7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100 merge time: 
> 34 minutes and 55 seconds.
> 
> 
> If you're interested in testing it, 'layman -a mgorny' and enjoy. 
> I'd appreciate any bug reports, except for those covering things 
> i've already listed as missing :). Any further comments will be 
> very helpful in deciding on the way forward.
> 
> If there is a real interest in my fork, I will probably move it to 
> gx86 as sys-devel/gcc-mgorny. 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.
> 

As a user, what would adopting this do? For instance I run ~amd64
multilib and have had quite a time dealing with the recent multilib
changes (specifically with Humble Bundle games). Would you recommend
helping you test this simplified and/or cleaned up toolchain on one's
primary system, or is it better off for more specific systems that
don't need to be as versatile as a multi-purpose desktop machine?

Regardless, it seems really ambitious and I hope positive change comes
about for the toolchain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUhC80AAoJEJUrb08JgYgHowwH/A7s/IBm6wbQL2HafNuYCN9f
I9MQlHeS7pBaf29u18nDPInFuViGgOfUjQBazhZ9TDdNFxG/EhmNhMfXRC0iIlPs
HV9MmPWOgRQCo6E0DtTw81+E2aEPiCurqpKpTtChFZlYgN31z3sx9prevwtH1vyT
ikHounODw4ml5aRCfQAm40Hgt+UJ5tre6mS9/3c/smmMSTO1/mxzxhMedHHs5Yol
sgghqbzce5TO/LWKFpR1Jti7qF967Y9UVvQUHa/qX+jFDMN2CgIVPWI2I2s9LeW5
rR/xe94lcgJDDhTxeBG5ep0o5JXhAjNeoCq/qgcbhGM1OTzBOI/aOGjYgYa8tfA=
=rsQ8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Dnia 2014-12-07, o godz. 04:43:05
Daniel Campbell <contact@sporkbox.us> napisał(a):

> > If you're interested in testing it, 'layman -a mgorny' and enjoy. 
> > I'd appreciate any bug reports, except for those covering things 
> > i've already listed as missing :). Any further comments will be 
> > very helpful in deciding on the way forward.
> > 
> > If there is a real interest in my fork, I will probably move it to 
> > gx86 as sys-devel/gcc-mgorny. 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.
> 
> As a user, what would adopting this do? For instance I run ~amd64
> multilib and have had quite a time dealing with the recent multilib
> changes (specifically with Humble Bundle games). Would you recommend
> helping you test this simplified and/or cleaned up toolchain on one's
> primary system, or is it better off for more specific systems that
> don't need to be as versatile as a multi-purpose desktop machine?

I wouldn't run it on production system, or when you need crossdev with
4.9.2. If you're on Hardened or some less common system, I wouldn't try
it as the primary compiler. Also, best if you have a backup gcc or
binary package you can downgrade to (quickpkg --include-configs=y gcc).

That said, I'm running it on all my ~amd64 and ~x86 systems and it
works. I've rebuilt all packages on my devbox using it and nothing
(new) failed. However, I didn't try building it using <gcc-4.8.


-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Anthony G. Basile]

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 reports, except for those covering things i've
> already listed as missing :). Any further comments will be very helpful
> in deciding on the way forward.

Removing the eclass is a bad idea:

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.

1) Those version specific conditionals that you don't like give a 
history/comparison of gcc versions.  It is not cruft.  It encodes what 
versions allow what features.  Moving to the ebuilds makes this history 
much harder to read.  Think of a diff -Naur when producing a patch.  I 
like the current eclass approach.

2) Getting this to work with hardened and cross compiling and 
musl/uclibc is going to need re-writing far beyond the eclass.  The gain 
is in my opinion not worth it given what I suggest below:

>
> If there is a real interest in my fork, I will probably move it to gx86
> as sys-devel/gcc-mgorny.

I don't think we should proceed this way.  The way I'd like to proceed 
is to introduce a new toolchain-r1.eclass which addresses at least your 
QA issues below.  If I understood Ryan's plan with the eclass, it was to 
simply refactor the phase functions to modernize things but keep 
backwards compat.  When toolchain-r1.eclass is mature, then we switch 
the inherit.  I'd like to keep gcc-2* and gcc-3* around.  We could 
consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new 
eclass or just leave them with the old eclass.

Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the 
excellent hard work you've done on eclasses, but the reason this is 
happening is because of patches that toolchain lead is not accepting. 
Anyhow, most of the work with gcc (in my opinion) is with the patches 
against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When 
you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the 
tree?

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 interested in going that way.  Also, I 
take the QA issues seriously, but threatening a QA intervention against 
toolchain and then acting by forking is heavy handed.  QA actions 
against the current codebase is understandable.

So to sum, I'd like to see the QA issues (and others) address in the 
current approache and toolchain.eclass.  Since we can make mistakes and 
since toolchain is fragile, I suggest a toolchain-r1.eclass where we can 
test (just change the inheritance in gcc ebuilds for testing) and 
finally, when we're happy, do the switcheroo.


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3909 bytes --]

Dnia 2014-12-07, o godz. 08:05:59
"Anthony G. Basile" <basile@opensource.dyc.edu> napisał(a):

> 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 reports, except for those covering things i've
> > already listed as missing :). Any further comments will be very helpful
> > in deciding on the way forward.
> 
> Removing the eclass is a bad idea:
> 
> 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.

kgcc64 is no longer necessary given --enable-targets in gcc.
And the eclass code is not really reusable, it's too damn complex
and too tightly-coupled to be.

> 1) Those version specific conditionals that you don't like give a 
> history/comparison of gcc versions.  It is not cruft.  It encodes what 
> versions allow what features.  Moving to the ebuilds makes this history 
> much harder to read.  Think of a diff -Naur when producing a patch.  I 
> like the current eclass approach.

And why should I care about what gcc3.4 had? I'd rather have a properly
working gcc4.[89] ebuild I could understand. Without code that no
longer does anything but you can't see it because you are blinded by
stupid conditionals and eclass complexity.

> > If there is a real interest in my fork, I will probably move it to gx86
> > as sys-devel/gcc-mgorny.
> 
> I don't think we should proceed this way.  The way I'd like to proceed 
> is to introduce a new toolchain-r1.eclass which addresses at least your 
> QA issues below.  If I understood Ryan's plan with the eclass, it was to 
> simply refactor the phase functions to modernize things but keep 
> backwards compat.  When toolchain-r1.eclass is mature, then we switch 
> the inherit.  I'd like to keep gcc-2* and gcc-3* around.  We could 
> consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new 
> eclass or just leave them with the old eclass.

And we create a new eclass every time the old one proves being
unmaintainable to the point nobody is willing to work on it? That's
a workaround, not a solution to the problem.

> Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the 
> excellent hard work you've done on eclasses, but the reason this is 
> happening is because of patches that toolchain lead is not accepting. 
> Anyhow, most of the work with gcc (in my opinion) is with the patches 
> against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When 
> you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the 
> tree?

Naming is the least of the problems. As far as I am concerned, it can
be 'gcc-sanity-restored' or whatever.

> > 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 interested in going that way.  Also, I 
> take the QA issues seriously, but threatening a QA intervention against 
> toolchain and then acting by forking is heavy handed.  QA actions 
> against the current codebase is understandable.
> 
> So to sum, I'd like to see the QA issues (and others) address in the 
> current approache and toolchain.eclass.  Since we can make mistakes and 
> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can 
> test (just change the inheritance in gcc ebuilds for testing) and 
> finally, when we're happy, do the switcheroo.

First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
understand and track. If you can remove it and make gcc into proper
ebuilds that can get revision-level changes, we can discuss.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Rich Freeman]

On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
<basile@opensource.dyc.edu> 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 reports, except for those covering things i've
>> already listed as missing :). Any further comments will be very helpful
>> in deciding on the way forward.
>
> Removing the eclass is a bad idea:
>
> 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.

Well, other packages could keep using the eclass.

I think that eclasses tend to get abused in situations like these.  It
is one thing if you have 300 ebuilds that are all maintained together
like there are with kde and logic really is shared in common between
them.

However, this eclass is only used by a few packages, the shared code
isn't across stuff installed in parallel but across stuff that changes
over time.  This is done without upstream support for the most part,
so it becomes a growing collection of workarounds.  When eclasses
start following different code paths every time a package that uses
them is versioned, it makes a lot more sense to either version the
eclass every time or move the code to the ebuild.

>
> 1) Those version specific conditionals that you don't like give a
> history/comparison of gcc versions.  It is not cruft.  It encodes what
> versions allow what features.  Moving to the ebuilds makes this history much
> harder to read.  Think of a diff -Naur when producing a patch.  I like the
> current eclass approach.

Why do we need a history/comparison of gcc written in shell script?
Wouldn't a text file or webpage be a better way to document this?
Wouldn't upstream be the place to document this?

This seems a bit like saying that we don't need the EAPI/PMS guide or
even PMS itself because anybody can just read the portage source code
and figure out how it works.

If you need a list of what features are supported in what versions of
gcc, wouldn't it make more sense to create a wiki page somewhere?

>>
>> If there is a real interest in my fork, I will probably move it to gx86
>> as sys-devel/gcc-mgorny.
>
>
> I don't think we should proceed this way.  The way I'd like to proceed is to
> introduce a new toolchain-r1.eclass which addresses at least your QA issues
> below.  If I understood Ryan's plan with the eclass, it was to simply
> refactor the phase functions to modernize things but keep backwards compat.
> When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
> keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
> to work with EAPI=4 or 5 with the new eclass or just leave them with the old
> eclass.
>
> Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
> excellent hard work you've done on eclasses, but the reason this is
> happening is because of patches that toolchain lead is not accepting.
> Anyhow, most of the work with gcc (in my opinion) is with the patches
> against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When you
> don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree?

Well, that would be in keeping with GLEP 39, which seems to encourage
everybody to fork each other's packages.  :)

It seems like there is a fundamental disagreement here over the right
way to refactor all this code.  Honestly, the fact that nobody seems
to even want to look at the toolchain suggests to me that
simplification is probably worthwhile.

>
> 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 interested in going that way.  Also, I
> take the QA issues seriously, but threatening a QA intervention against
> toolchain and then acting by forking is heavy handed.  QA actions against
> the current codebase is understandable.

Agree somewhat.

Forking is perfectly fine - a complete non-issue.  Trying to exclude
the other branch in the name of QA is something we need to be careful
about and consider on the merits.  If somebody wants to add yet
another gcc implementation to the tree and it is really lousy, I don't
really have a problem with it if it builds and doesn't contain
security issues, etc.  I think people sometimes try to make QA into
something that it isn't.  In the same way there is nothing wrong with
the existing gcc implementation being completely unmaintainable and
obsolete as long as it builds and doesn't contain security issues.

I think the real issue we run into in these kinds of cases is
namespace.  If I want to add my own competing ebuild for chromium I
can't call it chromium.

--
Rich

[gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> wrote:
>
> 2. No gcj support. [...] Not sure if anybody
> actually uses it, and if it is actually useful for anything

The most important consumer is app-text/pdftk
Unfortunately, there is still no replacement for the latter
which works as good, especially if you have tricky pdfs to
process. Loosing gcj would therefore be a real loss.

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Dnia 2014-12-07, o godz. 18:15:50
Martin Vaeth <martin@mvath.de> napisał(a):

> Michał Górny <mgorny@gentoo.org> wrote:
> >
> > 2. No gcj support. [...] Not sure if anybody
> > actually uses it, and if it is actually useful for anything
> 
> The most important consumer is app-text/pdftk
> Unfortunately, there is still no replacement for the latter
> which works as good, especially if you have tricky pdfs to
> process. Loosing gcj would therefore be a real loss.

Have you tried mcpdf? I heard it's drop-in replacement, but testing
with your tricky PDFs would be a great test.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Tim Harder]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On 2014-12-07 13:15, Martin Vaeth wrote:
> The most important consumer is app-text/pdftk
> Unfortunately, there is still no replacement for the latter
> which works as good, especially if you have tricky pdfs to
> process. Loosing gcj would therefore be a real loss.

As long as you're fine with any command-line pdf processing tool, you
could use app-text/cpdf which I've used for a long time and just added
to the tree.

Note that it's licensed under a non-commercial type license though.

Tim

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/07/2014 07:45 PM, Tim Harder wrote:
> On 2014-12-07 13:15, Martin Vaeth wrote:
>> The most important consumer is app-text/pdftk Unfortunately,
>> there is still no replacement for the latter which works as
>> good, especially if you have tricky pdfs to process. Loosing gcj
>> would therefore be a real loss.
> 
> As long as you're fine with any command-line pdf processing tool, 
> you could use app-text/cpdf which I've used for a long time and
> just added to the tree.
> 
> Note that it's licensed under a non-commercial type license
> though.

Why would we want to replace a working GPL-2 application for an
application under a non-free license? As one of the users of
app-text/pdftk I'm not a big supporter of this (although I have not
looked into mcpdf as was brought up earlier in this thread, although
that as well seems to be under a more restrictive AGPL-3 license).


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUhLI0AAoJEPw7F94F4TagRZcQAJyjF0xSxiwawZCa12vVu/nK
xt8G1QaXyy89g/hcnRuqaK23+5thEoz5F3KOkHCmq8M5G6IeZ39JTVxHgLtLUtaV
5XMSf/b+WU8SDB6UPB8aMphZPx1BtcYls4HMgjK+a5+wzkNyzlFL5cjVkSzC0ldw
WEz1qerE7mmE+7Rh6ae7/iqxArjH+Y8rKRzdXmnK10b4bhibCZtCSi3ew9nHcYLi
5wraotSLWSWZQc6Z6kysFmKqR6dlhzYNuQsGtNmE4Pum3fmmiKXlTKYao2fyn+Uf
afvW+rCokUfF4uEUHVAeNKhyrSkGU7ojcVhl1K4TnD6iGgKRz2aT9McELDI+JVrf
AsOWsr8Hjno6jypdKvHUOMKmFFFkq8vLtiS+gHtGkT5nNeeM8tjvkqBgKgFED13q
5CpTXn2Sccxvl8aJBv6LXFP4Ye4GenwKpow7nhutBR9nYLrP6JlLp7g6xWELLUxn
ARTwQRtLWkKsroWh+EQyCQWQu55pRsvNAjcxUEVs+wEC/O3DHXrSUaFK7wTP5OhU
pn0dNg3eZ8SMCmSGc4X+qhlPXRPTC1bUPPhlNjf2q3jzIPScyAkdjVpGsmsvncK8
B4tbDj0tG3S1p+U1nc2ZPEd9SLaInEP41b9pDuFHnI6UF2ydNAsYN1+1ro6p+Pe/
LL+AwkuHLPvI4p/XoVlz
=t1ZM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Tim Harder]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On 2014-12-07 15:02, Kristian Fiskerstrand wrote:
> >> The most important consumer is app-text/pdftk Unfortunately,
> >> there is still no replacement for the latter which works as
> >> good, especially if you have tricky pdfs to process. Loosing gcj
> >> would therefore be a real loss.
> > As long as you're fine with any command-line pdf processing tool, 
> > you could use app-text/cpdf which I've used for a long time and
> > just added to the tree.
> > Note that it's licensed under a non-commercial type license
> > though.

> Why would we want to replace a working GPL-2 application for an
> application under a non-free license? As one of the users of
> app-text/pdftk I'm not a big supporter of this (although I have not
> looked into mcpdf as was brought up earlier in this thread, although
> that as well seems to be under a more restrictive AGPL-3 license).

I'm not saying it's a replacement, it's an alternative. Also, some of us
are less picky about licensing issues as long as the source code is
available and free for personal use. :)

Tim

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/07/2014 10:05 PM, Tim Harder wrote:
> On 2014-12-07 15:02, Kristian Fiskerstrand wrote:
>>>> The most important consumer is app-text/pdftk Unfortunately, 
>>>> there is still no replacement for the latter which works as 
>>>> good, especially if you have tricky pdfs to process. Loosing
>>>> gcj would therefore be a real loss.
>>> As long as you're fine with any command-line pdf processing
>>> tool, you could use app-text/cpdf which I've used for a long
>>> time and just added to the tree. Note that it's licensed under
>>> a non-commercial type license though.
> 
>> Why would we want to replace a working GPL-2 application for an 
>> application under a non-free license? As one of the users of 
>> app-text/pdftk I'm not a big supporter of this (although I have
>> not looked into mcpdf as was brought up earlier in this thread,
>> although that as well seems to be under a more restrictive AGPL-3
>> license).
> 
> I'm not saying it's a replacement, it's an alternative. Also, some
> of us are less picky about licensing issues as long as the source
> code is available and free for personal use. :)

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-free use (even if this
is a developers primary focus as reason for contribution), otherwise
we'll hit a wall quickly enough.

In this specific case I at least use pdftk for some batch jobs on
business-related servers and a non-commercial license would not be
viable.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUhMTtAAoJEPw7F94F4Tagn10P/R2gwMiIY+e4lziLeeV00o5R
J+u9VStV34Hbl38KuinwQOMZR3ZyBv1NY0wvTB185S6GdsrXX2kNUK2iIyAL+5PN
aiOrVbvskIaeiHI1aBaWVminFIuXf+ZEcR0/qGRXnLWqeQrXjhBWeaQUooXy1t9S
FPkzSgfHjBxtWjRRrPCEhgVY4IqQDFXbTAIg86hkYHZENXfTAURMC2Xg/fRjl+Uo
OHkaJSyh+LsHKOwwTUpGjd9RLpVA1JV/Hr+vTPIEdFEcUcegmFJ6xza1qzG3WevH
LPkiebx427R7goDkiEe+cjQXBAS/Rt2Hi8gYJdVfPgYqIf+qZlfuUMg6AprqCr6S
+Q7ppK3zF57doakAMQnmgNscctTzIuD2iZz0paiQFnJhX2vayO8CRVLg3mQhFsL2
pW2NaPrDU1y1ONRGQlDWEcHzhwbkeO9e4vZPm4eYLYLuLsO2voQaVeWts8JFeH59
7Yy1XdXPQVyxKZUK0QNoIB9PC/bzyFhjZLvSAc5Z4J7Aqkktuf16FmvQavJuNBd6
IBL2lnU+mdo3xTIGbwi1Sfu/pfFkZ/NvQDHE70PaAnUlxZyS3vkAq7RehHsBMZ3J
syne19H7EFjSRZToTd8GRqyuhLzAYC/rd6NS2isppbJeKE3NHw2ercL8jXEusosP
gIXiLmbLh0wpIUynexgJ
=QVxo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

Hi,

On Sun, 07 Dec 2014 22:21:50 +0100 Kristian Fiskerstrand wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 12/07/2014 10:05 PM, Tim Harder wrote:
> > On 2014-12-07 15:02, Kristian Fiskerstrand wrote:
> >>>> The most important consumer is app-text/pdftk Unfortunately, 
> >>>> there is still no replacement for the latter which works as 
> >>>> good, especially if you have tricky pdfs to process. Loosing
> >>>> gcj would therefore be a real loss.
> >>> As long as you're fine with any command-line pdf processing
> >>> tool, you could use app-text/cpdf which I've used for a long
> >>> time and just added to the tree. Note that it's licensed under
> >>> a non-commercial type license though.
> > 
> >> Why would we want to replace a working GPL-2 application for an 
> >> application under a non-free license? As one of the users of 
> >> app-text/pdftk I'm not a big supporter of this (although I have
> >> not looked into mcpdf as was brought up earlier in this thread,
> >> although that as well seems to be under a more restrictive AGPL-3
> >> license).
> > 
> > I'm not saying it's a replacement, it's an alternative. Also, some
> > of us are less picky about licensing issues as long as the source
> > code is available and free for personal use. :)
> 
> 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-free use (even if this
> is a developers primary focus as reason for contribution), otherwise
> we'll hit a wall quickly enough.
> 
> In this specific case I at least use pdftk for some batch jobs on
> business-related servers and a non-commercial license would not be
> viable.

Seconded here. Now and then I use pdftk for some conversions for my
job, so non-commercial licensed alternative is a no go.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 4509 bytes --]

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
> <basile@opensource.dyc.edu> 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 reports, except for those covering things i've
> >> already listed as missing :). Any further comments will be very helpful
> >> in deciding on the way forward.
> >
> > Removing the eclass is a bad idea:
> >
> > 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.
> 
> Well, other packages could keep using the eclass.
> 
> I think that eclasses tend to get abused in situations like these.  It
> is one thing if you have 300 ebuilds that are all maintained together
> like there are with kde and logic really is shared in common between
> them.
> 
> However, this eclass is only used by a few packages, the shared code
> isn't across stuff installed in parallel but across stuff that changes
> over time.  This is done without upstream support for the most part,
> so it becomes a growing collection of workarounds.  When eclasses
> start following different code paths every time a package that uses
> them is versioned, it makes a lot more sense to either version the
> eclass every time or move the code to the ebuild.

This makes sense to me as well, let's work twoard getting rid of
toolchain.eclass.

> 
> >
> > 1) Those version specific conditionals that you don't like give a
> > history/comparison of gcc versions.  It is not cruft.  It encodes what
> > versions allow what features.  Moving to the ebuilds makes this history much
> > harder to read.  Think of a diff -Naur when producing a patch.  I like the
> > current eclass approach.
> 
> Why do we need a history/comparison of gcc written in shell script?
> Wouldn't a text file or webpage be a better way to document this?
> Wouldn't upstream be the place to document this?
> 
> This seems a bit like saying that we don't need the EAPI/PMS guide or
> even PMS itself because anybody can just read the portage source code
> and figure out how it works.
> 
> If you need a list of what features are supported in what versions of
> gcc, wouldn't it make more sense to create a wiki page somewhere?

I thinkk this makes more sense as well. Historical reasons don't work
for me by them selves as a reason to justify keeping old code,
especially when it is to support versions of packages that are no longer
really supported upstream.

> 
> >>
> >> If there is a real interest in my fork, I will probably move it to gx86
> >> as sys-devel/gcc-mgorny.
> >
> >
> > I don't think we should proceed this way.  The way I'd like to proceed is to
> > introduce a new toolchain-r1.eclass which addresses at least your QA issues
> > below.  If I understood Ryan's plan with the eclass, it was to simply
> > refactor the phase functions to modernize things but keep backwards compat.
> > When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
> > keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
> > to work with EAPI=4 or 5 with the new eclass or just leave them with the old
> > eclass.

Why do you want to keep these outdated and not supported versions of gcc
around? Have you tried building a modern system with gcc-2 or gcc-3? I
haven't but I'm sure it would fail horribly.

> >
> > Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
> > excellent hard work you've done on eclasses, but the reason this is
> > happening is because of patches that toolchain lead is not accepting.
> > Anyhow, most of the work with gcc (in my opinion) is with the patches
> > against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When you
> > don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree?
> 
> Well, that would be in keeping with GLEP 39, which seems to encourage
> everybody to fork each other's packages.  :)
> 
> It seems like there is a fundamental disagreement here over the right
> way to refactor all this code.  Honestly, the fact that nobody seems
> to even want to look at the toolchain suggests to me that
> simplification is probably worthwhile.
 
 I tend to agree here too; let's get rid of the old versions of things
 where we can and simplify.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Martin Vaeth]

Michał Górny <mgorny@gentoo.org> 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 seems to be that it does not insist
on gcj but apparently should work with any java: I had
suspected that it is the library which depends on some
gcj internals and not just the front-end which consists
just of a few lines, anyway.

So, indeed, this looks like it should be a drop-in
replacement, though I did not check whether the
license of the updated library changed.

Anyway, it would be nice to have it in the tree. ;)

> but testing with your tricky PDFs

I do not remember anymore. I just remember that
several times, when some deadline approached,
I had to resort to pdftk at my institute's Debian
(in the lack of a gcj at home), even for simple tasks
as merging pdftex output with some scanned PDF pages:
neither pdfjam nor poppler did it satisfactory,
though I do not remember the reasons.

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

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-free use (even if this
> is a developers primary focus as reason for contribution), otherwise
> we'll hit a wall quickly enough.
>
> In this specific case I at least use pdftk for some batch jobs on
> business-related servers and a non-commercial license would not be
> viable.


pdfTK is also GPLv2, (effectively GPLv3 since iText is /A/GPLv/3/?
Effectively AGPLv3 when in a public-facing service?) unless you're paying
for it. I doubt m-click would refuse to consider alternative paid licensing
if they were asked.

[-- Attachment #2: Type: text/html, Size: 1053 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Alexis Ballier]

On Sun, 7 Dec 2014 11:37:57 +0100
Michał Górny <mgorny@gentoo.org> 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 this broke, what is wrong in glibc, what would be a "sane
crossdev alternative" and how crossdev is not.

Alexis.

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Anthony G. Basile]

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 interested in going that way.  Also, I
>> take the QA issues seriously, but threatening a QA intervention against
>> toolchain and then acting by forking is heavy handed.  QA actions
>> against the current codebase is understandable.
>>
>> So to sum, I'd like to see the QA issues (and others) address in the
>> current approache and toolchain.eclass.  Since we can make mistakes and
>> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
>> test (just change the inheritance in gcc ebuilds for testing) and
>> finally, when we're happy, do the switcheroo.
> First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
> understand and track. If you can remove it and make gcc into proper
> ebuilds that can get revision-level changes, we can discuss.
>

Hey! why don't I join QA so I can also "fix" eclasses that I find 
"intrusive".  Let's not make QA the final refuge of those who want to 
push through their preferences.

To proceed forward, you have bugs open against toolchain.eclass. The 
practice is to submit the patches to this list for review.  If after 
awards you have community support, commit despite the maintainer's 
objections.  Having obtained community support, you will have much more 
legitimacy against reverts.  I can't speak for the whole council, but I 
would support you under such circumstances.  I cannot support a position 
where QA simply asserts itself.  When/if an appeal percolates up to the 
council, I will side with the maintainer under the argument that the 
commit to the eclass was not sufficiently reviewed.

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

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Rich Freeman]

On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile <blueness@gentoo.org> 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 of QA issues so I at least can work towards a
>>> toolchain-r1.eclass if you're not interested in going that way.  Also, I
>>> take the QA issues seriously, but threatening a QA intervention against
>>> toolchain and then acting by forking is heavy handed.  QA actions
>>> against the current codebase is understandable.
>>>
>>> So to sum, I'd like to see the QA issues (and others) address in the
>>> current approache and toolchain.eclass.  Since we can make mistakes and
>>> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
>>> test (just change the inheritance in gcc ebuilds for testing) and
>>> finally, when we're happy, do the switcheroo.
>>
>> First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
>> understand and track. If you can remove it and make gcc into proper
>> ebuilds that can get revision-level changes, we can discuss.
>>
>
> Hey! why don't I join QA so I can also "fix" eclasses that I find
> "intrusive".  Let's not make QA the final refuge of those who want to push
> through their preferences.
>
> To proceed forward, you have bugs open against toolchain.eclass. The
> practice is to submit the patches to this list for review.  If after awards
> you have community support, commit despite the maintainer's objections.
> Having obtained community support, you will have much more legitimacy
> against reverts.  I can't speak for the whole council, but I would support
> you under such circumstances.  I cannot support a position where QA simply
> asserts itself.  When/if an appeal percolates up to the council, I will side
> with the maintainer under the argument that the commit to the eclass was not
> sufficiently reviewed.
>

++ regarding how QA should operate.

I have no issues with him forking the ebuild and doing things his own
way though.

--
Rich

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Anthony G. Basile]

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
>> <basile@opensource.dyc.edu> 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 reports, except for those covering things i've
>>>> already listed as missing :). Any further comments will be very helpful
>>>> in deciding on the way forward.
>>> Removing the eclass is a bad idea:
>>>
>>> 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.
>> Well, other packages could keep using the eclass.
>>
>> I think that eclasses tend to get abused in situations like these.  It
>> is one thing if you have 300 ebuilds that are all maintained together
>> like there are with kde and logic really is shared in common between
>> them.
>>
>> However, this eclass is only used by a few packages, the shared code
>> isn't across stuff installed in parallel but across stuff that changes
>> over time.  This is done without upstream support for the most part,
>> so it becomes a growing collection of workarounds.  When eclasses
>> start following different code paths every time a package that uses
>> them is versioned, it makes a lot more sense to either version the
>> eclass every time or move the code to the ebuild.
> This makes sense to me as well, let's work twoard getting rid of
> toolchain.eclass.

Hardened has used the eclass in its overlay and continues to use it.  We 
do not wish to get rid of it.

@hardened, we should discuss this at our next meeting.

>>> 1) Those version specific conditionals that you don't like give a
>>> history/comparison of gcc versions.  It is not cruft.  It encodes what
>>> versions allow what features.  Moving to the ebuilds makes this history much
>>> harder to read.  Think of a diff -Naur when producing a patch.  I like the
>>> current eclass approach.
>> Why do we need a history/comparison of gcc written in shell script?
>> Wouldn't a text file or webpage be a better way to document this?
>> Wouldn't upstream be the place to document this?
>>
>> This seems a bit like saying that we don't need the EAPI/PMS guide or
>> even PMS itself because anybody can just read the portage source code
>> and figure out how it works.
>>
>> If you need a list of what features are supported in what versions of
>> gcc, wouldn't it make more sense to create a wiki page somewhere?
> I thinkk this makes more sense as well. Historical reasons don't work
> for me by them selves as a reason to justify keeping old code,
> especially when it is to support versions of packages that are no longer
> really supported upstream.

I'm not sure what you mean by "old code" which is "no longer really 
supported upstream".  gcc is built using gcc.  We should have a window 
on gcc versions which goes backwards and forwards a couple of versions, 
so I can build 4.8 with 4.7 or 4.6 and vice versa.  And build 4.6 with 
4.5 or 4.4, etc.  There is an entire chain there. Keeping the detailed 
decisions in an eclass of what features were on/off for each version 
makes sense so we can conveniently track that chain.  When I say I want 
to keep history, that's what I'm talking about.  In hardened we went 
through a pains taking process of making sure the first hardened gcc-4 
versions (4.4 I believe) was buildable by the previous one, and that it 
could build itself and could rebuild itself both adding and remove 
hardening etc.  (BTW by "we" I mean Magnus who deserves all the kudos.  
I just helped with testing and told him what broke.)

If you want to simplify code, then let's bump all the gcc ebuilds to 
EAPI 4 or above and refactor the phase functions and remove all the EAPI 
checks.  But removing all instances of tc_version_is_* is not a good idea.

>
>>>> If there is a real interest in my fork, I will probably move it to gx86
>>>> as sys-devel/gcc-mgorny.
>>>
>>> I don't think we should proceed this way.  The way I'd like to proceed is to
>>> introduce a new toolchain-r1.eclass which addresses at least your QA issues
>>> below.  If I understood Ryan's plan with the eclass, it was to simply
>>> refactor the phase functions to modernize things but keep backwards compat.
>>> When toolchain-r1.eclass is mature, then we switch the inherit.  I'd like to
>>> keep gcc-2* and gcc-3* around.  We could consider cleaning up those ebuilds
>>> to work with EAPI=4 or 5 with the new eclass or just leave them with the old
>>> eclass.
> Why do you want to keep these outdated and not supported versions of gcc
> around? Have you tried building a modern system with gcc-2 or gcc-3? I
> haven't but I'm sure it would fail horribly.

But not certain embedded systems or other scenarios.  gcc-3 for instance 
did hardening differently than 4.  While I'm not as interested in gcc-2, 
I don't want to see gcc-3 dumped.  Even minor leaps like 4.7 to 4.8 
introduced deep changes like requiring c++. Its easy to say, why do we 
need this? when one forgets that evolution, or was never familiar with it.

This line of reasoning is used often: "I can't see how this is useful 
for the type of systems I envision, so this is not useful." Gentoo is 
not that spectacular as a "regular" distro.  Only masochists pick gentoo 
as a desktop given that it has no installer --- why wouldn't the average 
user pick ubuntu over gentoo if they want something that "just works."  
But for niche systems, Gentoo shines like nothing else.  ChromeOS would 
never have been born of a debian-ish or fedora-ish distro.  Let's keep 
this alive.

>
>>> Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
>>> excellent hard work you've done on eclasses, but the reason this is
>>> happening is because of patches that toolchain lead is not accepting.
>>> Anyhow, most of the work with gcc (in my opinion) is with the patches
>>> against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When you
>>> don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree?
>> Well, that would be in keeping with GLEP 39, which seems to encourage
>> everybody to fork each other's packages.  :)
>>
>> It seems like there is a fundamental disagreement here over the right
>> way to refactor all this code.  Honestly, the fact that nobody seems
>> to even want to look at the toolchain suggests to me that
>> simplification is probably worthwhile.

This statement is not true.  The maintainer is actively making commits 
to toolchain.eclass and gcc.  The problem stems from the maintainer 
ignoring patches to the eclass regarding certain fixes, eg the thorny 
dependencies on gcj[awt] which draws in windowing system stuff.  A 
compiler depending on media-libs/alsa-lib!  Yuck!

These are QA issues.  I do agree with Michal that they should be 
addressed.  I am willing to support QA against the maintainer as I said 
in a previous email, after a review of proposed changes.  But these 
problems are not the occasion to throw out the current approach to 
toolchain.

>   
>   I tend to agree here too; let's get rid of the old versions of things
>   where we can and simplify.

This move will not simply things.  It will just re-encode the 
complexities in a new way.  Or it will throw out stuff we later realize 
we want.  Take a look at bug #513716, #513578, #513576 and others and 
tell me how any of the above suggestions to remove the eclass will make 
that ugliness simple?

If people really want this, then I'd rather see a fork in the tree for 
those "forward looking devs" and leave the current toolchian stuff in 
tact for us old "fuddy duddies" like me.

>
> William
>


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

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Anthony G. Basile]

On 12/08/14 07:32, Rich Freeman wrote:
> On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile <blueness@gentoo.org> 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 of QA issues so I at least can work towards a
>>>> toolchain-r1.eclass if you're not interested in going that way.  Also, I
>>>> take the QA issues seriously, but threatening a QA intervention against
>>>> toolchain and then acting by forking is heavy handed.  QA actions
>>>> against the current codebase is understandable.
>>>>
>>>> So to sum, I'd like to see the QA issues (and others) address in the
>>>> current approache and toolchain.eclass.  Since we can make mistakes and
>>>> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
>>>> test (just change the inheritance in gcc ebuilds for testing) and
>>>> finally, when we're happy, do the switcheroo.
>>> First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
>>> understand and track. If you can remove it and make gcc into proper
>>> ebuilds that can get revision-level changes, we can discuss.
>>>
>> Hey! why don't I join QA so I can also "fix" eclasses that I find
>> "intrusive".  Let's not make QA the final refuge of those who want to push
>> through their preferences.
>>
>> To proceed forward, you have bugs open against toolchain.eclass. The
>> practice is to submit the patches to this list for review.  If after awards
>> you have community support, commit despite the maintainer's objections.
>> Having obtained community support, you will have much more legitimacy
>> against reverts.  I can't speak for the whole council, but I would support
>> you under such circumstances.  I cannot support a position where QA simply
>> asserts itself.  When/if an appeal percolates up to the council, I will side
>> with the maintainer under the argument that the commit to the eclass was not
>> sufficiently reviewed.
>>
> ++ regarding how QA should operate.
>
> I have no issues with him forking the ebuild and doing things his own
> way though.
>
> --
> Rich
>

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.  In that respect, I'm simply voicing my 
opinion as a dev.   However regarding how QA should operate, I am 
operating with the guidelines of gentoo self-governance.

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

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Rich Freeman]

On Mon, Dec 8, 2014 at 9:00 AM, Anthony G. Basile <blueness@gentoo.org> 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.  In that respect, I'm simply voicing my opinion
> as a dev.   However regarding how QA should operate, I am operating with the
> guidelines of gentoo self-governance.
>

++

Honestly, I don't think internal forks are terribly helpful either in
the long run.  Sometimes they seem to be needed at some point to at
least push things along, but obviously it would be better to focus on
one package.  I just don't want to be critical of those who want to
fork things, as they usually have very legitimate concerns and at
least by forking they're producing something new that people can play
with and test, which can help us cross the gap from where we are to
where we want to be.

A big reason there are forks is that sometimes people just get fed up
with trying to work with people and would prefer to go do something
even if it basically means re-inventing the wheel.

I was thinking about this earlier today after being somewhat
frustrated with a completely different FOSS issue.  The nature of
Gentoo tends to draw a lot of people who want to achieve their vision
of technical perfection.  This makes it really hard for all of us to
work together.  I'll admit that there are times I get sick of some of
the debates on the lists/etc, and I'm sure everybody on all sides of
every issue tends to feel the same way.  We keep coming back because
we think there is something here worth fighting for, and sometimes
even worth compromising for.

Forks can be a way to try out new things, and turning theoretical
arguments into practical comparisons.  Sure, they can also be
incredible "wastes" of time, but so is just about anything that any of
us do for fun.  I think that creating something new is far more
productive than arguing on lists, even if in the end the work gets
abandoned (though this is rarely the case - usually something gets
re-appropriated which is the whole point of FOSS).  Forks are also a
great way to get new blood into an arcane subject - making incremental
changes on a mature codebase is often a lot harder than making
incremental changes on a new codebase that likely leaves out 50% of
the corner cases.

If we don't have friendly internal competition, it will just make it
that much harder to stay relevant.  Let's just try to keep it
friendly.  :)

--
Rich

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Matt Turner]

On Sun, Dec 7, 2014 at 5:05 AM, Anthony G. Basile
<basile@opensource.dyc.edu> 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 good thing.

With all of the logic encoded in that huge eclass, any modifications
to it change the code any version of the gcc ebuild executes,
including stable versions that you're not thinking about at the time.

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.

glibc does the same thing with "eblits."

I think I remember Ciaran making the same argument in the past, but
much better said than mine.

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Rich Freeman]

On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner <mattst88@gentoo.org> 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 ebuilds that all
just set a few environment variables and then genuinely share common
code for everything else.  Also, major updates only come once every
few years, which helps keep the eclass from becoming a rat's nest.  I
think it is better to just version an eclass instead of having a mess
of conditionals based on version, but then we'd have 300 revisions of
toolchain.eclass (which is probably a good hint that we're doing it
wrong).

A library is a good analogy of how to avoid all of this.  Each
function does one thing well, and you call them as you need them, and
you don't tweak their APIs 10 times per year.  And if you find you're
never using a function more than once after doing this, then you don't
need a library in the first place.

--
Rich

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[vivo75]

Il 08/12/2014 00:17, Martin Vaeth ha scritto:
> Michał Górny <mgorny@gentoo.org> 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 seems to be that it does not insist
> on gcj but apparently should work with any java: I had
> suspected that it is the library which depends on some
> gcj internals and not just the front-end which consists
> just of a few lines, anyway.
>
> So, indeed, this looks like it should be a drop-in
> replacement, though I did not check whether the
> license of the updated library changed.
>
> Anyway, it would be nice to have it in the tree. ;)
>
>> but testing with your tricky PDFs
> I do not remember anymore. I just remember that
> several times, when some deadline approached,
> I had to resort to pdftk at my institute's Debian
> (in the lack of a gcj at home), even for simple tasks
> as merging pdftex output with some scanned PDF pages:
> neither pdfjam nor poppler did it satisfactory,
> though I do not remember the reasons.
>
A simple concatenation does not work for me:

$ alias pdftk='java -jar /srv/git/M/mcpdf-0.2.1-jar-with-dependencies.jar'
$ pdftk \
>  4265498/0010-visura_alvise.pdf 4265498/report_sister_AT00.pdf
4265499/0010-visura_alvise.pdf \
>  cat output OUT.pdf
java.lang.RuntimeException: Unknown operation:
4265498/report_sister_AT00.pdf
See README for more information.

also having it in tree would be better, and a pair of warnings:

- The project only has 20 commit, last one 8 months ago
  https://github.com/m-click/mcpdf.git
- in the readme there is this "Note that not all PDFtk operations are
implemented at the moment."

hardly a drop in I would trust to replace pdftk which only had problems
once (at compile time) because of a gcc upgrade.

but
find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +
show that really only pdftk, dev-java/ecj-gcj and dev-java/gcj-jdk
depend on gcc with gcj enabled.
maybe too few to maintain a broken gcc extension, probably also "go"
should go

regards,
Francesco Riosa

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[vivo75]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

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-free use (even if this
>     is a developers primary focus as reason for contribution), otherwise
>     we'll hit a wall quickly enough.
>
>     In this specific case I at least use pdftk for some batch jobs on
>     business-related servers and a non-commercial license would not be
>     viable. 
>
>
> pdfTK is also GPLv2, (effectively GPLv3 since iText is /A/GPLv/3/?
> Effectively AGPLv3 when in a public-facing service?) unless you're
> paying for it. I doubt m-click would refuse to consider alternative
> paid licensing if they were asked.
pdftk 2.02 use an older itext with license GPLv2+

license_gpl_pdftk/third_party/itext-paulo.txt
 *
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Library General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Library General Public License for more details.
 *
 * You should have received a copy of the GNU Library General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
 * Boston, MA  02110-1301, USA.


[-- Attachment #2: Type: text/html, Size: 2940 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Tomas Mozes]

On 2014-12-07 11:37, Michał Górny wrote:
> Hello, developers and users.
> 
> As some of you know, the toolchain packages in Gentoo suffer from
> lack-of-sanity issues and their maintainers are completely unwilling to
> improve things. I have finally decided to start working on a fork of
> the sys-devel/gcc ebuilds, and I have some bits ready for initial
> testing in 'mgorny' repo, so I would like to know your opinion.
> 
> 
> Before you start, the shortcomings are:
> 
> 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.
> 
> 2. No gcj support. Since the ebuild has been forked out of
> toolchain.eclass, and the gcj support suffers a lot of issues there, I
> decided there's no point in copying the code. Not sure if anybody
> actually uses it, and if it is actually useful for anything but will
> probably get reintroduced one day [above 'if' applies too].
> 
> 3. No bootstrapping, fallbacks and possible some other random feature
> support. The goal was pretty much to get gcc compiling first, and avoid
> awful lot of effort if things prove to have no future.
> 
> 4. Hardened is not tested. I think I have copied all the needed code
> and fixed some stuff but I have no clue if it still works ;).
> 
> 
> Now, the major changes are:
> 
> 1. Most of the insanity removed. No more toolchain.eclass. The ebuild
> has just the code for the current gcc version. You can read it and know
> what it does, you don't have to parse a few dozen version conditionals,
> runtime conditionals and random crap code that doesn't do anything in
> some gcc versions. In fact, I think I removed most of the no-op code.
> And now you can actually change something in the ebuild without caring
> for gcc3.4, or without breaking stuff for stable ebuilds.
> 
> 2. USE flags are supposed to work. I've replaced the cases when they
> were silently ignored with REQUIRED_USE. I've also removed the silent
> removals when they didn't work -- so if your current toolchain is
> broken, things may actually fail instead of giving your different gcc
> than you wanted. Probably deserves explanatory pkg_pretend() at some
> point, with messages like 'disable USE=-foo because your toolchain is
> broken'.
> 
> 3. Things simplified where they could have been simplified. For
> example, I removed the big gcc executable moving function and replaced
> it with --enable-version-specific-runtime-libs. It was enabled in
> toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
> up the behaviour this eclass relies on.' So yep, precious cargo cult --
> why enable something that would require you to remove your useless
> complex function?!
> 
> 4. Added gx86-multilib love. Now you have abi_* flags to control
> the compiler runtime. Of course, since gcc is a pile of random modules
> not fit for one another it has different code for different targets. In
> particular, on mips you can't do two ABIs -- either single one
> (non-multilib) or all three of them (--enable-multilib).
> 
> 5. Added multilib gcc wrappers. Long story short, multilib gcc now
> shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
> doesn't screw up your system! Of course, the final implementation may
> differ since it's an early idea but it works. Now distcc happily builds
> stuff for your x86 clients.
> 
> 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
> rather than silently skipping doc build when it's not installed...
> 
> 7. Disabled bootstrap by default (and in fact completely for now). It
> is not *that* useful, and means time savings (and distcc support):
> 
>      Thu Nov  6 20:39:31 2014 >>> sys-devel/gcc-4.9.2
>        merge time: 1 hour, 56 minutes and 43 seconds.
> 
>      Sun Dec  7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100
>        merge time: 34 minutes and 55 seconds.
> 
> 
> If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
> appreciate any bug reports, except for those covering things i've
> already listed as missing :). Any further comments will be very helpful
> in deciding on the way forward.
> 
> If there is a real interest in my fork, I will probably move it to gx86
> as sys-devel/gcc-mgorny. 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.

Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), 
tested to build some core stuff with it:
kernel 3.17, glibc, coreutils, openssl, ssh...

All seems to work fine. I'll try to recompile the whole machine with it.

After emerge, there are these notices:
  * QA Notice: command not found:
  *
  *      /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3110: pax-mark: command not found
  *      /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
3111: pax-mark: command not found

# emerge -pvq gcc
[ebuild   R   ] sys-devel/gcc-4.9.2-r100  USE="cxx fortran nls nptl 
openmp pie sanitize (-altivec) -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -objc -objc++ -objc-gc {-test} -vanilla" 
ABI_X86="(64) -32 (-x32)"

Portage 2.2.14 (python 2.7.8-final-0, default/linux/amd64/13.0/desktop, 
gcc-4.9.2, glibc-2.20, 3.17.5-gentoo x86_64)
=================================================================
System uname: 
Linux-3.17.5-gentoo-x86_64-Intel-R-_Core-TM-_i5-3570_CPU_@_3.40GHz-with-gentoo-2.2
KiB Mem:    15908668 total,  12616592 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Tue, 09 Dec 2014 02:45:01 +0000
ld GNU ld (Gentoo 2.24 p1.4) 2.24
app-shells/bash:          4.3_p30-r1
dev-java/java-config:     2.2.0
dev-lang/perl:            5.20.1-r3
dev-lang/python:          2.7.8, 3.2.5-r4, 3.3.5-r1, 3.4.2
dev-util/cmake:           3.0.2
dev-util/pkgconfig:       0.28-r2
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.13.6
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.14.1
sys-devel/binutils:       2.24-r3
sys-devel/gcc:            4.8.3, 4.9.2-r100::mgorny
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.3-r2
sys-devel/make:           4.1-r1
sys-kernel/linux-headers: 3.17-r1 (virtual/os-headers)
sys-libs/glibc:           2.20
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-mtune=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d 
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release 
/etc/php/apache2-php5.5/ext-active/ /etc/php/apache2-php5.6/ext-active/ 
/etc/php/cgi-php5.5/ext-active/ /etc/php/cgi-php5.6/ext-active/ 
/etc/php/cli-php5.5/ext-active/ /etc/php/cli-php5.6/ext-active/ 
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-mtune=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified 
distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch 
preserve-libs protect-owned sandbox sfperms strict unknown-features-warn 
unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync 
xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://tux.rainside.sk/gentoo/"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
USE="X a52 aac acl acpi alsa amd64 berkdb bindist branding bzip2 cairo 
cdda cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr 
emboss encode exif fam firefox flac fortran gdbm gif glamor gpm gtk 
iconv jpeg lcms ldap libnotify mad mmx mng modules mp3 mp4 mpeg multilib 
ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds 
qt3support qt4 readline sdl session sse sse2 ssl startup-notification 
svg tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets 
x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 
als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 
es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident 
usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core 
authz_core authz_host dir mime unixd socache_shmcb log_config rewrite 
vhost_alias log_forensic proxy proxy_fcgi info status deflate filter 
auth_digest authn_file authz_user access_compat actions alias auth_basic 
authn_alias authn_anon env expires headers mime_magic negotiation 
reqtimeout setenvif unique_id version cgi" CALLIGRA_FEATURES="kexi words 
flow plan sheets stage tables krita karbon braindump author" 
CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool 
swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate 
evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom 
oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing 
tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" 
INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz 
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" 
LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" 
LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 
php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 
python3_3" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 
i386" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel 
i128" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset 
ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark 
ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, 
LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, 
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5490 bytes --]

Dnia 2014-12-09, o godz. 14:23:21
Tomas Mozes <tomas.mozes@shmu.sk> napisał(a):

> On 2014-12-07 11:37, Michał Górny wrote:
> > Hello, developers and users.
> > 
> > As some of you know, the toolchain packages in Gentoo suffer from
> > lack-of-sanity issues and their maintainers are completely unwilling to
> > improve things. I have finally decided to start working on a fork of
> > the sys-devel/gcc ebuilds, and I have some bits ready for initial
> > testing in 'mgorny' repo, so I would like to know your opinion.
> > 
> > 
> > Before you start, the shortcomings are:
> > 
> > 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.
> > 
> > 2. No gcj support. Since the ebuild has been forked out of
> > toolchain.eclass, and the gcj support suffers a lot of issues there, I
> > decided there's no point in copying the code. Not sure if anybody
> > actually uses it, and if it is actually useful for anything but will
> > probably get reintroduced one day [above 'if' applies too].
> > 
> > 3. No bootstrapping, fallbacks and possible some other random feature
> > support. The goal was pretty much to get gcc compiling first, and avoid
> > awful lot of effort if things prove to have no future.
> > 
> > 4. Hardened is not tested. I think I have copied all the needed code
> > and fixed some stuff but I have no clue if it still works ;).
> > 
> > 
> > Now, the major changes are:
> > 
> > 1. Most of the insanity removed. No more toolchain.eclass. The ebuild
> > has just the code for the current gcc version. You can read it and know
> > what it does, you don't have to parse a few dozen version conditionals,
> > runtime conditionals and random crap code that doesn't do anything in
> > some gcc versions. In fact, I think I removed most of the no-op code.
> > And now you can actually change something in the ebuild without caring
> > for gcc3.4, or without breaking stuff for stable ebuilds.
> > 
> > 2. USE flags are supposed to work. I've replaced the cases when they
> > were silently ignored with REQUIRED_USE. I've also removed the silent
> > removals when they didn't work -- so if your current toolchain is
> > broken, things may actually fail instead of giving your different gcc
> > than you wanted. Probably deserves explanatory pkg_pretend() at some
> > point, with messages like 'disable USE=-foo because your toolchain is
> > broken'.
> > 
> > 3. Things simplified where they could have been simplified. For
> > example, I removed the big gcc executable moving function and replaced
> > it with --enable-version-specific-runtime-libs. It was enabled in
> > toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
> > up the behaviour this eclass relies on.' So yep, precious cargo cult --
> > why enable something that would require you to remove your useless
> > complex function?!
> > 
> > 4. Added gx86-multilib love. Now you have abi_* flags to control
> > the compiler runtime. Of course, since gcc is a pile of random modules
> > not fit for one another it has different code for different targets. In
> > particular, on mips you can't do two ABIs -- either single one
> > (non-multilib) or all three of them (--enable-multilib).
> > 
> > 5. Added multilib gcc wrappers. Long story short, multilib gcc now
> > shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
> > doesn't screw up your system! Of course, the final implementation may
> > differ since it's an early idea but it works. Now distcc happily builds
> > stuff for your x86 clients.
> > 
> > 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
> > rather than silently skipping doc build when it's not installed...
> > 
> > 7. Disabled bootstrap by default (and in fact completely for now). It
> > is not *that* useful, and means time savings (and distcc support):
> > 
> >      Thu Nov  6 20:39:31 2014 >>> sys-devel/gcc-4.9.2
> >        merge time: 1 hour, 56 minutes and 43 seconds.
> > 
> >      Sun Dec  7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100
> >        merge time: 34 minutes and 55 seconds.
> > 
> > 
> > If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
> > appreciate any bug reports, except for those covering things i've
> > already listed as missing :). Any further comments will be very helpful
> > in deciding on the way forward.
> > 
> > If there is a real interest in my fork, I will probably move it to gx86
> > as sys-devel/gcc-mgorny. 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.
> 
> Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), 
> tested to build some core stuff with it:
> kernel 3.17, glibc, coreutils, openssl, ssh...
> 
> All seems to work fine. I'll try to recompile the whole machine with it.
> 
> After emerge, there are these notices:
>   * QA Notice: command not found:
>   *
>   *      /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
> 3110: pax-mark: command not found
>   *      /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 
> 3111: pax-mark: command not found

Thanks for the report. I've just fixed the missing inherit.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[Martin Vaeth]

vivo75@gmail.com <vivo75@gmail.com> wrote:
>
> - The project only has 20 commit, last one 8 months ago
>   https://github.com/m-click/mcpdf.git

The "project" is just a few lines anyway: merely a wrapper to the library.
All the work happens in the itext library which AFAIK is the same project
(in different versions) for pdftk as for mcpdf.
Of course, the new library version might contain new bugs,
as your example seems to suggest (did pdftk work with this example?)

> find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +

Searching also through all layman (remote) overlays with

$ eix -#Rry 'sys-devel/gcc[^ ]*gcj'

I found besides the mentioned

app-text/pdftk
dev-java/ecj-gcj
dev-java/gcj-jdk

one further dependency:

$ eix -Rvle imule
  net-p2p/imule [1]
  [...]  irouter? ( sys-devel/gcc[gcj] ) [...]
  P2P sharing software which connects through I2P and Kad network [...]
[1] "zugaina" layman/zugaina

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]

Dnia 2014-12-08, o godz. 07:27:51
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> 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 interested in going that way.  Also, I
> >> take the QA issues seriously, but threatening a QA intervention against
> >> toolchain and then acting by forking is heavy handed.  QA actions
> >> against the current codebase is understandable.
> >>
> >> So to sum, I'd like to see the QA issues (and others) address in the
> >> current approache and toolchain.eclass.  Since we can make mistakes and
> >> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
> >> test (just change the inheritance in gcc ebuilds for testing) and
> >> finally, when we're happy, do the switcheroo.
> > First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
> > understand and track. If you can remove it and make gcc into proper
> > ebuilds that can get revision-level changes, we can discuss.
> >
> 
> Hey! why don't I join QA so I can also "fix" eclasses that I find 
> "intrusive".  Let's not make QA the final refuge of those who want to 
> push through their preferences.

Yes, that's exactly what occurred to me! Then I joined QA.

But seriously saying, I didn't mean forcing anything on anyone myself.
I meant starting proper QA process which could eventually hopefully
result in QA prohibiting the use of current eclass in future ebuilds,
and or referring to the Council about switching the default gcc
provider. Of course, that's only the worst scenario.

> To proceed forward, you have bugs open against toolchain.eclass. The 
> practice is to submit the patches to this list for review.  If after 
> awards you have community support, commit despite the maintainer's 
> objections.  Having obtained community support, you will have much more 
> legitimacy against reverts.  I can't speak for the whole council, but I 
> would support you under such circumstances.  I cannot support a position 
> where QA simply asserts itself.  When/if an appeal percolates up to the 
> council, I will side with the maintainer under the argument that the 
> commit to the eclass was not sufficiently reviewed.

As I already said, the main issue simply can't be fixed this way. It's
not that much *bugs in code in toolchain.eclass* but *what's in
toolchain.eclass*. If we think of eclasses as libraries, then your
library provides main() function. With conditionals for 14 consecutive
releases of your program. And you already told people to link random
stuff to it, and rely on every internal API detail.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

Dnia 2014-12-08, o godz. 09:56:11
Alexis Ballier <aballier@gentoo.org> napisał(a):

> On Sun, 7 Dec 2014 11:37:57 +0100
> Michał Górny <mgorny@gentoo.org> 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 this broke, what is wrong in glibc, what would be a "sane
> crossdev alternative" and how crossdev is not.

1. eblits are broken in glibc. Another case of incorrect interpretation
of code sharing with love for breaking stable ebuilds. Plus I'd love to
add multilib flags to it but we'll likely doing that to main glibc as
well soon, if eblits don't get into our way.

2. crossdev is broken because it creates semi-random, unmaintained
ebuilds in randomly chosen overlay, those ebuilds relying on
toolchain.eclass behavior.

3. I don't have any real alternative design yet. However, one 
of the first ideas of changing crossdev is to replace copying ebuilds
with symlinking gcc ebuild directory. This will at least ensure proper
sync between real ebuilds and cross-ebuilds.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Alexander Tsoy]

В Tue, 9 Dec 2014 17:21:22 +0100
Michał Górny <mgorny@gentoo.org> пишет:

> Dnia 2014-12-08, o godz. 09:56:11
> Alexis Ballier <aballier@gentoo.org> napisał(a):
> 
> > On Sun, 7 Dec 2014 11:37:57 +0100
> > Michał Górny <mgorny@gentoo.org> 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 this broke, what is wrong in glibc, what would be a "sane
> > crossdev alternative" and how crossdev is not.
> 
> 1. eblits are broken in glibc. Another case of incorrect interpretation
> of code sharing with love for breaking stable ebuilds. Plus I'd love to
> add multilib flags to it but we'll likely doing that to main glibc as
> well soon, if eblits don't get into our way.

Yeah. Stable glibc ebuild gets broken from time to time after changes
in eblits.

> 
> 2. crossdev is broken because it creates semi-random, unmaintained
> ebuilds in randomly chosen overlay, those ebuilds relying on
> toolchain.eclass behavior.
> 
> 3. I don't have any real alternative design yet. However, one 
> of the first ideas of changing crossdev is to replace copying ebuilds
> with symlinking gcc ebuild directory. This will at least ensure proper
> sync between real ebuilds and cross-ebuilds.
> 

crossdev already works that way for a long time (see -oO option in
help):

$ ls -l /var/cache/portage/repos/crossdev/cross-armv6j-hardfloat-linux-gnueabi/
total 0
lrwxrwxrwx 1 portage portage 42 Oct 23 22:24 binutils -> /var/cache/portage/tree/sys-devel/binutils
lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gcc -> /var/cache/portage/tree/sys-devel/gcc
lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gdb -> /var/cache/portage/tree/sys-devel/gdb
lrwxrwxrwx 1 portage portage 38 Oct 23 22:24 glibc -> /var/cache/portage/tree/sys-libs/glibc
lrwxrwxrwx 1 portage portage 48 Oct 23 22:24 linux-headers -> /var/cache/portage/tree/sys-kernel/linux-headers

-- 
Alexander Tsoy

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Alexis Ballier]

On Tue, 9 Dec 2014 17:21:22 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2014-12-08, o godz. 09:56:11
> Alexis Ballier <aballier@gentoo.org> napisał(a):
> 
> > On Sun, 7 Dec 2014 11:37:57 +0100
> > Michał Górny <mgorny@gentoo.org> 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 this broke, what is wrong in glibc, what would be a
> > "sane crossdev alternative" and how crossdev is not.
> 
> 1. eblits are broken in glibc. Another case of incorrect
> interpretation of code sharing with love for breaking stable ebuilds.

its a local toolchain.eclass yes

> Plus I'd love to add multilib flags to it but we'll likely doing that
> to main glibc as well soon, if eblits don't get into our way.

keep in mind that, thanks to implicit system deps, you'll have to
use.force what your toolchain is supposed to be able to produce.

also, you'll probably face much more problems with bootstrapping
than the cosmetics of eblits: get a gcc that can compile .o for your
abi is easy, but you do not have the libc yet so can't link anything
unless you use nodefaultlibs alike switches

> 2. crossdev is broken because it creates semi-random, unmaintained
> ebuilds in randomly chosen overlay, those ebuilds relying on
> toolchain.eclass behavior.

it symlinks the dirs these days, so its not unmaintained

toolchain.eclass behavior you're referring to is probably the category
parsing to get CTARGET; this is very likely used in all other libc
ebuilds so you'll have to fix them too; not mentioning the ability to
update your cross toolchains with 'emerge world' that you cant do if
you dont feed CTARGET in some way.


> 3. I don't have any real alternative design yet. However, one 
> of the first ideas of changing crossdev is to replace copying ebuilds
> with symlinking gcc ebuild directory. This will at least ensure proper
> sync between real ebuilds and cross-ebuilds.


as said above, this is the case here

Alexis.

Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing

[vivo75]

Il 09/12/2014 15:26, Martin Vaeth ha scritto:
> vivo75@gmail.com <vivo75@gmail.com> wrote:
>> - The project only has 20 commit, last one 8 months ago
>>   https://github.com/m-click/mcpdf.git
> The "project" is just a few lines anyway: merely a wrapper to the library.
> All the work happens in the itext library which AFAIK is the same project
> (in different versions) for pdftk as for mcpdf.
> Of course, the new library version might contain new bugs,
> as your example seems to suggest (did pdftk work with this example?)
my example work daily in a box with very few updated and some builds at
least 2 years old, and it's the simplest one.
yet it's working well from a lot of time.

pdftk is NOT only a wrapper to itext (a 9 years old version [2]) it also
include a java library for crypto and it's own management  in c++ files.
now,  without counting the java crypto lib the c++ files weight around
8k LOC [3]

itext may have been evolved, but calling a 90 LOC java program a "drop
in" replacement for pdftk seem adventurous ...
for comparison  `pdftk --help` output is 556 lines of text.

so we can conclude that the "project" is NOT what it claims to be and a
replacement (even using modern itext with licensing problems) will
weight at least at least 556 lines?


>
>> find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +
> Searching also through all layman (remote) overlays with
>
> $ eix -#Rry 'sys-devel/gcc[^ ]*gcj'
>
> I found besides the mentioned
>
> app-text/pdftk
> dev-java/ecj-gcj
> dev-java/gcj-jdk
>
> one further dependency:
>
> $ eix -Rvle imule
>   net-p2p/imule [1]
>   [...]  irouter? ( sys-devel/gcc[gcj] ) [...]
>   P2P sharing software which connects through I2P and Kad network [...]
> [1] "zugaina" layman/zugaina
[2]
http://sourceforge.net/projects/itextpdf/files/itext-paulo/itext-paulo-155/
[3] $ LC_ALL=C wc -l  *cc
   542 attachments.cc
   498 passwords.cc
  4482 pdftk.cc
  2433 report.cc
   137 win32_utf8_include.cc
  8092 total

Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Joshua Kinard]

On 12/09/2014 11:21, Michał Górny wrote:
> Dnia 2014-12-08, o godz. 09:56:11
> Alexis Ballier <aballier@gentoo.org> napisał(a):
> 
>> On Sun, 7 Dec 2014 11:37:57 +0100
>> Michał Górny <mgorny@gentoo.org> 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 this broke, what is wrong in glibc, what would be a "sane
>> crossdev alternative" and how crossdev is not.
> 
> 1. eblits are broken in glibc. Another case of incorrect interpretation
> of code sharing with love for breaking stable ebuilds. Plus I'd love to
> add multilib flags to it but we'll likely doing that to main glibc as
> well soon, if eblits don't get into our way.

Originally, eblits were supposed to be ways of sharing common blocks of code
between ebuilds in a specific package, but not anything that would warrant a
new eclass (local package eclasses, kinda?).  They never really took off for
reasons lost to time.  I use them in mips-sources, but version them so that if
I change an eblit, it gets a new version and the old version is removed only
when there are no more consumers.

The idea of eblits itself isn't bad, but probably could use some re-thinking
and/or re-implementation.  Especially if a decent amount of kilobytes can be
shaved off a given package's directory.


> 2. crossdev is broken because it creates semi-random, unmaintained
> ebuilds in randomly chosen overlay, those ebuilds relying on
> toolchain.eclass behavior.

I would argue this isn't necessarily "broken".  crossdev produces working
cross-toolchains and is a valuable tool for anyone running multiple arches,
especially slower arches.  How it produces said working cross-toolchains is an
implementation detail.  Don't be so hasty as to throw the baby out with the
bathwater.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic