[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/
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/eclass/commons-jelly-tags-2.eclass
*
/home/alistair/gentoo/overlays/java-experimental/eclass/java-pkg-2.eclass
*
[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
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
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.
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] 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
[gentoo-dev] Re: perl-module.eclass -- review - 2
* Donnie Berkholz dberkh...@gentoo.org:
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.
[gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
Hi, Petteri Räty betelge...@gentoo.org: 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-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - 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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: bzr.eclass
Hi, Brian Harring ferri...@gmail.com: 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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
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
