[gentoo-dev] github <> g.o.g.o
Hi all, is there a way to do a way or two way sync between a repo on github and on g.o.g.o? I have the felling that I heard of an official overlay which is operated like this. Could someone please point me to this overlay and the technique? thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] github <> g.o.g.o
On 25/02/12 16:11, Alex Alexander wrote: > On Sat, Feb 25, 2012 at 01:55:37PM +0100, Justin wrote: >> Hi all, >> >> is there a way to do a way or two way sync between a repo on github and >> on g.o.g.o? >> >> I have the felling that I heard of an official overlay which is operated >> like this. Could someone please point me to this overlay and the technique? > > For every secondary repo you want to keep synced, add a pushurl entry > > pushurl = > > below your main "url =" line in the repo's .git/config file. > Git will automatically push to all pushurl entries automatically when > you "git push". > > We do this in the Qt overlay (with gitorious atm): > > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://git.overlays.gentoo.org/proj/qt.git > pushurl = g...@gitorious.org:gentoo-qt/qt.git > > Regards, Thanks, this works really nice. justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: License problem
Hi, I need some comments on following License Agreement: http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do QUOTE In downloading this code you agree with the following: I will not redistribute the software to others outside of my immediate research group. I will suggest to other interested research groups to contact the authors directly. I will not alter or suppress the run-time copyright message. I will acknowledge the program authors on any publication of scientific results based in part on use of the program and cite the article in which the program was described. I will report evidence of program bugs to the author. I will not extract part of the software, e.g. subroutines, for use in other contexts without permission of the author. /QUOTE The source file do not contain any further license statements. Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: License problem
On 21.03.2012 15:48, Ian Stakenvicius wrote: > On 21/03/12 10:34 AM, Richard Yao wrote: >> On 03/21/12 10:18, Justin wrote: >>> I will not extract part of the software, e.g. subroutines, for >>> use in other contexts without permission of the author. > >> Portage could be considered to be one of these contexts. > > > If the entire package is installed (ie, it's not broken up into > separate libraries or sub-packages) this would be fine (ie having the > package in portage), wouldn't it? > > I guess the primary restriction here would be that nothing else would > be allowed to link against any embedded libraries; ie, the package > couldn't be a dep. > It simply creates one binary which I am interested in. I don't see any problem if I use fetch restriction. The only remaining question would be the actual LICENSE? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 25/03/12 20:56, Krzysztof Pawlik wrote: > On 28/02/12 22:13, Krzysztof Pawlik wrote: >> If there are no objections then during the weekend (March 3, 4) I will add >> this >> to portage (after finishing remaining TODO items, PyPy requires 4G of >> RAM(!!)). > > Hello, > > Slightly late due to Real Life™ but finally it's in the main tree :) > > (and yes - I've tested it with pypy - works as expected :) > Hi, is there any documentation beside the man page somewhere? I tried to port some ebuilds but as soon I set PYTHON_COMPAT="python2_7 python2_6 python2_5 pypy1_8" inherit python-distutils-ng I get REQUIRED_USE: USE flag 'python_targets_python3_1' is not in IUSE Did I do something wrong, or is there something not straight in the eclass? Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 25/03/12 20:56, Krzysztof Pawlik wrote: > On 28/02/12 22:13, Krzysztof Pawlik wrote: >> If there are no objections then during the weekend (March 3, 4) I will add >> this >> to portage (after finishing remaining TODO items, PyPy requires 4G of >> RAM(!!)). > > Hello, > > Slightly late due to Real Life™ but finally it's in the main tree :) > > (and yes - I've tested it with pypy - works as expected :) > Hi, is it okay if I start fixing things for prefix? jusitn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ESCM_OFFLINE/ EVCS_OFFLINE env variable policy
On 31.03.2012 20:49, Alexander V Vershilov wrote: > Hello. > > It seems that in eclasses we have two differenct environment variables > with same meaning ESCM and EVCS OFFLINE. Some of eclasses use one and > some another: > > find . -type f | xargs grep -l EVCS_OFFLINE > ./git-2.eclass > ./bzr.eclass > > find . -type f | xargs grep -l ESCM_OFFLINE > ./darcs.eclass > ./cvs.eclass > ./mercurial.eclass > ./git.eclass > ./subversion.eclass > > It seems we should have some concusion about what env variable should > be used to prevent downloading of live repo. > > Thanks. > > -- > Alexander Vershilov > [2048R/5E05C6C2] Hi, I would vote for EVCS_OFFLINE as we already agreed in the dev-vcs discussion on vcs. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About maintaining sci-physics/abinit
On 03/04/12 00:11, Pacho Ramos wrote: > El lun, 19-03-2012 a las 10:22 +0100, Pacho Ramos escribió: >> Hello >> >> As talked some time ago with Donnie, sci-physics/abinit is hard to >> maintain and, then, he would like to lastrite it after moving package to >> sci overlay because looks like nobody from sci team wants to take it. >> >> If anybody is willing to help with maintaining abinit, could he take it? >> If not, could anybody with commit access to sci overlay to move abinit >> to it and let us lastrite it from main tree? >> >> Thanks a lot > > Maybe we could mask it for removal anyway as looks nobody wants to > maintain it and our current versions are really old :/ Oh I am sorry for not replying. We have a contributor who is doing a great job and maintains it in the sci overlay. As there is currently no active contribution from the developer teams site I would vote for removal and help Honza with his contributions outside the tree. justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: iotop needs to run as root after kernel change
Hi, after this change https://github.com/torvalds/linux/commit/1a51410abe7d0ee4b1d112780f46df87d3621043 iotop cannot be used as user anymore. Any suggestions how to proceed? The solution I see are 1. Leave it to root (Fedora and Suses way) 2. suid it (bad in my view) 3. file capabilities (can this be done with portage) Please comment and help me with the right proceeding. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change
On 04/04/12 14:56, Greg KH wrote: > On Wed, Apr 04, 2012 at 08:32:41AM +0200, justin wrote: >> Hi, >> >> after this change >> >> https://github.com/torvalds/linux/commit/1a51410abe7d0ee4b1d112780f46df87d3621043 >> >> iotop cannot be used as user anymore. >> Any suggestions how to proceed? >> >> The solution I see are >> >> 1. >> Leave it to root (Fedora and Suses way) > > Please leave it this way, the information leakage otherwise is too big > of a risk to do anything else. > > greg k-h > Thanks for all your responses. I will follow what was suggested by upstream and what is the best from my feelings and restrict it to be root only. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 23/05/12 14:42, Michael Weber wrote: > Hi, > > i've looked at the blockers of "[TRACKER] portage migration to git" > [1] and want to discuss "testing git-cvsserver" [2]. > > There are two proposed scenarios how to migrate the developers write > access to the portage tree. > > "Clean cut" turns of cvs access on a given and announced timestamp, I want to see to it gone. +1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 23.05.2012 18:47, Robin H. Johnson wrote: > On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: >> i've looked at the blockers of "[TRACKER] portage migration to git" >> [1] and want to discuss "testing git-cvsserver" [2]. >> >> There are two proposed scenarios how to migrate the developers write >> access to the portage tree. > The primary reasons to continue to support CVS-style access via > git-cvsserver: > 1. Lightweight partial/subtree checkouts >- Git has implemented subtree checkouts, but they still bring down a >fairly large packfile. > 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) > > If we can get rid of #2, we're willing to live with #1. > >> "Clean cut" turns of cvs access on a given and announced timestamp, >> rsync-generation/updates is suspended (no input -> no changes), some >> magic scripts prepare the git repo (according to [3], some hours >> duration) and we all checkout the tree (might be some funny massive load). > 1. You will be given git bundles instead of being allowed to do initial >clone. That way it's just a resumable HTTP download. > 2. rsync generation is NOT going away. Users will still be using it. > Was this a vote for or against a quick proceeding towards git? You are probably the one who can judge best if the infra side could be made ready soonish. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
On 30.05.2012 18:58, Aaron W. Swenson wrote: > On 05/30/2012 12:53 PM, Tobias Klausmann wrote: >> Hi! > >> On Wed, 30 May 2012, Rich Freeman wrote: >>> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman >>> wrote: >>>> Yeah... this is why I was asking about access to infra to test >>>> the conversion; so far, I haven't had any replies, though. >>> >>> A mock conversion would probably help with creating >>> procedures/docs/etc as well. It is nice to say that we're "just >>> going to use git" but I think everybody has a slightly different >>> picture of how that is going to work. > >> I recommend having a smallish set of willing alpha/beta testers >> for this. This usually helps with some of the near-edge cases. >> You'll still find a thousand other bugs once things go live for >> everybody. Still, it turns a million into a thousand. It also gives >> you slightly more realistic load test. Regards, Tobias > > > As one that's relatively new to Git, I'm a perfect candidate for > testing. If we go this way, I volunteer. > > - Aaron > As I am a hater of CVS and my current checkout is repeatability spiting weird errors, I would join as a tester here. justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles
Hi, these days still FFLAGS and FCFLAGS are unset by default. Any objections to to default to CFLAGS of the profile equally to CXXFLAGS? Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles
On 12.06.2012 21:30, Markos Chandras wrote: > On 06/12/2012 06:55 PM, Justin wrote: >> Hi, > >> these days still FFLAGS and FCFLAGS are unset by default. Any >> objections to to default to CFLAGS of the profile equally to >> CXXFLAGS? > > >> Thanks justin > > > This is the first time I see these variables. Where are they being used? > > They are compiler flags for fortran compiler. g77 used to use FFLAGS and implicit makerule for .f file use this one. FCFLAGS are used by gfortran and for newer dialects (see man make.conf). So in case you like to compile fortran code, even potentially you might want to have them set. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles
On 12.06.2012 19:55, Justin wrote: > Hi, > > these days still FFLAGS and FCFLAGS are unset by default. > Any objections to to default to CFLAGS of the profile equally to CXXFLAGS? > > > Thanks justin > Added. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About what would be included in EAPI5
On 16.06.2012 14:26, Pacho Ramos wrote: > El sáb, 16-06-2012 a las 14:12 +0200, Ulrich Mueller escribió: >>>>>>> On Sat, 16 Jun 2012, Pacho Ramos wrote: >> >>> I would like to know if there is some place where things going to be >>> included (or proposed to be included) for eapi5 are listed (if such >>> place exists). Currently, looks like there is no eapi5 tracker :-/ >> >> The PMS git repository has an eapi-5 development branch, and some >> parallel discussion took place in the gentoo-pms mailing list. >> >> So far we have: >> ╓ >> ║ EAPI 5 is EAPI 4 with the following changes: >> ║ >> ║ • econf adds --disable-silent-rules. >> ║ • Slot operator dependencies. >> ║ • src_test supports parallel tests. >> ║ • USE is calculated differently. >> ║ • IMAGE is gone. >> ║ • REQUIRED_USE now supports ?? groups. >> ║ • apply_user_patches function, with src_prepare changes. >> ║ • EBUILD_PHASE_FUNC. >> ║ • find is guaranteed to be GNU. >> ║ • new* can read from standard input. >> ╙ >> >> Ulrich >> >> > > OK, would you let me to create a tracker bug for eapi5 accepted item? > About suggesting new item (like forcing rebuilding of other packages as > discussed some days ago and crosscompile support suggested by Tommy > today), I guess we need to get them voted by the council? > > Thanks :) > At Fosdem Petteri talked about ideas for next EAPI, which brought up some discussions. Perhaps he or someone else who remembers could summarize the ideas. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17.06.2012 14:13, Maxim Koltsov wrote:
> Hi,
> During prefix bootstrap i noticed that strip-flags removes -L and -I
> flags from *FLAGS while these flags are essential for prefix
> bootstrapping. Therefore i propose a fix for strip-flags function to
Is this really necessary? I never experienced any problems which need
this when following the guides. I looks like a hack, because something
else is borked.
> make it preserve prefix-related flags. I have attached a patch, please
> review it. It works for me, but I'm unsure how it will work with
> spaces in ${EPREFIX}
Why not use "use prefix" instead of checking for the variable?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]flag-o-matic.eclass strip-flags change to support prefix
On 17.06.2012 15:23, Maxim Koltsov wrote: > 2012/6/17 Justin : >> On 17.06.2012 14:13, Maxim Koltsov wrote: >>> Hi, >>> During prefix bootstrap i noticed that strip-flags removes -L and -I >>> flags from *FLAGS while these flags are essential for prefix >>> bootstrapping. Therefore i propose a fix for strip-flags function to >> >> Is this really necessary? I never experienced any problems which need >> this when following the guides. I looks like a hack, because something >> else is borked. > > I've just hit binutils on OpenBSD not finding libdl.so installed in > $EPREFIX/usr/lib/ because of this. > Don't tell me that OpenBSD prefix is unsupported, i'm working on > getting it supported. > I am still not convinced. libdl.so is provided by glibc, at least on my linux system. And glibc is one of the rare packages which needs to be provided by the host system instead of being installed in the prefix. Is there something different on BSD which makes libdl.so appear inside the prefix? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My wishlist for EAPI 5
On 20.06.2012 22:35, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 16:25:30 -0400 > Richard Yao wrote: >> Multilib (and/or multiarch) support >> The current binaries cause a great deal of pain, particularly >> when a user does not want to upgrade something. I had this problem >> with WINE and glibc because I wanted to avoid the reverse memcpy() >> fiasco on my systems. This situation would have been avoided entirely >> if the package manager supported multilib. > > This one's unlikely to happen unless someone's prepared to put in the > work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My wishlist for EAPI 5
On 21/06/12 08:41, Ciaran McCreesh wrote: > On Wed, 20 Jun 2012 23:43:36 +0200 > Justin wrote: >> On 20.06.2012 22:35, Ciaran McCreesh wrote: >>> On Wed, 20 Jun 2012 16:25:30 -0400 >>> Richard Yao wrote: >>>> Multilib (and/or multiarch) support >>>>The current binaries cause a great deal of pain, >>>> particularly when a user does not want to upgrade something. I had >>>> this problem with WINE and glibc because I wanted to avoid the >>>> reverse memcpy() fiasco on my systems. This situation would have >>>> been avoided entirely if the package manager supported multilib. >>> >>> This one's unlikely to happen unless someone's prepared to put in >>> the work. >> >> Tommy worked a lot on this and he asked for help to bring his >> proposal/spec/glep into shape. >> We are all aware what this is all about and know that anybody who is >> using multilib would benefit. >> Can't you simply work with him together to get it into what you expect >> it to be instead of pointing out that it isn't? > > In order to do that, it would have to get to the stage where I > understood exactly what changes are needed and why. I'm not convinced > *anyone* understands that yet. > > Writing PMS patches, at least to the level that we can review them, is > only difficult if you don't know what you want changed or why. > He wants to deprecate the app-emulation/emul-linux-x86-* packages and build it if needed directly from "normal" ebuilds through the package manager. This was stated a couple of times and is not hard to understand, even without PMS patches, GLEPS and so. *anyone* understands that there are cases when the x86 libs are needed and every gentoo package maintainer should understand, that letting the user build their own x86 libs is what we want in ideal case. There is a working implementation as a branch of portage for some time now and people work on it. So two basic things are there, the need and the idea of a working solution. This also means, that people need to have an idea of what is real problem. (And if not, it was asked a couple of times for discussion) Won't it be a good thing, if you instead of showing all of us, that you can tell where people fail to present something in the right way, help and guide them to write the necessary things like PMS patches, GLEPs etc., so that we can proceed in an efficient way? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 15:21, Ciaran McCreesh wrote: > There's been a move towards using slots for "clever" things that don't > fit the traditional way of how slots worked. Examples include the new > gtk2 / gtk3 handling and Ruby gems virtuals. > > Aside from being abusive, this screws things up for Paludis users. > Paludis tends to bring in newer versions when possible (so that users > aren't stuck with an old GCC forever), and allows the user to select > when new slots are brought in. When suddenly a few packages are using > slots and versions to "mean" something other than what they used to, > this makes the feature unusable. > > Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES > value called "funky-slots", which should be set on every version of any > package that uses slots in an unconventional manner. This probably > doesn't need EAPI control, since package manglers are free to ignore > PROPERTIES tokens. It won't solve the abuse, but it will allow the > impact upon users to be lessened. > Did you read what you wrote and thought about what you request from others? Probably you better should. I can't see any good and more importantly, sufficient description of the problem. There is some vague hint, that paludis is not able to solve dependency chains correctly, but this is something I might got wrong from your mail. An example: "...slots and versions to "mean" something other than what they used to,..." is completely useless without a description of what SLOTS are about and how the should be used. And what is the wrong usage you can find; examples are necessary here for understanding. And your approach (a workaround called "funky-slots") to tackle this what-ever-the-problem-really is, doesn't fit to anything you want from others. To me, it doesn't solve the root cause, but actually I can't judge this, because I am missing a description of what is really going wrong. Don't behave in a way, which you disallow for others. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 18:17, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 18:13:23 +0200 > Justin wrote: >> Did you read what you wrote and thought about what you request from >> others? Probably you better should. > > Uh huh, and I think we all know there's a huge difference between > knowing what versions and slots are and knowing what "a multilib" is. > Might be right, but that doesn't allow you to break your own rules. Plus I still don't get the problem of using SLOTS in the way they are used now. And I can't find this out by simply googling. In contrast, an explanation of multilib in context of linux distribution and more specific gentoo can be found easily. But that's nothing I wanted to discuss here. Stop acting in this arrogant way you are doing right now. This doesn't make sympathetic in any way and heavily overshadows the technically skills you will have for sure. >> An example: >> >> "...slots and versions to "mean" something other than what they used >> to,..." >> >> is completely useless without a description of what SLOTS are about >> and how the should be used. And what is the wrong usage you can find; >> examples are necessary here for understanding. > > That's covered in the devmanual and in the user documentation, so > there's no need to repeat it here. Ever heard about references. They are good, if you don't like to repeat what is written, but which are necessary context to understand what you are writing. You should use them for the sake of understanding, if you are to lazy to write it out again. > >> To me, it doesn't solve the root cause, but actually I can't judge >> this, because I am missing a description of what is really going >> wrong. > > As I've already said, this isn't about solving the root cause. It's > about reducing the impact of damage that's already been done until the > root cause is solved properly. > My clear vote is No. We shouldn't implement anything which allows bad coding anywhere, just for the sake of having it "solved" now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 18:53, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 18:47:26 +0200 > Justin wrote: >> On 23.06.2012 18:17, Ciaran McCreesh wrote: >>> On Sat, 23 Jun 2012 18:13:23 +0200 >>> Justin wrote: >>>> Did you read what you wrote and thought about what you request from >>>> others? Probably you better should. >>> >>> Uh huh, and I think we all know there's a huge difference between >>> knowing what versions and slots are and knowing what "a multilib" >>> is. >>> >> >> Might be right, but that doesn't allow you to break your own rules. >> Plus I still don't get the problem of using SLOTS in the way they are >> used now. > > "My own rules" are that enough material is presented that the relevant > people understand it. If you look at simple proposals like usex, silent > rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for > very little in the way of text in cases where the change is easily > understood. > >> And I can't find this out by simply googling. In contrast, an >> explanation of multilib in context of linux distribution and more >> specific gentoo can be found easily. > > Oh really? I was under the impression that there wasn't even general > agreement upon whether or not multilib applied to "C" or to "C, and > Python, and things like it". > >> Stop acting in this arrogant way you are doing right now. > > Come on. Submitting a simple proposal with at least as much detail as > was provided for other, equally simple proposals is "arrogant" now? > >>> That's covered in the devmanual and in the user documentation, so >>> there's no need to repeat it here. >> >> Ever heard about references. They are good, if you don't like to >> repeat what is written, but which are necessary context to understand >> what you are writing. You should use them for the sake of >> understanding, if you are to lazy to write it out again. > > Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where > it references what "phase functions" are, or the proposal for usex and > say where it references what "use flags" are, or the proposal for > silent rules where it references what "econf" is. > >>>> To me, it doesn't solve the root cause, but actually I can't judge >>>> this, because I am missing a description of what is really going >>>> wrong. >>> >>> As I've already said, this isn't about solving the root cause. It's >>> about reducing the impact of damage that's already been done until >>> the root cause is solved properly. >> >> My clear vote is No. We shouldn't implement anything which allows bad >> coding anywhere, just for the sake of having it "solved" now. > > The bad coding has already happened. Are you volunteering to revert the > Ruby virtuals? > I give up. And actually I don't care anymore. When I saw the first people leaving this project, because of all this non social bitching, I thought by myself, this will never happen to me. But the amount of fruitful discussion here is so less compared to the shire amount crap coming through, that it is not worth following it. justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: intel-sdp.eclass (new eclass to handle intels compiler suites and libraries)
Hi all,
please give comments on the attached eclass.
The purpose of the eclass is
* handle the suite bundle and its single rpms
* simplify ebuilds
* a clean and easy way to unpack what is needs to be install
Thanks,
justin
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: intel-sdp.eclass
# @MAINTAINER:
# Sébastien Fabbro
# Justin Lecher
# Sci Team
# @BLURB: Handling of Intel's Software Development Products package management
# @ECLASS-VARIABLE: INTEL_DID
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download ID from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2504
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPN
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package name to download from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. parallel_studio_xe
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPV
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download version from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2011_sp1_update2
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_SUBDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package sub-directory where it will end-up in /opt/intel
# To find out its value, you have to do a raw install from the Intel tar ball
# @ECLASS-VARIABLE: INTEL_RPMS_DIRS
# @DESCRIPTION:
# List of subdirectories in the main archive which contains the
# rpms to extract.
: ${INTEL_RPMS_DIRS:=rpm}
# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
# 32bit arch in rpm names
#
# e.g. i484
: ${INTEL_X86:=i486}
# @ECLASS-VARIABLE: INTEL_BIN_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm without any version/arch tag
#
# e.g. compilerprof
# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm of common data which are arch free
# without any version tag
#
# e.g. openmp
inherit check-reqs multilib versionator
_INTEL_PV1=$(get_version_component_range 1)
_INTEL_PV2=$(get_version_component_range 2)
_INTEL_PV3=$(get_version_component_range 3)
_INTEL_PV4=$(get_version_component_range 4)
_INTEL_URI="http://registrationcenter-download.intel.com/irc_nas/${INTEL_DID}/${INTEL_DPN}";
SRC_URI="
amd64? ( multilib? ( ${_INTEL_URI}_${INTEL_DPV}.tgz ) )
amd64? ( !multilib? ( ${_INTEL_URI}_${INTEL_DPV}_intel64.tgz ) )
x86? ( ${_INTEL_URI}_${INTEL_DPV}_ia32.tgz )"
LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"
IUSE="multilib"
KEYWORDS="-* ~amd64 ~x86"
RESTRICT="mirror"
RDEPEND=""
DEPEND=">=app-arch/rpm2targz-9.0.0.3g"
_INTEL_SDP_YEAR=${INTEL_DPV%_update*}
_INTEL_SDP_YEAR=${INTEL_DPV%_sp*}
# @ECLASS-VARIABLE: INTEL_SDP_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rootless path to installation dir
INTEL_SDP_DIR="opt/intel/${INTEL_SUBDIR}-${_INTEL_SDP_YEAR:-${_INTEL_PV1}}.${_INTEL_PV3}.${_INTEL_PV4}"
# @ECLASS-VARIABLE: INTEL_SDP_EDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rooted path to installation dir
INTEL_SDP_EDIR="${EROOT%/}/${INTEL_SDP_DIR}"
S="${WORKDIR}"
QA_PREBUILT="${INTEL_SDP_DIR}/*"
intel-sdp_pkg_pretend() {
: ${CHECKREQS_DISK_BUILD:=256M}
check-reqs_pkg_pretend
}
# @ECLASS-VARIABLE: INTEL_ARCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# Intels internal names of the arches; will be set at runtime accordingly
#
# e.g. amd64-multilib -> INTEL_ARCH="intel64 ia32"
intel-sdp_pkg_setup() {
local arch a p
if use x86; then
arch=${INTEL_X86}
INTEL_ARCH="ia32"
elif use amd64; then
arch=x86_64
INTEL_ARCH="intel64"
if has_multilib_profile; then
arch="x86_64 ${INTEL_X86}"
INTEL_ARCH="intel64 ia32"
fi
fi
INTEL_RPMS=""
for p in ${INTEL_BIN_RPMS}; do
for a in ${arch}; do
INTEL_RPMS="${INTEL_RPMS}
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.${a}.rpm"
done
done
for p in ${INTEL_DAT_RPMS}; do
INTEL_RPMS="${INTEL_RPMS}
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.noarch.rpm"
done
case "${EAPI:-0}" in
0|1|2|3) intel-sdp_pkg_pretend ;;
esac
}
intel-sdp_src_unpack() {
local l r t rpmdir
for t in ${A}; do
for r in ${INTE
[gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran
Hi,
I want to add following change to fortran-2.eclass to achieve more
simpler usage.
The patch will make the eclass depend on virtual/fortran so that no
manual addition is needed.
Two exception are present, a) the ebuild has the USE flag fortran, then
we check for that, or b) the FORTRAN_OPTIONAL variable is set, which
leaves the control to the ebuild (e.g. for cases like "lapack? (
virtual/fortran )").
This is the best coverage of the use cases present, because
* most ebuild using the eclass want to have a fortran compiler
* most other trigger optional fortran support through USE=fortran
* only minor have different USE for this purpose (e.g. numpy)
Thanks for comments,
Justin
Index: fortran-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.11
diff -u -B -r1.11 fortran-2.eclass
--- fortran-2.eclass7 Oct 2012 14:53:43 - 1.11
+++ fortran-2.eclass7 Oct 2012 17:18:28 -
@@ -35,6 +35,26 @@
inherit eutils toolchain-funcs
+# @ECLASS-VARIABLE: FORTRAN_OPTIONAL
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this before inheriting the eclass, if your package has an optional
+# fortran support, which is triggered by a different USE flag than 'fortran'.
+# This requires manual handling of the dependency on virtual/fortran.
+#
+# If unset, the dependency on virtual/fortran is added directly.
+
+if [[ -n ${FORTRAN_OPTIONAL} ]]; then
+ if in_iuse fortran; then
+ DEPEND="fortran? ( virtual/fortran )"
+ else
+ DEPEND="virtual/fortran"
+ fi
+fi
+
+RDEPEND="${DEPEND}"
+
+
# @FUNCTION: _write_testsuite
# @INTERNAL
# @DESCRIPTION:
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran
On 10/7/12 7:36 PM, Jonathan Callen wrote: > On 10/07/2012 01:20 PM, justin wrote: >> Hi, > >> I want to add following change to fortran-2.eclass to achieve more >> simpler usage. > >> The patch will make the eclass depend on virtual/fortran so that >> no manual addition is needed. Two exception are present, a) the >> ebuild has the USE flag fortran, then we check for that, or b) the >> FORTRAN_OPTIONAL variable is set, which leaves the control to the >> ebuild (e.g. for cases like "lapack? ( virtual/fortran )"). > >> This is the best coverage of the use cases present, because > >> * most ebuild using the eclass want to have a fortran compiler * >> most other trigger optional fortran support through USE=fortran * >> only minor have different USE for this purpose (e.g. numpy) > >> Thanks for comments, > >> Justin > > > You cannot check the value of IUSE in global scope in an eclass, as at > least portage actually unsets it before sourcing an eclass (also, it > is not defined in PMS what value IUSE would have at that point). You > also got a conditional backwards -- if you don't set FORTRAN_OPTIONAL > with that patch, then *nothing* gets appended to DEPEND -- if you do > set it, then DEPEND="virtual/fortran" will always be set (with your > current logic). > > Regarding your first point I copied the behavior from the toolchain.eclass and I thought it would work. Testing it, I see you are right. Any suggestion how to check for a USE being IUSE in an eclass? NAd your second point is completely right. I fix this when we sorted out the USE check. Thanks Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran
On 10/7/12 8:19 PM, Chí-Thanh Christopher Nguyễn wrote:
> justin schrieb:
>> Hi,
>>
>> I want to add following change to fortran-2.eclass to achieve more
>> simpler usage.
>>
>> The patch will make the eclass depend on virtual/fortran so that
>> no manual addition is needed. Two exception are present, a) the
>> ebuild has the USE flag fortran, then we check for that, or b) the
>> FORTRAN_OPTIONAL variable is set, which leaves the control to the
>> ebuild (e.g. for cases like "lapack? ( virtual/fortran )").
>
> I suggest that you do something similar to the XORG_DRI variable in
> xorg-2.eclass.
>
> For example:
> FORTRAN_WANT_COMPILER=no would not add a virtual/fortran dependency
> FORTRAN_WANT_COMPILER=always would unconditionally depend on
> virtual/fortran
> FORTRAN_WANT_COMPILER=useflag would depend on useflag? ( virtual/fortran )
>
> To avoid breaking existing packages, you could default to
> FORTRAN_WANT_COMPILER=fortran
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
Thanks for that suggestion. Please find the new version attached. It
basically follows what is done in the xorg-2.eclass. But we allow a list
of USE and don't allow a no, because the eclass itself needs a fortran
compiler.
Thanks,
justin
Index: fortran-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.11
diff -u -B -r1.11 fortran-2.eclass
--- fortran-2.eclass7 Oct 2012 14:53:43 - 1.11
+++ fortran-2.eclass7 Oct 2012 18:52:49 -
@@ -35,6 +35,32 @@
inherit eutils toolchain-funcs
+# @ECLASS-VARIABLE: FORTRAN_SUPPORT
+# @DESCRIPTION:
+# If your package has an optional fortran support, set this variable
+# to the space seperated list of USE triggering the fortran
+# dependence.
+#
+# e.g. FORTRAN_SUPPORT=lapack would result in
+#
+# DEPEND="lapack? ( virtual/fortran )"
+#
+# If unset, we always depend on virtual/fortran.
+: ${FORTRAN_SUPPORT:=always}
+
+DEPEND=""
+for _f_use in ${FORTRAN_SUPPORT}; do
+ case ${_f_use} in
+ always)
+ DEPEND+=" virtual/fortran"
+ ;;
+ *)
+ DEPEND+=" ${FORTRAN_SUPPORT}? ( virtual/fortran )"
+ ;;
+ esac
+done
+RDEPEND="${DEPEND}"
+
# @FUNCTION: _write_testsuite
# @INTERNAL
# @DESCRIPTION:
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran
On 09/10/12 15:12, Ian Stakenvicius wrote: > On 07/10/12 02:56 PM, justin wrote: >> On 10/7/12 8:19 PM, Chí-Thanh Christopher Nguyễn wrote: >>> justin schrieb: >>>> Hi, >>>> >>>> I want to add following change to fortran-2.eclass to achieve >>>> more simpler usage. >>>> >>>> The patch will make the eclass depend on virtual/fortran so >>>> that no manual addition is needed. Two exception are present, >>>> a) the ebuild has the USE flag fortran, then we check for that, >>>> or b) the FORTRAN_OPTIONAL variable is set, which leaves the >>>> control to the ebuild (e.g. for cases like "lapack? ( >>>> virtual/fortran )"). >>> >>> I suggest that you do something similar to the XORG_DRI variable >>> in xorg-2.eclass. >>> >>> For example: FORTRAN_WANT_COMPILER=no would not add a >>> virtual/fortran dependency FORTRAN_WANT_COMPILER=always would >>> unconditionally depend on virtual/fortran >>> FORTRAN_WANT_COMPILER=useflag would depend on useflag? ( >>> virtual/fortran ) >>> >>> To avoid breaking existing packages, you could default to >>> FORTRAN_WANT_COMPILER=fortran >>> >>> >>> Best regards, Chí-Thanh Christopher Nguyễn >>> >>> > >> Thanks for that suggestion. Please find the new version attached. >> It basically follows what is done in the xorg-2.eclass. But we >> allow a list of USE and don't allow a no, because the eclass itself >> needs a fortran compiler. > >> Thanks, justin > > > Looks better, but it would still be a good idea to have a possibility > of setting FORTRAN_SUPPORT=no so that the eclass can be used without > setting *DEPEND if a dev so desires. > > Right now it looks like FORTRAN_SUPPORT=no would result in > DEPEND+="no? (virtual/fortran)" > I thought about it, but it makes no sense. There is exactly no need for an ebuild to use this eclass if no fortran support is required. The only purpose of this eclass is to check that F77 and FC are valid fortran compilers. But in order to have this possibility available I will add it. Thanks for commenting, Jusitn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran
On 09.10.2012 23:19, Mike Frysinger wrote: > On Sunday 07 October 2012 13:58:04 justin wrote: >> On 10/7/12 7:36 PM, Jonathan Callen wrote: >>> You cannot check the value of IUSE in global scope in an eclass, as at >>> least portage actually unsets it before sourcing an eclass (also, it >>> is not defined in PMS what value IUSE would have at that point). >> >> Regarding your first point I copied the behavior from the >> toolchain.eclass and I thought it would work. Testing it, I see you are >> right. Any suggestion how to check for a USE being IUSE in an eclass? > > toolchain.eclass is testing its own IUSE which is why it works, not the IUSE > from ebuilds > -mike > Right I just saw this. Thanks, Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Ohloh Organizations - Gentoo Linux
Hi, does anybody like to setup an Organization[1] profile @ ohloh for Gentoo? justin [1] https://www.ohloh.net/orgs signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On 16/11/12 09:48, Samuli Suominen wrote: > On 16/11/12 00:07, Justin Lecher (jlec) wrote: >> jlec12/11/15 22:07:13 >> >>Modified: 80cgc-opt-2 >>Log: >>media-gfx/nvidia-cg-toolkit: Version BUmp, #270480, thanks Myckel Habets, >> Piotr Szymaniak and Jean-Marc Hengen working on the ebuild; add multilib >> support, #262477, thanks Russell Harmon and Dennis Schridde working on this; >> Add additional variables to enviroment to find headers and libs, #344603 >> >>(Portage version: 2.2.0_alpha142/cvs/Linux x86_64, signed Manifest commit >> with key 8009D6F070EB7916) >> >> Revision ChangesPath >> 1.2 media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2 >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?rev=1.2&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?rev=1.2&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?r1=1.1&r2=1.2 >> >> Index: 80cgc-opt-2 >> === >> RCS file: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v >> retrieving revision 1.1 >> retrieving revision 1.2 >> diff -u -r1.1 -r1.2 >> --- 80cgc-opt-2 15 Nov 2012 21:12:55 - 1.1 >> +++ 80cgc-opt-2 15 Nov 2012 22:07:13 - 1.2 >> @@ -1,7 +1,11 @@ >> -# $Header: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v 1.1 >> 2012/11/15 21:12:55 jlec Exp $ >> +# $Header: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v 1.2 >> 2012/11/15 22:07:13 jlec Exp $ >> >> # Configures the CG Runtime environment for Bourne shell and compatible >> shells >> CG_COMPILER_EXE=@GENTOO_PORTAGE_EPREFIX@/opt/bin/cgc >> +CG_INC_PATH=@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/include >> +CG_LIB_PATH="ELDPATH" >> >> -# Make sure the helper files are found >> -LDPATH="/opt/nvidia-cg-toolkit/lib" >> +PATH="@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/bin" >> +ROOTPATH="@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/bin" >> + >> +LDPATH="ELDPATH" > > does this mean it puts the binary-only package, nvidia-cg-toolkit, to > the default search path when you call the linker (compiler)? right, I trusted what Mike committed before. > > please don't do that, it is counterproductive with the purpose of > putting libraries to /opt. binary only packages should be isolated. > > it was already once reverted for the package... > > it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags > -L/opt/... or similar. > > thanks > That's true. I will fix this by adding support for pkg-config. Thanks, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On 16/11/12 09:48, Samuli Suominen wrote: > On 16/11/12 00:07, Justin Lecher (jlec) wrote: >> jlec12/11/15 22:07:13 >> >>Modified: 80cgc-opt-2 >>Log: >>media-gfx/nvidia-cg-toolkit: Version BUmp, #270480, thanks Myckel Habets, >> Piotr Szymaniak and Jean-Marc Hengen working on the ebuild; add multilib >> support, #262477, thanks Russell Harmon and Dennis Schridde working on this; >> Add additional variables to enviroment to find headers and libs, #344603 >> >>(Portage version: 2.2.0_alpha142/cvs/Linux x86_64, signed Manifest commit >> with key 8009D6F070EB7916) >> >> Revision ChangesPath >> 1.2 media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2 >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?rev=1.2&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?rev=1.2&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2?r1=1.1&r2=1.2 >> >> Index: 80cgc-opt-2 >> === >> RCS file: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v >> retrieving revision 1.1 >> retrieving revision 1.2 >> diff -u -r1.1 -r1.2 >> --- 80cgc-opt-2 15 Nov 2012 21:12:55 - 1.1 >> +++ 80cgc-opt-2 15 Nov 2012 22:07:13 - 1.2 >> @@ -1,7 +1,11 @@ >> -# $Header: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v 1.1 >> 2012/11/15 21:12:55 jlec Exp $ >> +# $Header: >> /var/cvsroot/gentoo-x86/media-gfx/nvidia-cg-toolkit/files/80cgc-opt-2,v 1.2 >> 2012/11/15 22:07:13 jlec Exp $ >> >> # Configures the CG Runtime environment for Bourne shell and compatible >> shells >> CG_COMPILER_EXE=@GENTOO_PORTAGE_EPREFIX@/opt/bin/cgc >> +CG_INC_PATH=@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/include >> +CG_LIB_PATH="ELDPATH" >> >> -# Make sure the helper files are found >> -LDPATH="/opt/nvidia-cg-toolkit/lib" >> +PATH="@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/bin" >> +ROOTPATH="@GENTOO_PORTAGE_EPREFIX@/opt/nvidia-cg-toolkit/bin" >> + >> +LDPATH="ELDPATH" > > does this mean it puts the binary-only package, nvidia-cg-toolkit, to > the default search path when you call the linker (compiler)? > > please don't do that, it is counterproductive with the purpose of > putting libraries to /opt. binary only packages should be isolated. > > it was already once reverted for the package... > > it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags > -L/opt/... or similar. > > thanks > +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) + + 16 Nov 2012; Justin Lecher +files/80cgc-opt-3, + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, +files/nvidia-cg-toolkit.pc.in, + +files/nvidia-cg-toolkit-gl.pc.in: + Don't add binary packages to global linker search path; instead using + pkg-config. Thanks ssuominen pointing this out + signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On 18.11.2012 15:37, Samuli Suominen wrote: > On 18/11/12 16:11, hasufell wrote: >> On 11/18/2012 03:08 PM, Peter Alfredsen wrote: >>> On Fri, Nov 16, 2012 at 10:43 AM, justin wrote: >>>> On 16/11/12 09:48, Samuli Suominen wrote: >>> >>>>> does this mean it puts the binary-only package, nvidia-cg-toolkit, to >>>>> the default search path when you call the linker (compiler)? >>>>> >>>>> please don't do that, it is counterproductive with the purpose of >>>>> putting libraries to /opt. binary only packages should be isolated. >>>>> >>>>> it was already once reverted for the package... >>>>> >>>>> it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags >>>>> -L/opt/... or similar. >>>>> >>>>> thanks >>>>> >>>> >>>> +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) >>>> + >>>> + 16 Nov 2012; Justin Lecher +files/80cgc-opt-3, >>>> + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, >>>> +files/nvidia-cg-toolkit.pc.in, >>>> + +files/nvidia-cg-toolkit-gl.pc.in: >>>> + Don't add binary packages to global linker search path; instead >>>> using >>>> + pkg-config. Thanks ssuominen pointing this out >>>> + >>> >>> This is a shared library, used by the plugin google-talkplugin. If >>> there is no >>> LDPATH set, browsers using that plugin will crash mysteriously and >>> unpredictably. You can't use chrpath to change the rpath because >>> lengthof(/opt/nvidia-cg-toolkit/lib64)>lengthof(/opt/google/talkplugin/lib) >>> >>> and we don't have the sources, so we can't really recompile. And it's >>> being dl-opened so LD_LIBRARY_PATH is a no-go, unless we want to add >>> magic to all browser that sets it to the correct path before starting >>> them. >>> >>> So please re-add the LDPATH to the env.d file. Pretty please. >>> Just cause it's binary doesn't mean it has to be cordoned off >>> and isolated like it's got the spanish flu. >>> >>> /Peter >>> >>> PS >>> pkgconfig is irrelevant if it's only gentoo that's shipping them. >>> HTH. HAND. >>> >> >> this is also breaking dev-games/ogre >> >> linking works fine (since we got proper pkgconfig fils), runtime is >> broken. >> > > umm, indeed... that's why I had ? marks in my original post. runtime is > OK to add, so LDPATH should be fine. > > sorry for any confusion. > > - Samuli > +*nvidia-cg-toolkit-3.1.0013-r2 (19 Nov 2012) + + 19 Nov 2012; Justin Lecher + +nvidia-cg-toolkit-3.1.0013-r2.ebuild: + Readding LDPATH into env as binary only apps use dl-open to load + I left the pkg-config support, because on prefix LDPATH is irrelevant and having pkg-config gives at least support for lib resolution at compile time. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: intel-sdp.eclass unpacking speedup
Hi,
Change of the unpacking logic which allows at least a speed up of factor 2.
Before we unpacked every single rpm from the tarball separately, now we
generate all possibilities and unpack them at once, ignoring warnings.
Justin
commit f13912b377189f6b80d05eb122c9f27e187c02a6
Author: Justin Lecher
Date: Sun Nov 25 10:51:00 2012 +0100
Speed up unpacking #431614
diff --git a/eclass/intel-sdp.eclass b/eclass/intel-sdp.eclass
index eafb523..a0f5b37 100644
--- a/eclass/intel-sdp.eclass
+++ b/eclass/intel-sdp.eclass
@@ -180,28 +180,27 @@ intel-sdp_pkg_setup() {
}
intel-sdp_src_unpack() {
- local l r t rpmdir
- debug-print "INTEL_RPMS_DIRS are \"${INTEL_RPMS_DIRS}\""
+ local l r subdir rb t list=()
+
for t in ${A}; do
for r in ${INTEL_RPMS}; do
- # Find which subdirectory of the archive the rpm
is in
- rpm_found="false"
for subdir in ${INTEL_RPMS_DIRS}; do
- [[ "${rpm_found}" == "true" ]] && continue
rpmdir=${t%%.*}/${subdir}
- l=.${r}_$(date +'%d%m%y_%H%M%S').log
- tar xf "${DISTDIR}"/${t} ${rpmdir}/${r}
2> /dev/null || continue
- einfo "Unpacking ${r}"
- rpm_found="true"
- rpm2tar -O "./${rpmdir}/${r}" | tar xvf
- | sed -e \
- "s:^\.:${EROOT#/}:g" > ${l} ||
die "unpacking ${r} failed"
- mv ${l} opt/intel/ || die "failed moving
extract log file"
+ list+=( ${rpmdir}/${r})
done
- [[ "${rpm_found}" == "false" ]] && \
- debug-print "RPM \"${r}\" not found in ${t}"
+ done
+ tar xf "${DISTDIR}"/${t} ${list[@]} 2> /dev/null || die
+ for r in ${list[@]}; do
+ rb=$(basename ${r})
+ l=.${rb}_$(date +'%d%m%y_%H%M%S').log
+ einfo "Unpacking ${rb}"
+ rpm2tar -O ${r} | tar xvf - | sed -e \
+ "s:^\.:${EROOT#/}:g" > ${l} || die
"unpacking ${r} failed"
+ mv ${l} opt/intel/ || die "failed moving extract
log file"
done
done
- mv -v opt/intel/* ${INTEL_SDP_DIR} || die "mv to INTEL_SDP_DIR
failed"
+
+ mv opt/intel/* ${INTEL_SDP_DIR} || die "mv to INTEL_SDP_DIR failed"
}
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] New eclass cuda.eclass
Hi,
I would like to introduce a new eclass for packages using the nvidia
cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS.
May be extended in the future.
Two problems come up with using nvcc:
* Each version only supports a limited number of gcc versions. Therefore
we need to pass the path to a supported gcc bindir
* nvcc calls CXX but doesn't pass CXXFLAGS on.
justin
# Copyright 1999-20012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit toolchain-funcs versionator
# @ECLASS: cuda.eclass
# @MAINTAINER:
# Justin Lecher
# @BLURB: Common functions for cuda packages
# @DESCRIPTION:
# This eclass contains functions to be used with cuda package. Currently it is
# setting and/or sanitizing NVCCFLAGS, the compiler flags for nvcc. This is
# automatically done and exported in src_prepare() or manually by calling
# cuda_sanatize.
#
# Common usage:
#
# inherit cuda
# @ECLASS-VARIABLE: NVCCFLAGS
# DESCRIPTION:
# nvcc compiler flags (see nvcc --help), which should be used like
# CFLAGS for c compiler
: ${NVCCFLAGS:=-O2}
# @ECLASS-VARIABLE: CUDA_VERBOSE
# DESCRIPTION:
# Being verbose during compilation to see underlying commands
: ${CUDA_VERBOSE:=true}
[[ "${CUDA_VERBOSE}" == true ]] && NVCCFLAGS+=" -v"
# @ECLASS-FUNCTION: cuda_gccdir
# @DESCRIPTION:
# Helper for determination of the latest gcc bindir supported by
# then current nvidia cuda toolkit.
#
# Calling plain it returns simply the path, but you probably want to add \"-f\""
# to get the full flag to add to nvcc call.
#
# Example:
#
# cuda_gccdir -f
# -> --compiler-bindir="/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3"
cuda_gccdir() {
local _gcc_bindir _ver _args="" _flag _ret
# Currently we only support the gnu compiler suite
if [[ $(tc-getCXX) != *g++* ]]; then
ewarn "Currently we only support the gnu compiler suite"
return 2
fi
while [ "$1" ]; do
case $1 in
-f)
_flag="--compiler-bindir="
;;
*)
;;
esac
shift
done
if [[ ! $(type -P cuda-config) ]]; then
eerror "Could not execute cuda-config"
eerror "Make sure >=dev-util/nvidia-cuda-toolkit-4.2.9-r1 is
installed"
die "cuda-config not found"
else
_args="$(version_sort $(cuda-config -s))"
if [[ ! -n ${_args} ]]; then
die "Could not determine supported gcc versions from
cuda-config"
fi
fi
for _ver in ${_args}; do
has_version sys-devel/gcc:${_ver} && \
_gcc_bindir="$(ls -d ${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${_ver}* |
tail -n 1)"
done
if [[ -n ${_gcc_bindir} ]]; then
if [[ -n ${_flag} ]]; then
_ret="${_flag}\\\"${_gcc_bindir}\\\""
else
_ret="${_gcc_bindir}"
fi
echo ${_ret}
return 0
else
eerror "Only gcc version(s) ${_args} are supported,"
eerror "of which none is installed"
die "Only gcc version(s) ${_args} are supported"
return 1
fi
}
# @ECLASS-FUNCTION: cuda_sanitize
# @DESCRIPTION:
# Correct NVCCFLAGS by adding the necessary reference to gcc bindir and
# passing CXXFLAGS to underlying compiler without disturbing nvcc.
cuda_sanitize() {
# Tell nvcc where to find a compatible compiler
NVCCFLAGS+=" $(cuda_gccdir -f)"
# Tell nvcc which flags should be used for underlying C compiler
NVCCFLAGS+=" --compiler-options=\"${CXXFLAGS}\""
export NVCCFLAGS
}
# @ECLASS-FUNCTION: cuda_pkg_setup
# @DESCRIPTION:
# Sanitise and export NVCCFLAGS by default in pkg_setup
cuda_pkg_setup() {
cuda_sanitize
}
EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3|4|5) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass cuda.eclass
On 25.11.2012 18:59, Rick "Zero_Chaos" Farina wrote: > On 11/25/2012 11:47 AM, Justin wrote: >> Hi, > >> I would like to introduce a new eclass for packages using the nvidia >> cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS. >> May be extended in the future. > >> Two problems come up with using nvcc: > >> * Each version only supports a limited number of gcc versions. Therefore >> we need to pass the path to a supported gcc bindir > >> * nvcc calls CXX but doesn't pass CXXFLAGS on. > > This whole idea seems great but I see two issues. Issue 1.) I'm stupid > and don't really understand all the intricacy of the toolchain stuff and > 2.) you didn't include an example ebuild. > > Fortunately issue 1 can (at least functionally) be solved by providing a > solution for issue 2. If you need an ebuild to cuda.eclassify then I am > happy to provide (or feel free to use a before and after of anything you > have available). > > https://code.google.com/p/pentoo/source/browse/portage/trunk/app-crypt/cryptohaze-combined/cryptohaze-combined-.ebuild > > Thanks! > Zero > 1) The build fails if you are using a compiler newer then the supported ones. In file included from /opt/cuda/include/cuda_runtime.h:59:0, from :0: /opt/cuda/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.7 and up are not supported! make[1]: *** [obj/x86_64/release/segmentationTree.cu_13.o] Error 1 or similar. Solution, tell nvcc where to find a compatible compiler. 2) The underlying call of c compiler doesn't respect CXXFLAGS, therefore we need to tell nvcc what to use. Otherwise only the plain NVCCFLAGS are used. How to fix your package, depends on the buildsystem and where and how they are calling the nvcc. Normally you need to sed it in. Here as an example the nvidia-cuda-sdk version bump: https://github.com/gentoo-science/sci/blob/cuda/dev-util/nvidia-cuda-sdk/nvidia-cuda-sdk-5.0.35.ebuild justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass cuda.eclass
On 26/11/12 01:26, "C. Bergström" wrote: > On 11/26/12 12:59 AM, Rick "Zero_Chaos" Farina wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 11/25/2012 11:47 AM, Justin wrote: >>> Hi, >>> >>> I would like to introduce a new eclass for packages using the nvidia >>> cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS. >>> May be extended in the future. >>> >>> Two problems come up with using nvcc: >>> >>> * Each version only supports a limited number of gcc versions. Therefore >>> we need to pass the path to a supported gcc bindir >>> >>> * nvcc calls CXX but doesn't pass CXXFLAGS on. > I don't know if this is helpful feedback, but it would be great if our > "CUDA" compiler was also detected in your eclass. > > Notable differences : Probably a lot faster compilation times (needs > benchmarking), no external userland dependencies (gcc or nvidia), we > don't support nvcc flags and we have a driver just for the CUDA language > > Example: > pathcu deadbeef.cu > ./a.out > > (Unfortunately our recent nightly builds started to do a license check, > but any interested open source dev just ping me to get setup) > > To validate simple things you could use an older nightly > http://c591116.r16.cf2.rackcdn.com/enzo/nightly/Linux/enzo-2012-11-18-installer.run > > chmod +x enzo-2012-11-18-installer.run ; ./enzo-2012-11-18-installer.run > --mode unattended # --prefix /opt/foobar > > ./C > > Hi, its definitely a nice thing to have more choices. Could you file bug for that please, so that we can support it in future versions? Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux
On 26.11.2012 21:58, Dirkjan Ochtman wrote: > On Fri, Nov 23, 2012 at 12:18 PM, Dirkjan Ochtman wrote: >> I haven't heard back from them, maybe you can ask them what's up. > > This has been setup (with Donnie's help): > > https://www.ohloh.net/orgs/gentoo > > I've claimed 15 of the projects on there that I could easily find, > analysis on those should complete shortly. If you're on Ohloh, please > nominate further projects. You can also add the organization as a tag > to your project contributions (which I've done for my gentoo-x86 > commits). > > Also, if you're an active Ohloh user, let me know if you want to be a > manager for the Gentoo organization. > > Cheers, > > Dirkjan > Thanks both of you for your work, justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: intel-sdp.eclass check user license
Hi,
next patch for intel-sdp.eclass
Problem:
If the intel compiler are installed but no valid license is present,
several buildsystem including cmake generate sandbox violations.
Solution:
Do not let the user install the package without valid license. Its
useless anyway without.
Realized in two checks, first in pkg_pretend check for simple existence
of a license file; second check in pkg_postinst calls for version
informations from compiler (runtime test).
First test is deadly; Second not, because user already intervened
manually to bypass first check and we consider this as
he-knows-what-he-is-doing.
Thanks justin
+# @ECLASS-FUNCTION: big-warning
+# @INTERNAL
+# warn user that we really require a license
+big-warning() {
+case ${1} in
+ pre-check )
+echo ""
+ewarn "License file not found!"
+;;
+test-failed )
+echo
+ewarn "Function test failed. Most probably due to an invalid license."
+ewarn "This means you already tried to bypass the license check once."
+;;
+esac
+
+echo ""
+ewarn "Make sure you have recieved the an Intel license."
+ewarn "To receive a non-commercial license, you need to register at:"
+ewarn "http://software.intel.com/en-us/articles/non-commercial-software-development/";
+ewarn "Install the license file into ${INTEL_SDP_EDIR}/licenses/"
+
+case ${1} in
+pre-check )
+ewarn "before proceeding with installation of ${P}"
+echo ""
+;;
+* )
+echo ""
+;;
+esac
+}
+
+# @ECLASS-FUNCTION: _version_test
+# @INTERNAL
+# Testing for valid license by asking for version information of the compiler
+_version_test() {
+local _comp _comp_full _arch _file _warn
+case ${PN} in
+ifc )
+debug-print "Testing ifort"
+_comp=ifort
+;;
+icc )
+debug-print "Testing icc"
+_comp=icc
+;;
+*)
+die "${PN} is not supported for testing"
+;;
+esac
+
+for _arch in ${INTEL_ARCH}; do
+case ${EBUILD_PHASE} in
+install )
+_comp_full="${ED}/${INTEL_SDP_DIR}/bin/${_arch}/${_comp}"
+;;
+postinst )
+_comp_full="${INTEL_SDP_EDIR}/bin/${_arch}/${_comp}"
+;;
+* )
+ewarn "Compile test not supported in ${EBUILD_PHASE}"
+continue
+;;
+esac
+
+debug-print "LD_LIBRARY_PATH=\"${INTEL_SDP_EDIR}/bin/${_arch}/\" \"${_comp_full}\" -V"
+
+LD_LIBRARY_PATH="${INTEL_SDP_EDIR}/bin/${_arch}/" "${_comp_full}" -V &>/dev/null
+[[ $? -ne 0 ]] && _warn=yes
+done
+[[ "${_warn}" == "yes" ]] && big-warning test-failed
+}
+
+# @ECLASS-FUNCTION: run-test
+# @INTERNAL
+# Test if installed compiler is working
+run-test() {
+case ${PN} in
+ifc | icc )
+_version_test ;;
+* )
+debug-print "No test available for ${PN}"
+;;
+esac
+}
+
+# @ECLASS-FUNCTION: intel-sdp_pkg_pretend
+# @DESCRIPTION:
+# * Check that the user has a (valid) license file before going on.
+#
+# * Check for space requirements being fullfilled
+intel-sdp_pkg_pretend() {
+ local _warn=1 _dirs i _ret arch a p
+
+ : ${CHECKREQS_DISK_BUILD:=256M}
+ check-reqs_pkg_pretend
+
+ _dirs=(
+ "${INTEL_SDP_EDIR}/licenses"
+ "${INTEL_SDP_EDIR}/Licenses"
+ "${EPREFIX}/opt/intel/licenses"
+ )
+ for ((i = 0; i < ${#_dirs[@]}; i++)); do
+ ebegin "Checking for a license in: ${_dirs[$i]}"
+ [[ $( ls "${_dirs[$i]}"/*lic 2>/dev/null ) ]]; _ret=$?
+ eend ${_ret}
+ if [[ ${_ret} == "0" ]]; then
+ _warn=${_ret}
+ break
+ fi
+ done
+ if [[ ${_warn} == "1" ]]; then
+ big-warning pre-check
+ die "Could not find license file"
+ fi
+}
@@ -238,8 +390,12 @@ intel-sdp_pkg_postinst() {
echo >> ${INTEL_SDP_DB} \
"<:${r%-${_INTEL_PV4}*}-${_INTEL_PV4}:${r}:${INTEL_SDP_EDIR}:${l}:>"
done
+ run-test
}
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] RFC: intel-sdp.eclass add USE="examples doc"
Hi,
next patch for intel-sdp.eclass
Problem:
Documentation and examples are installed on every system. Also japanese
man pages are installed.
Solution:
Use USE.
Thanks justin
@@ -93,13 +97,13 @@ LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"
-IUSE="multilib"
+IUSE="doc examples multilib"
KEYWORDS="-* ~amd64 ~x86 ~amd64-linux ~x86-linux"
RESTRICT="mirror"
RDEPEND=""
-DEPEND=">=app-arch/rpm2targz-9.0.0.3g"
+DEPEND="app-arch/rpm2targz"
_INTEL_SDP_YEAR=${INTEL_DPV%_update*}
_INTEL_SDP_YEAR=${INTEL_DPV%_sp*}
+# @ ECLASS-FUNCTION: intel-sdp_src_install
+# @DESCRIPTION:
+# Install everything
intel-sdp_src_install() {
- [[ -d ${INTEL_SDP_DIR}/eclipse_support ]] && \
- has eclipse ${IUSE} && \
- use eclipse && \
- intel_link_eclipse_plugins
+ if ! use doc && [[ -d "${INTEL_SDP_DIR}"/Documentation ]]; then
+ ebegin "Cleaning out documentation"
+ find "${INTEL_SDP_DIR}"/Documentation -delete || die
+ eend
+ fi
+ if ! use examples && [[ -d "${INTEL_SDP_DIR}"/Samples ]]; then
+ ebegin "Cleaning out examples"
+ find "${INTEL_SDP_DIR}"/Samples -delete || die
+ eend
+ fi
+ if [[ -d "${INTEL_SDP_DIR}"/eclipse_support ]]; then
+ if has eclipse ${IUSE} && use eclipse; then
+ intel_link_eclipse_plugins
+ else
+ ebegin "Cleaning out eclipse plugin"
+ find "${INTEL_SDP_DIR}"/eclipse_support -delete || die
+ eend
+ fi
+ fi
+
+ if [[ -d "${INTEL_SDP_DIR}"/man ]]; then
+ doman "${INTEL_SDP_DIR}"/man/en_US/man1/*
+ [[ ${LINGUAS} == "*ja_JP*" ]] && \
+ doman -i18n=ja_JP "${INTEL_SDP_DIR}"/man/ja_JP/man1/*
+
+ find "${INTEL_SDP_DIR}"/man -delete || die
+ fi
+
einfo "Tagging ${PN}"
find opt -name \*sh -type f -exec sed -i \
-e "s:<.*DIR>:${INTEL_SDP_EDIR}:g" \
- '{}' \;
- mkdir -p "${ED:-${D}}"/ || die
- mv opt "${ED:-${D}}"/ || die "moving files failed"
-}
+ '{}' + || die
+ [[ -d "${ED}" ]] || dodir /
+ mv opt "${ED}"/ || die "moving files failed"
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] intel-sdp.eclass new version
Hi,
here the complete eclass, as requested on irc.
Several minor changes are present:
* Drop numerous blank lines
* Drop Sebastien as maintainer
* Shuffle/Resort variables and functions (without changes)
* Write manpage jingle for everything
* and probably more.
justin
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/intel-sdp.eclass,v 1.4 2012/09/20
13:54:56 jlec Exp $
# @ECLASS: intel-sdp.eclass
# @MAINTAINER:
# Justin Lecher
# Sci Team
# @BLURB: Handling of Intel's Software Development Products package management
# @ECLASS-VARIABLE: INTEL_DID
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download ID from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2504
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPN
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package name to download from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. parallel_studio_xe
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPV
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download version from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2011_sp1_update2
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_SUBDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package sub-directory where it will end-up in /opt/intel
# To find out its value, you have to do a raw install from the Intel tar ball
# @ECLASS-VARIABLE: INTEL_RPMS_DIRS
# @DESCRIPTION:
# List of subdirectories in the main archive which contains the
# rpms to extract.
: ${INTEL_RPMS_DIRS:=rpm}
# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
# 32bit arch in rpm names
#
# e.g. i484
: ${INTEL_X86:=i486}
# @ECLASS-VARIABLE: INTEL_BIN_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm without any version/arch tag
#
# e.g. compilerprof
# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DEFAULT_UNSET
# @DESCRIPTION:
# Functional name of rpm of common data which are arch free
# without any version tag
#
# e.g. openmp
# @ECLASS-VARIABLE: INTEL_SDP_DB
# @DESCRIPTION:
# Full path to intel registry db
INTEL_SDP_DB="${EROOT%/}"/opt/intel/intel-sdp-products.db
inherit check-reqs multilib versionator
_INTEL_PV1=$(get_version_component_range 1)
_INTEL_PV2=$(get_version_component_range 2)
_INTEL_PV3=$(get_version_component_range 3)
_INTEL_PV4=$(get_version_component_range 4)
_INTEL_URI="http://registrationcenter-download.intel.com/irc_nas/${INTEL_DID}/${INTEL_DPN}";
SRC_URI="
amd64? ( multilib? ( ${_INTEL_URI}_${INTEL_DPV}.tgz ) )
amd64? ( !multilib? ( ${_INTEL_URI}_${INTEL_DPV}_intel64.tgz ) )
x86? ( ${_INTEL_URI}_${INTEL_DPV}_ia32.tgz )"
LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"
IUSE="doc examples multilib"
KEYWORDS="-* ~amd64 ~x86 ~amd64-linux ~x86-linux"
RESTRICT="mirror"
RDEPEND=""
DEPEND="app-arch/rpm2targz"
_INTEL_SDP_YEAR=${INTEL_DPV%_update*}
_INTEL_SDP_YEAR=${INTEL_DPV%_sp*}
# @ECLASS-VARIABLE: INTEL_SDP_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rootless path to installation dir
INTEL_SDP_DIR="opt/intel/${INTEL_SUBDIR}-${_INTEL_SDP_YEAR:-${_INTEL_PV1}}.${_INTEL_PV3}.${_INTEL_PV4}"
# @ECLASS-VARIABLE: INTEL_SDP_EDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Full rooted path to installation dir
INTEL_SDP_EDIR="${EROOT%/}/${INTEL_SDP_DIR}"
S="${WORKDIR}"
QA_PREBUILT="${INTEL_SDP_DIR}/*"
# @ECLASS-VARIABLE: INTEL_ARCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# Intels internal names of the arches; will be set at runtime accordingly
#
# e.g. amd64-multilib -> INTEL_ARCH="intel64 ia32"
# @ECLASS-FUNCTION: intel_link_eclipse_plugins
# @DESCRIPTION:
# Creating necessary links to use intel compiler with eclipse
intel_link_eclipse_plugins() {
local c f
pushd ${INTEL_SDP_DIR}/eclipse_support > /dev/null
for c in cdt*; do
local cv=${c#cdt} ev=3.$(( ${cv:0:1} - 1))
if has_version "dev-util/eclipse-sdk:${ev}"; then
einfo "Linking eclipse (v${ev}) plugin cdt (v${cv})"
for f in cdt${cv}/eclipse/features/*; do
dodir /usr/$(get_libdir)/eclipse-${ev}/features
dosym "${INTEL_SDP_EDIR}"/eclipse_support/${f} \
/usr/$(get_libdir)/eclipse-${ev}/features/ || die
done
for f in cdt${cv}/eclipse/plugins/*; do
dodir /usr/$(get_libdir)/eclipse-${ev}/plugins
dosym "${INTEL_SDP_EDIR}"/eclipse_suppo
Re: [gentoo-dev] RFC: intel-sdp.eclass add USE="examples doc"
On 11/27/12 4:18 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 27 Nov 2012, justin wrote:
>
>> next patch for intel-sdp.eclass
>
>> Problem:
>> Documentation and examples are installed on every system. Also japanese
>> man pages are installed.
>
>> Solution:
>> Use USE.
>
>> +[[ ${LINGUAS} == "*ja_JP*" ]] && \
>> +doman -i18n=ja_JP "${INTEL_SDP_DIR}"/man/ja_JP/man1/*
>
> Since LINGUAS is USE-expanded, shouldn't you rather test for
> "use linguas_ja"?
>
> Ulrich
>
You are right, I will check for that.
Thanks for the comment,
Justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: intel-sdp.eclass add USE="examples doc"
On 11/27/12 4:38 PM, Diego Elio Pettenò wrote: > On 27/11/2012 04:32, justin wrote: >> Documentation and examples are installed on every system. Also japanese >> man pages are installed. > > Does the documentation take time to build, or is it an external > download? If no, don't use a doc USE flag. > > Do the example require to be built? If no, don't use an examples USE flag. Everything is bundled and doesn't need to be built. I know your are against USE for installation only purposes, so my question is why? The reason I introduced the USE here and in general to use it in similar locations is that those packages install tons of documentation and examples, which I personally don't like to waste my diskspace with. What is wrong to give the user this install only option? justin > > Japanese man pages are installed by a number of packages, and so are > Italian and others — you could make them optional with linguas_ja, but > my suggestion would rather be to keep them and tell people who want to > have a minimal install to either use localepurge or installmask. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: intel-sdp.eclass add USE="examples doc"
On 11/27/12 5:49 PM, Diego Elio Pettenò wrote: > On 27/11/2012 08:01, justin wrote: >> The reason I introduced the USE here and in general to use it in similar >> locations is that those packages install tons of documentation and >> examples, which I personally don't like to waste my diskspace with. What >> is wrong to give the user this install only option? > > You could go with "minimal" in that case. How big said documentation > would be? Over 100M? Because boost's libraries are 100M without debug > information. > > In general I prefer having everything available by default if it doesn't > require impossible amount of space, add dependency, or take time to build. > > We have INSTALL_MASK and FEATURES=nodoc if you don't want the > documentation, after all. > Probably you are right. It's around 25% (60-80MB) which we would save. As long we make sure things are in places where noman, nodoc and friends work, it should be fine. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: intel-sdp.eclass check user license
On 28/11/12 00:04, Mike Frysinger wrote:
> On Tuesday 27 November 2012 07:26:50 justin wrote:
>> next patch for intel-sdp.eclass
>
> your code has a lot of whitespace damage (leading spaces instead of tabs).
> you should fix that up.
I am sorry for that and we fix it up. Did some writing on mac where the
editor did magic tab -> whitespace conversion.
>
>> +# @ECLASS-FUNCTION: big-warning
>> +# @INTERNAL
>> +# warn user that we really require a license
>
> there should be @DESCRIPTION line before the description
>
I have overlooked that. Fixed now.
> you can run
> /usr/portage/app-portage/eclass-manpages/files/eclass-to-manpage.sh
> against the eclass to check for errors.
Didn't know, that you can run it on single files. Nice to know, Thanks.
>
> also, just because they're @INTERNAL doesn't mean short names like "big-
> warning" and "run-test" are OK. your eclass is putting funcs into global
> scope which can collide with other eclasses/ebuilds and possibly things in
> $PATH (dejagnu provides a standard program called `runtest`). best to give
> them a unique prefix like _isdp_big_warning().
You are right. I will prefix and name them correctly.
>
>> +_version_test() {
>> +local _comp _comp_full _arch _file _warn
>
> you've declared the vars all local. there's no need for the _ prefix.
>
>> + for ((i = 0; i < ${#_dirs[@]}; i++)); do
>
> for dir in "${dirs[@]}" ; do
I can't remember what was my problem, but somehow I didn't manage to
iterate properly over the array. So I looked that up and found this syntax.
But maybe something else was wrong too.
>
> that avoids indexing dirs constantly
> -mike
>
thanks for your comments mike,
Jusitn
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: intel-sdp.eclass add USE="examples doc"
On 28/11/12 00:06, Mike Frysinger wrote: > On Tuesday 27 November 2012 11:49:52 Diego Elio Pettenò wrote: >> On 27/11/2012 08:01, justin wrote: >>> The reason I introduced the USE here and in general to use it in similar >>> locations is that those packages install tons of documentation and >>> examples, which I personally don't like to waste my diskspace with. What >>> is wrong to give the user this install only option? >> >> You could go with "minimal" in that case. How big said documentation >> would be? Over 100M? Because boost's libraries are 100M without debug >> information. >> >> In general I prefer having everything available by default if it doesn't >> require impossible amount of space, add dependency, or take time to build. >> >> We have INSTALL_MASK and FEATURES=nodoc if you don't want the >> documentation, after all. > > documentation is not the same thing as examples. if the examples are large > (or even if they aren't), then USE=examples is an acceptable approach to > filtering. > -mike > That's exactly my opinion, therefore doc was dropped and examples is still living. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass cuda.eclass
On 28/11/12 00:11, Mike Frysinger wrote:
> On Sunday 25 November 2012 11:47:42 Justin wrote:
>> # Copyright 1999-20012 Gentoo Foundation
>
> it is not yet 20012
>
> also, this file too has whitespace damage (indenting with spaces)
>
>> [[ "${CUDA_VERBOSE}" == true ]] && NVCCFLAGS+=" -v"
>
> wouldn't this be better done in cuda_sanitize ?
>
>> local _gcc_bindir _ver _args="" _flag _ret
>
> they're local vars, so you don't need to use _ prefixes
>
>> if [[ ! $(type -P cuda-config) ]]; then
>
> it's more common to do something like:
> if cuda-config --help >/dev/null ; then
>
> or, you could even inline it with the existing code:
>
> if ! args=$(cuda-config -s); then
> ... eerror/die ...
> else
> args=$(version_sort ${args})
> ...
>
>>if [[ ! -n ${_args} ]]; then
>
> use "-z", not "! -n"
> -mike
>
Thanks for your comments, those are now integrated,
Justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass cuda.eclass
Please review my inclusion of your suggestions. Additionally I move to
src_prepare to be more binpackage compatible as things are only of
interest at compile time.
commit 366a690925f5cc5e4bdd2ea984d9ccca65d8f996
Author: Justin Lecher
Date: Wed Nov 28 11:54:16 2012 +0100
Be bin package friendly
Move standard call of cuda_sanitize to src_prepapere as it isn't need
for bin packages.
Signed-off-by: Justin Lecher
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 08cfb72..beac082 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -110,13 +110,23 @@ cuda_sanitize() {
# @FUNCTION: cuda_pkg_setup
# @DESCRIPTION:
-# Sanitise and export NVCCFLAGS by default
+# Call cuda_src_prepare for EAPIs not supporting src_prepare
cuda_pkg_setup() {
+ cuda_src_prepare
+}
+
+# @FUNCTION: cuda_src_prepare
+# @DESCRIPTION:
+# Sanitise and export NVCCFLAGS by default
+cuda_src_prepare() {
cuda_sanitize
}
-EXPORT_FUNCTIONS pkg_setup
+
case "${EAPI:-0}" in
- 0|1|2|3|4|5) ;;
+ 0|1)
+ EXPORT_FUNCTIONS pkg_setup ;;
+ 2|3|4|5)
+ EXPORT_FUNCTIONS src_prepare ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
commit 07b5a629a7f6e9f163e0dfe9c1927010f527508f
Author: Justin Lecher
Date: Wed Nov 28 11:24:51 2012 +0100
Fix typo in Copyright year
Signed-off-by: Justin Lecher
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 0b2e084..08cfb72 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-20012 Gentoo Foundation
+# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
commit 7319422dd7c7427cc741e9bdab2f1211b5af1be4
Author: Justin Lecher
Date: Wed Nov 28 11:24:16 2012 +0100
Implemented comments from g-dev review
* Fix whitespacing
* Fix man pages tags
* Try to do things in functions instead of global scope
* remove _ from local variables
* inline check for presents and functionality of cuda-config
Signed-off-by: Justin Lecher
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index f8ebd81..0b2e084 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -13,49 +13,45 @@ inherit toolchain-funcs versionator
# setting and/or sanitizing NVCCFLAGS, the compiler flags for nvcc. This is
# automatically done and exported in src_prepare() or manually by calling
# cuda_sanatize.
-#
-# Common usage:
-#
+# @EXAMPLE:
# inherit cuda
# @ECLASS-VARIABLE: NVCCFLAGS
-# DESCRIPTION:
+# @DESCRIPTION:
# nvcc compiler flags (see nvcc --help), which should be used like
# CFLAGS for c compiler
: ${NVCCFLAGS:=-O2}
# @ECLASS-VARIABLE: CUDA_VERBOSE
-# DESCRIPTION:
+# @DESCRIPTION:
# Being verbose during compilation to see underlying commands
: ${CUDA_VERBOSE:=true}
-[[ "${CUDA_VERBOSE}" == true ]] && NVCCFLAGS+=" -v"
-
-# @ECLASS-FUNCTION: cuda_gccdir
+# @FUNCTION: cuda_gccdir
+# @USAGE: [-f]
+# @RETURN: gcc bindir compatible with current cuda, optionally (-f)
prefixed with "--compiler-bindir="
# @DESCRIPTION:
# Helper for determination of the latest gcc bindir supported by
# then current nvidia cuda toolkit.
#
-# Calling plain it returns simply the path, but you probably want to
add \"-f\""
-# to get the full flag to add to nvcc call.
-#
# Example:
-#
+# @CODE
# cuda_gccdir -f
# -> --compiler-bindir="/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3"
+# @CODE
cuda_gccdir() {
- local _gcc_bindir _ver _args="" _flag _ret
+ local gcc_bindir ver args="" flag ret
# Currently we only support the gnu compiler suite
if [[ $(tc-getCXX) != *g++* ]]; then
-ewarn "Currently we only support the gnu compiler suite"
+ ewarn "Currently we only support the gnu compiler suite"
return 2
fi
while [ "$1" ]; do
case $1 in
-f)
- _flag="--compiler-bindir="
+ flag="--compiler-bindir="
;;
*)
;;
@@ -63,43 +59,46 @@ cuda_gccdir() {
shift
done
- if [[ ! $(type -P cuda-config) ]]; then
+ if ! args=$(cuda-config -s); then
eerror "Could not execute cuda-config"
eerror "Make sure >=dev-util/nvidia-cuda-toolkit-4.2.9-r1 is
installed"
die "cuda-config not found"
else
- _args="$(version_sort $(cuda-config -s))"
- if [[ ! -n ${_args} ]]; then
+ args=$(version_sort ${args})
+ if [[ -z ${args} ]]; then
die "Could not determine supported gcc versions from
cu
[gentoo-dev] RFC: new eclass - pkgconfig.eclass
Hi,
and another one.
Problem:
Some packages aren't lucky and their buildsystem doesn't create
pkg-config files out of the box.
Solution:
Create them by hand.
Eclass:
Simplifies this by providing a general function for that.
Example:
https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild
Thanks for comments,
Justin
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: pkgconfig.eclass
# @MAINTAINER:
# j...@gentoo.org
# @BLURB: Simplify creation of pkg-config files
# @DESCRIPTION:
# Use this if you buildsystem doesn't create pkg-config files.
inherit multilib
# @ECLASS-VARIABLE: PC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_PREFIX:="${EPREFIX}/usr"}
# @ECLASS-VARIABLE: PC_EXEC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_EXEC_PREFIX:="${PC_PREFIX}"}
# @ECLASS-VARIABLE: PC_LIBDIR
# @DESCRIPTION:
# libdir to use
: ${PC_LIBDIR:="${EPREFIX}/usr/$(get_libdir)"}
# @ECLASS-VARIABLE: PC_INCLUDEDIR
# @DESCRIPTION:
# include dir to use
: ${PC_INCLUDEDIR:="${PC_PREFIX}/include"}
# @ECLASS-VARIABLE: PC_NAME
# @DESCRIPTION:
# A human-readable name for the library or package
: ${PC_NAME:=${PN}}
# @ECLASS-VARIABLE: PC_DESCRIPTION
# @DESCRIPTION:
# A brief description of the package
: ${PC_DESCRIPTION:=${DESCRIPTION}}
# @ECLASS-VARIABLE: PC_URL
# @DESCRIPTION:
# An URL where people can get more information about and download the package
: ${PC_URL:=${HOMEPAGE}}
# @ECLASS-VARIABLE: PC_VERSION
# @DESCRIPTION:
# A string specifically defining the version of the package
: ${PC_VERSION:=${PV}}
# @ECLASS-VARIABLE: PC_REQUIRES
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of packages required by this package. The versions of these packages
# may be specified using the comparison operators =, <, >, <= or >=.
# @ECLASS-VARIABLE: PC_REQUIRES_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of private packages required by this package but not exposed to
# applications. The version specific rules from the PC_REQUIRES field also
# apply here.
# @ECLASS-VARIABLE: PC_CONFLICTS
# @DEFAULT_UNSET
# @DESCRIPTION:
# An optional field describing packages that this one conflicts with.
# The version specific rules from the PC_REQUIRES field also apply here.
# This field also takes multiple instances of the same package. E.g.,
# Conflicts: bar < 1.2.3, bar >= 1.3.0.
# @ECLASS-VARIABLE: PC_LIBS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags specific to this package and any required libraries that
# don't support pkg-config. The same rule as PC_CFLAGS applies here.
# @ECLASS-VARIABLE: PC_LIBS_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags for private libraries required by this package but not
# exposed to applications. The same rule as PC_CFLAGS applies here.
# @ECLASS-VARIABLE: PC_CFLAGS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The compiler flags specific to this package and any required libraries
# that don't support pkg-config. If the required libraries support
# pkg-config, they should be added to PC_REQUIRES or PC_REQUIRES_PRIVATE.
# @FUNCTION: create_pkgconfig
# @USAGE: [-p | --prefix PC_PREFIX] [-e | --exec-prefix PC_EXEC_PREFIX] [-L |
--libdir PC_LIBDIR ] [-I | --includedir PC_INCLUDEDIR ] [-n | --name PC_NAME]
[-d | --description PC_DESCRIPTION] [-V | --version PC_VERSION] [-u | --url
PC_URL] [-r | --requires PC_REQUIRES] [--requires-private PC_REQUIRES_PRIVATE]
[--conflicts PC_CONFLICTS] [-l | --libs PC_LIBS] [--libs-private
PC_LIBS_PRIVATE] [-c | --cflags PC_CFLAGS]
# @DESCRIPTION:
# Creates and installs .pc file. Function arguments overrule the global set
# eclass variables. The function should only be executed in src_install().
create_pkgconfig() {
local pcname
[[ "${EBUILD_PHASE}" != "install" ]] && \
die "create_pkgconfig should only be used in src_install()"
while (($#)); do
case ${1} in
-p | --prefix )
shift; PC_PREFIX=${1} ;;
-e | --exec-prefix )
shift; PC_EXEC_PREFIX=${1} ;;
-L | --libdir )
shift; PC_LIBDIR=${1} ;;
-I | --includedir )
shift; PC_INCLUDEDIR=${1} ;;
-n | --name )
shift; PC_NAME=${1} ;;
-d | --description )
shift; PC_DESCRIPTION=${1} ;;
-V | --version )
shift; PC_VERSION=${1} ;;
-u | --url )
shift; PC_URL=${1} ;;
-r | --requires )
shift; PC_REQ
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 02:14, Mike Frysinger wrote: > On Wednesday 28 November 2012 16:49:14 Justin wrote: >> Problem: >> Some packages aren't lucky and their buildsystem doesn't create >> pkg-config files out of the box. >> >> Solution: >> Create them by hand. > > i agree this is a problem. but i think the only real place to fix this is in > the upstream package. otherwise, the .pc file is largely unused and kind of > pointless. other people have already enumerated more detailed responses, so > i'll just leave it at this. > -mike > Hi, I will respond here, but this also is addressed to all the other negative responses. Let me explain the reason we (sci team) are using manually created .pc files. And as a side note I totally agree with the statement that pc file creation should be upstreams business. Back to the problem. We are mainly using this approach to allow multiple installations of packages providing BLAS and LAPACK implementations, and its derivative. Why this? There is a reference implementation, a closed source intel implementation, optimized versions for speed, a gnu version and so on, from which the user should be able to choose. Still why we need a switchable system? I would like to point [1] you to some great GSOC work from andy which he also present in Praque [2]. He clearly showed, that different implementations are good for different puposes. Therefore we need to have different implementations installed in parallel. Currently we have an eselect module to switch between different implementations by setting /usr/lib/lib[blas,lapack].so to the selected implementation. This has two drawbacks, which some of you might already of hit: 1. They seem to be not completely API/ABI compatible (I don't which one is correct here. And please don't be nitpicking on this point). So switching would mean recompilation of all packages linked against it before, otherwise you might get runtime errors. This takes time and triggers point 2. 2. As andy showed we should stick with specific implementations for specific tasks. The current way flattens this out to be optimal for some and suboptimal for others. Now, there has been a lot of effort around Andy and Sebastien to solve this problem. The solution is simple: don't install any libblas.so or liblapack.so in libdir, but instead make the pkg-config module eselectable and force packages to used pkg-config. Nearly (I think its 100%) of the packages in the tree already use pkg-config to detect blas/lapack. The only remaining problem is on the implementation side. As you can imagine, this effort is nothing in which the upstreams are really interested in. Therefore most of our .pc files are created inside the ebuild. Eventually they will find their way back upstream, but currently this is something gentoo specific, it's about choices. The eclass should just be a reduction of redundant code. And of course its not meant to be a replacement to upstream work on packages with sane buildsystems. Its just a last resort for corner cases like our lapack/blas stuff, which do not have any reasonable option. I hope this clears my intention and makes it reasonable to have this eclass, justin 1) https://github.com/andyspiros/numbench/wiki http://andyspiros.wordpress.com/category/google-summer-of-code/ 2) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/miniconf/presentations/miniconf-2012-numbench-spiros.pdf signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 09:48, Gilles Dartiguelongue wrote: > Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : >> Currently we have an eselect module to switch between different >> implementations by setting /usr/lib/lib[blas,lapack].so to the selected >> implementation. >> >> This has two drawbacks, which some of you might already of hit: >> 1. They seem to be not completely API/ABI compatible (I don't which one >> is correct here. And please don't be nitpicking on this point). So >> switching would mean recompilation of all packages linked against it >> before, otherwise you might get runtime errors. This takes time and >> triggers point 2. >> >> 2. As andy showed we should stick with specific implementations for >> specific tasks. The current way flattens this out to be optimal for some >> and suboptimal for others. >> >> Now, there has been a lot of effort around Andy and Sebastien to solve >> this problem. The solution is simple: don't install any libblas.so or >> liblapack.so in libdir, but instead make the pkg-config module >> eselectable and force packages to used pkg-config. Nearly (I think its >> 100%) of the packages in the tree already use pkg-config to detect >> blas/lapack. > > I think I understand the problem now. You should not patch/generate .pc > files but install them to an implementation specific subdirectory. > If I get you correctly you are assuming that we have pkgconfig files for all implementations coming from upstreams. That's not correct, we have nearly none. So we need to generate them our own. And yes this need to be sent upstream. That's the reason for the eclass. > That way, you just have to append that path to PKGCONFIG_PATH when > configuring your package using blas and you should be able to > transparently select which implementation to get without further > patching of either upstream or downstream packages. > This would mean that the pkg maintainer decides the implementation. But we leave this choice to the user which works fine. And we have a working eselect based solution. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 09:52, Michał Górny wrote: > On Thu, 29 Nov 2012 08:52:01 +0100 > justin wrote: > >> The only remaining problem is on the implementation side. As you can >> imagine, this effort is nothing in which the upstreams are really >> interested in. Therefore most of our .pc files are created inside the >> ebuild. Eventually they will find their way back upstream, but currently >> this is something gentoo specific, it's about choices. >> >> The eclass should just be a reduction of redundant code. And of course >> its not meant to be a replacement to upstream work on packages with sane >> buildsystems. Its just a last resort for corner cases like our >> lapack/blas stuff, which do not have any reasonable option. >> >> I hope this clears my intention and makes it reasonable to have this eclass, > > Nope, it doesn't. If the pkg-config file is created within an ebuild > (or eclass), it is *completely unsuitable* to go anywhere. > > You should write a template, preferably 'mostly' compatible with > the build system and put it into FILESDIR. Even if it's going to be > redundant. This way, we have a simple, ready, clean, constant file > which can be sent upstream or copied by any other distro. It also makes > clear that the file is Gentoo-specific. > > Just to be clear on some points. 1. We are _not_ talking about packages like e.g. gnome libs which have upstreams who know how to work with buildsystem and use sane standard ones. Those love to accept patches making things smoother. Most of the sci upstreams are using custom shell scripts or badly written makefiles. They normal don't get the point in accepting things from us. 2. Even if we would directly start working with upstream on a solution, we would not have something in broad distribution downstream before we all will retire from gentoo. (If you like, you can go to intel and tell them to have a buildsystem which creates the necessary files. This will not happen in near future.) 3. Most distribution, as they happen to be binary, only build against one implementation usually the reference. And a significantly large number even rename their libraries. So no sense to convince them to use standard pc files. So no need for us to force a solution with upstream now, before proceeding with gentoo. We need to think about gentoo now. Therefore a manual creation of those files is what we are doing now. With or without an eclass. Now back to your good argument. You are right, we should work with some sort of template. I think for the reference implementations this can be realized quite easily, as they moved to cmake quite recently. For most of the others it will be quite some work. We will take a look into their buildsystem and see what we can achieve. Thanks, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 14:16, hasufell wrote: > > again, even if there are corner cases which cannot be dealt with in a > different way... > > having an eclass function like the mentioned one is bad, cause it > suggests that this is a way to fix things. It's not. Application > developers running gentoo might think "oh great, there is a pkgconfig > file for this, so I can use it in my Makefile". Then a Fedora packager > comes across this package and realizes a compile failure until he > notices the build system is calling for a pkgconfig file that cannot be > found anywhere. So he contacts this developer and asks which distro he > is using. Standard autotools based packages always use --with-blas= so it is pretty simple for us to make it to --with-blas="$(pkg-config --libs blas)" same thing goes for cmake and -DBLAS_LIBRARIES="$(pkg-config --libs blas)" This game has been played since ever, because blas/lapack are bundled in more then 80% of the packages using it. So we are used to patch them to use system libs. So why not making our lives easier by having a pkg-config option? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On 29/11/12 16:51, Ian Stakenvicius wrote: > On 29/11/12 09:56 AM, justin wrote: > >> Standard autotools based packages always use > >> --with-blas= > >> so it is pretty simple for us to make it to > >> --with-blas="$(pkg-config --libs blas)" > >> same thing goes for cmake and > >> -DBLAS_LIBRARIES="$(pkg-config --libs blas)" > >> This game has been played since ever, because blas/lapack are >> bundled in more then 80% of the packages using it. So we are used >> to patch them to use system libs. So why not making our lives >> easier by having a pkg-config option? > >> justin > > > ..ok remind me again what the .pc files provide you? this is so that > you can have slotted blas providers and various packages can choose > their preferred one instead of having to use the eselected one? or... > > > > > Not exactly. The user can choose for each package newly by eselecting the wanted implementation. This is the user side. From the pm side we ensure that the choice is really respected by linking against package specific names [1] instead of the generic ones e.g. libblas.so. And this can be achieved in an easy way by using pkg-config. justin 1) # eselect blas set atlas-threads # pkg-config --libs blas -lptf77blas -lm -latlas -lpthread # eselect blas set reference # pkg-config --libs blas -lrefblas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 17:23, hasufell wrote: > On 11/29/2012 03:56 PM, justin wrote: >> On 29/11/12 14:16, hasufell wrote: >>> >>> again, even if there are corner cases which cannot be dealt with >>> in a different way... >>> >>> having an eclass function like the mentioned one is bad, cause >>> it suggests that this is a way to fix things. It's not. >>> Application developers running gentoo might think "oh great, >>> there is a pkgconfig file for this, so I can use it in my >>> Makefile". Then a Fedora packager comes across this package and >>> realizes a compile failure until he notices the build system is >>> calling for a pkgconfig file that cannot be found anywhere. So he >>> contacts this developer and asks which distro he is using. > >> So why not making our lives easier by having a pkg-config option? > > Did you read what you quoted? Are you saying cross distro interfaces > for accessing libraries in build systems are ok to break? > Not only are people using foo.pc to compile a package on gentoo, but > also when writing a build system for "bar" which might link against "foo". > > So having largely unused .pc files is the best case, the worst is > causing random breakage/annoyance for other distros without even > knowing, cause yeah... for us it works. > I understand the pros about pc files and the cons about doing it the way I propose. _But_, there is no cross distro way which we are disturbing. Every distro is having its own magic and naming of those libs. That means, they all patch the buildsystem if needed to use their stuff. The same way as we do since ever. (And I can tell you, for sci package handling blas/lapack is one of the simplest tasks) Our approach is of no interest to 90% or more of the other distros because it would only work on a source distro which has capabilities of selecting different implementations at compile time. And the number of non gentoo derived distros which fullfill this criteria is rather limited. So no general interest of bringing things back upstream. We also do not disturb standard non pm builds as they are normally hardcoding the path to bundled lib or provide a sane autotools/cmake way to point to the lib. And currently all ebuilds in the portage are using pkg-config for a long time, so nothing new here. And nothing non-sci-team members need to worry about. In fact they never did. The only thing what happened was, that I had this crazy idea of writing an eclass to reduce redundant code. This was not about inventing or implementing something new. That has been done a long time before. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 17:54, Gilles Dartiguelongue wrote: > Le jeudi 29 novembre 2012 à 10:07 +0100, justin a écrit : >> On 29/11/12 09:48, Gilles Dartiguelongue wrote: >>> Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : >>>> Currently we have an eselect module to switch between different >>>> implementations by setting /usr/lib/lib[blas,lapack].so to the selected >>>> implementation. >>>> >>>> This has two drawbacks, which some of you might already of hit: >>>> 1. They seem to be not completely API/ABI compatible (I don't which one >>>> is correct here. And please don't be nitpicking on this point). So >>>> switching would mean recompilation of all packages linked against it >>>> before, otherwise you might get runtime errors. This takes time and >>>> triggers point 2. >>>> >>>> 2. As andy showed we should stick with specific implementations for >>>> specific tasks. The current way flattens this out to be optimal for some >>>> and suboptimal for others. >>>> >>>> Now, there has been a lot of effort around Andy and Sebastien to solve >>>> this problem. The solution is simple: don't install any libblas.so or >>>> liblapack.so in libdir, but instead make the pkg-config module >>>> eselectable and force packages to used pkg-config. Nearly (I think its >>>> 100%) of the packages in the tree already use pkg-config to detect >>>> blas/lapack. >>> >>> I think I understand the problem now. You should not patch/generate .pc >>> files but install them to an implementation specific subdirectory. >>> >> >> If I get you correctly you are assuming that we have pkgconfig files for >> all implementations coming from upstreams. That's not correct, we have >> nearly none. So we need to generate them our own. And yes this need to >> be sent upstream. >> >> That's the reason for the eclass. >> >>> That way, you just have to append that path to PKGCONFIG_PATH when >>> configuring your package using blas and you should be able to >>> transparently select which implementation to get without further >>> patching of either upstream or downstream packages. >>> >> >> This would mean that the pkg maintainer decides the implementation. But >> we leave this choice to the user which works fine. And we have a working >> eselect based solution. > > No, this means you can then use USE flags to select it which is package > manager controlled and usually easier to deal with than eselected stuff. > So you mean adding a USE for each implementation to each package which is using one fo blas/cblas/lapack/clapack/lapacke and all the others which I forgot? And in the end, we still would need pc files, because version A of implementation X could have different library names then version B. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 28/11/12 22:49, Justin wrote: > Hi, > > and another one. > > Problem: > Some packages aren't lucky and their buildsystem doesn't create > pkg-config files out of the box. > > Solution: > Create them by hand. > > Eclass: > Simplifies this by providing a general function for that. > > Example: > https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild > > Thanks for comments, > Justin > So, to end this whole thing here, I pull back my request for integration of this eclass. Thanks for all the comments, critics and suggestions, justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On 29.11.2012 21:11, Ralph Sennhauser wrote: > On Thu, 29 Nov 2012 17:09:34 +0100 > justin wrote: > >> On 29/11/12 16:51, Ian Stakenvicius wrote: > [...] >>> ..ok remind me again what the .pc files provide you? this is so >>> that you can have slotted blas providers and various packages can >>> choose their preferred one instead of having to use the eselected >>> one? or... >>> >> >> Not exactly. >> The user can choose for each package newly by eselecting the wanted >> implementation. This is the user side. From the pm side we ensure that >> the choice is really respected by linking against package specific >> names [1] instead of the generic ones e.g. libblas.so. And this can be >> achieved in an easy way by using pkg-config. >> >> justin >> >> 1) >> # eselect blas set atlas-threads >> # pkg-config --libs blas >> -lptf77blas -lm -latlas -lpthread >> >> # eselect blas set reference >> # pkg-config --libs blas >> -lrefblas >> > > This immediately bears the following questions: > > * How do you ensure the linked against implementation doesn't get > depcleaned? revdep-rebuild maybe? portage handles this fine. > > * How do you let users configure the implementation to be used on a per > package basis? Interrupt an emerge world to set the appropriate > implementation for the next few packages? > The Standard user will get reference implementation and has no problem. Setting individual implementation on per package basis needs to be considered as they-know-what-they-are-doing. Otherwise you don't know which implementation to choose . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass
On 30.11.2012 05:37, Duncan wrote: > hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted: > >> again, even if there are corner cases which cannot be dealt with in a >> different way... >> >> having an eclass function like the mentioned one is bad, cause it >> suggests that this is a way to fix things. It's not. Application >> developers running gentoo might think "oh great, there is a pkgconfig >> file for this, so I can use it in my Makefile". Then a Fedora packager >> comes across this package and realizes a compile failure until he >> notices the build system is calling for a pkgconfig file that cannot be >> found anywhere. So he contacts this developer and asks which distro he >> is using. >> >> This already happened for me multiple times and the answers was >> "debian". >> >> All this sounds like a very dirty workaround and if you need it, then do >> it, but _don't_ create an eclass, cause it's not a good thing to >> standardize. >> These files should _not_ be distro-dependant. Try to find other >> solutions. >> >> -1 for this eclass > > Suggestion/question for Justin, Mike (Spanky), and others. > > Assuming people eventually agree that this is a special case, which I'm > beginning to think it might be after reading Justin's arguments, tho I > recognize that's not a settled case yet... > > The glibc ebuilds use glibc-specific eblits. This keeps the glibc- > specific common code out of the ebuilds (and out of more general purpose > eclasses) and in the files dir. > > Obviously that specific solution won't work for the multiple blas/ > whatever packages, since it's single-package/multi-version specific, but > is there some variant of it that could work, keeping the code out of > eclasses where the not-for-general-purpose solution might be mistakenly > thought to be general purpose and get used as such, while still allowing > a common to the various *blas/whatever packages solution? > > The best I can come up with is eblits, thus keeping it out of the > individual ebuilds, but forcing the eblits to be copied to all the > different implementations individually. Still, that'd save a bit of code > between multiple versions of the same package, and a script could be > setup that updates all the eblits in the various packages in one go, so > it'd be a bit better than having to do it per ebuild. > > But perhaps someone else can improve on that idea... > > Another alternative might be an eclass, but name it something like blas- > utils or some such, not pkgconfig, thus discouraging inappropriate use, > and put in strict warnings and possibly repoman checks, so that only a > specific list of packages are allowed to use it. That list could then be > controlled by either the science or QA teams as thought appropriate, thus > strictly limiting the spread of this ordinarily inappropriate practice. > Thanks for making thoughts about this issue. Meanwhile I talked back to my team lead and he told me that the final solution will be without pc files. This is work in progress, but it will be pc file free and alos not bypassing the buildsystem in anyway. But lets wait. Thanks, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing
On 06/03/16 12:24, Davide Pesavento wrote: > On Sun, Mar 6, 2016 at 12:04 PM, Michał Górny wrote: >> On Sun, 6 Mar 2016 12:01:19 +0100 >> Michał Górny wrote: >> >>> Please test and review. I'm going to reply to this mail with the list >>> of current metadata.xml validation failures (it's quite long). >> >> And here's the list: >> > ... >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value >> 'media-libs/gstreamer:1.0' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:12: element pkg: >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not a >> valid value of the atomic type 'pkgType'. >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: >> Schemas validity error : Element 'pkg': [facet 'pattern'] The value >> 'media-libs/gstreamer:0.10' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml:13: element pkg: >> Schemas validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is not a >> valid value of the atomic type 'pkgType'. >> /var/db/repos/gentoo/dev-qt/qtmultimedia/metadata.xml fails to validate >> >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: Schemas >> validity error : Element 'pkg': [facet 'pattern'] The value >> 'media-libs/gstreamer:1.0' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:12: element pkg: Schemas >> validity error : Element 'pkg': 'media-libs/gstreamer:1.0' is not a valid >> value of the atomic type 'pkgType'. >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: Schemas >> validity error : Element 'pkg': [facet 'pattern'] The value >> 'media-libs/gstreamer:0.10' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml:13: element pkg: Schemas >> validity error : Element 'pkg': 'media-libs/gstreamer:0.10' is not a valid >> value of the atomic type 'pkgType'. >> /var/db/repos/gentoo/dev-qt/qtwebkit/metadata.xml fails to validate >> > > Slots are not accepted in elements? Is that intentional? If so, > is there something else we can use? > We should definitely include SLOTs in the allowed syntax.
Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing
On 06/03/16 18:18, Michał Górny wrote: >> We should definitely include SLOTs in the allowed syntax. > > Why? What's their use? In fact, does have any use? Because as I > see it, it's just some fancy feature that could turn package name into > link to packages.gentoo.org and nothing more... > Using SLOTs you have more precision in what you are writing. There are quite a number of packages where SLOTs differ a lot, e.g. grub. So clearly specifying a SLOT make sense to me. Take this example Install theme for sys-boot/grub:2 Dropping the SLOT here doesn't make sense, as the content of the package with USE=grub2 won't work for grub-1. I can assume there are a number of packages where file formats or such changed between SLOTs, so it makes sense to specify it.
Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing
On 06/03/16 19:28, Ulrich Mueller wrote: >>>>>> On Sun, 6 Mar 2016, Michał Górny wrote: > >> On Sun, 6 Mar 2016 19:26:15 +0100 >> Davide Pesavento wrote: > >>> So I guess we could use the following form when SLOTs are needed: >>> media-libs/gstreamer:1.0 >>> ? > >> Prolly. > >> Just to be clear, I have no clue what the original use of >> was and what the final outcome of this will be. This thread was >> established mostly in order to determine that. I'd wait for ulm to >> turn up and have some suggestions ;-). > > :) > > No idea what the original purpose was, but and are > specified in GLEP 56 [1]: > >- Each XML tag allows 0 or more nested XML tags whose > character data is a valid CP or CPV as defined by the Gentoo > Development Manual - Ebuild File Format [2]. Michał, your current syntax breaks with multiple pkg (sci-libs/metis or sci-libs/parmetis) results in metadata.xml:21: element pkg: Schemas validity error : Element 'pkg': [facet 'pattern'] The value '' is not accepted by the pattern '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. metadata.xml:21: element pkg: Schemas validity error : Element 'pkg': '' is not a valid value of the atomic type 'pkgType'. metadata.xml:24: element pkg: Schemas validity error : Element 'pkg': [facet 'pattern'] The value '' is not accepted by the pattern '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. metadata.xml:24: element pkg: Schemas validity error : Element 'pkg': '' is not a valid value of the atomic type 'pkgType'. Justin
Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing
On 06/03/16 20:49, Michał Górny wrote: > On Sun, 6 Mar 2016 20:22:18 + > "Justin " wrote: > >> On 06/03/16 19:28, Ulrich Mueller wrote: >>>>>>>> On Sun, 6 Mar 2016, Michał Górny wrote: >>> >>>> On Sun, 6 Mar 2016 19:26:15 +0100 >>>> Davide Pesavento wrote: >>> >>>>> So I guess we could use the following form when SLOTs are needed: >>>>> media-libs/gstreamer:1.0 >>>>> ? >>> >>>> Prolly. >>> >>>> Just to be clear, I have no clue what the original use of >>>> was and what the final outcome of this will be. This thread was >>>> established mostly in order to determine that. I'd wait for ulm to >>>> turn up and have some suggestions ;-). >>> >>> :) >>> >>> No idea what the original purpose was, but and are >>> specified in GLEP 56 [1]: >>> >>>- Each XML tag allows 0 or more nested XML tags whose >>> character data is a valid CP or CPV as defined by the Gentoo >>> Development Manual - Ebuild File Format [2]. >> >> Michał, your current syntax breaks with multiple pkg >> >> (sci-libs/metis or sci-libs/parmetis) >> >> results in >> >> metadata.xml:21: element pkg: Schemas validity error : Element 'pkg': >> [facet 'pattern'] The value '' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> metadata.xml:21: element pkg: Schemas validity error : Element 'pkg': '' >> is not a valid value of the atomic type 'pkgType'. >> metadata.xml:24: element pkg: Schemas validity error : Element 'pkg': >> [facet 'pattern'] The value '' is not accepted by the pattern >> '[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'. >> metadata.xml:24: element pkg: Schemas validity error : Element 'pkg': '' >> is not a valid value of the atomic type 'pkgType'. > > Are you sure about this? > > $ xmllint --noout --schema metadata.xsd > /var/db/repos/gentoo/sci-libs/spqr/metadata.xml > /var/db/repos/gentoo/sci-libs/spqr/metadata.xml validates > > What validator do you use for this? > I was wrong, the output actually meant another line which contains a . Sorry for the noise.
Re: [gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing
On 02/05/2016 12:57 am, M. J. Everitt wrote: > On 02/05/16 00:53, Brian Dolbec wrote: >> In order to further improve the chances of Q/A tools catching >> errors. I have created a new repo (overlay) which will contain minimal >> test case ebuilds. The idea is to have test case ebuilds to run >> repoman code against. The outcome of these runs should be comparable >> to pre-recorded output. In that way as more code changes are applied >> as part of the stage3 re-write as well as new test cases and checks to >> be added to it's capabilities. It should minimize the bugs introduced >> in releases. >> >> Repoman does have some unit tests, but it is far from 100% coverage. >> Also with the major structural changes that the code has been >> undergoing, it is not always possible for the unit tests to be >> compatible with the new code. >> >> This new repository is open to all Gentoo developers to contribute to. >> All we ask is that you follow some simple common sense rules for adding >> additional test ebuilds. >> >> The repo is located at: >> >> https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ >> >> Here is the README included in the base directory. >> >> This repository is for the primary purpose of testing Q/A tools like repoman. >> >> The ebuilds it contains are for testing specific areas of tests that are >> performed as part of the normal operation of that Q/A tool. >> >> This repository is open to all Gentoo developers under the following rules: >> >> 1) The master branch is to remain the stable Q/A testing branch. >> >> 2) All ebuilds are to be minimal test cases. >> >> 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect. >>This makes it easier to spot errors during code development. Simply >> running >>repoman in a category should be enough to test everything the module >> tests. >>This excludes some commit only checks which can be run in a local only >> branch. >> >> 4) All category names are to represent the Q/A category being tested. >> ie: >> ebuild-test - tests various aspects of the ebuild repoman module >> eclass-test - various eclass module tests >> ... >> >> 5) like the category naming, the package naming will follow the test >>being performed. >>ie: >>eclass-test/live-keywords - test the eclass module >> LiveEclassChecks >>keywords check >>ebuild-test/invalid - test for invalid package name detection >> >> 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo >>That should ensure it maintains co-ordination with the main gentoo repo. >>All new or modified eclasses that affect pkg metadata should be validated >> in >>a branch. >> >> 7) New module development and test ebuilds will be done in a branch or >> personal >>repo and submitted to the gentoo-portage-dev email list for review and >>approval to merge into master. >>NOTE: This rule is lifted for the initial creation and population of >> test ebuilds to use to test out the repoman code. An anouncemnt to >> the gentoo-project email list will be made when this initial >> population >> period is being ended. >> >> 8) Signed commits only, also signed-pushes are mandatory >> >> 9) The metadata category will get files of validated output that can be used >>to verify code changes in the various categories and repo wide runs. >>Diffing the output, should help to verify code changes did not break >> anything. >> >> 10) See rules 1-9 :-) >> > +1 be good to have somewhere central for this stuff :] > We can also run this on our new recruits. :) signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: global USE c++11
Hi all How about making USE="c++11" a global USE? Description: Build using the C++11 standard. Current situation: sci-libs/dealii: Compile the library with -std=c++11 sci-physics/herwig++: Build Herwig++ using the C++11 standard. sci-astronomy/casacore: Build casacore using the C++11 standard sci-libs/ceres-solver: Build ceres-solver using the C++11 standard sci-physics/herwig++: Build Herwig++ using the C++11 standard. sci-physics/root: Build ROOT using the C++11 standard sci-physics/thepeg: Build ThePEG using the C++11 standard. sci-physics/yoda: Build using the C++11 standard Seems to be very consistent in usage. Best, Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Global USE cuda
Hi all How about making USE=cuda a global USE? Description: Enable support for nVidia CUDA Current Situation: dev-lang/pgi: Install PGI's CUDA components (e.g. for OpenACC) dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g. dev-util/VampirTrace: Enable tracing of CUDA calls and GPU kernels. sci-chemistry/ball: Include cuda support sci-chemistry/nwchem: Enable CUDA GPU support for the Tensor sci-libs/arrayfire: Build CUDA backend. sci-libs/bigdft-abi: Enable support for nVidia CUDA sci-libs/libgeodecomp: Enables plugins for NVIDIA GPUs (e.g. sci-libs/trilinos: Add support for cuda (dev-util/nvidia-cuda-toolkit) sci-misc/kaldi: Build with CUDA support. sci-physics/abinit: Enable support for nVidia CUDA sci-physics/bigdft: Enable support for nVidia CUDA GPU acceleration sys-cluster/openmpi: Add GPU direct support app-crypt/johntheripper: Use nvidia cuda toolkit for speeding up dev-libs/libdynd: Enable NVIDIA CUDA toolkit support dev-libs/libflatarray: Enables plugins for NVIDIA GPUs (e.g. dev-libs/starpu: Enable NVIDIA CUDA toolkit support dev-util/nvidia-cuda-sdk: Build CUDA binaries. media-gfx/blender: Build cycles renderer with nVidia CUDA support. media-gfx/k3d: Use nvidia cuda toolkit for speeding up computations media-gfx/nvidia-texture-tools: Enable NVIDIA CUDA toolkit support media-libs/opencv: Enable NVIDIA Cuda computations support media-libs/opensubdiv: Enable NVIDIA CUDA Toolkit support through net-analyzer/suricata: Enable NVIDIA Cuda computations support net-wireless/pyrit: Enable CUDA support via net-wireless/cpyrit-cuda sci-chemistry/ball: Include cuda support sci-chemistry/gromacs: Enable cuda non-bonded kernels sci-chemistry/vmd: Use nvidia cuda toolkit for speeding up sci-libs/cholmod: Use nvidia cuda toolkit for speeding up computations sci-libs/flann: Enable support for nVidia CUDA sci-libs/pcl: Adds support for NVIDIA CUDA. sci-libs/suitesparse: Enable nvidia cuda toolkit for speeding up sci-misc/boinc: Use nvidia cuda toolkit for speeding up computations. sci-physics/espresso: Enable cuda support sci-physics/hoomd-blue: Enable cuda non-bonded kernels sys-apps/hwloc: Enable CUDA device discovery sys-cluster/openmpi: Add GPU direct support More or less consistent in enabling CUDA support. Best, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: global USE c++11
On 03/01/2017 08:51, Kristian Fiskerstrand wrote: > On 01/02/2017 10:34 PM, Justin wrote: >> >> Seems to be very consistent in usage. > > But I'm not convinced it is a correct approach to have use flag changing > this. First thing that springs to mind is if introducing something like > that it should be done consistently across Gentoo, so a GLEP. But > presumably a lot of packages are already built using C++11 without a use > flag given Qt5.7 requiring it etc. > > If using C++11 enables different features the feature should be the use > flag rather than C++11. Couldn't this just be determined using Autotools > etc? What is the gain of the use flag? Immediately it sounds like it > adds complexity without much gain. > I tried to find some example usages from upstream. Two things I found * Most upstreams dropped the flag in recent versions * If present, it is used to append -std=c++11 Probably we should keep it local and wait until it is gone everywhere upstream. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: sci-libs/blas-atlas & sci-libs/lapack-atlas
# Justin Lecher (5 Dec 2012) # sci-libs/(lapack/blas)-altas will be removed due to # fragile build and runtime behaviour #372323. # Alternatives are sci-libs/lapack-reference & sci-libs/blas-reference. # Follow up package named sci-libs/atlas can be found in # sci overlay and will be moved once ready for prime time sci-libs/blas-atlas sci-libs/lapack-atlas signature.asc Description: OpenPGP digital signature
[gentoo-dev] [gentoo-dev-announce] Lastrites: sci-astronomy/sextractor & sci-astronomy/scamp
# Sebastien Fabbro (13 Dec 2012) # Necessary removal to get rid of very unstable sci-libs/lapack-atlas # Packages are in the science overlay # until sci-libs/atlas replacement make it to the main tree sci-astronomy/sextractor sci-astronomy/scamp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On 17/12/12 11:23, Diego Elio Pettenò wrote: > On 17/12/2012 11:19, Tomáš Chvátal wrote: >> >> I've always myself override these defaults in make.conf to point for >> /var/portage/ (not /var/lib because I never bothered enough how to >> make world and config files to be put elsewhere :P). > > I would say let's work on that so that portage can keep them there. > Although I'm more for /var/cache/portage myself, as both distfiles and > tree can be re-generated. > fetch-restricted files are to be considered critical here. Do we want to force the user to keep them twice? So an additional location which is not a "cache"? Of course PORTAGE_RO_DISTDIRS and friends are nice here, but they are not part of a default setup. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On 17/12/12 12:17, Diego Elio Pettenò wrote: > On 17/12/2012 12:06, justin wrote: >> fetch-restricted files are to be considered critical here. Do we want to >> force the user to keep them twice? So an additional location which is >> not a "cache"? >> Of course PORTAGE_RO_DISTDIRS and friends are nice here, but they are >> not part of a default setup. > > I would still think they are cache. I can re-download Oracle's JRE > binaries; Portage's copy is a cache because I don't need to back it up. > I am more thinking about packages which are not as easy accessible as JRE. There are a couple sci packages which are distributed on request by mail other inconvenient methods. Sometimes even not by your own, but by your PI or other seniors. And even sometimes upstreams doesn't distribute them anymore at all. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 03/01/13 00:41, Pacho Ramos wrote:
> What is the purpose of this stuff:
> if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_EUTILS="recur -_+^+_- spank"
>
I don't know exactly sure if this is the source of some recent problems,
but I assume it is.
While fixing some issues, I found a worrisome abnormally.
$ diff -uarN tcl-8.5.13-r*
--- tcl-8.5.13-r1.ebuild2013-01-09 09:05:09.342608806 +0100
+++ tcl-8.5.13-r2.ebuild2013-01-09 09:05:06.132529434 +0100
@@ -4,7 +4,7 @@
EAPI=4
-inherit versionator autotools eutils flag-o-matic multilib toolchain-funcs
+inherit autotools eutils flag-o-matic multilib toolchain-funcs versionator
MY_P="${PN}${PV/_beta/b}"
Only _non_ phase function exporting eclasses are used, so the order of
inheriting shouldn't matter. As you can see the only difference is the
place of the versionator.eclass during inheriting. As an result the
package builds completely different. Following diff can be seen during
configuration:
--- tcl-8.5.13-r1/temp/build.log
+++ tcl-8.5.13-r2/temp/build.log
checking whether to use symlinks for manpages... no
checking whether to compress the manpages... no
checking whether to add a package name suffix for the manpages... no
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
+checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
-checking whether the C compiler works... yes
+checking for suffix of executables...
checking whether we are cross compiling... no
-checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
-checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed
+checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none
needed
checking for inline... inline
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
-checking for egrep... grep -E
+checking for grep that handles long lines and -e... /bin/grep
+checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
The changes are small but the shouldn't be there at all, as the ebuilds
are completely equal except for the inheriting order.
Also the internals of the build are affected (probably through the
difference in configure). This leads to disrespected LDFLAGS and broken
tclConfig.sh. So this simple change has deep consequences.
My question, did anybody else might have observed similar things? Is
there a flaw in this *ECLASS_ONCE_* stuff?
Thanks,
Justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 10:03, Zac Medico wrote: > On 01/09/2013 12:40 AM, justin wrote: >> My question, did anybody else might have observed similar things? Is >> there a flaw in this *ECLASS_ONCE_* stuff? > > There could well be, but even in the absence of the *ECLASS_ONCE_* > stuff, the problem that you're describing could be attributed to eclass > conflicts that cause order of inheritance to make a difference. For > example, it could be that multilib.eclass definitions conflict with one > or more other eclasses, as noted here: > > https://bugs.gentoo.org/show_bug.cgi?id=450988#c1 > That could be, but in this case it is a matter of the versionator.eclass. This means only global scope variables from that eclass (and I can't find any) would matter and conflict. So I don't think this is the reason. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 10:26, Diego Elio Pettenò wrote: > On 09/01/2013 09:40, justin wrote: >> >> Also the internals of the build are affected (probably through the >> difference in configure). This leads to disrespected LDFLAGS and broken >> tclConfig.sh. So this simple change has deep consequences. > > This looks like the _version_ of autoconf used is different. Is the > output from the same exact system? > Yes, I created to revisions of the ebuild, changed the order of inherits and run ebuild on them directly after one another. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 10:26, Diego Elio Pettenò wrote: > On 09/01/2013 09:40, justin wrote: >> >> Also the internals of the build are affected (probably through the >> difference in configure). This leads to disrespected LDFLAGS and broken >> tclConfig.sh. So this simple change has deep consequences. > > This looks like the _version_ of autoconf used is different. Is the > output from the same exact system? > Okay, did some more debugging and it seems to be not the new singly inheriting eclass. Repeating the sequential emerge on different FS I get a completely mixed result. Sometimes both compile are good, sometimes only one and sometime none. Could this be a problem with eautoreconf or is this autotools specifc problem? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 12:29, justin wrote: > On 09/01/13 10:26, Diego Elio Pettenò wrote: >> On 09/01/2013 09:40, justin wrote: >>> >>> Also the internals of the build are affected (probably through the >>> difference in configure). This leads to disrespected LDFLAGS and broken >>> tclConfig.sh. So this simple change has deep consequences. >> >> This looks like the _version_ of autoconf used is different. Is the >> output from the same exact system? >> > > Okay, did some more debugging and it seems to be not the new singly > inheriting eclass. > > Repeating the sequential emerge on different FS I get a completely mixed > result. Sometimes both compile are good, sometimes only one and sometime > none. > Could this be a problem with eautoreconf or is this autotools specifc > problem? > I assume it is a portage problem, because the log says autoconf is run but configure.in didn't change. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 12:44, Diego Elio Pettenò wrote: > On 09/01/2013 12:39, justin wrote: >> I assume it is a portage problem, because the log says autoconf is run >> but configure.in didn't change. >> > > What do you mean configure.in didn't change but autoconf is run? > the build.log says Running eautoreconf in '/home/justin/extData/tmp/portage/dev-lang/tcl-8.5.13-r1/work/tcl8.5.13/unix' ... Running autoconf ... [ok] Running autoheader ...[!!] >>> Source prepared. I overlooked the failed autoheader, which interesting didn't died (EAPI=4 ebuild). But autoconf should have been run successfully. A diff between the original and the two run build's configure.in shows only a difference by one of the two (in both cases the autoheader failed). > Does it cause a maintainer-mode rebuild? interesting not. > > Did you use eautoreconf? > yes signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 09/01/13 13:40, Diego Elio Pettenò wrote: > On 09/01/2013 13:35, justin wrote: >> Running autoheader ...[!!] > > That is unfortunately common... > >> A diff between the original and the two run build's configure.in shows >> only a difference by one of the two (in both cases the autoheader failed). > > I lost you here... can you attach the build logs? > There are no differences in the build.logs. So nothing to see here. I found the problem. The patch works on configure and configure.in. If both files are patched sometimes autoconf doesn't run. I fixed the patch to only touch .in and everything is fine. autoconf or eautoconf problem? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 11/01/13 05:10, Mike Frysinger wrote: > On Wednesday 09 January 2013 06:39:37 justin wrote: >> On 09/01/13 12:29, justin wrote: >>> On 09/01/13 10:26, Diego Elio Pettenò wrote: >>>> On 09/01/2013 09:40, justin wrote: >>>>> Also the internals of the build are affected (probably through the >>>>> difference in configure). This leads to disrespected LDFLAGS and broken >>>>> tclConfig.sh. So this simple change has deep consequences. >>>> >>>> This looks like the _version_ of autoconf used is different. Is the >>>> output from the same exact system? >>> >>> Okay, did some more debugging and it seems to be not the new singly >>> inheriting eclass. >>> >>> Repeating the sequential emerge on different FS I get a completely mixed >>> result. Sometimes both compile are good, sometimes only one and sometime >>> none. >>> Could this be a problem with eautoreconf or is this autotools specifc >>> problem? >> >> I assume it is a portage problem, because the log says autoconf is run >> but configure.in didn't change. > > this sounds like bug 417355. the autom4te.cache dir gets busted (somehow). > when autotools runs, it looks at the cache dir, sees that things are up to > date, and then doesn't regen any files. > -mike > Yeah, it was because of the double patching of configure and configure.in. Cleaning the patch made it work. Interestingly in the beginning I really could reproduce a correlation between the inherit order and this breakage. Bad that was false. Thanks justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] tcl/tk-8.6 incompatibilities
Hi, some packages do not build against version 8.6 and show errors like this: error: 'Tcl_Interp' has no member named 'result' and error: 'Tcl_Interp' has no member named 'errorline' This is due to a removal of an old and deprecated (at least since 2004) feature. Here some simple fixes: Version A (will stop working with tcl/tk-9.0): append -DUSE_INTERP_RESULT and/or -DUSE_INTERP_ERRORLINE to the *FLAGS. Version B (long lasting and better): patch code (and send upstream) to use Tcl_GetResult(), Tcl_GetStringResult(), Tcl_SetResult(), Tcl_SetStringResult(), Tcl_GetErrorLine() Examples: @@ -1980,10 +1980,10 @@ void tcl_run( trace = (char *)Tcl_GetVar(interp, "errorInfo", 0); if (trace == NULL) - trace = interp->result; + trace = Tcl_GetStringResult(interp); fprintf(stderr, "%s: TCL error @ line %d: %s\n", -script, interp->errorLine, trace); +script, Tcl_GetErrorLine(interp), trace); } Tcl_DeleteInterp(interp); Some more little facts: * Please link against libtcl.so and libtk.so instead of libtcl8.6.so and libtk8.6. * Version 8.6 supports pkg-config * Version 8.6 is subslotted. * Reference bug https://bugs.gentoo.org/show_bug.cgi?id=451368 Thanks justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] tcl/tk-8.6 incompatibilities
One additional note: application-specific initialization failed: package not known invalid command name "auto_mkindex_parser::command" This comes from a broken dev-lang/tcl-8.6.0. Revision 1 is fixed. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due spock retirement
On 1/20/13 11:09 AM, Pacho Ramos wrote: > dev-python/pycuda Sci is taking this. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] tcltk herd has no active maintainer
On 03.02.2013 13:48, Pacho Ramos wrote: > matsuu was its last member but nothing was really being fixed related > with this herd for a long time. > > If nobody joins this herd in a week, I would vote for moving its > packages to maintainer-needed > As I took care of packages from that herd, so I will join. But please, if someone likes to help, please join. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 14/03/13 04:50, gro...@gentoo.org wrote: > Hello *, > > I've followed all the instructions successfully (I think). By the way, the > following lines need a small correction: > > perl_ldap -b user -M gpgkey > perl_ldap -b user -M gpgfingerprint > > perl_ldap says that attributes of type multiple cannot be modified. I had > to delete these attributes and then create the new ones. > > But my first attempt to do a signed commit has failed: > > Using commit message: > -- > Version bump > > (Portage version: 2.2.0_alpha166/cvs/Linux i686, signed Manifest commit > with key 00C6DAB1!) > -- > > Warning: untrusted X11 forwarding setup failed: xauth key data not > generated > Warning: No xauth data; using fake authentication data for X11 forwarding. > X11 forwarding request failed on channel 0 > /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/ChangeLog,v <-- ChangeLog > new revision: 1.9; previous revision: 1.8 > /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.9.ebuild,v <-- > clozurecl-1.9.ebuild > initial revision: 1.1 > /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/clozurecl-1.7.ebuild,v <-- > clozurecl-1.7.ebuild > new revision: delete; previous revision: 1.3 >>>> Creating Manifest for /home/gentoo-x86/dev-lisp/clozurecl > gpg: no default secret key: No secret key > gpg: /home/gentoo-x86/dev-lisp/clozurecl/Manifest: clearsign failed: No > secret key > !!! !!! gpg exited with '2' status > !!! Disabled FEATURES='sign' > Warning: untrusted X11 forwarding setup failed: xauth key data not > generated > Warning: No xauth data; using fake authentication data for X11 forwarding. > X11 forwarding request failed on channel 0 > /var/cvsroot/gentoo-x86/dev-lisp/clozurecl/Manifest,v <-- Manifest > new revision: 1.10; previous revision: 1.9 > > Commit complete. > RepoMan sez: "If everyone were like you, I'd be out of business!" > > What else should I do? > Either use a gpg agent or use a curses based version of pinentry. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] kdump
Hi all, if someone is interested in implementing any infrastructure for a more advanced usage of kdump for gentoo, please contact me. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kdump
On 27/03/13 12:40, Rich Freeman wrote: > On Wed, Mar 27, 2013 at 7:27 AM, Justin wrote: >> >> if someone is interested in implementing any infrastructure for a more >> advanced usage of kdump for gentoo, please contact me. >> > > I've blogged a bit about this and wrote the wiki page. However, the > last time I actually tried to use kdump it wasn't working. I don't > remember the details. I know I could boot another kernel immediately, > but if I loaded a crash kernel it wouldn't actually boot on a panic. > > It would be nice to have a more official solution for this on Gentoo. > I don't mind messing around with it. I don't have a ton of time but > if you want to take the lead I can try to pitch in a bit. > > Rich > Hi, Actually I don't need kdump that's why I asked for some input. During the version bump today, I saw that fedora is providing lots of script and services for it. So I thought someone might be interested and port that to gentoo. kexec itself is working fine on gentoo. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-chemistry/talos+
# Justin Lecher (09 Apr 2013) # Fetch fails and mirroring is restricted #465144 =sci-chemistry/talos+-1.2009.1013.14 Please use sci-chemistry/nmrpipe which is in the sci overlay or the webservice at http://spin.niddk.nih.gov/bax/nmrserver/talos/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/id3lib: metadata.xml ChangeLog id3lib-3.8.3-r9.ebuild
On 03/05/13 19:56, Samuli Suominen wrote: > On 03/05/13 20:33, Justin Lecher (jlec) wrote: >> jlec13/05/03 17:33:56 >> >>Modified: metadata.xml ChangeLog >>Added:id3lib-3.8.3-r9.ebuild >>Log: >>media-libs/id3lib: Fix obsolete macros to work with automake-1.13, >> #467704; bumped to EAPI=5 and autotools-utils.eclass >> >>(Portage version: 2.2.0_alpha173/cvs/Linux x86_64, signed Manifest >> commit with key 8009D6F070EB7916) >> >> Revision ChangesPath >> 1.3 media-libs/id3lib/metadata.xml >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/metadata.xml?rev=1.3&view=markup >> >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/metadata.xml?rev=1.3&content-type=text/plain >> >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/metadata.xml?r1=1.2&r2=1.3 >> >> >> Index: metadata.xml >> === >> RCS file: /var/cvsroot/gentoo-x86/media-libs/id3lib/metadata.xml,v >> retrieving revision 1.2 >> retrieving revision 1.3 >> diff -u -r1.2 -r1.3 >> --- metadata.xml16 Jul 2009 19:18:11 -1.2 >> +++ metadata.xml3 May 2013 17:33:56 -1.3 >> @@ -1,5 +1,5 @@ >> >> http://www.gentoo.org/dtd/metadata.dtd";> >> >> -sound >> + sound >> > > What's the point of kludging unrelated commits like this one...? You personally told me, that you want to have metadata.xml indented with two spaces. Did you change your own style? > >> >> >> >> 1.81 media-libs/id3lib/ChangeLog >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/ChangeLog?rev=1.81&view=markup >> >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/ChangeLog?rev=1.81&content-type=text/plain >> >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/id3lib/ChangeLog?r1=1.80&r2=1.81 >> >> >> Index: ChangeLog >> === >> RCS file: /var/cvsroot/gentoo-x86/media-libs/id3lib/ChangeLog,v >> retrieving revision 1.80 >> retrieving revision 1.81 >> diff -u -r1.80 -r1.81 >> --- ChangeLog22 Mar 2012 12:33:36 -1.80 >> +++ ChangeLog3 May 2013 17:33:56 -1.81 >> @@ -1,6 +1,13 @@ >> # ChangeLog for media-libs/id3lib >> -# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 >> -# $Header: /var/cvsroot/gentoo-x86/media-libs/id3lib/ChangeLog,v 1.80 >> 2012/03/22 12:33:36 ssuominen Exp $ >> +# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 >> +# $Header: /var/cvsroot/gentoo-x86/media-libs/id3lib/ChangeLog,v 1.81 >> 2013/05/03 17:33:56 jlec Exp $ >> + >> +*id3lib-3.8.3-r9 (03 May 2013) >> + >> + 03 May 2013; Justin Lecher +id3lib-3.8.3-r9.ebuild, >> + metadata.xml: >> + Fix obsolete macros to work with automake-1.13, #467704; bumped to >> EAPI=5 and >> + autotools-utils.eclass > > There was no reason to use autotools-utils.eclass in the ebuild. Any reason to not using it? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-fs/aufs2
# Justin Lecher (25 May 2013) # Upstream dropped support long ago # Switch to sys-fs/aufs3 or # sys-kernel/aufs-sources sys-fs/aufs2 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rite: sci-biology/allpaths
# Justin Lecher (17 Jul 2013) # superseeded by sci-biology/allpathslg # Upstream wants anybody to move over sci-biology/allpaths signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: fortran-2.eclass - Support for bin package system without compiler
Hello,
I would like to add support for MERGE_TYPE=binary. Therefore I like to
deprecate EAPI < 4 on long term and use MERGE_TYPE now for EAPIs which
support it.
Thanks
Justin
Index: fortran-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.18
diff -u -B -b -u -p -r1.18 fortran-2.eclass
--- fortran-2.eclass 18 Jul 2013 07:03:33 - 1.18
+++ fortran-2.eclass 18 Jul 2013 07:06:41 -
@@ -203,11 +203,11 @@ _fortran_test_function() {
fi
}
-# @FUNCTION: fortran-2_pkg_setup
+# @FUNCTION: _fortran-2_pkg_setup
+# @INTERNAL
# @DESCRIPTION:
-# Setup functionallity,
-# checks for a valid fortran compiler and optionally for its openmp
support.
-fortran-2_pkg_setup() {
+# _The_ fortran-2_pkg_setup()
+_fortran-2_pkg_setup() {
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
@@ -229,6 +229,29 @@ fortran-2_pkg_setup() {
done
}
+
+# @FUNCTION: fortran-2_pkg_setup
+# @DESCRIPTION:
+# Setup functionallity,
+# checks for a valid fortran compiler and optionally for its openmp
support.
+fortran-2_pkg_setup() {
+ if [[ ${EAPI:-0} -lt 4 ]]; then
+ eqawarn "The fortran-2.eclass is going to deprecate support for"
+ eqawarn "EAPI < 4. Please migrate your package to a higher EAPI"
+ eqawarn "or file a bug at https://bugs.gentoo.org";
+ fi
+
+ case ${EAPI:-0} in
+ 0|1|2|3)
+ _fortran-2_pkg_setup ;;
+ 4|5)
+ if [[ ${MERGE_TYPE} != binary ]]; then
+ _fortran-2_pkg_setup
+ fi
+ ;;
+ esac
+}
+
case ${EAPI:-0} in
0|1|2|3|4|5) EXPORT_FUNCTIONS pkg_setup ;;
*) die "EAPI=${EAPI} is not supported" ;;
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fortran-2.eclass - Support for bin package system without compiler
On 18/07/13 09:12, Michał Górny wrote:
>> +
>> +# @FUNCTION: fortran-2_pkg_setup
>> +# @DESCRIPTION:
>> +# Setup functionallity,
>> +# checks for a valid fortran compiler and optionally for its openmp
>> support.
>> +fortran-2_pkg_setup() {
>> + if [[ ${EAPI:-0} -lt 4 ]]; then
>
> Someone else's going to tell you this, so I'll tell you it first hand:
> EAPI is not guaranteed to be a number and you shouldn't be using
> numerical comparison against it.
>
> Not that you support any non-numerical EAPI. But then some people who
> fork eclasses in overlays will have to patch it more to support their
> weird EAPIs. And I'm not pointing my finger at anyone in particular.
>
Doesn't matter to me who is doing crazy things. If I can support it
easily then I will do it.
Next try, which is removes one redundant check.
Thanks for the suggestion.
Index: fortran-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.18
diff -u -B -b -u -p -r1.18 fortran-2.eclass
--- fortran-2.eclass 18 Jul 2013 07:03:33 - 1.18
+++ fortran-2.eclass 18 Jul 2013 07:28:12 -
@@ -203,11 +203,11 @@ _fortran_test_function() {
fi
}
-# @FUNCTION: fortran-2_pkg_setup
+# @FUNCTION: _fortran-2_pkg_setup
+# @INTERNAL
# @DESCRIPTION:
-# Setup functionallity,
-# checks for a valid fortran compiler and optionally for its openmp
support.
-fortran-2_pkg_setup() {
+# _The_ fortran-2_pkg_setup()
+_fortran-2_pkg_setup() {
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
@@ -229,6 +229,26 @@ fortran-2_pkg_setup() {
done
}
+
+# @FUNCTION: fortran-2_pkg_setup
+# @DESCRIPTION:
+# Setup functionallity,
+# checks for a valid fortran compiler and optionally for its openmp
support.
+fortran-2_pkg_setup() {
+ case ${EAPI:-0} in
+ 0|1|2|3)
+ eqawarn "The fortran-2.eclass is going to deprecate support for"
+ eqawarn "EAPI < 4. Please migrate your package to a higher EAPI"
+ eqawarn "or file a bug at https://bugs.gentoo.org";
+ _fortran-2_pkg_setup ;;
+ 4|5)
+ if [[ ${MERGE_TYPE} != binary ]]; then
+ _fortran-2_pkg_setup
+ fi
+ ;;
+ esac
+}
+
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: fortran-2.eclass - Support for bin package system without compiler
On 18/07/13 10:25, Duncan wrote:
> Justin posted on Thu, 18 Jul 2013 09:28:49 +0200 as excerpted:
>
>> + case ${EAPI:-0} in
>> + 0|1|2|3)
>> + eqawarn "The fortran-2.eclass is going to deprecate support
>
> ^^^
>
> That reads strange to me. Deprecated doesn't mean it no longer works; it
> means it's declared obsolete and recommended against but it still works
> for now, thus giving users a time to migrate.[1]
>
> So "is going to deprecate" seems strange. It should be "has deprecated",
> or rewording a bit more "support is deprecated for" or the like. Because
> by the time someone's actually reading that output, the warning is
> already there; the deprecation has already happened.
>
> Alternatively, keep the future tense and say "will be removed" or some
> such, or use a hybrid, "support is deprecated and will be removed".
>
> ---
>
> [1] deprecate/deprecation online references:
> http://en.wiktionary.org/wiki/deprecate
> https://en.wikipedia.org/wiki/Deprecation
> http://www.thefreedictionary.com/deprecate
> http://www.google.com/search?q=define:deprecate
>
As long as there are only wording problems...
Index: fortran-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/fortran-2.eclass,v
retrieving revision 1.18
diff -u -B -b -u -p -r1.18 fortran-2.eclass
--- fortran-2.eclass 18 Jul 2013 07:03:33 - 1.18
+++ fortran-2.eclass 18 Jul 2013 08:42:56 -
@@ -203,11 +203,11 @@ _fortran_test_function() {
fi
}
-# @FUNCTION: fortran-2_pkg_setup
+# @FUNCTION: _fortran-2_pkg_setup
+# @INTERNAL
# @DESCRIPTION:
-# Setup functionallity,
-# checks for a valid fortran compiler and optionally for its openmp
support.
-fortran-2_pkg_setup() {
+# _The_ fortran-2_pkg_setup()
+_fortran-2_pkg_setup() {
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
@@ -229,6 +229,27 @@ fortran-2_pkg_setup() {
done
}
+
+# @FUNCTION: fortran-2_pkg_setup
+# @DESCRIPTION:
+# Setup functionallity,
+# checks for a valid fortran compiler and optionally for its openmp
support.
+fortran-2_pkg_setup() {
+ case ${EAPI:-0} in
+ 0|1|2|3)
+ eqawarn "Support for EAPI < 4 will be removed from the"
+ eqawarn "fortran-2.eclass in near future."
+ eqawarn "Please migrate your package to a higher EAPI"
+ eqawarn "or file a bug at https://bugs.gentoo.org";
+ _fortran-2_pkg_setup ;;
+ 4|5)
+ if [[ ${MERGE_TYPE} != binary ]]; then
+ _fortran-2_pkg_setup
+ fi
+ ;;
+ esac
+}
+
case ${EAPI:-0} in
0|1|2|3|4|5) EXPORT_FUNCTIONS pkg_setup ;;
*) die "EAPI=${EAPI} is not supported" ;;
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: fortran-2.eclass - Support for bin package system without compiler
On 18/07/13 17:39, Donnie Berkholz wrote:
> On 10:44 Thu 18 Jul , Justin wrote:
>> +fortran-2_pkg_setup() {
>> + case ${EAPI:-0} in
>> + 0|1|2|3)
>> + eqawarn "Support for EAPI < 4 will be removed from the"
>> + eqawarn "fortran-2.eclass in near future."
>> + eqawarn "Please migrate your package to a higher EAPI"
>> + eqawarn "or file a bug at https://bugs.gentoo.org";
>> + _fortran-2_pkg_setup ;;
>
> It's more useful if you provide a date here (30+ days from the commit)
> after which things are no longer guaranteed to work, versus "near
> future."
>
> I didn't catch it in your original email — have you run a scan to see
> how many ebuilds are affected?
>
I did.
In absolute numbers there per EAPI following consumers
1: 2
2: 24
3: 32
4: 106
5: 71
but there are only 10 packages where there is no version with a
sufficient high EAPI?
Most if not all affected packages are under the control of sci, so that
I can easily manage the transition.
I think I will place the deadline 60 days ahead after committing.
Everybody who likes to see the immediate affect just need to bump the
packages to the correct EAPI?
Justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On 7/21/13 4:26 PM, Michael Weber wrote: > On 07/21/2013 01:42 PM, Pacho Ramos wrote: >> Would be possible to generate and provide squashed files at the >> same time tarballs with portage tree snapshots are generated? >> mksquashfs can take a lot of resources depending on the machine, >> but providing the squashed images would still benefit people >> allowing them to download and mount them > > I've establish a cron job on my server to generate gzip and xz > squashed snapshots. I sync distfiles from utwente at 6:05 and generate > the squashfs at 6:35 after verifying the gpg signatures. > There's a 10,5h lag between snapshots and squashfs files - we could > improve if I'm allowed to sync against master rsync/dinstfiles. > > [1] http://lore.xmw.de/gentoo/genberry/snapshots/ > > I am creating them as well. Perhaps we can bundle the effort. What I also found out that using zsync is quite efficient with squashfs images. I normally don't sync more then 20-30% of the image. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: intel-sdp.eclass - support for absolute location of rpms
Hi,
this patch adds proper support for rpm location outside the main directory.
The old API only allowed defining the rpm basic name, which gets
combined with the possible subdirs containing rpms.
The new API only allows a single main directory where it expects rpms
in. If there are rpms outside this dir, you need to give the full path.
Thanks for comments,
Justin
--- /local/home/justin/tree/eclass/intel-sdp.eclass 2013-07-19
16:00:50.0 +0200
+++ intel-sdp.eclass2013-07-22 14:02:16.686582103 +0200
@@ -65,11 +65,10 @@
# Possibility to skip the mandatory check for licenses. Only set this
if there
# is really no fix.
-# @ECLASS-VARIABLE: INTEL_RPMS_DIRS
+# @ECLASS-VARIABLE: INTEL_RPMS_DIR
# @DESCRIPTION:
-# List of subdirectories in the main archive which contains the
-# rpms to extract.
-: ${INTEL_RPMS_DIRS:=rpm}
+# Main subdirectory which contains the rpms to extract.
+: ${INTEL_RPMS_DIR:=rpm}
# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
@@ -84,6 +83,11 @@
# Functional name of rpm without any version/arch tag
#
# e.g. compilerprof
+#
+# if the rpm is located in a directory different to INTEL_RPMS_DIR you can
+# specify the full path
+#
+# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DEFAULT_UNSET
@@ -92,6 +96,11 @@
# without any version tag
#
# e.g. openmp
+#
+# if the rpm is located in a directory different to INTEL_RPMS_DIR you can
+# specify the full path
+#
+# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli-common
# @ECLASS-VARIABLE: INTEL_SDP_DB
# @DESCRIPTION:
@@ -328,14 +337,23 @@
INTEL_ARCH="intel64 ia32"
fi
fi
- INTEL_RPMS=""
+ INTEL_RPMS=()
+ INTEL_RPMS_FULL=()
for p in ${INTEL_BIN_RPMS}; do
- for a in ${arch}; do
- INTEL_RPMS+="
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.${a}.rpm"
- done
+ if [ ${p} == $(basename ${p}) ]; then
+ for a in ${arch}; do
+ INTEL_RPMS+=(
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.${a}.rpm
)
+ done
+ else
+ INTEL_RPMS_FULL+=(
${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.${a}.rpm )
+ fi
done
for p in ${INTEL_DAT_RPMS}; do
- INTEL_RPMS+="
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.noarch.rpm"
+ if [ ${p} == $(basename ${p}) ]; then
+ INTEL_RPMS+=(
intel-${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.noarch.rpm
)
+ else
+ INTEL_RPMS_FULL+=(
${p}-${_INTEL_PV4}-${_INTEL_PV1}.${_INTEL_PV2}-${_INTEL_PV3}.noarch.rpm )
+ fi
done
case "${EAPI:-0}" in
@@ -347,23 +365,31 @@
# @DESCRIPTION:
# Unpacking necessary rpms from tarball, extract them and rearrange the
output.
intel-sdp_src_unpack() {
- local l r subdir rb t list=()
+ local l r subdir rb t list=() debug_list
for t in ${A}; do
- for r in ${INTEL_RPMS}; do
- for subdir in ${INTEL_RPMS_DIRS}; do
- rpmdir=${t%%.*}/${subdir}
- debug-print "Adding to decompression list:
${rpmdir}/${r}"
- list+=( ${rpmdir}/${r})
- done
+ for r in ${INTEL_RPMS[@]}; do
+ rpmdir=${t%%.*}/${INTEL_RPMS_DIR}
+ list+=( ${rpmdir}/${r} )
+ done
+
+ for r in ${INTEL_RPMS_FULL[@]}; do
+ list+=( ${t%%.*}/${r} )
done
- tar xvf "${DISTDIR}"/${t} ${list[@]} &>
"${T}"/rpm-extraction.log || die
+
+ debug_list="$(IFS=$'\n'; echo ${list[@]} )"
+
+ debug-print "Adding to decompression list:"
+ debug-print ${debug_list}
+
+ tar xvf "${DISTDIR}"/${t} ${list[@]} &>
"${T}"/rpm-extraction.log
+
for r in ${list[@]}; do
rb=$(basename ${r})
l=.${rb}_$(date +'%d%m%y_%H%M%S').log
einfo "Unpacking ${rb}"
rpm2tar -O ${r} | tar xvf - | sed -e \
- "s:^\.:${EROOT#/}:g" > ${l} || die "unpacking
${r} failed"
+ "s:^\.:${EROOT#/}:g" > ${l}; assert "unpacking
${r} failed"
mv ${l} opt/intel/ || die "failed moving extract log
file"
done
done
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] "Upgraded" Developer Joachim Bartosik (jbartosik)
Hi, I would like to announce that Joachim Bartosik (jbartosik) just joined the team as a "full" dev. He contributed as a staffer before and would like to help now various areas, among others in the gnome project. Please give him again a warm welcome. Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last Rite: sci-libs/mccp4
+# Justin Lecher (11 Aug 2013) +# Not needed anymore +# All consumer upstreams moved away from it +sci-libs/mccp4 + signature.asc Description: OpenPGP digital signature
[gentoo-dev] [gentoo-project] New developer: Alexander Berntsen (bernalex)
Hello everyone, please join me in giving Alexander (bernalex) a very warm welcome. When asking for his reason to be become a member of the dev team, he said among other things "I would be proud to be a Gentoo dev". I like it very much, that one can still be proud to be part of this team and community. Let's spread this spirit. He is joining us as staffer (for now, let's see what the future brings) to work on portage (the PM) development, where he already contributed code. He also has been actively helping with Gentoo Haskell, which will be another region of interest for him. And finally he also is in contact with the licensing team. One of the questions we asked him and where we got some impressive answer, was What other projects have you contributed to, if any? Some of the more mentionable ones follows. bweakfwu F-Droid GNU LibreJS i3 Libregamewiki LIMBS OFF ndla OpenRC quizbot Portage Project Sunrise PRISM break reactive-banana So it seems he loves to contribute to voluntary project, which we greatly appreciate. This also resembles in the lines he wrote about himself. I'm a free software hacker wizard who lives in Norway with my cohabitant who occasionally bakes me muffins. I have used Gentoo for many years, and am particularly interested in Portage. My main interests are hacking, free software, free culture, computer games, interactive fiction, role-playing games, fantasy literature, science fiction cinema, anime, music, and cosmology. Feel very welcome, Alexander, Justin P.s. And don't worry, Diego already kindly asked him to not port portage to haskell ;). signature.asc Description: OpenPGP digital signature
