Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-20 Thread Guilherme Amadio
On Sat, Jun 20, 2020 at 12:58:20AM -0400, Aaron Bauman wrote:
> > # Aaron Bauman  (2020-06-20)
> > # Py2 only
> > # Removal in 14 days
> > dev-util/uftrace

This is a function tracer written in C. I don't know why it's on this
list. If a package has only optional support for python like this,
just drop python support rather than the whole package, please. In this
case it's just a matter of adding --without-libpython to the call to econf.

In any case, the release notes for the latest version says that it now does
support python3, even though the configuration for python3 seems a bit broken
after I've had a look at it. I will take it and fix nevertheless.


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Guilherme Amadio

On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote:
> On 5/27/20 2:16 PM, Thomas Deutschmann wrote:
> > The problem when doing review on Github
> > for me is, that we usually create new revisions. Therefore we don't see
> > what's changed in new revision versus previous revision. 
> That's my main concern with the current behaviour: a "git diff" often doesn't 
> show a diff against the previous (ebuild) file, it shows a diff against 
> /dev/null :-/

Indeed, on GitHub it is hard to review, but locally you can add

algorithm = patience

to your .gitconfig, and that should help with the diffs even when
the revision changes by moving the file. When copying, it probably
won't help.

We could also try as a policy to split the revision bump from the
changes, i.e. bump the revision in the first commit, then apply the
changes in a second one. That way, one can click on the right commit
to see the differences only, even on GitHub. Then we can squash when
merging locally, since we don't click merge on GitHub anyway.


Re: [gentoo-dev] [PATCH] dev-python/metadata.xml: Clarify description

2020-03-09 Thread Guilherme Amadio
Hi Michał,

longdescription lang="pt"

A categoria dev-python contém pacotes cujo propósito principal é
fornecer módulos, extensões e bindings para Python, bem como ferramentas
e outros utilitários para desenvolvimento de software em Python.


On Sun, Mar 08, 2020 at 10:24:17AM +0100, Francesco Riosa wrote:
> longdescription lang="it"
> La categoria dev-python contiene pacchetti il cui scopo principale
> è fornire moduli, estensioni e bindings per Python,
> nonché strumenti e utilità per lo sviluppo nel linguaggio
> di programmazione Python.
> Il giorno dom 8 mar 2020 alle ore 09:52 Michał Górny  ha
> scritto:
> > Rewrite the description for dev-python category in order to clarify
> > its purpose.  It has been pointed out that the previous description may
> > have suggested that it is the category for *all* things written
> > in Python.
> >
> > Signed-off-by: Michał Górny 
> > ---
> >  dev-python/metadata.xml | 44 +++--
> >  1 file changed, 12 insertions(+), 32 deletions(-)
> >
> > // If you can supply translations for the remaining languages, please
> > // send them my way and I'll update the patch.
> >
> > diff --git a/dev-python/metadata.xml b/dev-python/metadata.xml
> > index ed6a813dd009..b90b8f66f45a 100644
> > --- a/dev-python/metadata.xml
> > +++ b/dev-python/metadata.xml
> > @@ -2,41 +2,21 @@
> >;>
> >  
> > 
> > -   The dev-python category contains libraries, utilities or
> > -   bindings written in or for the Python programming
> > language.
> > +   The dev-python category contains packages whose primary
> > purpose
> > +   is to provide Python modules, extensions and bindings, as
> > well
> > +   as tools and utilities useful for development in the Python
> > +   programming language.
> > 
> > 
> > -   Die Kategorie dev-python enthält Bibliotheken und
> > Werkzeuge für die
> > -   Programmiersprache Python.
> > -   
> > -   
> > -   La categoría dev-python contiene librerias y utilidades
> > referentes al
> > -   lenguaje de programación Python.
> > -   
> > -   
> > -   dev-pythonカテゴリーにはPythonプログラミング言語で記述された/のために
> > -   記述されたライブラリーと>ユーティリティとバインディングが含まれます。
> > -   
> > -   
> > -   De dev-python categorie bevat bibliotheken en hulpmiddelen
> > voor het
> > -   gebruik van de programmeertaal Python.
> > -   
> > -   
> > -   Nhóm dev-python chứa các thư viện và tiện ích liên quan
> > -   đến ngôn ngữ lập trình Python.
> > -   
> > -   
> > -   La categoria dev-python contiene librerie ed utilità per
> > il linguaggio
> > -   di programmazione Python.
> > -   
> > -   
> > -   A categoria dev-python contém bibliotecas, utilitários e
> > -   bindings escritos em ou para a linguagem de programação
> > Python.
> > +   Die Kategorie dev-python enthält Pakete, die hauptsächlich
> > +   Module, Erweiterungen und Sprachbindungen für Python zur
> > +   Verfügung stellen, sowie Werkzeuge und Dienstprogramme für
> > die
> > +   Entwicklung in der Programmiersprache Python
> > 
> > 
> > -   Kategoria dev-python zawiera biblioteki, narzędzia i
> > powiązania
> > -   (bindings) napisane w lub stworzone do pisania w języku
> > programowania
> > -   Python.
> > +   Kategoria dev-python zawiera paczki dostarczające przede
> > +   wszystkim moduły, rozszerzenia i powiązania (bindings)
> > Pythona,
> > +   jak również przydatne narzędzia dla wiary programującej
> > +   w Pythonie.
> > 
> >  
> > -
> > --
> > 2.25.1
> >
> >
> >

Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

2019-09-25 Thread Guilherme Amadio
Hi Michał,

On Tue, Sep 10, 2019 at 10:44:54PM +0200, Michał Górny wrote:
> Hi, everyone.
> I've recently (finally!) started adding tests to cpuid2cpuflags.  Tests
> are based on mocked syscalls that return arch-specific data read from
> text files.  So far I've got x86 and ppc covered, and now I'd like to
> add tests for various arm hardware.  Since ARM covers a pretty broad
> range of hardware, I'd use as much data as possible, especially from
> different ARM generations.
> If you have an ARM board and would like to help, please:
> wget
> tar -xf cpuid2cpuflags-7-dev.tar.bz2
> cd cpuid2cpuflags-7-dev
> ./configure
> make hwcap-dump
> ./hwcap-dump
> and send me the output along with 'uname -m'.  TIA!

Sorry for the late reply, I was on vacations in the last couple of
weeks. Here is some data on hardware not yet submitted:

## Raspberry Pi Zero W:
More info at:

$ uname -m

$ ./hwcap-dump

$ lscpu
Byte Order:  Little Endian
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
Vendor ID:   ARM
Model:   7
Model name:  ARM1176
CPU max MHz: 1000.
CPU min MHz: 700.
Flags:   half thumb fastmult vfp edsp java tls

processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS: 997.08
Features: half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xb76
CPU revision: 7

Hardware: BCM2835
Revision: 9000c1
Serial  : 81342439

## Raspberry Pi 4 Model B:
More info at:

$ uname -m

$ ./hwcap-dump

$ lscpu
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   3
Model name:  Cortex-A72
CPU max MHz: 1500.
CPU min MHz: 600.
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm crc32

processor   : 0-3
model name  : ARMv7 Processor rev 3 (v7l)
BogoMIPS: 270.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd08
CPU revision: 3

Hardware: BCM2835
Revision: c03111
Serial  : 299a8a34

## HP Moonshot XGene 1:
More info at:

$ uname -m

$ ./hwcap-dump

$ lscpu
Architecture:  aarch64
Byte Order:Little Endian
On-line CPU(s) list:   0-7
Thread(s) per core:1
Core(s) per socket:8
Socket(s): 1
NUMA node(s):  1
Model: 1
BogoMIPS:  100.00
NUMA node0 CPU(s): 0-7
Flags: fp asimd evtstrm

processor   : 0-7
BogoMIPS: 100.00
Features: fp asimd evtstrm
CPU implementer : 0x50
CPU architecture: 8
CPU variant : 0x0
CPU part: 0x000
CPU revision: 1

## Cavium ThunderX:
More info at:

$ uname -m

$ ./hwcap-dump

$ lscpu
Architecture:  aarch64
Byte Order:Little Endian
On-line CPU(s) list:   0-95
Thread(s) per core:1
Core(s) per socket:48
Socket(s): 2
NUMA node(s):  2
Model: 0
BogoMIPS:  200.00
L1d cache: 32K
L1i cache: 78K
L2 cache:  16384K
NUMA node0 CPU(s): 0-47
NUMA node1 CPU(s): 48-95
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics

processor   : 0-95
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part: 0x0a1
CPU revision: 0

## Cavium ThunderX2:
More info at:

$ uname -m

$ ./hwcap-dump

$ lscpu
Architecture:  aarch64
Byte Order:Little Endian
On-line CPU(s) list:   0-255
Thread(s) per core:4
Core(s) per socket:32

Re: [gentoo-dev] util-linux build time increase?

2019-02-21 Thread Guilherme Amadio
On Thu, Feb 21, 2019 at 04:36:24AM -0500, Joshua Kinard wrote:
> Does anyone have an idea why util-linux's build time would go up
> significantly from 2.32.x to 2.33.x?  It may be a MIPS thing, as my x86_64
> box shows no discernible change in build times between the same versions.
> Can any other archs check w/ genlop to see if they see a large jump in build
> time?
> 'genlop -t util-linux' output on my SGI system (some entries removed for
> brevity):
>  Thu Feb  1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1
>merge time: 27 minutes and 48 seconds.
>  Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32
>merge time: 28 minutes and 44 seconds.
>  Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1
>merge time: 32 minutes and 58 seconds.
>  Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33
>merge time: 1 hour, 19 minutes and 49 seconds.
>  Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1
>merge time: 1 hour, 23 minutes and 37 seconds.
>  Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1
>merge time: 1 hour, 25 minutes and 15 seconds.

Indeed. Here's what I see in one of my machines at work (Core i7-7820X):

 Fri Jul 20 16:31:38 2018 >>> sys-apps/util-linux-2.32.1
   merge time: 1 minute and 40 seconds.

 Fri Aug  3 14:38:40 2018 >>> sys-apps/util-linux-2.32.1
   merge time: 1 minute and 40 seconds.

 Wed Nov 14 16:49:40 2018 >>> sys-apps/util-linux-2.33
   merge time: 4 minutes and 24 seconds.

 Tue Feb  5 14:21:40 2019 >>> sys-apps/util-linux-2.33.1
   merge time: 4 minutes and 24 seconds.

Not sure what causes it.


Re: [gentoo-dev] [RFC] C++ standard in ebuilds

2018-09-18 Thread Guilherme Amadio
On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote:
> I don't understand what a potential solution would be.
> The various projects use -std=c++XXX because that's what their code
> requires. -std=c++XXX can't generally be changed. If a dependent
> project is incompatible that's no different than any other case of
> incompatible dependencies in Gentoo.
> I think -std=c++XXX discussions before happened because gcc changed
> the C++ ABI with -std=c++11. I don't think that's particularly
> relevant here, since as far as I know different -std=c++XXX values
> don't change the ABI with current gcc.
> So I guess my understanding is that there isn't a problem different
> than existing incompatible dependencies, but maybe I have
> misunderstood you.

My concern is with, say, package foo that depends on both bar and baz,
and bar and baz support from C++11 to C++17, but must be compiled with
the same version of the standard so that foo can link against both of
them without having a broken ABI. I think that depending on bar[c++14],
or having a similar mechanism to Python to handle "same version of the
standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be


Re: [gentoo-dev] [RFC] C++ standard in ebuilds

2018-09-18 Thread Guilherme Amadio
On Tue, Sep 18, 2018 at 08:46:46AM -0400, Richard Yao wrote:
> > On Sep 17, 2018, at 12:40 PM, Vadim A. Misbakh-Soloviov  
> > wrote:
> > 
> > I'd prefer to wait another replies on the list for the main theme of this e-
> > mail, but this problem also affects C (so, as **c**flags and C standards), 
> > so 
> > solution shoudn't be c++ specific, imho.
> You would think that, but the C standard version does not effect ABI 
> compatibility. We had a very long discussion about this in OpenZFS because 
> the other platforms were using C99 while we had backported everything to C89 
> on Linux because of the Linux kernel. No one could find a single example of 
> ABI breakage caused by mixing and matching C89 and C99 (C99 LKM and C89 
> kernel). After a few years of not a single example being raised, the Linux 
> team lead opted to adopt C99.
> Now, there are flags affecting the ABI, but those are separate from the C 
> standard version. As for C++, mixing standard versions does go badly because 
> new language features require ABI changes.
> > 

Yes, since mixing standard versions is not so good, and many ebuilds
hard-code it with append-cxxflags, I think it's worth discussing a
better solution that will avoid unnecessary breakage. The big problem
is going from C++14 to C++17 as mentioned before. The 'noexcept' became
part of the mangled name. C++17 also removes features, so there will be
code that will need to be changed to compile as well. If we have a
system-wide setting, we can start warning upstreams about it at least
when things break.


[gentoo-dev] [RFC] C++ standard in ebuilds

2018-09-17 Thread Guilherme Amadio
Hi everyone,

I would like to discuss a system-wide way to handle C++ standard setting
in Gentoo. We currently have many packages appending -std=c++XX to their
flags, and it's hard to keep track of which packages use which version
of the standard. This is a problem when packages force dependencies to
use the same version of the standard, or if certain combinations cause
ABI or other breakage (i.e., due to backports conflicting with standard
classes). We currently have the page below with some documentation, but
I have not found much else on the topic:

One problem is that depending on the compiler version, the right option
may change (e.g. -std=c++1y vs -std=c++14 and -std=c++1z vs -std=c++17).
This isn't a big problem when using recent compilers, but may be it will
if you want to test some package you develop with an older compiler you
still need to support (out of Gentoo), or if you use ICC, which lags a
bit behind in standards support. For CMake projects, we could set
CMAKE_CXX_STANDARD in cmake-utils.eclass. For other projects we could
use other means. In any case, it might make sense to have global USE
flags like c++11 (already a local USE flag), c++14, etc, along with a
small eclass that C++ projects can inherit to get the right setting
instead of using append-cxxflags with a hard-coded standard version.
Hard-coding the standard flag may create problems because we will have a
mix of the default and the hard-coded ones. The USE flags would also
allow depending on a package with the same standard configuration or
setting the standard globally to something different than the compiler
default (i.e. either stay with C++11 because that's what you need to
work with, or use C++17 since you are on ~arch and your system compiler
supports it, etc).

What are your thoughts on the matter? This has been discussed in the
past¹, but it doesn't seem we have a global solution yet. I think
another discussion happened more recently, but I didn't find the thread.



[gentoo-dev] [RFC] Make 'cuda' a global USE flag

2018-09-17 Thread Guilherme Amadio
Hi everyone,

We have several packages (~35) with local USE=cuda. Should we make that
a global USE flag? It's a quite generic flag for GPU support, so I was
surprised to learn it was still local when I added support for it to a
package recently.

Another thing we might want to discuss is a global setting for the CUDA
architecture to be used¹. We compile from source, so it would be a shame
not to compile with the right features for newer GPUs². Maybe just
advertising the NVCCFLAGS one should put in make.conf is enough?



Re: [gentoo-dev] rfc: [QA] Ban policy introduction

2018-07-30 Thread Guilherme Amadio

I like the idea of enforcing quality rules in the tree, but I have a few
reservations regarding the current plan.

On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote:
> Sent from my phone. Please excuse my brevity.
> On Sun, 29 Jul 2018, 16:39 Fabian Groffen,  wrote:
> > Completely agreeing with Sergei, with some additional suggestions:
> >
> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote:
> > > On Sun, 29 Jul 2018 00:40:18 +0300
> > > Mikle Kolyada  wrote:
> > >
> > > > Hello,
> > > >
> > > > The Gentoo QA team would like to introduce the following policy that
> > > > would be applied to individuals breaking the state and quality of the
> > > > main gentoo.git tree

If you introduce penalties for breaking prefix as well, I'm afraid many
people will be unnecessarily penalized. I think that such penalties are
counter productive in most cases. If someone is really being careless it
might make sense to get some warning and lose commit access temporarily.
If someone made a simple mistake that can be easily fixed, like version
bumping a package that starts to fail in some corner case, then
punishment doesn't make much sense. 

I'd rather prefer to see improvements to our automated checks as the
mean to improve the quality of the tree, and penalties for people that
do not use repoman. Rather than a temporary ban, it would also make more
sense to just require someone to go through the ebuild quiz again as
penalty for breaking the tree many times.

> > > > ( as we do not have this strictly documented yet):
> > > >
> > > > 
> > > >
> > > > If recommended
> > >
> > > It's not called "recommended" but "enforced".
> >
> > I agree.  If you put penalties on these, they become hard rules.  I
> > think that change should be discussed by the council perhaps?
> >
> > > > Gentoo workflow policies are not followed by an
> > > > individual developer
> > > > (e.g make major changes to the widely used eclasses without prior
> > > > discussion on the mailing list or
> > > > commit changes that lead to multiple CI checks failure)
> > >
> > > Here should go exhaustive list of links to the policies to be enforced.
> >
> > At least.  And they should be clear and concise.  No "common sense" or
> > anything involved for exceptions and the like.  In addition, new checks
> > should be introduced to the community and possibly approved by council
> > as to whether being enforced or not.
> >
> > Fabian
> >
> > >
> > > > the standard QA
> > > > procedure is:
> > > >
> > > > 1.) Two warnings granted by QA team, after two independent breakages
> > > > 2.) Revoking the commit access for 14 days
> > > >
> > > > These violations will be evaluated individually by all QA team members.
> > > > Warnings can be revoked, if during 6 months period a developer makes at
> > > > least 20 non trivial changes not producing more breakages.
> > > >
> > > > 
> > >
> > > --
> > >
> >
> if you want to enforce rules, would be productive to also have extensive
> documentation on how to avoid to make such problems.
> Better would be to invest more time in something like the breckage checker
> script, similar at what mgorny is doing, than adding more ways to block
> developers contributions.

I agree with Alice here. We already have the devmanual and repoman, as
well as the CI system, which are all very good. Extending them is the
best way to keep Gentoo in good shape. Also, if we have enough
resources, we can try to reject broken pushes, rather than punishing
devs after broken changes reach the main tree.


[gentoo-dev] [PATCH] udev.eclass: return unprefixed udevdir

2018-06-08 Thread Guilherme Amadio

This is a simple fix, but I'd like it to be reviewed.

Without this get_udevdir returns the prefixed directory, leading
to double prefix on udev related packages (e.g. fuse-common).

Even if not used in prefix, udev related packages are usually pulled
in as dependencies of other packages (xrootd for fuse).


diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 5e5df073880..148581b8bd5 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -46,7 +46,8 @@ DEPEND="virtual/pkgconfig"
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
if $($(tc-getPKG_CONFIG) --exists udev); then
-   echo "$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
+   local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
+   echo ${udevdir#${EPREFIX%/}}
echo /lib/udev

Re: [gentoo-dev] rfc: Remove inherit eutils from font.eclass for EAPI=6

2018-02-14 Thread Guilherme Amadio
On Thu, Feb 15, 2018 at 03:16:22AM +0200, Mart Raudsepp wrote:
> On Wed, 2018-02-14 at 23:43 +0100, Jonas Stein wrote:
> > Did I miss something?
> > Who can help to check with (an automatic) testenvironment, if these
> > packages will survive?
> Don't check with test environments, read the ebuilds.

I agree with this. Font ebuilds are usually quite trivial, so it might
even be faster to just read them. The font.eclass has not been touched
since the move to git, but I suspected few fonts would actually use
eutils, so here is another grep that shows it may be easier than we
think to get rid of inherit eutils, even if for all EAPIs:

gentoo $ export eutils_funcs=(eqawarn ecvs_clean esvn_clean \
egit_clean emktemp edos2unix strip-linguas built_with_use make_wrapper \
path_exists use_if_iuse optfeature epause ebeep usex einstalldocs \
gentoo $ for func in ${eutils_funcs[@]}; do grep -rI 'inherit.*font' 
--include='*.ebuild' -l | \
xargs grep $func; done | cut -d: -f1 | sort | uniq


Most of the above only use usex, and terminus-font uses einstalldocs as well.
I think these should be pretty easy to fix to not use eutils, or simply
add 'inherit eutils' for these ebuilds, then remove from the eclass.

I can help with testing by reading ebuilds more carefully and emerging
them after the change in font.eclass.


Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

2017-04-25 Thread Guilherme Amadio
On Tue, Apr 25, 2017 at 11:26:16AM -0500, William Hubbs wrote:
> On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
> > 
> > I would rather prefer to keep essential development tools in tree.
> > GCC is not only used as system compiler, but also for development.
> > I already had problems before with CMake being aggressively removed,
> > so I couldn't just install CMake 3.5.2 to test something that got
> > broken with the latest CMake (3.7.2 at the time).
> >
> > For things like autotools, CMake, compilers, etc, I would like to
> > see at least the latest release of the previous major version (e.g.
> > CMake 2.8), and the last few latest releases from the current major
> > version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
> > as in prefix you may be somewhat limited by the host (think macOS),
> > so removing old ebuilds aggressively breaks stuff. I think this was
> > the case with clang before, where we needed 3.5 and that got removed,
> > so bootstrapping on macOS was broken for sometime.
> That's completely reasonable. My concern is that we have the following
> versions of gcc in the tree:
> gcc-2.95.3-r10
> gcc-3.3.6-r1
> gcc-3.4.6-r2
> gcc-4.0.4
> gcc-4.1.2
> gcc-4.2.4-r1
> gcc-4.3.6-r1
> gcc-4.4.7
> gcc-4.5.4
> gcc-4.6.4
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.3
> gcc-4.9.4
> gcc-5.4.0
> gcc-5.4.0-r3
> gcc-6.3.0
> Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
> and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
> correct?

I'm not saying we should cut down to the set of versions I mentioned.
I think it's totally fine to have all the gcc versions above in the tree.
What I want to avoid is having less than what I said due to aggressive
removal of older versions, at least for critical packages like the toolchain
and related tools. So, I'd be happy with the set below for gcc, for example:

> gcc-4.4.7
> gcc-4.7.4
> gcc-4.8.5
> gcc-4.9.4
> gcc-5.3.0
> gcc-5.4.0-r3
> gcc-6.3.0

However, it doesn't hurt to have the older 3.x and 2.95 versions in case
someone needs to compile, say, software that was developed a long time
ago and doesn't compile anymore with the latest compilers.


Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc

2017-04-24 Thread Guilherme Amadio
On Mon, Apr 24, 2017 at 11:01:32AM -0500, William Hubbs wrote:
> On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote:
> > Hi,
> > 
> > I'm thinking of masking old versions of sys-devel/gcc, in particular
> > older than the 4.9 branch.
> [...]
> > My solution
> > ===
> > 
> > I think there is no point in having explicit support for ancient gcc
> > versions these days. However, I admit that some specific developers
> > and users may have a need for them. Therefore, I think the best way
> > forward would be to keep them in ::gentoo but p.mask with
> > an explanatory message.
> > 
> > The most important goal of having the packages masked is that it would
> > cause Portage to verbosely complain whenever the users have it
> > installed. With appropriate comment (displayed by Portage), we could
> > clearly inform users that they need to upgrade gcc and switch to a new
> > version to ensure that majority of packages work.
> > 
> > We would also clearly indicate that we no longer support the old
> > versions and do not have to explicitly indicate this non-support via
> > explicit version checks in ebuilds.
> > 
> > At the same time, users who really need those versions could unmask them
> > on their own responsibility and knowing the implications of setting them
> > as system-wide compilers.
> > 
> > 
> > What do you think?


> Honestly,
> if we aren't going to officially support those older versions of gcc, I
> would rather see them moved to an overlay and removed from the main
> tree.

I would rather prefer to keep essential development tools in tree.
GCC is not only used as system compiler, but also for development.
I already had problems before with CMake being aggressively removed,
so I couldn't just install CMake 3.5.2 to test something that got
broken with the latest CMake (3.7.2 at the time).

For things like autotools, CMake, compilers, etc, I would like to
see at least the latest release of the previous major version (e.g.
CMake 2.8), and the last few latest releases from the current major
version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
as in prefix you may be somewhat limited by the host (think macOS),
so removing old ebuilds aggressively breaks stuff. I think this was
the case with clang before, where we needed 3.5 and that got removed,
so bootstrapping on macOS was broken for sometime.


Re: [gentoo-dev] Package up for grab

2016-08-03 Thread Guilherme Amadio
On Wed, Aug 03, 2016 at 11:15:30AM +0800, Jason Zaman wrote:
> On Tue, Aug 02, 2016 at 04:08:34PM -0700, Jigme Datse Rasku wrote:
> > I'd have to say, there is likely a reason we are looking for a new
> > maintainer.  I don't know what is involved, but I might be interested.
> > Might be wanting to start that direction...
> There is a new alpha skype for linux too now that should be looked into.
> I have no idea how stable it is but it's probably not much worse than
> what we currently have :P.

There is also a web version at for those that feel
that installing the desktop client is too much of a hassle. I've moved
to Google Hangouts long ago, though, and never looked back.


Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Guilherme Amadio
On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote:
> Dear friends,
> while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> list could be expanded a bit:

I like the idea of expanding the list of CPU_FLAGS_X86, and having flags
for other arches too, but I would be in favor of dropping the _X86
suffix and using CPU_FLAGS for all arches. Your machine most likely will
only have one kind anyway. Not sure what others think about it, though.

> avx512 - introduced with Skylake and Knights Landing

Only Skylake Xeons (yet to be launched) will support AVX512, and
as mentioned in another email, the subsets supported by Skylake and
KNL are a bit different. So, adding each subset should be better
(e.g. avx512f, avx512cd, avx512er, etc).

> I also propose creating a CPU_FLAGS_PPC variable containing (at least):
> altivec - PowerPC's SSE
> vsx - PowerPC's AVX
> Finally, I also propose creating CPU_FLAGS_ARM variable containing:
> neon
> Any ideas? Currently cpu-feature flags for non-x86 are package local,
> whereas making them globally available makes masking easier for non-
> applicable archs etc. and makes enabling them easier for users.

Masking flags is not needed if they are determined from /proc/cpuinfo.


Re: [gentoo-dev] Need design help/input for eclean-kernel

2016-07-01 Thread Guilherme Amadio
On Thu, Jun 30, 2016 at 02:38:26PM +0200, Michał Górny wrote:
> So if you have some time, please reply to this thread with
> a specific /boot layout that you think needs to be handled, with
> as much helpful information as possible -- including possible
> distinctive features and pitfalls.

Looks like not too many people are booting kernels like me, so
I'm going to add my crude setup to the pile :)

I compile most stuff into the kernel (at least enough so I don't
need to use an initrd/initramfs to mount / or /usr). I do not use a boot
loader either, I use CONFIG_EFI_STUB=y and compile in the command
line arguments to avoid trouble. Then, I use efibootmgr to boot the
kernel at /boot/EFI/Gentoo/bootx64.efi

I usually keep several kernels in the same directory with a version
suffix (e.g. bootx64-4.6.2.efi, etc) and overwrite the bootx64.efi
file with whatever kernel I want to boot with cp bootx64{-4.x.x,}.efi

I keep a few older kernels around in case I screw up the configuration
of a new one (usually video drivers), but for the most part, that's it.

My compiled kernel command line is also pretty simple:

quiet console=tty1 root=/dev/sda4 init=/usr/lib/systemd/systemd

I never really though about writing scripts to manage this, since it's
quite a simple setup, but having tools to manage it would be nice.

Just think about supporting a simple EFI/UEFI setup, I would say, in
addition to the more common setups using a boot loader.


Re: [gentoo-dev] Migrate to Phabricator

2016-04-18 Thread Guilherme Amadio

On Mon, Apr 18, 2016 at 01:44:00PM +0200, Jonas Jelten wrote:
> Ohai!
> Phabricator is a fun adventure game:
> It provides a tightly coupled set of project management tools.
> Many bigger projects (e.g. blender, mediawiki, ...) started using
> phabricator, it could also be very beneficial for gentoo.

The website lists "Companies probably using Phabricator", which not a
very good for transmitting trust.

We've just been through major migrations: moving to git, website
migration, etc. We should not forget all the work that has been put into
making the current system work for Gentoo, and I have to say, I think that
our new website looks really nice, gitweb looks great too, and we have a
really large history of bugs on bugzilla, that also has a Gentoo theme.
Migrating to something else would be a huge undertaking. That's why,
even though I use and like Atlassian tools, I never proposed a migration
to JIRA, bitbucket and other tools. If others would like moving to
something else, I believe that Atlassian tools are more attractive.
Yes, they are a proprietary company, but they do offer free licenses for
open source projects that could be hosted on Gentoo Infra.

That said, I'm not saying we should move to Atlassian tools, just that
it's probably a better option than Phabricator, if such a big migration
happens. I think that what we have now is already pretty good.

> Migrating would contradict the apparent goal of integrating github more
> tightly, but still we could consider to use Phabricator instead,
> especially to dump bugzilla.

While I'm not particularly against integrating more tightly with GitHub,
there is no such goal in Gentoo as far as I can tell. As much as I like
GitHub, I do understand the concerns of others about making GitHub
essential. It has been blocked before in certain regions of the world,
and that's not good for us, regardless of the free vs proprietary
debate. I don't think that GitHub is evil or anything, but GitHub is a
nice place for extras, to interact with the user community, receive
patches, etc. It should not replace our own infra.


Re: [gentoo-dev] packages to grab

2016-01-08 Thread Guilherme Amadio

On Fri, Jan 08, 2016 at 11:04:03AM -0500, Göktürk Yüksek wrote:
> Hi,
> >
> > I will move all packages I maintain [1] to the associated projects if
> > possible. All devs are free to take what ever you are interested in. I
> > am also happy to proxy contributors if they like to maintain a package.
> > 
> I would like to proxy-maintain dev-vcs/gitstats if possible.

Sure, I can be your proxy-maintainer.


> > 
> > Cheers,
> > Justin
> > 
> > 1)
> >
> Thanks,
> --
> gokturk

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

2015-12-03 Thread Guilherme Amadio
On Tue, Dec 01, 2015 at 10:58:55PM +, James Le Cuirot wrote:
> Sorry for the length of this but you really need to consider the bigger
> picture with this stuff and not all devs are familiar with it.
> For EAPI 7, mgorny and I are seeking to address some cross-compiling
> issues. This is a subject I've long had an interest in and before I
> became a developer, I created a project called cross-boss that, to be
> blunt, hacks its way through the shortcomings in Portage and the tree.
> It does (or at least did when I last worked on it) achieve a higher
> success rate than you would get from crossdev alone and allows you to
> install a brand new standalone system from scratch as opposed to one
> under /usr/${CHOST}.
> I have heard some developers say that cross-compiling is simply not
> worth the effort but I have succeeded in building some big ticket items
> including MariaDB, GTK+, Qt4, and LibreOffice. This is one area where
> Gentoo can really shine so I would like to exploit that potential.

Thanks for the nice write up.

I've been using a prefix installation (no root privileges to use Gentoo)
and Intel compilers with Portage to cross compile stuff for the Xeon Phi[1].
For the most part I've just hacked my way into making things work, but
it would be cool to get a project going to do this properly.



Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

2015-09-05 Thread Guilherme Amadio
On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote:
> > On Sat, 5 Sep 2015, Rich Freeman wrote:
> > I certainly support the principle, but for the sake of transparency
> > can we try to coordinate this so that the setting name doesn't
> > change when this moves into the package manager for EAPI6?
> So far, the EAPI 6 draft says [1]:
>Takes no arguments. Package managers supporting it apply
>user-provided patches to the source tree in the current working
>directory. Exact behaviour is implementation defined and beyond
>the scope of this specification. Package managers not supporting
>it must implement the function as a no-op. Only available in
>EAPIs listed in table [...] as supporting eapply_user.

Is there a reason to pick eapply_user rather than epatch_user? I think
the second one would fit better with what we already have.
Alternatively, if we would like to avoid adding a new function, it could
be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES,
where $DIRECTORY_WITH_PATCHES either defaults to something like
$EPATCH_SOURCE_USER, or can be specified via package.env. This takes the
burden away from the package manager for where to put patches, and lets
the user make that choice.


Re: [gentoo-dev] repoman adding Package-Manager: portage- to every single commit

2015-08-19 Thread Guilherme Amadio
On Wed, Aug 19, 2015 at 11:00:49AM -0700, Zac Medico wrote:
 On 08/19/2015 10:49 AM, hasufell wrote:
  On 08/19/2015 07:37 PM, Zac Medico wrote:
  On 08/19/2015 09:33 AM, hasufell wrote:
  I don't want to start a lot of bikeshed, but I think this information is
  practically useless.
  If there has been a problem with a commit, ask the developer about his
  repoman version (which I believe was the reason for this, unless you
  want me to add Package-Manager: paludis-2.4.0 to every commit ;).
  Let's just remove it.
  The intent is to leave a record of the version of repoman used, which
  leaves an audit trail in case there's a bug in some some version (or to
  detect if someone is using an ancient version). It can especially be
  useful when new repoman checks need to be added for new EAPI features.
  Why is it called Package-Manager: then?
 Because repoman in bundled with portage, I guess. I suppose we could
 change it to something else.

How about the line below?

Signed-off-by: dev name (repoman version)


Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-03-01 Thread Guilherme Amadio
On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote:
 On 28 February 2015 at 19:52, Michael Orlitzky wrote:
  On 02/28/2015 01:47 AM, Ben de Groot wrote:
  Since this is mostly used for web developers, I recommend to leave it
  off for desktop users, but possibly on for servers, for example.
  If we do the use expand, we should leave it up for users to set. I
  suggest we default to only otf, if there is a choice. Other formats
  should not be installed by default, unless it's the only option for
  that package.
  This is going to get confusing fast -- please consider just installing
  everything by default. If you default to only OTF, what happens when
  you install a foo-ttf package? Is it a no-op? What if there's a package
  that only ships WOFF files? A combination of TTF and WOFF?
  Most of the fonts are tiny and it's not worth the hassle to avoid a few
  kilobytes. It will also keep the eclass nice and clean. If you default
  to installing everything, then when a user goes out of his way to remove
  (say) WOFF, you can go ahead and just ignore WOFF files even if the
  result is something stupid like an empty package.
  (The webfonts might be useful for clients, by the way. If they're not
  installed locally, your browser downloads them on-demand and caches them
  for later use.)
 Actually, after thinking about it some more, and doing some more
 research, I think this approach is unnecessary. Unless someone can
 tell me otherwise, I don't think we have any software that can handle
 truetype fonts but not opentype fonts. Most if not all of these
 packages use media-libs/freetype, which displays both formats just
 fine. So when we have font packages that offer both ttf and otf, then
 we should just install the superior format, which is OpenType.
 For packages that only offer one format, we install that format.
 Webfonts are also not an issue, as they are simply repackaged OpenType
 fonts aimed at web delivery. But most web developers use third party
 CDNs for that, such as Google Fonts. For the very few people who want
 to serve WOFF fonts from their own websites, I'm sure they can locate
 them as necessary.
 And webfonts are not useful for clients. Users should simply install
 the otf (or ttf) format of those fonts locally, and they will be
 picked up instead of the webfonts.
 Summarized, I propose the following policy:
 1. If there is a choice of formats between otf and ttf, install only otf.
 2. Do not install webfonts.

I agree with your policy, but I think it's still a good idea to offer a
mechanism to install the other formats for those who need it, maybe via
truetype and woff or webfont USE flags. LaTeX, for example, may not be
able to use OpenType fonts, unless you use XeTeX, or other newer
variant, and sometimes a package you may want to use is only available
for plain LaTeX or PDFTeX (pst-solides3d and pstricks come to mind).

We could have global USE flags for each popular font format, turn on the
flag for OpenType by default, and let users choose extra formats they
want. Another thing we might want to work on is on a way to convert
fonts for use with legacy LaTeX software that can't use OpenType files.


Re: [gentoo-dev] Re: Fonts project meeting and elections

2015-02-27 Thread Guilherme Amadio

On Fri, Feb 27, 2015 at 03:45:23PM +0800, Ben de Groot wrote:
 On 22 February 2015 at 03:43, Ben de Groot wrote:
  To anyone within Gentoo who is interested in fonts
  I would like to announce a meeting to be held in #gentoo-meetings on
  Freenode, on Friday February 27 at 06:00 UTC, unless another date
  and/or time will be suggested by people who want to attend.
 Since nobody actually showed up, here is what I've decided and am proposing:

Oops, got caught up by the timezone difference... Sorry about that.
It was late at night here, but yesterday.

 1. lu_zero, matsuu, pva: do you still want to be members of the Fonts
 project? Then add yourselves to the new project page:

I'm listed, but why can I not edit the page? I'd like to be able to.

 2. Since aballier voted for me, and there were no other nominations,
 we default to me becoming the lead.
 3. Handling of fonts with both truetype and opentype variants, as
 brought up in
 Since OpenType is an extension of TrueType, and superior for desktop
 and printing use, I propose that we prefer installing just OpenType.
 But this should be user configurable, so in those cases I propose we
 if use opentype; then

Both this and the use expand suggested by Luca seem good methods.
I also suggest we prefer OpenType over TrueType whenever possible.

 4. Project member should have a look at font bugs. has a lot
 of low hanging fruit: version bumps, dead homepages, etc. Also some
 good new packages.

I've seen a few of those and suggested webpages for a couple of them.
I can go fix some of these if nobody else does.

 5. Some fonts have webfont variants (WOFF is the important one here).
 This may be useful for users doing web development. What are your
 thoughts on installing those (conditionally, toggled by useflag)?

Since this is mostly used for web developers, I recommend to leave it
off for desktop users, but possibly on for servers, for example.

 Anything else you want to discuss?

I'd like to suggest that we do not name new font packages font-*, but
simply by the name of the typeface, such as open-sans, source-pro, etc.
There is Source Serif, Source Sans, and Source Han Sans that are not
packaged yet (see for more info), as well
as many other nice and well-known typefaces and icon fonts such as
Aller, Amble, Casper, Clear Sans, Entypo, Font Awesome, Signika, Comic
Neue, Fira, Nexa, Exo, Nobile, Open Sans, etc.

There is also the really nice Input (, but
its license is only free for personal use, so we may need to talk to its
designer to see if we can package it at all. I'm using it on my laptop,
and it's a pleasure to read and very customizable.

Well, maybe opening a #gentoo-fonts on IRC will be a nice way to
coordinate our efforts.

Also, this is definitely a minor thing, but all designers prefer the
term typeface to font when referring to typefaces, so they'd probably be
happy if media-fonts became media-type, or something similar. The
distinction is that the set of fonts (regular, light, bold, condensed,
etc) is what makes a typeface, which is the general style of all fonts
in the set. Anyway, just food for thought.


Re: [gentoo-dev] Fonts project meeting and elections

2015-02-22 Thread Guilherme Amadio

On Sun, Feb 22, 2015 at 03:43:33AM +0800, Ben de Groot wrote:
 To anyone within Gentoo who is interested in fonts
 I would like to announce a meeting to be held in #gentoo-meetings on
 Freenode, on Friday February 27 at 06:00 UTC, unless another date
 and/or time will be suggested by people who want to attend.
 There hasn't been much activity in the fonts area of Gentoo, and our
 lead seems to be MIA.
 The main points on the agenda:
 1. Who wants to be member of the Fonts project, and help out?
 2. Members to elect a new lead. I'm nominating myself.
 3. Make a plan for dealing with open bugs
 4. Open floor

 Yes, I would like to be part of the team. I was thinking about creating
 a Typography project, but if there is already a Fonts project, it will
 work just as well. I won't nominate myself as a lead, since I just
 became a Gentoo dev, but I do want to help. I will show up to the


Re: [gentoo-dev] News item review: bash-completion-2.1-r90

2014-10-13 Thread Guilherme Amadio
On Mon, Oct 13, 2014 at 07:37:19AM -0400, Alex Xu wrote:
 On 13/10/14 05:35 AM, Michał Górny wrote:
  Please review the following news item.
  Title: bash-completion-2.1-r90
  Author: Michał Górny
  Content-Type: text/plain
  Posted: -MM-DD
  Revision: 1
  News-Item-Format: 1.0
  Display-If-Installed: app-shells/bash-completion-2.1-r90
  Starting with app-shells/bash-completion-2.1-r90, we are enabling
  the completion autoloading support. Along with it, we are replacing
  the eselect-bashcomp module with a new one suited better for the new
  Users will notice that the new framework is opt-out rather than opt-in.
  Since completions are loaded on-demand, all of them are enabled
  by default. If some of them are undesired, eselect-bashcomp can be used
  to explicitly disable (mask) them.
  The current eselect-bashcomp setup will *not* be migrated. It may be
  necessary to rebuild packages installing completions after the upgrade,
  and remove old configuration symlinks afterwards. For details, please
  consult the app-shells/bash-completion post-install messages.
 seems too oriented towards developer audiences, whereas news items are
 intended to target users; iow, I don't care what's going on behind the
 scenes, just tell me what I need to do to fix it.

 I disagree. I'm a user, and I'm interested in what is going on behind
 the scenes. I think that it's safe to assume that many Gentoo users care
 about the internals of the distribution too. I've actually been waiting
 for this to hit the tree since mgorny announced it. The news announcement
 is pretty good; I'd only incorporate pacho's suggestion to include the two
 commands needed to fix old stuff, and then I think it's good to go.


[gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils

2007-10-31 Thread Guilherme Amadio

 Hi guys,

 I totally agree with the patch sent by Daniel in the previous message.
 I think it clarifies to the user (me, for example), why it's not possible
 to build pciutils with the zlib USE flag. This is just my humble opinion,
 though, as a user.

 And sorry to a bit off this thread, but I also would like to help with
 some translations of official docs and development. I've been using Gentoo
 since 1.4, but never really had time to help. Now I feel I'll have more
 time and, if you can point me to some Brazilian dev, if there are any, I
 can take some stuff to do.



[EMAIL PROTECTED] mailing list