Re: [gentoo-dev] Proposal for changes for the next EAPI version

2016-05-17 Thread Sébastien Fabbro
On 17 May 2016 at 08:34, Luis Ressel  wrote:

>
> Automated post-merge tests sound kinda dangerous to me. And I don't
> think there's any stipulation about src_test() only running
> upstream-provided test suites. IMHO, src_test() would be a good place
> for most of the maintainter-provided tests you have in mind.
>

The idea of this project is not for a typical Gentoo user to run this
post-merge test, but for an automated arch-tester bot to run them in
batch jobs. The result of which would be an update of the ebuild to
stable.
Basically CI for ebuilds: it could be implemented as a script living
in the package directory, something like a .travis.yml in the GitHub
repositories or may be an EAPI change. Debian has a similar project
[1]. Upstream could provide CI tests and sometimes they do, but we
want to make sure the package integrates well in an installed Gentoo
distribution.

 [1] https://ci.debian.net/doc/

Sebastien



Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?

2012-05-31 Thread Sébastien Fabbro
Michał Górny wrote:

 
 There is a number of virtuals in Gentoo which switching active
 implementation via eselect. However, most of the packages being
 'alternative providers' don't seem to care about eselect at all. Is
 that the correct thing to do, or maybe should every package ensure
 that after its removal another implementation is eselected
 (or a cleanup is done)?
 

we have been using for quite a while now the alternatives-2 eclass in
the science overlay for many virtual packages. the nice thing about it
apart from implementing the issues you raised is we do not have to
write a new eselect package for the virtual.

sebastien


signature.asc
Description: PGP signature


Re: [gentoo-dev] intel (icc,mkl...) packages looking for new maintainer

2012-05-14 Thread Sébastien Fabbro
On Sun, May 13, 2012 at 9:14 AM, Jeroen Roovers j...@gentoo.org wrote:
 On Fri, 11 May 2012 16:19:33 -0700
 Sébastien Fabbro bicat...@gentoo.org wrote:

 dev-lang/icc
 dev-lang/ifc

 they have up-to-date versions in the science overlay.

 Do these up-to-date ebuilds fix the Macrovision bug[1]? Do we even have
 a proper workaround for the sandbox violation that doesn't involve
 disabling the sandbox?

unfortunately they do not. this bug is indeed quite annoying i have no
easy solution. this is even more annoying for x86* users with
USE=-fortran who might need to pull a fortran compiler to build lapack
as a dependency of a package, and since it depends on virtual/fortran,
dev-lang/ifc will be chosen.

-- 
sébastien



[gentoo-dev] intel (icc,mkl...) packages looking for new maintainer

2012-05-11 Thread Sébastien Fabbro
the following  intel packages need new maintainers:

dev-cpp/tbb
dev-lang/icc
dev-lang/ifc
dev-lang/idb
sci-libs/mkl
sci-libs/ipp

some of them are listed as me as maintainer, others as sci herd, but i
was mostly the one maintaining them.
they have up-to-date versions in the science overlay.

email me if you are interested (proxy-maintainers also welcome).

-- 
sébastien



Re: [gentoo-dev] Six month major project on Gentoo

2011-12-19 Thread Sébastien Fabbro
Gaurav Saxena grvsaxena...@gmail.com wrote:

 I am interested in doing my final year computer scence project on gentoo. I
 would be having a duration of six months to work on the project. Could you
 please suggest me some good project ideas that would be helpful to me as
 well as gentoo. I am interested in parallel computing, data structures ,
 operating system. I am well versed in C/C++. I think  there might be
 projects which need to be done, I would like to work on them.


One project that could be very useful for Gentoo is an automated
stabilization/testing for ebuilds. Obviously it will require some work
from the ebuild maintainers, but the ability to distribute the
stabilization recipes across a volunteering Gentoo community via
something like BOINC could be worth looking at.

-- 
Sébastien



[gentoo-dev] scilab in gentoo

2010-06-18 Thread Sébastien Fabbro
folks,

we are desperately looking for a sci-mathematics/scilab dedicated
maintainer. none of us in the sci teams have the time for it. 

i did some work for a major bump in the science overlay, but it depends
on many java packages, some of them in the java-experimental overlay.
it has also some bugs and is one of the most voted bump. the good thing
is that upstream is responsive and maintains the debian package.

thanks,

--
sebastien



Re: [gentoo-dev] [RFC]: Proxy-maintainer project

2010-03-18 Thread Sébastien Fabbro
On Thursday 18 March, Markos Chandras wrote:

 1) Should we use a new overlay? A new branch on sunrise? or work
 ebuilds in Gentoo bugzilla?I think the latter is the best
 2) I think an email alias is not needed We can monitor
 maintainer-wanted/- needed alias if needed. What do you think?
 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get
 informed that the specific bug is already taking by another developer
 and that somebody is working on it. So marking a bug with a keyword
 e.g. PROXY might be useful.

0) Switch portage cvs tree to multiple git ones.

Sebastien



Re: [gentoo-dev] redistribute intel rpms

2009-11-13 Thread Sébastien Fabbro
On Thursday 12 November, Robin H. Johnson wrote:

   Thus, we need to review the any specific restrictions which may
   appear in the Redistributables text files for problems as well.
  The Redistributables seem a bit different in Intel sense, see my
  post in [1]. I also put the redist file in [2].
 Can you make a list of files in the giant tarball aren't included in
 the credist.txt list?

I put a list in [1] of the files we are thinking of splitting from the
tar balls. We could go further and split the rpms, but it should be
enough to get us working.

[1] http://dev.gentoo.org/~bicatali/intel-distrib.list

--
Sebastien




Re: [gentoo-dev] Re: redistribute intel rpms

2009-11-11 Thread Sébastien Fabbro
On Sat, 7 Nov 2009, Duncan wrote:

 The big combo tarball could then be restrict=mirror or whatever, with
 or without a specific user click-thru (and restrict=interactive or
 whatever) as necessary and already used on some packages, following
 existing policies.
 
 Of course, there's certainly the complexity of automating the tarball 
 unpack of only the specific needed components, but gentoo/kde has a 
 **LOT** of experience with that sort of thing by now, and I'm sure
 they'd be happy to share hints and helpful tactical strategies with
 you, if you ask, and there's no way I can conceive it being even half
 as dependency convoluted as kde4 was to figure out, so it should be
 FAR easier.

To make myself clearer, the tar ball includes a few binary rpms and a
installer blob. Both icc and ifc tar ball include the mkl, idb and some
common library rpms. If we go for a kde-split with a mirror
restrict approach, users would still have to download the big (~800Mb)
tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb)
intel software would benefit of downloading them. It is also the fact
Intel has a history of changing their packaging system. Not to
mention that a rpm split seems to me lot simpler to maintain and
quicker to package for me than the kde-split mirror-restricted approach,
and the fact my interest for these packages is limited.

--
Sébastien



Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding

2009-03-30 Thread Sébastien Fabbro
On Monday March 30 Ciaran McCreesh wrote:

 It, along with the half dozen other variants floating around, are good
 starting points, but we need a final solution.
 

Yet another one: how about building/installing the documentation into
two separate functions doc_compile and doc_install? 

It's a bit of overtuning, but it could allow features such
re-installing package with switching the doc flag without
the need of re-compiling everything, and trivialize the src_install.

Going further, we could even define a USE-like variable such as
DOC, with a limited spectrum of values e.g. api examples html pdf.

-- 
Sébastien


signature.asc
Description: PGP signature


Re: [gentoo-dev] Ideas for a (fast) EAPI=3

2009-03-10 Thread Sébastien Fabbro
On Monday March 09 Ciaran McCreesh wrote:
 
 * src_test run unless RESTRICTed or explicitly disabled by the user
 (bug 184812)

Yes, and I would go even further: keep src_test for unit tests and
some kind of pkg_posttest for either a routine to test the package
once installed or an elog test recipe, a bit like the emacs testing
plans. It could be useful for arch testers, guis, and revdep tests.
It would force packagers to define an omitted src_test when upstream
actually had one.
 
As mentioned by Christian, src_test is desirable in sci
packages to get consistent results, but sci packages depend on lots of
others, so you can't limit tests to some categories. And yes, you can't
revdep test everything, but you can reduce bug load.

It seems to be controversial, so unfortunately does not look like a good
candidate for a flash EAPI upgrade. But really, don't dismiss it just
because your pet package doesn't pass tests or it takes too long. One
solution for packages taking too long to compile is not dismissing
tests but a good binary package system.

-- 
Sébastien


signature.asc
Description: PGP signature


Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apologies if you received this mail already, I'm having problems with my
smtp.

On Thursday July 17 Adam Stylinski wrote:

 The intel C Compiler (icc) has an ebuild for gentoo and the wiki has
 a script to integrate it with portage.  This script works will in
 terms of building binaries, however when mixed with gcc environments
 there are massive linking issues.  I propose that an ICC profile is
 made which contains specific versions and default flags for people
 who want to build a mixed icc-gcc environment.  ICC is much faster
 than GCC and although not free, offers a free non-commercial
 license.  I would be very interested in this project and more than
 willing to help to the best of my abilities.  I've already been
 trying to maintain a mixed environment with some luck, while there
 have been a lot of problems using dynamically linked libraries (ld
 from intel and ld from gcc don't always get along), my system is
 substatially faster.  The kernel obviously will still be built under
 gcc as well as bash (unless intel helps submit patches to make the
 code work with their compiler).  There are many tools icc ! has to
 offer for vectorization.  If these were streamlined into Gentoo with
 a fetch restriction for ICC, a bootsrapping boot disk could be made
 and result in a very fast distribution. 


An icc profile would be welcome. I've been the maintainer of icc (and
other Intel tools) for the last year or so more by default than
real interest. I would welcome any input from the Gentoo community.
Re-adding slots and an icc profile was on my mind, but never found the
time to invest in it, and got at the tail of my priority list. So don't
hesitate to contact me (email, irc, bugs) and others.

There was some attempts a few years ago for rolling up a full Gentoo
with icc, but it hit several problems if I recall. Now both icc and gcc
have improved since then.

Also, if you haven't already, check also some of the old bugs [1,2] we
have, and a recurring one [3].

I would like to recall one important issue with the Intel license
concerning the free for non-commercial use [4]. It means
you can't use it for free if you're paid to use it. Yes,
beer is not free for academic scientists too.

[1] http://bugs.gentoo.org/show_bug.cgi?id=26757
[2] http://bugs.gentoo.org/show_bug.cgi?id=53808
[3] http://bugs.gentoo.org/show_bug.cgi?id=201596
[4] http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm#0

- - -- 
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiApboACgkQ1ycZbhPLE2BMHgCggfzfS4SakVyw42r+JnnxYNpL
E9gAoJvRrocinIDlInF6kbeSGF2kvX9t
=M4XK
-END PGP SIGNATURE-


Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Thursday July 17, Adam Stylinski wrote:

 Pro's:
 
 1.) Bloody fast machine code.  Intel obfuscates their architecture
 but they give back to the community as much as possible to make their
 hardware marketable toward the open source sysadmin, developer, etc
 etc.  Their drivers are open and they develop for the kernel
 constantly.  This cooperation leads me to believe that they would
 assist a team of developers in making 100% icc compatible code.  

Gentoo is not supported from Intel, and they had not plans doing so. As
of October 2007, I asked their Software channel whether Gentoo
users have similar support as RedHat or SUSE users and the answer was:

No, we have no current plans to support Gentoo. Also, Gentoo is NOT a
derivative of a Linux we do support.  My understanding is that it is
independently derived from Kernel.org.  Thus it is less likely to work
than a distro which is a derivative of a supported distribution.

Meanwhile, Debian/Ubuntu got support, so things might change if
Gentoo re-becomes/remains popular. Any Intel dev reading this list,
please contact us.

And as Luca mentioned, having sunstudio, xlc (is this one free?) or llvm
would not make Intel a privileged case for Gentoo.


 2.) Bloody fast compilation time.  In my experience the compiler
 works much faster even with heavy optimization.  

I don't experience this that much, but I really don't use it much
either. Would be nice to have benchmarks here.

 
 4.) will project gentoo toward the power user more, helps the gentoo
 image, and overall will make linux a more professional operating
 system (and a quite competitive alternative to something like a
 SPARC+Solaris configuration).  This would also make cluster farms and
 science application more respectful toward the gentoo community.  The
 academic and research world already uses ICC to compile their apps
 for the sake of speed.  The interprocedural optimizations for both
 the fortran and c/c++ compilers make it a must.  

I would be careful about this, and this needs benchmarks, especially
with gcc  4.3. By default icc flags are fairly agressive. For example,
for many scientific applications, you don't want a simple -O2 where you
loose floating point precision. Add -mp or -mp1 to your icc flags, add
some decent gcc flags, and improvement over gcc is much smaller.
 
 5.) It's free, albeit a commercial product.  As gentoo is entirely
 non-profit, there is no restriction when it comes to licensing.  The
 binaries won't be sold for the intel-compiled livecd, and the
 compiler itself with a fetch restriction allows the user to legally
 register for their free non-commercial license.

Again, as long as you're not being compensated for doing it (for Gentoo
I'm not).

In summary, I'm completely in favor of trying projects like this, but
first, this needs a few benchmarks before going further.


- -- 
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiApcoACgkQ1ycZbhPLE2C0TQCfYLD2+mazHKjosK7wiHFU6FGb
d3EAnR1FWZ92O2B9xBJerCj4dj2GRUZ4
=YhT2
-END PGP SIGNATURE-
���^�X�����(��j)b�b�

Re: [gentoo-dev] why not player/stage/gazebo

2008-05-17 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 On Sat, May 17, 2008 at 2:37 PM, Zhu Sha Zang
 [EMAIL PROTECTED] wrote: snip
  Ok, show me the path to be a gentoo's developer.
 
  Maybe i can do it now.

0. Participate in improving the player [1], stage [2], and gazebo [3]
ebuilds.

[1] http://bugs.gentoo.org/show_bug.cgi?id=26373
[2] http://bugs.gentoo.org/show_bug.cgi?id=185298
[3] http://bugs.gentoo.org/show_bug.cgi?id=185470

Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgutW0ACgkQ1ycZbhPLE2ABHgCbBfAx4QiGaM4YIa03DCshLUg9
E2IAnjO6pltg+hv+JXjoe2GkoTROrWMl
=ifox
-END PGP SIGNATURE-
���^�X�����(��j)b�b�

[gentoo-dev] Removal of icc and ifc global use flags

2008-04-26 Thread Sébastien Fabbro
Hi,

I am planning to remove the icc and ifc global use flags [1]. The idea
is to avoid specific compilers as use flags.

Only two packages have the use flags, sci-libs/acml and dev-lang/idb.
They are binary packages which specifically depend on either of the
Intel compilers, and I will switch the flags to local ones.


[1] http://bugs.gentoo.org/show_bug.cgi?id=97929

--
Sébastien


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


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-06 Thread Sébastien Fabbro
On Wed, 5 Mar 2008, Anant Narayanan [EMAIL PROTECTED] wrote:
 
 If it's not too late for this month's meeting, I'd like to discuss
 the possibility of including a new post in our developer base -
 the package maintainer.
 

The idea is interesting. We have been thinking about something similar
in the sci team. We are already maintaining some packages we don't know
how to test. We also don't particularly like the idea of getting
scientific results based on untested software.

The overlays are not a solution. Packages in the overlays do not
go through keywording or stabilisation processes, do not get all the
publicity, and don't have bug support as advanced as the ones in the
main tree.

In all the sci* herds, we have more than 180 requests for new
packages only in bugzilla. Our active team is small and overloaded with
already more than 430 packages to maintain. Many other teams are facing
the same issue. We have contacted some talented ebuild submitters who
neither want to spend the time nor feel the responsibility of a full
dev. A formal proxy-maintainer could really help in our sometimes blind
maintaining duties.

--
Sébastien


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: some sci-mathematics packages

2008-01-05 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Cloos wrote:

 Sébastien sci-mathematics/pariguide: unmaintained since 2002
 
 Is there anything actually wrong with this one?
 
 I don't see any bugs open on it, and it works fine here.
 
 Dropping packages just because they are stable is rather questionable.

Not stable on all arches, and ebuild would need some work. Sorry, not
enough time/manpower to take care of packages unmaintained upstream.

The pari resources page mentions mathguide as a pariguide successor from
the same author. Haven't looked at it yet (and all the doc is in German).

- --
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHf6jd1ycZbhPLE2ARAsqmAJ4gud6c/cZrzLFAn5SBxp1P4wkSYQCglVS6
wXyu0f1Z3qb8jvy++avwLKo=
=vmKh
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

2007-12-14 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/12/07 10:24, Matthias Langer wrote:
 On 02:10 Thu 13 Dec , Justin Bronder (jsbronder) wrote:
 1.1  sys-cluster/openmpi/openmpi-1.2.4.ebuild

 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1content-type=text/plain
 
 Why have you removed the ifc USE flag (as well as a few others), that
 was present in the ebuilds that can still be found at bug 166787?

For icc and  f90-typesafe, I advised him to do so on #gentoo-science.

ifc/icc use flags should be avoided (see bug #97929).
Disabling f90-typesafe did not make much sense as a use flag once you
have the fortran one enabled, but why --with-mpi-f90-size=medium
and --with-f90-max-array-dim=4 disappeared I don't know.

For the gm and gx flags, I don't know, and there is still a nocxx one.

- --
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYnNi1ycZbhPLE2ARAq10AKCtnkZMWBkws7lD90bNAziSc4XJ3wCgiDD4
T5oOmc65RMnjswIBlHHh3Yg=
=VcUX
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

2007-12-14 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/12/07 14:12, Matthias Langer wrote:

 F77=ifort FC=ifort FFLAGS=-O3 -xO emerge -av openmpi

This how it should be. To make it automatically reproducible, specify
environment variables in the configuration files.

 Maybe someone can explain to me what positive side effects the removal
 of the ifc USE flag has - and why this flag is generally discouraged.

Positive side effect: avoid cluttering the tree. Why icc/ifc are
discouraged: you can always try to compile every C/C++ package with
CC=icc and fortran packages with F77=ifort or FC=ifort. Packages which
do specify more options with e.g. --enable-icc and friends can be easily
worked out with the toolchain-funcs and fortran eclass, and most of the
time they do nothing more than specify the environment variables.

If we allow icc/ifc flags, at some point, we could allow a whole bunch
of other compiler flags such as sunstudio. New keywords for compilers
could be a better idea, but I doubt we have the human resources to test
them.

 The reason it disappeared is that it makes gfortran horribly slow when
 compiling against mpi. This is not the case with ifc, and therefore the
 old ebuild in bugzilla emitted a bold warning when emerging with
 USE=-ifc f90-typesafe but kept quiet if USE=ifc f90-typesave. Thus
 it *did make sense* to control it with a USE flag, at least with the
 ifc USE flag being around also.

If the f90-typesafe options always improve compilation time with
gfortran only,  why not using something like this (modified from the
openmpi bump bug):

if use fortran; then
case ${FORTRANC} in
g77) myconf=${myconf} --disable-mpi-f90 ;;
gfortran) myconf=${myconf} --with-mpi-f90-size=medium 

myconf=${myconf} --with-f90-max-array-dim=4 ;;
if*) myconf=${myconf} blah ;;
*) die unsupported fortran compiler: ${FORTRANC}
esac
else
myconf=${myconf} --disable-mpi-f90 --disable-mpi-f77
fi

Let the ebuild make reasonable choices instead of making a user trying
to find out about undocumented use flags.

- --
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYqxv1ycZbhPLE2ARAlRRAJ9BySHhbxAzLOgJdG4I2L3RpCPPNwCgi8aF
v3OgmxW4UZj1Gqf7Pg2vBWE=
=vYF+
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild

2007-12-14 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Langer wrote:
 On Fri, 2007-12-14 at 16:16 +, Sébastien Fabbro wrote:
 F77=ifort FC=ifort FFLAGS=-O3 -xO emerge -av openmpi
 This how it should be. To make it automatically reproducible, specify
 environment variables in the configuration files.
 
 Hmm, i know this isn't a support list, but as it fits quite well: can
 you tell me what configuration files I have to look for?

At some point, one possibility was to create a
/etc/portage/env/cat/package file with your own set of environment
variables in it. But I have not checked lately if we can still do this.

- --
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYt7j1ycZbhPLE2ARAj4YAKCl2ONWLpnEoE71ntWfUlTTh8kmqwCgjQXV
o9lmFEUHuZpVofae23MeL3M=
=Sd/I
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/ifc: metadata.xml ChangeLog ifc-10.0.026.ebuild

2007-10-02 Thread Sébastien Fabbro
On Mon, 2007-10-01 at 16:06 -0700, Donnie Berkholz wrote:
 On 19:16 Mon 01 Oct , Sébastien Fabbro wrote:
  On Sun, 2007-09-30 at 13:53 -0700, Donnie Berkholz wrote:
1.1  dev-lang/ifc/ifc-10.0.026.ebuild
  
INSTALL_DIR=/opt/intel/${PB}${ext}/${PV}

if use debugger  [[ ! -x /opt/intel/idb${ext}/${PV}/bin/idb 
]]; then
INSTALL_IDB_DIR=/opt/intel/idb${ext}/${PV}
else
use debugger  einfo Debugger already installed
rm -f data/intel*idb*.rpm
fi
   
   Could you explain what this is doing? Does some other package (icc?) 
   also install the debugger? Perhaps it should get split off into a 
   separate package.
  
  Yes, icc can install the same debugger. I thought about splitting idb in
  another package but it would need either the ifc or the icc tar ball. I
  thought the or was not supported in SRC_URI/unpack. Forcing the tar
  ball of icc would force the ifc users to download icc one (at least
  40Mb) when not necessary, and vice-versa. There are probably solutions
  to this problem, but I could not think of a simple one. Any suggestion
  welcome.
 
 As kind of a hack solution, the idb package could have icc/ifc USE flags 
 to pick which tarball it used.

I have been trying to avoid the icc/ifc use flags as much as possible,
in preference for things like [[ $(tc-getCC) = icc ]] but in that case
it would make sense.

Thanks.

Sébastien



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


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/ifc: metadata.xml ChangeLog ifc-10.0.026.ebuild

2007-10-01 Thread Sébastien Fabbro
On Sun, 2007-09-30 at 13:53 -0700, Donnie Berkholz wrote:
  1.1  dev-lang/ifc/ifc-10.0.026.ebuild

  INSTALL_DIR=/opt/intel/${PB}${ext}/${PV}
  
  if use debugger  [[ ! -x /opt/intel/idb${ext}/${PV}/bin/idb ]]; then
  INSTALL_IDB_DIR=/opt/intel/idb${ext}/${PV}
  else
  use debugger  einfo Debugger already installed
  rm -f data/intel*idb*.rpm
  fi
 
 Could you explain what this is doing? Does some other package (icc?) 
 also install the debugger? Perhaps it should get split off into a 
 separate package.

Yes, icc can install the same debugger. I thought about splitting idb in
another package but it would need either the ifc or the icc tar ball. I
thought the or was not supported in SRC_URI/unpack. Forcing the tar
ball of icc would force the ifc users to download icc one (at least
40Mb) when not necessary, and vice-versa. There are probably solutions
to this problem, but I could not think of a simple one. Any suggestion
welcome.

Sébastien



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


[gentoo-dev] intel packages support

2007-08-30 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am in the process of testing updates of dev-lang/icc dev-lang/icc and
sci-libs/mkl on the tree. Right now, I just put an update of these
packages together with sci-libs/ipp in the gentooscience overlay.

The Linux versions of a bunch of Intel products come with non-commercial
licenses [1], but this license is quite restrictive [2]. So before I
carry on more testing and push them to the tree, I would like feed-back
on the following points.

- - I've seen various mentions or bugs request to remove Intel products
from the tree. Are we willing to keep these packages?
Keeping up with updates and bugs is not trivial mainly because upstream
always changes packaging style and are large packages (sometimes 300Mb)

- - do you see a need, or significant performance increases with the
compilers? Up to gcc/gfortran-4.2, ifc was the only complete FORTRAN-95
compiler in portage, so there was a definite need among the scientific
community.

- - in the past, they were fetch-restricted. I don't really see why in the
documents I've read mirror-restricted should not be enough.

Obviously anyone willing to help on the process is welcome.

Regards,

- --
Sébastien

[1] http://www.intel.com/cd/software/products/asmo-na/eng/340679.htm
[2] http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm


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

iD8DBQFG1uC41ycZbhPLE2ARAlRnAJ94enzEM6mcf4o22WLW9q3JO/T5KwCdHKs4
vTKxHAGfXQQACXdkAWLhUK4=
=tFfH
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New developer: Sebastien Fabbro (bicatali)

2007-02-03 Thread Sébastien Fabbro
Thanks for the welcome!

 Gastronomy or astronomy? I'm confused ;)

It's nice to switch. The sky has more than 3 stars ;)

 If you're a cosmology researcher, does that mean that you like astronomy
 photography?

I admire it more than I can do.

Sébastien

On Friday 02 February 2007 10:49, Marcus D. Hanwell wrote:
 It is my pleasure to introduce Sebastien Fabbro (also known as bicatali) to
 you as the latest addition to the Gentoo scientific applications team. In
 his own words he is a French guy (don't worry - we won't hold that against
 you ;) ) living and working n Portugal.

 He is experienced with C, C++, Python and bash and so should fit in great
 around here. He also has some experience of autotools which always helps
 when working with some of the less well thought out build systems we seem
 to encounter in some scientific applications!

 He is a post-doctoral researcher in observational cosmology - I think that
 means he gets paid to stare up at the sky and tell us all how big it is.
 May be you could ask him to clarify, His interests include gastronomy,
 outdoor activities and programming.

 He has plenty of Gentoo experience having already acted as a herd tester
 since the inception of the herd tester programme. He administers a small
 LAN of Gentoo machines on their network at work and has already been very
 helpful for the scientific applications herd. Thanks also go to Kugelfang
 for sorting out his developer bug ;)

 I hope you will all join me in welcoming Sebastien as a fellow developer.

 Thanks,

 Marcus

-- 
gentoo-dev@gentoo.org mailing list