Re: [gentoo-dev] Packages up for grabs: app-cdr/iat, dev-util/flawfinder

2021-02-09 Thread Alfredo Tupone
On Mon, 8 Feb 2021 08:25:28 +0200
Joonas Niilola  wrote:

> Packages up for grabs due to retirement of a proxied maintainer:

> dev-util/flawfinder (outdated)

I take this

Alfredo



[gentoo-dev] dev-ml/ocaml-data-notation scheduled for removal

2021-02-01 Thread Alfredo Tupone
No package is using it
last update 2013
No more in the opam package list

Alfredo Tupone



[gentoo-dev] ml project created

2021-01-12 Thread Alfredo Tupone
As I have interest on lot of ebuild on dev-ml, and most of them are not
managed by any project, I have created a project to handle them.

I have build https://wiki.gentoo.org/wiki/Project:Ml tring to revive
an old ml project.

Any comments?

Alfredo



[gentoo-dev] Last rites: dev-tcltk/tcl-mccp

2020-04-10 Thread Alfredo Tupone
Last release is 2002
No reverse dependency



[gentoo-dev] Changes to toolchain.eclass to better support gnat-gpl ebuild

2020-04-02 Thread Alfredo Tupone
I would like to have the attached changes reviewed and, if possible,
applied to the toolchain eclass.

This will simplify the gnat-gpl ebuild and is a step to add ada to
sys-devel/gcc

And also I suggest temporary to mask the ada flag for sys-devel/gcc

Thanks

Alfredo Tupone
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index ee466ee4d904..c18864b60ded 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -172,31 +172,31 @@ if [[ ${PN} != "kgcc64" && ${PN} != gcc-* ]] ; then
 	tc_version_is_at_least 4.2 && IUSE+=" +openmp"
 	tc_version_is_at_least 4.3 && IUSE+=" fixed-point"
 	tc_version_is_at_least 4.7 && IUSE+=" go"
 	# sanitizer support appeared in gcc-4.8, but  src_compile <
 
 toolchain_src_compile() {
 	touch "${S}"/gcc/c-gperf.h
 
 	# Do not make manpages if we do not have perl ...
 	[[ ! -x /usr/bin/perl ]] \
 		&& find "${WORKDIR}"/build -name '*.[17]' -exec touch {} +
 
+	# Do not set ADAFLAGS to build the compiler
+	unset ADAFLAGS
+
 	# Older gcc versions did not detect bash and re-exec itself, so force the
 	# use of bash.  Newer ones will auto-detect, but this is not harmful.
 	# This needs to be set for compile as well, as it's used in libtool
 	# generation, which will break install otherwise (at least in 3.3.6): #664486
 	CONFIG_SHELL="${EPREFIX}/bin/bash" \
 	gcc_do_make ${GCC_MAKE_TARGET}
+	if use ada; then
+		gcc_do_make "-C gcc gnatlib-shared"
+		ln -s gcc ../build/prev-gcc || die
+		ln -s ${CHOST} ../build/prev-${CHOST} || die
+		gcc_do_make "-C gcc gnattools"
+	fi
 }
 
 gcc_do_make() {
 	# This function accepts one optional argument, the make target to be used.
 	# If omitted, gcc_do_make will try to guess whether it should use all,
 	# or bootstrap-lean depending on CTARGET and arch.
 	# An example of how to use this function:
 	#
 	#	gcc_do_make all-target-libstdc++-v3
 
 	[[ -n ${1} ]] && GCC_MAKE_TARGET=${1}
 
 	# default target
 	if is_crosscompile || tc-is-cross-compiler ; then
 		# 3 stage bootstrapping doesnt quite work when you cant run the


[gentoo-dev] toolchain.eclass more friendly about ada/gnat

2019-11-23 Thread Alfredo Tupone
I would like to have comments about the followinf changes.
I "fear" the shopts nullglob a little

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a3081c38bac1..aca10b4f37ed 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1817,33 +1817,37 @@ toolchain_src_install() {
fi
 
dodir /etc/env.d/gcc
create_gcc_env_entry
create_revdep_rebuild_entry
 
# Setup the gcc_env_entry for hardened gcc 4 with minispecs
want_minispecs && copy_minispecs_gcc_specs
 
# Make sure we dont have stuff lying around that
# can nuke multiple versions of gcc
gcc_slot_java
 
dodir /usr/bin
cd "${D}"${BINPATH}
+
+   shopt nullglob
+   local gnat_extra_bins="gnat*"
+
# Ugh: we really need to auto-detect this list.
#  It's constantly out of date.
-   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
+   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo 
${gnat_extra_bins} ; do
# For some reason, g77 gets made instead of ${CTARGET}-g77...
# this should take care of that
if [[ -f ${x} ]] ; then
# In case they're hardlinks, clear out the target first
# otherwise the mv below will complain.
rm -f ${CTARGET}-${x}
mv ${x} ${CTARGET}-${x}
fi
 
if [[ -f ${CTARGET}-${x} ]] ; then
if ! is_crosscompile ; then
ln -sf ${CTARGET}-${x} ${x}
dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
/usr/bin/${x}-${GCC_CONFIG_VER}
fi



[gentoo-dev] media-libs/cal3d needs a mantainer

2019-11-13 Thread Alfredo Tupone
I am no more interest in media-libs/cal3d.

Reverse dependency are:

games-rpg/eternal-lands
dev-python/soya

I think games should take it

Alfredo Tupone



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

2019-09-18 Thread Alfredo Tupone
On 22:56 Tue 17 Sep , Michał Górny wrote:
> On Tue, 2019-09-10 at 22:44 +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 https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2
> > 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!
> > 
> 
> Thanks for all the data so far.  I've released v8 with the lot of ARM
> tests just now.
> 
> If someone's got older hardware ( results.  After all, we technically do support ARMv4.
> 
> -- 
> Best regards,
> Michał Górny
> 
Something from my RaspberryPI 1B+

Raspberry Pi 1 Model B+
./hwcap-dump
hwcap:81d6 hwcap2:
/proc/cpuinfo
processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS: 697.95
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: 0010
Serial  : e598822e
./cpuid2cpuflags
CPU_FLAGS_ARM: edsp thumb vfp v4 v5 v6
uname -m
armv6l

Regards



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

2019-09-06 Thread Alfredo Tupone
On 23:45 Thu 05 Sep , Mike Gilbert wrote:
> On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann  wrote:
> >
> > On 2019-09-05 22:16, Michał Górny wrote:
> > >> But as per the way the dev manual is written, he arguably *is*
> > >> following policy.
> > >>
> > >> Stop taking the line of assuming he's trying to be belligerent.
> > >
> > > He says explicitly that he is against fixing devmanual because he likes
> > > the way he can abuse it right now.
> >
> > You are the only one adding _abuse_ here. Stop that, thanks. When I
> > replied to your mail I was just asking... nothing more. I don't
> > understand why you are reading so much into it.
> 
> The devmanual o clearly indicates that an email to gentoo-dev is
> strongly preferred. I don't see any reason why tupone could not have
> done this.
> 
> You seem to be trying to take this opportunity to prove some loosely
> related point.
> 
> > But yes, I like the current exception for "per-package" eclasses like I
> > am concerned that a review requirement would cause a significant delay:
> >
> > Back to my example, imagine we would move pkg_config to new mysql
> > eclass. If we would bump mysql/percona-server/mariadb package and will
> > receive bug reports later because upstream changed something causing
> > pkg_config to fail we would now have to propose a patch, wait 48
> > hours... i.e. package would be broken for ~72 hours just because of a
> > policy I don't reject in general (yes, I like reviews) but where I think
> > exceptions must be possible.
> 
> This argument is stupid. If you need to push a critical bug fix, then
> do it. Nobody will fault you for it.
> 
> This clearly does not apply to ada.eclass.
> 
I am going just to explain the reason why I did not ask ml about review the 
first time.
1) ada.eclass is copied from python-single-r1 eclass with s/PYTHON/ADA/ and 
removing pieces that I don't need
2) The eclass is only for packages that I mantains exclusively and they are not 
such a great number

The eclass is an effort to avoid in the future the same problems raised from 
qa-check
All comes from a suggestion to use USE_EXPAND for gnat_2016 gnat_2017 ...

My opinion is that the ml review should be mandatory only for new eclasses that 
are meant to be used by all the tree or by a great number of packages (>= 100 ?)

However, as stated in the email I reverted my changes and add the eclass to the 
ml.

Then, what a review means, when it is approved or denied, I will try to learn

Alfredo



Re: [gentoo-dev] Packages up for grabs post disbanding Ada: dev-lang/gnat-gcc and metastuff

2017-02-22 Thread Alfredo Tupone
On Wed, 22 Feb 2017 11:07:47 +0100
Michał Górny  wrote:

> Hi,
> 
> The Ada project has been disbanded as having no members. Although
> there were a few people interested in helping out with Ada, nobody
> made it past the initial reply. If anyone is still interested, the
> packages are up for grabs.
> 
> This involves the following packages:
> 
> app-eselect/eselect-gnat
> dev-ada/asis-gcc [lastrited]
> dev-ada/charles [lastrited]
> dev-lang/gnat-gcc
> virtual/ada
> virtual/gnat
> 

I asked to, but I needed a change in the toolchain eclass that is not
under my umbrella.

However the packages you cited are not needed by my implementation



Re: [gentoo-dev] Changes in toolchain.eclass to enable Ada

2016-12-22 Thread Alfredo Tupone
Il giorno Thu, 22 Dec 2016 21:11:45 +0100
Michał Górny <mgo...@gentoo.org> ha scritto:

> On Thu, 22 Dec 2016 14:55:05 +0100
> Alfredo Tupone <tup...@gentoo.org> wrote:
> 
> > > > I would like to start including, in the gentoo tree, GNAT-GPL
> > > > built in the same way as sys-devel-gcc and selectable with
> > > > gcc-config
> > > 
> > > 1. Does this mean that GNAT-GPL build will include building a C
> > > compiler? If yes, will the C compiler be installed?
> > Yes, a C and a C++ compiler, and they will be installed  
> > > 
> > > 2. Will it be possible to combine GNAT-GPL with a different
> > > version of regular gcc C/C++ compilers?
> > No, not easily  
> 
> To be honest, I don't like this at all. This sounds like doubling
> the effort on maintaining gcc, and it sounds like people using
> GNAT-GPL would end up being forced to use old versions of GCC (also
> possibly missing patches).
All the patch that we (gentoo) apply to sys-devel/gcc-4.7.4 are applied
to gnat-gpl without any changes. Well I actually did two small patches
to the piepatches that apply to gcc, but the rest goes well.
It seems that gcc-4.7.4 and gcc included in gnat-gpl-2014 are very near.

I have still to check the newest 2015 (4.9.3) and 2016 (4.9.4) version.

The other path to provide gnat compiler to gentoo is using the one in
the FSF gcc. 
The advantage are 
a) that you don't have two gcc to align,
b) you can compile closed source.
but 
a) when you provide a new version of gcc you also need to check the
ada compiler
b) the ada compiler is an older version even if it is running on a new
gcc
> 
> If the Ada compiler requires Ada to boostrap anyway, can't you just
> make it build the Ada compiler alone?
> 
To bootstrap it needs a C, C++, and an Ada Compiler. and they should be
provided by using the gcc driver. (At least without changing a lot the
compilation scripts). So a standalone ada compiler cannot be used to
boostrap.

More over, as the gnat provide interfaces between languages, the layer
of interface between Ada and C++ depends on the version.
Sometimes happened that Ada and C++ had problems for differences in
the vtable layout (if I remember well, when going from gcc-3 to
gcc-4), or in mangling (gcc-2.8.1 to gcc-3, yes long time ago)
that caused problems when passing objects between languages. It
is better that the version of C++ and Ada used in a program are aligned.

If both are provided by the same gcc, that is automatic.



Re: [gentoo-dev] Changes in toolchain.eclass to enable Ada

2016-12-22 Thread Alfredo Tupone
On 13:49 Thu 22 Dec , Michał Górny wrote:
> On Wed, 21 Dec 2016 23:00:47 +0100
> Alfredo Tupone <tup...@gentoo.org> wrote:
> 
> > I would like to revive the Ada support in gentoo.
> > 
> > One ada compiler is produced by AdaCore and is provided in three
> > versions, in the order starting from the best supported :
> > 
> > 1) GnatPro, available with a contract support.
> > 
> > 2) Gnat-GPL that can only build GPL-3 product
> > 
> > 3) The gnat included in the gcc tree that is GPL-3 with exception.
> > 
> > Gnat-GPL is very like the gnat in the gcc-tree so it can be built in
> > the same way of sys-devel/gcc
> > 
> > To be compiled from source the gcc compiler needs a C, C++, and Ada
> > Compiler. I will provide one with the gnat-gpl-bin tar that could be
> > installed under /opt . When the gcc is properly compiled we don't need
> > it any more.
> 
> Do I correctly understand that this is also true for gnat-gpl? Is there
> any Ada compiler that could be used to bootstrap Ada on platforms that
> lack prebuilt binaries?
There is no difference between gcc and gnat-gpl.
>From what I see adacore take a snapshot of gcc and make its own changes to
add ada supports.
So gnat-gpl needs a gnat compiler to be built, like vanilla gcc does.

>From my research on internet adacore "guarantees" that the compiler can be
built with itself or a version "-1" of it. Normally any version of a gnat
compiler that is enough near can build it, but, without any big work, I don't 
expect that either gcc or gnat-gpl can be built with other non gcc/gnat Ada 
compilers.
I have read of gcc ada compilers built on several platforms using cross
compilation. Maybe those could be used, like suggested in
https://bugs.gentoo.org/show_bug.cgi?id=592060
However I am for adding the boostrap via the binary provided by adacore
only, via gnat-gpl-bin packages. At least for the beginning.

> 
> > I would like to start including, in the gentoo tree, GNAT-GPL
> > built in the same way as sys-devel-gcc and selectable with gcc-config
> 
> 1. Does this mean that GNAT-GPL build will include building a C
> compiler? If yes, will the C compiler be installed?
Yes, a C and a C++ compiler, and they will be installed
> 
> 2. Will it be possible to combine GNAT-GPL with a different version of
> regular gcc C/C++ compilers?
No, not easily
> 
> > As for instance gnat-gpl-2014 is based on gcc-4.7.4 they cannot coexist
> > and gnat-gpl-2014 will block sys-devel/gcc-4.7.4
> 
> Block the whole sys-devel/ or just sys-devel/gcc[ada]?
Block the whole sys-devel/gcc-4.7.4
> 
> > As a reference I have my overlay on https://github.com/atupone/overlay
> > and a pull request at https://github.com/gentoo/gentoo/pull/3186
> > 
> > To start I need to change the toolchain.eclass 
> > 
> > -   tc_version_is_at_least 4.7 && IUSE+=" go"
> > +   tc_version_is_at_least 4.7 && IUSE+=" go ada"
> > 
> > -   # We do NOT want 'ADA support' in here!
> > -   # is_ada && GCC_LANG+=",ada"
> > +   # We do want 'ADA support' here!
> > +   is_ada && GCC_LANG+=",ada" 
> > 
> > -   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
> > +   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo gnatbind; do 
> > 
> > Thats all for that.
> > 
> > Then, to not change the behaviour of the gcc-compiler, we could mask the
> > ada use flag for sys-devel/gcc, at least temporarily
> > 
> > -
> > 
> > I would like to have comments on that, particularly because:
> > a) it is going to add a use flag to sys-devel/gcc that will bring gcc
> > to be rebuilt on most system, 
> 
> That's a minor problem. Toolchain people do this on us all the time,
> so...
> 
> > b) the gnat-gpl, if selected with gcc-config, can be used to recompile
> > all the system, and maybe is not so good ?
> 
> I don't really understand what you mean here. But it's probably related
> to the questions I asked above.
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>





[gentoo-dev] Changes in toolchain.eclass to enable Ada

2016-12-21 Thread Alfredo Tupone
I would like to revive the Ada support in gentoo.

One ada compiler is produced by AdaCore and is provided in three
versions, in the order starting from the best supported :

1) GnatPro, available with a contract support.

2) Gnat-GPL that can only build GPL-3 product

3) The gnat included in the gcc tree that is GPL-3 with exception.

Gnat-GPL is very like the gnat in the gcc-tree so it can be built in
the same way of sys-devel/gcc

To be compiled from source the gcc compiler needs a C, C++, and Ada
Compiler. I will provide one with the gnat-gpl-bin tar that could be
installed under /opt . When the gcc is properly compiled we don't need
it any more.

I would like to start including, in the gentoo tree, GNAT-GPL
built in the same way as sys-devel-gcc and selectable with gcc-config

As for instance gnat-gpl-2014 is based on gcc-4.7.4 they cannot coexist
and gnat-gpl-2014 will block sys-devel/gcc-4.7.4

As a reference I have my overlay on https://github.com/atupone/overlay
and a pull request at https://github.com/gentoo/gentoo/pull/3186

To start I need to change the toolchain.eclass 

-   tc_version_is_at_least 4.7 && IUSE+=" go"
+   tc_version_is_at_least 4.7 && IUSE+=" go ada"

-   # We do NOT want 'ADA support' in here!
-   # is_ada && GCC_LANG+=",ada"
+   # We do want 'ADA support' here!
+   is_ada && GCC_LANG+=",ada" 

-   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do
+   for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo gnatbind; do 

Thats all for that.

Then, to not change the behaviour of the gcc-compiler, we could mask the
ada use flag for sys-devel/gcc, at least temporarily

-

I would like to have comments on that, particularly because:
a) it is going to add a use flag to sys-devel/gcc that will bring gcc
to be rebuilt on most system, 
b) the gnat-gpl, if selected with gcc-config, can be used to recompile
all the system, and maybe is not so good ?

Alfredo



Re: [gentoo-dev] Ada project needs your help!

2016-12-17 Thread Alfredo Tupone
Il giorno Sun, 11 Dec 2016 16:59:50 +0100
Michał Górny  ha scritto:

> Hello, everyone.
> 
> The Ada project seriously needs help. For some time already, it has no
> active developers (George is retiring), and a lot of bugs needing
> attention.
> 
> The packages maintained by aga@g.o are:
> 
> app-eselect/eselect-gnat
> dev-ada/asis-gcc
> dev-ada/charles
> dev-lang/gnat-gcc
> virtual/ada
> virtual/gnat
> 
> Since the Ada subsystem in Gentoo is practically unmaintained now
> and has only those two packages, the alternative is to lastrite it
> all.
> 
> Is anyone interested in Ada? Any comments?
> 

If nobody is interested in ada as it is, I would like to bring back it
in a new way, more simple and more in line with gcc

An example is https://github.com/atupone/overlay. 

As it is using the same tools of sys-devel/gcc and provide another gcc.
It is going to conflict with gcc-same-version.

My github overlay is not yet gentoo-ready but I use it regularly

Alfredo



[gentoo-dev] eutils.class fix for make_desktop_entry

2006-06-04 Thread Alfredo Tupone
I need to add a desktop entry that call an executable with arguments.
Actually the entry Exec (that could contain the executable with
parameters) and the entry TryExec (used to test if the executable is
installed) are set to the same value.
I wonder if I can fix that with the following patch to the eutils eclass
@@ -900,7 +902,7 @@
 Type=Application
 Comment=${DESCRIPTION}
 Exec=${exec}
-TryExec=${exec}
+TryExec=${exec%% *}
 Path=${path}
 Icon=${icon}
 Categories=Application;${type};  ${desktop}

I meant: is there some ebuild that has space in the executable name, or
is there some way this change can break ebuilds. eutils is used by lot
of them, so I'm scared to break the whole tree.

Going to apply if I get no negative answer in, say, 10 days.

Alfredo

-- 
gentoo-dev@gentoo.org mailing list