Re: [gentoo-dev] Proposal for changes for the next EAPI version
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?
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
On Sun, May 13, 2012 at 9:14 AM, Jeroen Roovers wrote: > On Fri, 11 May 2012 16:19:33 -0700 > Sébastien Fabbro 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
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
Gaurav Saxena 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
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
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
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
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
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
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
-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] ICC Profile
-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] why not player/stage/gazebo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > On Sat, May 17, 2008 at 2:37 PM, Zhu Sha Zang > <[EMAIL PROTECTED]> wrote: > > 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
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
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
-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
[gentoo-dev] Last rites: some sci-mathematics packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
The sci-mathematics herd (markusle and me) intends to remove from the
tree the following packages we can't maintain:
1) Removal in 7 days (already masked 2 years ago)
sci-mathematics/gturing: unmaintained upstream since 2002
Replacements: unknown.
sci-mathematics/mupad: now commercial and $$
Replacements: maxima, yacas, mathomatic
2) Masked for removal in 30 days:
sci-mathematics/kalamaris: unmaintained upstream since 2004.
Replacements: maxima, yacas, mathomatic
sci-mathematics/pariguide: unmaintained since 2002
Replacements: unknown
sci-mathematics/ksimus-{boolean,datarecorder,floatingpoint}:
unmaintained upstream since 2003, see bug #157577
Replacements: unknown
Best,
- --
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHfibx1ycZbhPLE2ARAnLzAJ9rTkfM2ab9GhdNm8ZpKkRGxz+GswCdG9N+
TpmeqBFgtX+ibW6tODlIwtA=
=c0Ca
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Langer wrote: > On Fri, 2007-12-14 at 16:16 +0000, 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// 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 sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild
-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
-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.1&view=markup >>> plain: >>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1&content-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 dev-lang/ifc: metadata.xml ChangeLog ifc-10.0.026.ebuild
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
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
-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)
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
