Re: [gentoo-dev] QA Overlay Layout support.
Donnie Berkholz wrote: On 19:18 Mon 02 Mar , Alistair Bush wrote: Donnie Berkholz wrote: Could you explain what you see as the important difference that makes package.mask bad and a separate overlay good? Contributors sometimes have difficulty following standards (hell even dev's do). I have little confidence that would also be able to actually add packages to package.mask without breaking anything else. As an example we had a contributor break the manifests of a dozen or so packages because he updated the Copyright header then couldn't get the ebuild to manifest. I can imagine someone committing dev-java/ant-core to the file. That and there are 325 ebuilds [1] in java-experimental. Masking even 1/2 of them separately would be a complete nightmare. I also note that sunrise doesn't seem to do this either. Also no ebuilds are ever marked stable, so it should be easy for someone to just add an entry in their package.keywords file. And what is stopping a user from wanting to have their own overlay, that uses java-overlay ( or java-experimental or any other overlay ) packages. Are we to say that we shouldn't allow tools to have support for this. I think that it is a nature progression that if we are to allow overlays to extend the portage tree that we should allow overlays to extend other overlays. [1] java-experimental $ find . -iname '*.ebuild' | wc -l
[gentoo-dev] Re: bzr.eclass
Hi, Brian Harring : > Kindly drop that; the REPO_URI/BRANCH seperation that is in use there > really isn't all that useful for bzr ebuilds in my experience- more > often then not it winds up biting me in the ass rather then being > useful. > My usage (and understanding of bzr), there isn't a scenario where > seperation of the repo and branch applies- you only need the branch > uri, that encompasses it all (unlike cvs, where this probably was > inherited from). Yes, this sounds sane to me, so I will try to work something out. > So... any reason to even have the var seperation like that? Nothing I can think of. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
Hi, Petteri Räty : > Let's try something new. I would like to get opinions from as many > people as possible about GLEP 55 and alternatives listed here in order > to get some idea what the general developer pool thinks. Everyone is > only allowed to post a single reply to this thread in order to make it > easy to read through. The existing thread should be used for actual > discussion about the GLEP and the alternatives. This should be a > useful experiment to see if we can control ourselves :) Thanks. > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage All of them are ugly as hell. Though a) has my preference because of the added flexibility. Can we use cool names instead of numbers as eapi or omit the dash? => .ebuild3 or .ebuild-upyours > 3) EAPI in locked down place in the ebuild No, you never know when you need the flexibility. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: perl-module.eclass -- review - 2
* Donnie Berkholz : Thanks for your comments. > On 12:28 Sat 28 Feb , Torsten Veller wrote: > > case "${EAPI:-0}" in > > 0|1) > > EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm > > pkg_postrm src_compile src_install src_test src_unpack > > ;; > > *) > > EXPORT_FUNCTIONS src_unpack src_prepare src_configure > > src_compile src_test src_install > > ;; > > esac > > Maybe this is just me, but I prefer to reserve '*' cases for the > fallback when I don't understand what I'm given. As this is a general problem we should move it out of this thread. I also think this should have been discussed months ago. > > find "${D}/${VENDOR_LIB}" -type f -a \( -name .packlist \ > > -o \( -name '*.bs' -a -empty \) \) -delete > > find "${D}/${VENDOR_LIB}" -depth -mindepth 1 -type d -empty -delete > > I'm curious how portable the find () construct is. Do you know? http://www.opengroup.org/onlinepubs/95399/utilities/find.html The brackets are no problem. But -mindepth and -delete are not in the specs: | The -mindepth and -maxdepth options are GNU extensions that should be | avoided if possible. (from devmanual.g.o) Well, even the portage ebuild uses -mindepth. So should I replace it? | The `-delete' action was introduced by the BSD family of operating | systems (from `info find`) and is also used several times in the tree. > > find "${D}" -type f -not -name '*.so' | while read f ; do > > if file "${f}" | grep -q -i " text" ; then > > if grep -q "${D}" "${f}" ; then ewarn "QA: File contains a temporary path > > ${f}" ; fi > > sed -i -e "s:${D}:/:g" "${f}" || die > > Could you just use dosed here? I guess you mean the default expression? dosed defaults to "s:${D}::g" $D is supposed to end with a trailing slash. -> is the path still absolute? Strange at least. BTW: After I looked up the devmanual part about "find" above, I wonder: | find "${S}" -type f | while read f ; do | [...] | for f in $(find "${S}" -type f) ; do | [...] | Warning | In both cases, files with weird characters or spaces in their names may | cause serious problems. Is there still a problem in the snippet above and is the following better (if we assume that packages contain files with sane names)? pushd "${D}" > /dev/null for f in $(find . -type f -not -name '*.so' ) ; do if file "${f}" | grep -q -i " text" ; then sed -i -e "s:${D}:/:g" "${f}" || die fi done popd > /dev/null Maybe i need some coffee.
Re: [gentoo-dev] QA Overlay Layout support.
On 19:18 Mon 02 Mar , Alistair Bush wrote: > Donnie Berkholz wrote: >> Combine this with package.mask. To me, experimental means masked. > > Experimental within java means a lot of things, or at least it should. > Anything from user contributed and non-dev qa'd to packages with bundled > jars to attempts to package projects like maven which are difficult and > time consuming ( and which attempts to do so have failed numerous times > before might I add ). > > Asking non-dev contributors to handle package.mask's would be a "less > than ideal". Resulting in "interesting breakages". Currently by adding > java-experimental ( which might I add isn't available thru layman ) you > are accepting that risk. I don't understand the distinction you're making here. Either way, users explicitly take a manual action to enable additional experimental packages (unmasking or adding an overlay full of them). In fact, I see the separate-overlay option as worse because then you get *everything* from the overlay, whereas package.mask is more granular and can be fine-tuned per-package. Could you explain what you see as the important difference that makes package.mask bad and a separate overlay good? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpd33P1B6Dqm.pgp Description: PGP signature
Re: [gentoo-dev] QA Overlay Layout support.
Donnie Berkholz wrote: On 11:59 Sun 25 Jan , Alistair Bush wrote: Possible Solution: Merging java-overlay and java-experimental. From my perspective this isn't a good one as we loss most of the benefits of java-experimental. Combine this with package.mask. To me, experimental means masked. Experimental within java means a lot of things, or at least it should. Anything from user contributed and non-dev qa'd to packages with bundled jars to attempts to package projects like maven which are difficult and time consuming ( and which attempts to do so have failed numerous times before might I add ). Asking non-dev contributors to handle package.mask's would be a "less than ideal". Resulting in "interesting breakages". Currently by adding java-experimental ( which might I add isn't available thru layman ) you are accepting that risk. At least java and kde have need of this, and I could imagine sunrise could also use this ( either now or in the future ). I have implemented a patch [1] tho support this from a repoman perspective but believe its benefits could go much further. Eventually I hope that zmedico will accept it, once he has a chance to consider it and I have time to clean it up. Once repository support is implemented (this is very much depending on the details of the implementation) I will start making a patch to will have portage check whether an overlays parents are "before" that overlay. ali_bush [1] http://dev.gentoo.org/~ali_bush/portage_parent_repo_support.patch
Re: [gentoo-dev] Re: perl-module.eclass -- review - 2
On 12:28 Sat 28 Feb , Torsten Veller wrote: > case "${EAPI:-0}" in > 0|1) > EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm > pkg_postrm src_compile src_install src_test src_unpack > ;; > *) > EXPORT_FUNCTIONS src_unpack src_prepare src_configure > src_compile src_test src_install > ;; > esac Maybe this is just me, but I prefer to reserve '*' cases for the fallback when I don't understand what I'm given. > find "${D}/${VENDOR_LIB}" -type f -a \( -name .packlist \ > -o \( -name '*.bs' -a -empty \) \) -delete > find "${D}/${VENDOR_LIB}" -depth -mindepth 1 -type d -empty -delete I'm curious how portable the find () construct is. Do you know? > find "${D}" -type f -not -name '*.so' | while read f ; do > if file "${f}" | grep -q -i " text" ; then > if grep -q "${D}" "${f}" ; then ewarn "QA: File contains a temporary path > ${f}" ; fi > sed -i -e "s:${D}:/:g" "${f}" || die Could you just use dosed here? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpWs6JUuSQUs.pgp Description: PGP signature
Re: [gentoo-dev] QA Overlay Layout support.
On 11:59 Sun 25 Jan , Alistair Bush wrote: > Possible Solution: > > Merging java-overlay and java-experimental. From my perspective this > isn't a good one as we loss most of the benefits of java-experimental. Combine this with package.mask. To me, experimental means masked. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpLHb6tIrr5j.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-03-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-03-01 23h59 UTC. Removals: media-fonts/mikachan-font 2009-02-25 12:53:27 flameeyes x11-base/kdrive 2009-02-28 07:58:22 remi net-print/omni 2009-02-28 08:00:13 remi x11-misc/fluxbg 2009-02-28 08:01:05 remi dev-dotnet/mcatalog 2009-02-28 23:39:14 loki_val dev-dotnet/gtkgl-sharp 2009-02-28 23:42:32 loki_val app-pda/dopi2009-02-28 23:47:12 loki_val media-sound/monopod 2009-02-28 23:52:21 loki_val dev-dotnet/gda-sharp2009-03-01 01:01:25 loki_val dev-dotnet/gnomedb-sharp2009-03-01 01:02:16 loki_val net-im/tmsnc2009-03-01 21:01:47 tester Additions: dev-java/jsr311-api 2009-02-23 10:37:45 robbat2 net-analyzer/nagtrap2009-02-23 20:13:03 dertobi123 dev-games/openscenegraph2009-02-24 13:26:59 tupone app-admin/augeas2009-02-24 15:49:22 matsuu dev-ml/ocaml-augeas 2009-02-24 15:49:38 matsuu dev-python/python-augeas2009-02-24 15:49:55 matsuu dev-ruby/ruby-augeas2009-02-24 15:50:11 matsuu x11-terms/yeahconsole 2009-02-25 17:01:49 jer dev-ruby/net-ssh-multi 2009-02-25 21:09:07 robbat2 app-text/chm2pdf2009-02-26 11:50:49 hwoarang media-gfx/freepv2009-02-26 13:01:58 voyageur sci-biology/maq 2009-02-26 17:07:01 weaver sci-astronomy/scamp 2009-02-26 17:22:47 bicatali sci-biology/maqview 2009-02-26 18:22:42 weaver sci-biology/bwa 2009-02-26 22:11:27 weaver sci-biology/phred 2009-02-27 00:04:24 weaver sci-biology/trf 2009-02-27 00:11:33 weaver sci-biology/repeatmasker-libraries 2009-02-27 00:12:51 weaver sci-biology/repeatmasker2009-02-27 00:16:15 weaver sci-biology/lagan 2009-02-27 00:23:49 weaver media-video/ffprobe 2009-02-27 18:40:56 beandog dev-python/pygraphviz 2009-02-27 20:49:23 bicatali dev-python/logilab-constraint 2009-02-28 19:19:46 patrick dev-python/networkx 2009-02-28 19:40:26 bicatali dev-python/fusil2009-02-28 19:40:44 patrick dev-python/louie2009-02-28 20:04:29 patrick dev-python/pyproj 2009-02-28 20:16:57 patrick dev-python/snakefood2009-02-28 20:26:23 patrick app-crypt/gorilla 2009-02-28 20:50:22 patrick gpe-base/gpe-icons 2009-02-28 23:51:52 solar gpe-base/libgpewidget 2009-02-28 23:52:44 solar gpe-base/libgpepimc 2009-03-01 00:06:25 solar app-benchmarks/filebench2009-03-01 00:15:23 patrick gpe-base/libmimedir 2009-03-01 00:16:31 solar gpe-base/libeventdb 2009-03-01 00:23:21 solar gpe-base/libtododb 2009-03-01 00:26:01 solar gpe-base/libgpevtype2009-03-01 00:31:48 solar app-forensics/rdd 2009-03-01 00:36:59 patrick gpe-base/libcontactsdb 2009-03-01 00:37:57 solar app-forensics/libewf2009-03-01 00:46:59 patrick gpe-base/libgpelaunch 2009-03-01 00:51:42 solar app-forensics/afflib2009-03-01 00:59:58 patrick gpe-base/libschedule2009-03-01 01:00:27 solar gpe-base/libgtkstylus 2009-03-01 01:03:37 solar gpe-base/libhandoff 2009-03-01 01:10:57 solar net-wireless/blueman2009-03-01 09:09:17 dev-zero media-fonts/culmus-ancient 2009-03-01 09:35:55 pva dev-util/kdevplatform 2009-03-01 10:13:23 tampakrap dev-perl/PerlIO-gzip2009-03-01 10:48:08 pva -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-fonts/mikachan-font,removed,flameeyes,2009-02-25 12:53:27 x11-base/kdrive,removed,remi,2009-02-28 07:58:22 net-print/omni,removed,remi,2009-02-28 08:00:13 x11-misc/fluxbg,removed,remi,2009-02-28 08:01:05 dev-dotnet/mcatalog,removed,loki_val,2009-02-28 23:39:14 dev-dotnet/gtkgl-sharp,removed,loki_val,2009-02-28 23:42:32 app-pda/dopi,removed,loki_val,2009-02-28 23:47:12 media-sound/monopod,removed,lok
Re: [gentoo-dev] QA Overlay Layout support.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alistair Bush wrote: > Here is an issue that is currently being faced by the java project that > I would like to bring to the attention of everyone. I have already > discussed this will devs from all pm's. > > Intro: > > Within the java project we have 2 overlays. java-overlay and > java-experimental. java-overlay is mean't to be a "stable" overlay, is > available through layman while java-experimental is the opposite. We > attempt to not add packages to gentoo unless they are a dependency or an > application to help with maintainability. We allow newbies access to > java-experimental and there are a number of packages that are difficult > to support so are still very much experimental. Sorry for taking so long to reply to the mail. The KDE team had followed the Java example, but has since been forced to merge the 2 overlays together, exactly because of the issues discussed in this mail. > The way we are currently using the overlays results in a hierachy of > gentoo > java-overlay > java-experimental. Where > packages/eclasses/profiles can be inherited from the previous repository. > > Problem: > > Repoman currently only checks the current repository/overlay and gentoo. > This is a problem for java-experimental. Agreed. > These are the following problems:- > > 1) repoman does not find eclasses used to by java-experimental ebuilds > that are located in java-overlay. see [1] for error. Maintaining the > eclass in multiple locations _is not a solution_.(zmedico is expecting > to add repository support at some point with support for specifying > ECLASSDIRS. So this issue may be resolved). > > 2) repoman does not find packages used to by java-experimental ebuilds > that are located in java-overlay. > > Now this might be a result of the package not existing within gentoo or > as a result of a particular version/slot being available within > java-overlay. Now zmedico suggested that the use of repository deps ( > aka ::java-overlay ) could be the solution. I would rather this not be > the solution as packages shouldn't need to be edited to more them > between overlays. Also the dependency specified could be moved into gentoo. Repository deps would be very helpful. They could be used to "link" packages in an overlay to packages in another overlay. > Possible Solution: > > Now im going to shoot myself in the foot here by mentioning the > unmentionable. > > ( -->> ) paludis ( <<-- ) currently has support for specifying an > overlays parent(s) (master_repository) within an overlays > metadata/layout.conf file. Now i'm not suggesting that paludis's > implementation is the correct one, but I believe the concept is solid. > By specifying an overlays parent repositories would allow (at least): > > 1) emerge to error if that repository/overlay is not configured.; and > 2) repoman to locate packages by checking the current overlay, gentoo as > well as the parents specified within an "overlay metadata file" > > Possible Solution: > > Merging java-overlay and java-experimental. From my perspective this > isn't a good one as we loss most of the benefits of java-experimental. I agree, but that's what we (KDE) were forced to do. > Discussion: > > Do you support the "overlay metadata file" concept? > Are there any other possible solutions? > Is there anything stopping this from being implemented? another EAPI? > profile EAPI? > Is there anything else that would benefit from an "overlay metadata > file"? Default conf variables e.g ECLASSDIRS. > Any other comments? > > > Thanks > ali_bush > > Alistair Bush > Gentoo Linux Developer > > [1] > * ERROR: dev-java/commons-jelly-tags-util-1.0 failed. > > * Call stack: > > *ebuild.sh, line 1881: Called source > '/home/alistair/gentoo/overlays/java-experimental/dev-java/commons-jelly-tags-util/commons-jelly-tags-util-1.0.ebuild' > > > * commons-jelly-tags-util-1.0.ebuild, line7: Called inherit > 'commons-jelly-tags-2' > > *ebuild.sh, line 1238: Called qa_source > '/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass' > > > *ebuild.sh, line 37: Called source > '/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass' > > > * commons-jelly-tags-2.eclass, line 30: Called inherit > 'java-pkg-2' 'java-ant-2' 'java-maven-2' > > *ebuild.sh, line 1215: Called die > > * The specific snippet of code: > > * [ ! -e "$location" ] && die "${1}.eclass could not be > found by inherit()" > * The die message: > > * java-maven-2.eclass could not be found by inherit() > > * > > * If you need support, post the topmost build error, and the call stack > if relevant. > * This ebuild used the following eclasses from overlays: > > * > /home/alistair/gentoo/overlays/java-experimental/
[gentoo-dev] Monthly Gentoo Council Reminder for March
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/