[gentoo-dev] last rite: media-libs/raul

2021-01-09 Thread Miroslav Šulc

# Miroslav Šulc  (2021-01-09)
# media-sound/patchage used to depend on it but the dependency
# has been dropped in v1.0.0. There are no other packages in the tree
# depending on it. Also having issues compiling it. Removal in 30 days.
media-libs/raul




Re: [gentoo-dev] [PATCH 0/2] eclass/java-{utils-2,pkg-simple}.eclass: features and enhancements

2020-08-30 Thread Miroslav Šulc

hi all,

it's committed now:

commit a4d773b4c2f433438b00010bbf0981c81e123d1b (HEAD -> master, 
origin/master, origin/HEAD)

Author: Zhang Zongyu 
Date:   Wed Aug 26 00:30:10 2020 +0800

    patching ebuild files to support new java-pkg-simple

    Signed-off-by: Zhang Zongyu 
    Signed-off-by: Miroslav Šulc 

commit faa407032918b43fafe7d4e1de85dde4d30ba4f2
Author: Zhang Zongyu 
Date:   Wed Aug 26 00:30:09 2020 +0800

    java-pkg-simple.eclass and java-utils-2.eclass: features and 
enhancements


    1) support java resources
    2) support java main class and launcher
    3) enable java-pkg-simple_src_test()
    4) support binary jars (both for resolve circular deps and for 
pkgdiff test)


    Signed-off-by: Zhang Zongyu 
    Signed-off-by: Miroslav Šulc 

regards.

fordfrog


Dne 28. 08. 20 v 19:25 Miroslav Šulc napsal(a):

hi all,

jfyi, i'm going to commit these changes to the main tree at the end of 
the weekend if there are no objections. (i've been mentoring this 
project.) we have some other work that depends on these patches so i'd 
like to see it in the main tree as soon as possible.


regards.

fordfrog


Dne 25. 08. 20 v 17:46 zongyu napsal(a):

Dear all,

  I am one of the students who attend Gentoo's Google Summer of Code
  program [1] this year. And this email is attempting to trigger a
  review for a patch for eclass/java-{utils-2,pkg-simple}.eclass.

  Java-pkg-simple.eclass is widely used by java packages that do not
  provide a build.xml for building with java-ant-2.eclass. Although
  java-pkg-simple.eclass works well right now, it still lacks some
  features [2], such as installing java resources and providing
  src_test() function.

  The patch below is trying to enable some missing features of
  java-pkg-simple.eclass, including:
  1. Since some java packages (e.g. dev-java/commons-io) has java
 resources bundled in jar files, java-pkg-simple.eclass now 
has a

 function java-pkg-simple_prepend_resources() to recognize and
 install those java resource files;
  2. Some java packages have a "main class" so that we can execute
 the jar file from command line. With "JAVA_MAIN_CLASS" and
 "JAVA_LAUNCHER_FILENAME", the eclass can deal with the 
situation

 properly;
  3. Enabling src_test() function with multiple testing frameworks
 like junit, testng, pkgdiff and so on;
  4. Pkgdiff test will compare natively compiled jar file and 
upstream
 provided binary jar file, to support the feature the eclass 
will
 fetch pre-compiled java jars and accept 
"JAVA_BINJAR_FILENAME" to

 identify it.
 Besides, installing binjar will help resolve circular
 dependencies, so the eclass also accepts USE="binary" and
 installs the binary jars now.

  And for java-utils-2.eclass:
  1. To support java-pkg-simple_src_test(), there is a new function
 etestng() to launch java tests with dev-java/testng.

  Finally, there is a breaking change to java-pkg-simple. Instead of
  treating "JAVA_SRC_DIR" as a string of directories separated by
  spaces, currently the eclass will treat it as an array. A few
  packages will be affected and fail to build, and the second patch
  will solve the problem.

  P.S.
  This is the first time for me to write a patch for such a huge
  project and send such an email. I hope this email will meet your
  requirements, and I would appreciate your every response.

  Regards,
  Zhang Zongyu

  [1] the GSoC program
https://summerofcode.withgoogle.com/projects/#4994566568017920
  [2] a related bug
  https://bugs.gentoo.org/564158

zongyu (2):
   java-pkg-simple.eclass and java-utils-2.eclass: features and
 enhancements
   patching ebuild files to support new java-pkg-simple

  dev-java/juel/juel-2.1.0-r2.ebuild    |   2 +-
  dev-java/piccolo2d/piccolo2d-3.0-r1.ebuild    |   2 +-
  .../swingx-ws-1.0_p20110515-r1.ebuild |   4 +-
  .../xml-commons/xml-commons-1.4.01.ebuild |   2 +-
  dev-java/xsdlib/xsdlib-20090415.ebuild    |   4 +-
  eclass/java-pkg-simple.eclass | 379 --
  eclass/java-utils-2.eclass    |  38 ++
  7 files changed, 395 insertions(+), 36 deletions(-)







[gentoo-dev] last rite: media-sound/traverso

2020-08-29 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-29)
# Upstream has version 1.1.2, but only for Windows,
# sources are gone. Removal in 30 days.
media-sound/traverso




Re: [gentoo-dev] [PATCH 0/2] eclass/java-{utils-2,pkg-simple}.eclass: features and enhancements

2020-08-28 Thread Miroslav Šulc

hi all,

jfyi, i'm going to commit these changes to the main tree at the end of 
the weekend if there are no objections. (i've been mentoring this 
project.) we have some other work that depends on these patches so i'd 
like to see it in the main tree as soon as possible.


regards.

fordfrog


Dne 25. 08. 20 v 17:46 zongyu napsal(a):

Dear all,

  I am one of the students who attend Gentoo's Google Summer of Code
  program [1] this year. And this email is attempting to trigger a
  review for a patch for eclass/java-{utils-2,pkg-simple}.eclass.

  Java-pkg-simple.eclass is widely used by java packages that do not
  provide a build.xml for building with java-ant-2.eclass. Although
  java-pkg-simple.eclass works well right now, it still lacks some
  features [2], such as installing java resources and providing
  src_test() function.

  The patch below is trying to enable some missing features of
  java-pkg-simple.eclass, including:
  1. Since some java packages (e.g. dev-java/commons-io) has java
 resources bundled in jar files, java-pkg-simple.eclass now has a
 function java-pkg-simple_prepend_resources() to recognize and
 install those java resource files;
  2. Some java packages have a "main class" so that we can execute
 the jar file from command line. With "JAVA_MAIN_CLASS" and
 "JAVA_LAUNCHER_FILENAME", the eclass can deal with the situation
 properly;
  3. Enabling src_test() function with multiple testing frameworks
 like junit, testng, pkgdiff and so on;
  4. Pkgdiff test will compare natively compiled jar file and upstream
 provided binary jar file, to support the feature the eclass will
 fetch pre-compiled java jars and accept "JAVA_BINJAR_FILENAME" to
 identify it.
 Besides, installing binjar will help resolve circular
 dependencies, so the eclass also accepts USE="binary" and
 installs the binary jars now.

  And for java-utils-2.eclass:
  1. To support java-pkg-simple_src_test(), there is a new function
 etestng() to launch java tests with dev-java/testng.

  Finally, there is a breaking change to java-pkg-simple. Instead of
  treating "JAVA_SRC_DIR" as a string of directories separated by
  spaces, currently the eclass will treat it as an array. A few
  packages will be affected and fail to build, and the second patch
  will solve the problem.

  P.S.
  This is the first time for me to write a patch for such a huge
  project and send such an email. I hope this email will meet your
  requirements, and I would appreciate your every response.

  Regards,
  Zhang Zongyu

  [1] the GSoC program
  https://summerofcode.withgoogle.com/projects/#4994566568017920
  [2] a related bug
  https://bugs.gentoo.org/564158

zongyu (2):
   java-pkg-simple.eclass and java-utils-2.eclass: features and
 enhancements
   patching ebuild files to support new java-pkg-simple

  dev-java/juel/juel-2.1.0-r2.ebuild|   2 +-
  dev-java/piccolo2d/piccolo2d-3.0-r1.ebuild|   2 +-
  .../swingx-ws-1.0_p20110515-r1.ebuild |   4 +-
  .../xml-commons/xml-commons-1.4.01.ebuild |   2 +-
  dev-java/xsdlib/xsdlib-20090415.ebuild|   4 +-
  eclass/java-pkg-simple.eclass | 379 --
  eclass/java-utils-2.eclass|  38 ++
  7 files changed, 395 insertions(+), 36 deletions(-)





[gentoo-dev] last rite: media-libs/slv2

2020-08-22 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-22)
# SLV2 has been replaced by Lilv. The latest and final version
# of SLV2 is 0.6.6, released on May 26, 2009.
# Removal in 30 days.  Bug #735380.
media-libs/slv2



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Miroslav Šulc

Dne 18. 08. 20 v 19:06 Joonas Niilola napsal(a):

On 8/18/20 7:30 PM, Miroslav Šulc wrote:

hi,

how would be handled cases where you and me agreed that you will take
care of pull requests on behalf of sound@ and proaudio@? and what if a
package is maintained by multiple maintainers or even some maintainers
and a project, each with a different preference? how that would be
solved to not bring in some confusion? and how about maintainers that
are not gentoo devs? and what if there are packages that have a
maintainer that is mia but has the no-accept policy set and some other
dev would like to fix a package that has an annoying bug (using a pull
request by a contributor) as the reported maintainer is mia, or a
contributor might want to maintain the package? and what if a
maintainer wants pull requests just for some packages and not for
others? and what if a pull request is referenced from a bug at
bugzilla but the maintainer does not accept pull requests?

One idea for implementation would be to enable the flag in your User:
page. Then if any member in a project has it enabled, the project would
have it set positive as well. However it doesn't necessary directly
translate to you you merging personal PRs -> you merging all of your
project PRs. I also thought the project could count Yes's and No's from
their members, printing something like "This project has a 66 %
probability of handling Github PRs". But that'd look silly.
is there a way or would it be possible to get notified on pull requests 
that are relevant to me? though i get notifications from github, i get 
tens to hundreds daily and most of them are irrelevant to me so 
searching for those few that are related to me is really inefficient for 
me.

...

If the current maintainer is MIA, it doesn't change anything from our
current situation. At least it doesn't make it any worse than it is, but
has advantages for those available. I'm sorry I may have not understood
your question correctly here? We can claim maintainer timeout, or ask QA
to deal with these situations. It wouldn't change.
if a maintainer is mia and does not accept pull requests, there is much 
lower chance to get his/her package fixed/bumped. i personally do not 
hesitate to step up and fix a package though i do not maintain it if the 
bug bothers me and i see no activity from the maintainer. and if i can 
find a pull request for such a package, it could save me some time. so 
what i had on my mind is a situation with maintainer mia + 
no-pull-requests-policy -> worse situation than maintainer mia and 
yes-pull-requests-policy.

I believe toggling the flag per-package basis is too much. Sure I can
see the situation where this happens, but the point here is to enable
communication between contributor and maintainer. If you're not
accepting PRs to some packages, you can close the PR informing
contributor about it. It'd be better than leave it to rot for months,
years, with no answer.


you know much better than me how pull requests are processed and what 
benefits and problems those bring. for me pull requests are generally 
good thing but sometimes when i see the quality of them, basic issues 
not resolved like the missing signed-off-by, contributors not responding 
and disappearing... i'm just not sure this whole effort will bring some 
advancement, but i trust your opinion on that as you are the one 
spending a lot of time on github. anyway, when it comes to this feature 
mentioned above, if it might be of any use, it can work as an override 
for package where it is specified and otherwise be undefined. in the end 
the contributor will be interested in whether the package accepts pull 
requests, not a dev or project.



Your last question wouldn't be any different from a current situation,
however other devs/users can inform the contributor that this maintainer
can't/doesn't use Github, and the PR can be closed. I'm mostly looking
for communication here. I believe being rejected is better than being
ignored. The bug can be dealt separately from Github PR.

i agree with you, making a contribution and being ignored is demotivating.

There's a tool that tells what PRs reference a closed bug,

(ie contribution was made, but not accepted/noticed, and the bug was
closed regardless of it)

https://github.com/wimmuskee/gengee



sorry for this flood of questions but atm it brings confusion to me
:-) from my point of view and personal preference, i appreciate pull
requests from contributors if those are of a decent quality, but for
me it's hard to easily find out the relevant pull requests. with the
new packages.gentoo.org it might be easier in the future but i'm not
sure yet how reliable it is atm as for example the list of outdated
packages for proaudio@
(https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated)
does not seem to be updated or i misunderstood something. the same
goes for the list of bugs
(https://packages.gentoo.org/maintainer/proau...@gentoo.org/b

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Miroslav Šulc

Dne 18. 08. 20 v 19:10 Joonas Niilola napsal(a):

On 8/18/20 8:06 PM, Joonas Niilola wrote:

So I think it's just simplest to enable it per-user per-project basis.
We can all edit Project: pages, toggling the flag. If you're willing to
look and merge sound@ PRs, you enable it for Sound project. However this
might cause a problem when a member who enabled the flag leaves the
project, or gets retired. But that's relatively easy to keep a track of.

As for non-dev maintainers, they **require** @gentoo.org person/project
to proxy for them. It'd be a start to mirror the project/dev option,
since they'd be the one committing for non-dev maintainers anyway. Also
non-dev maintainers can have their own wiki pages to toggle this.
However I'm not aware if the linking is as simple as with @gentoo.org
metadata info.


Forgot to add, if you have say 1 person and 2 projects assigned as
maintainers, where 1 does look for Github PRs and 2 does not, it'd still
be flagged as "Yes". Or maybe the majority here wins?
i think the approach "one yes beats all no-es" makes more sense as there 
still is one person who can handle the pull request. up to that, the yes 
might come from a main maintainer and the no from inactive ones... or 
the opposite... so i guess it might be better to take it as a hint 
rather than a rule as the outcome might be various.

-- juippis

fordfrog



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Miroslav Šulc

hi,

how would be handled cases where you and me agreed that you will take 
care of pull requests on behalf of sound@ and proaudio@? and what if a 
package is maintained by multiple maintainers or even some maintainers 
and a project, each with a different preference? how that would be 
solved to not bring in some confusion? and how about maintainers that 
are not gentoo devs? and what if there are packages that have a 
maintainer that is mia but has the no-accept policy set and some other 
dev would like to fix a package that has an annoying bug (using a pull 
request by a contributor) as the reported maintainer is mia, or a 
contributor might want to maintain the package? and what if a maintainer 
wants pull requests just for some packages and not for others? and what 
if a pull request is referenced from a bug at bugzilla but the 
maintainer does not accept pull requests?


sorry for this flood of questions but atm it brings confusion to me :-) 
from my point of view and personal preference, i appreciate pull 
requests from contributors if those are of a decent quality, but for me 
it's hard to easily find out the relevant pull requests. with the new 
packages.gentoo.org it might be easier in the future but i'm not sure 
yet how reliable it is atm as for example the list of outdated packages 
for proaudio@ 
(https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) 
does not seem to be updated or i misunderstood something. the same goes 
for the list of bugs 
(https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) which 
seems to be missing some bugs as my list with "Assignee: 
proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at 
packages.gentoo.org.


fordfrog


Dne 18. 08. 20 v 14:05 Joonas Niilola napsal(a):

Hey,

some of you may already have seen the new packages.gentoo.org page,
   https://packages.gentoo.org/

and the new maintainer pages in it,
   https://packages.gentoo.org/maintainers

If you open a maintainer page,
   https://packages.gentoo.org/maintainer/juip...@gentoo.org

you can see a tab called "pull requests" there,
   https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests

with description saying:
"If you also like to help the Gentoo project, you can consider sending a
Pull Request via GitHub.
Before doing so, you might want to take a look at the wiki page."

I'm suggesting of adding a new metadata flag to our Wiki's
User:/Project: page which then prints a message to this page saying
whether the maintainer (be it project or user), "accepts" or "deals
with" Github contributions. The wording can be a bit better, but it'd be
there to **notify** our **contributors** whether their time and effort
will most likely be wasted making a pull request for this particular
maintainer.

This note would then be displayed in every package the maintainer is
assigned to,
   https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests

I'd imagine a simple switch in Wiki could do it. No need to add anything
to ::gentoo repo. The switch can be visible in User:/Project: page, but
it doesn't have to. Unspecified metadata flag would print something like
"This maintainer hasn't specified whether they handle Github pull
requests. If you wish to help using Github, please also open a bug prior
to that and link your pull request commit to that bug (add link to
glep-66 here)". Or just default it to "No."

Note that the bug text could always be displayed nevertheless, since
that is still the main channel to communicate with maintainers.

It's undeniable we get a lot of pull requests and unfortunate that many
are left without any attention to rot.
   https://github.com/gentoo/gentoo/pulls

I think this would serve both parties - devs and contributors, with
little to no cost.

-- juippis






[gentoo-dev] last rite: x11-libs/flowcanvas

2020-08-11 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-11)
# Package dead. No consumers in the tree.
# Removal in 30 days. Bug #735518
x11-libs/flowcanvas




[gentoo-dev] last rite: media-sound/tapiir

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# HOMEPAGE dead.
# Removal in 30 days. bug #736326
media-sound/tapiir




[gentoo-dev] last rite: media-sound/specimen

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# Last release in 2007, HOMEPAGE dead.
# Removal in 30 days. bug #736322
media-sound/specimen




[gentoo-dev] last rite: media-sound/jackbeat

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# Last release in 2010.
# Removal in 30 days. bug #736300
media-sound/jackbeat




[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs due to jlec being MIA

2020-08-06 Thread Miroslav Šulc

i'll take app-office/scribus.

miroslav

Dne 05. 08. 20 v 9:24 Michał Górny napsal(a):

Hello,

The following packages are looking for a new maintainer:

[vB] app-backup/cachedir
[vB] app-benchmarks/bootchart2
[ B] app-benchmarks/ramspeed
[ B] app-office/scribus
[vB] dev-lua/luaposix
[ b] net-analyzer/zmap
[  ] net-libs/czmq
[  ] net-vpn/vpncwatch
[vB] sys-block/blocks
[  ] sys-boot/makebootfat
[v ] sys-fs/aufs-headers
[vB] sys-fs/aufs-util
[vB] sys-fs/bcache-tools
[v ] sys-kernel/aufs-sources
[vB] sys-kernel/kergen

Legend:

v - needs version bump
b - has trivial (QA) bug reported
B - has non-trivial bug reported





[gentoo-dev] Last rite: media-libs/libclalsadrv

2019-12-27 Thread Miroslav Šulc

# Miroslav Šulc  (2019-12-26)
# Deprecated by upstream, not used anymore in the tree.
# Removal in 30 days.  Bug #703196.
media-libs/libclalsadrv




[gentoo-dev] Re: HOMEPAGE and DESCRIPTION in ebuilds? (was: Usefulness of HOMEPAGE=https://www.gentoo.org)

2019-12-04 Thread Miroslav Šulc

hi,

it's proly little bit off this topic, but why do we have to copy 
homepage and description from ebuild to ebuild? wouldn't it be better to 
move this information to metadata.xml and keep it just there? or does in 
reality one package really have various homepages and various 
descriptions for different versions? metadata.xml could also contain 
more structured data like you outlined, i.e. link to homepage, 
sources/repository, bug tracker and possibly other.


miroslav

Dne 04. 12. 19 v 13:36 Michał Górny napsal(a):

Hi,

Many of Gentoo-originating packages are listing the main Gentoo site
as HOMEPAGE.  In my opinion, this is suboptimal (not to say 'useless').

I can think of a few uses for HOMEPAGE:

1. providing additional information about the package (before the user
chooses it),

2. providing easy access to (additional) documentation,

3. providing easy access to package sources,

4. providing easy access to bug reporting,

5. providing easy access to downloads.

A good HOMEPAGE is dedicated to the package in question, and makes it
easy to find all the stuff (and all other stuff the user might need).
The more effort user needs to put into finding what he needs, the worse
HOMEPAGE is.

Now, if I consider gentoo.org as a HOMEPAGE for ~90 packages it
currently is, it's horribly bad.  I suppose that in some cases authors
meant to indicate that Gentoo is the package's upstream.  However, by
going to the main Gentoo site, it's *very hard* to find anything about
the package in question.

Just please select a totally random package from those listing
gentoo.org as HOMEPAGE, then go to gentoo.org and try to find either
of the points listed above.  If you click 'Downloads', you're certainly
not going to find anything relevant.  Through 'Support', you may
eventually find that tiny Bugzilla button at the bottom... and then try
to find the correct Product.  You may also find gitweb link somewhere,
and try to see if the project has a repo there.  Or maybe it's somewhere
else, or maybe it existed on somebody's devspace once.

My point is: gentoo.org as a HOMEPAGE sucks.  Please use something more
specific instead.  Even link to gitweb would be more helpful because it
would at least be relevant to the package in question.





[gentoo-dev] Last rite: dev-java/balloontip

2019-12-03 Thread Miroslav Šulc

# Miroslav Šulc  (2019-12-03)
# Project does not exist anymore.
# Removal in 30 days.  Bug #680452.
dev-java/balloontip




[gentoo-dev] rfc: eclass patch for javatoolkit path change

2019-10-29 Thread Miroslav Šulc
wrt bug https://bugs.gentoo.org/627440 there is a need to update java 
eclasses to use correctly both current path and the new path. the 
attached patch should provide that. i also attached updated ebuild with 
the new path. in the patch i also removed the old "/usr/bin/..." path 
which is not used anymore.


i tested that on some ebuilds and all works fine.

any comments and suggestions welcome.

fordfrog

diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass
index 1fd4feb39134..5be76953edd6 100644
--- a/eclass/java-ant-2.eclass
+++ b/eclass/java-ant-2.eclass
@@ -224,8 +224,13 @@ java-ant_bsfix_files() {
 			files+=( -f "${file}" )
 		done
 
-		local rewriter3="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-3.py"
-		local rewriter4="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/build-xml-rewrite"
+		if [ -e "${EPREFIX}/usr/libexec/javatoolkit" ]; then
+			local rewriter3="${EPREFIX}/usr/libexec/javatoolkit/xml-rewrite-3.py"
+			local rewriter4="${EPREFIX}/usr/libexec/javatoolkit/build-xml-rewrite"
+		else
+			local rewriter3="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-3.py"
+			local rewriter4="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/build-xml-rewrite"
+		fi
 
 		if [[ -x ${rewriter4} && ${JAVA_ANT_ENCODING} ]]; then
 			[[ ${JAVA_ANT_REWRITE_CLASSPATH} ]] && local gcp="-g"
@@ -375,11 +380,11 @@ java-ant_ignore-system-classes() {
 # @DESCRIPTION:
 # Run the right xml-rewrite binary with the given arguments
 java-ant_xml-rewrite() {
-	local gen2="${EPREFIX}/usr/bin/xml-rewrite-2.py"
 	local gen2_1="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-2.py"
+	local gen2_2="${EPREFIX}/usr/libexec/javatoolkit/xml-rewrite-2.py"
 	# gen1 is deprecated
-	if [[ -x "${gen2}" ]]; then
-		${gen2} "${@}" || die "${gen2} failed"
+	if [[ -x "${gen2_2}" ]]; then
+		${gen2_2} "${@}" || die "${gen2_2} failed"
 	elif [[ -x "${gen2_1}" ]]; then
 		${gen2_1} "${@}" || die "${gen2_1} failed"
 	else
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 4f7eb0356fc9..e32cb572f147 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -2729,10 +2729,13 @@ java-pkg_jar-list() {
 java-pkg_verify-classes() {
 	#$(find ${D} -type f -name '*.jar' -o -name '*.class')
 
-	local version_verify="/usr/bin/class-version-verify.py"
+	local version_verify_1="${EPREFIX}/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py"
+	local version_verify_2="${EPREFIX}/usr/libexec/javatoolkit/class-version-verify.py"
 
-	if [[ ! -x "${version_verify}" ]]; then
-		version_verify="/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py"
+	if [[ -x "${version_verify_1}" ]]; then
+		local version_verify=${version_verify_1}
+	else
+		local version_verify=${version_verify_2}
 	fi
 
 	if [[ ! -x "${version_verify}" ]]; then
# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

PYTHON_COMPAT=( python2_7 python3_{5,6,7} )
PYTHON_REQ_USE="xml(+)"

inherit distutils-r1 multilib prefix

DESCRIPTION="Collection of Gentoo-specific tools for Java"
HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Java;
SRC_URI="https://gitweb.gentoo.org/proj/${PN}.git/snapshot/${P}.tar.bz2;

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~arm ~arm64 ~ppc64 ~sparc ~x86 ~ppc-aix ~amd64-linux 
~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris 
~x64-solaris ~x86-solaris"

python_prepare_all() {
hprefixify src/py/buildparser src/py/findclass setup.py
distutils-r1_python_prepare_all
}

python_install() {
distutils-r1_python_install \
--install-scripts="${EPREFIX}"/usr/libexec/${PN}
}


Re: [gentoo-dev] RFC: ant-tasks.eclass patch

2019-09-26 Thread Miroslav Šulc


Dne 25. 09. 19 v 21:44 Michał Górny napsal(a):

On Wed, 2019-09-25 at 20:47 +0200, Miroslav Šulc wrote:

...

I don't think you need two branches here.  Non-array variable is
equivalent to an array with a single element for the purpose of [@], so
your 'for' loop will work correctly both for non-array and array.


thanks, you're right, i simplified the patch (attached) and all my tests 
passed.


miroslav

diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
index 309df084d156..04c6fb5b7d67 100644
--- a/eclass/ant-tasks.eclass
+++ b/eclass/ant-tasks.eclass
@@ -54,7 +54,9 @@ ANT_TASK_NAME="${PN#ant-}"
 # @DESCRIPTION:
 # Specifies JAVA_PKG_NAME (PN{-SLOT} used with java-pkg_jar-from) of the package
 # that this one depends on. Defaults to the name of ant task, ebuild can
-# override it before inheriting this eclass.
+# override it before inheriting this eclass. In case there is more than one
+# dependency, the variable can be specified as bash array with multiple strings,
+# one for each dependency.
 ANT_TASK_DEPNAME=${ANT_TASK_DEPNAME-${ANT_TASK_NAME}}
 
 # @ECLASS-VARIABLE: ANT_TASK_DISABLE_VM_DEPS
@@ -105,7 +107,7 @@ S="${WORKDIR}/${MY_P}"
 # base: performs the unpack, build.xml replacement and symlinks ant.jar from
 #	ant-core
 #
-# jar-dep: symlinks the jar file(s) from dependency package
+# jar-dep: symlinks the jar file(s) from dependency package(s)
 ant-tasks_src_unpack() {
 	[[ -z "${1}" ]] && ant-tasks_src_unpack all
 
@@ -129,9 +131,11 @@ ant-tasks_src_unpack() {
 # ant.jar to build against
 java-pkg_jar-from --build-only ant-core ant.jar;;
 			jar-dep)
-# get jar from the dependency package
+# get jar from the dependency package(s)
 if [[ -n "${ANT_TASK_DEPNAME}" ]]; then
-	java-pkg_jar-from ${ANT_TASK_DEPNAME}
+	for depname in "${ANT_TASK_DEPNAME[@]}"; do
+		java-pkg_jar-from ${depname}
+	done
 fi;;
 			all)
 ant-tasks_src_unpack base jar-dep;;


[gentoo-dev] RFC: ant-tasks.eclass patch

2019-09-25 Thread Miroslav Šulc

hi,

as per bug https://bugs.gentoo.org/693022 we need to add dependency on 
dev-java/gnu-jaf (or dev-java/sun-jaf) to the package. unfortunately 
ant-tasks.eclass variable ANT_TASK_DEPNAME supports only single 
dependency (it was sufficient till now), but we need one more in this 
case. the introduced patch adds support for alternatively specifying 
ANT_TASK_DEPNAME as an array and handle it correctly. i've tested the 
patch and all seems to work fine.


please let me know if something can/should be improved.

thanks.

miroslav

diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
index 309df084d156..26df9de26f1a 100644
--- a/eclass/ant-tasks.eclass
+++ b/eclass/ant-tasks.eclass
@@ -54,7 +54,9 @@ ANT_TASK_NAME="${PN#ant-}"
 # @DESCRIPTION:
 # Specifies JAVA_PKG_NAME (PN{-SLOT} used with java-pkg_jar-from) of the package
 # that this one depends on. Defaults to the name of ant task, ebuild can
-# override it before inheriting this eclass.
+# override it before inheriting this eclass. In case there is more than one
+# dependency, the variable can be specified as bash array with multiple strings,
+# one for each dependency.
 ANT_TASK_DEPNAME=${ANT_TASK_DEPNAME-${ANT_TASK_NAME}}
 
 # @ECLASS-VARIABLE: ANT_TASK_DISABLE_VM_DEPS
@@ -105,7 +107,7 @@ S="${WORKDIR}/${MY_P}"
 # base: performs the unpack, build.xml replacement and symlinks ant.jar from
 #	ant-core
 #
-# jar-dep: symlinks the jar file(s) from dependency package
+# jar-dep: symlinks the jar file(s) from dependency package(s)
 ant-tasks_src_unpack() {
 	[[ -z "${1}" ]] && ant-tasks_src_unpack all
 
@@ -129,9 +131,17 @@ ant-tasks_src_unpack() {
 # ant.jar to build against
 java-pkg_jar-from --build-only ant-core ant.jar;;
 			jar-dep)
-# get jar from the dependency package
+# get jar from the dependency package(s)
 if [[ -n "${ANT_TASK_DEPNAME}" ]]; then
-	java-pkg_jar-from ${ANT_TASK_DEPNAME}
+	local array=$(declare -p ANT_TASK_DEPNAME | grep "^declare \-a")
+
+	if [[ -n "${array}" ]]; then
+		for depname in "${ANT_TASK_DEPNAME[@]}"; do
+			java-pkg_jar-from ${depname}
+		done
+	else
+		java-pkg_jar-from ${ANT_TASK_DEPNAME}
+	fi
 fi;;
 			all)
 ant-tasks_src_unpack base jar-dep;;


Re: [gentoo-dev] ant-tasks.eclass patch proposal

2019-01-21 Thread Miroslav Šulc

hi,

i just committed the changes to the eclass:

commit f14e39de0e2eaa3d3011918e9febd89bfe98f7ee (HEAD -> master, 
origin/master, origin/HEAD)

Author: Miroslav Šulc 
Date:   Mon Jan 21 09:45:29 2019 +0100

    ant-tasks.eclass: cleanup and improvement

    1) removed obsolete code
    2) increased default jdk/jre version to the lowest available 
version 1.8
    3) added support for patching build.xml along with the original 
build.xml replacement


    Signed-off-by: Miroslav Šulc 

i did one minor change that was not in the patch. after chat with chewi 
i increased default jdk/jre to 1.8 instead of 1.6. this change does not 
affect any ebuild as all ebuilds have these values defined.


regards

miroslav


Dne 18. 01. 19 v 18:25 Miroslav Šulc napsal(a):
thank you for the comments. i added eapi check at the beginning 
supporting eapi 5|6|7 (5 is needed for current ebuilds). i also 
changed epatch to eapply and disabled patching build.xml for eapi5 
just to make the code more robust, build.xml patching is not used in 
current ebuilds and those will be soon gone. once they are gone, this 
check and support for eapi5 can both be removed. attached is the 
updated patch.


miroslav

Dne 18. 01. 19 v 17:23 Brian Evans napsal(a):

On 1/18/2019 11:11 AM, Miroslav Šulc wrote:

@@ -130,7 +112,11 @@ ant-tasks_src_unpack() {
  cd "${S}"
    # replace build.xml with our modified for split 
building

-    mv -f "${WORKDIR}"/build.xml .
+    if [ -e "${WORKDIR}"/${PV}-build.patch ] ; then
+    epatch "${WORKDIR}"/${PV}-build.patch

Adding epatch without 'inherit epatch'?  Sounds like gambling on faith.
Also limits to EAPI=6.

Brian


+    else
+    mv -f "${WORKDIR}"/build.xml .
+    fi
    cd lib
  # remove bundled xerces




Re: [gentoo-dev] ant-tasks.eclass patch proposal

2019-01-18 Thread Miroslav Šulc
thank you for the comments. i added eapi check at the beginning 
supporting eapi 5|6|7 (5 is needed for current ebuilds). i also changed 
epatch to eapply and disabled patching build.xml for eapi5 just to make 
the code more robust, build.xml patching is not used in current ebuilds 
and those will be soon gone. once they are gone, this check and support 
for eapi5 can both be removed. attached is the updated patch.


miroslav

Dne 18. 01. 19 v 17:23 Brian Evans napsal(a):

On 1/18/2019 11:11 AM, Miroslav Šulc wrote:

@@ -130,7 +112,11 @@ ant-tasks_src_unpack() {
cd "${S}"
  
  # replace build.xml with our modified for split building

-   mv -f "${WORKDIR}"/build.xml .
+   if [ -e "${WORKDIR}"/${PV}-build.patch ] ; then
+   epatch "${WORKDIR}"/${PV}-build.patch

Adding epatch without 'inherit epatch'?  Sounds like gambling on faith.
Also limits to EAPI=6.

Brian


+   else
+   mv -f "${WORKDIR}"/build.xml .
+   fi
  
  cd lib

# remove bundled xerces
diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
index 31683e682437..50e03aa9cfa7 100644
--- a/eclass/ant-tasks.eclass
+++ b/eclass/ant-tasks.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License, v2 or later
 
 # @ECLASS: ant-tasks.eclass
@@ -11,27 +11,37 @@
 # This eclass provides functionality and default ebuild variables for building
 # dev-java/ant-* packages easily.
 
+case "${EAPI:-0}" in
+	0|1|2|3|4)
+		die "ant-tasks.eclass: EAPI ${EAPI} is too old."
+		;;
+	5|6|7)
+		;;
+	*)
+		die "ant-tasks.eclass: EAPI ${EAPI} is not supported yet."
+		;;
+esac
 
 # we set ant-core dep ourselves, restricted
 JAVA_ANT_DISABLE_ANT_CORE_DEP=true
 # rewriting build.xml for are the testcases has no reason atm
 JAVA_PKG_BSFIX_ALL=no
 inherit java-pkg-2 java-ant-2
-[[ ${EAPI:-0} == [0123456] ]] && inherit eapi7-ver
+[[ ${EAPI:-0} == [56] ]] && inherit eapi7-ver
 
 EXPORT_FUNCTIONS src_unpack src_compile src_install
 
 # @ECLASS-VARIABLE: ANT_TASK_JDKVER
 # @DESCRIPTION:
-# Affects the >=virtual/jdk version set in DEPEND string. Defaults to 1.5, can
+# Affects the >=virtual/jdk version set in DEPEND string. Defaults to 1.6, can
 # be overridden from ebuild BEFORE inheriting this eclass.
-ANT_TASK_JDKVER=${ANT_TASK_JDKVER-1.5}
+ANT_TASK_JDKVER=${ANT_TASK_JDKVER-1.6}
 
 # @ECLASS-VARIABLE: ANT_TASK_JREVER
 # @DESCRIPTION:
-# Affects the >=virtual/jre version set in DEPEND string. Defaults to 1.5, can
+# Affects the >=virtual/jre version set in DEPEND string. Defaults to 1.6, can
 # be overridden from ebuild BEFORE inheriting this eclass.
-ANT_TASK_JREVER=${ANT_TASK_JREVER-1.5}
+ANT_TASK_JREVER=${ANT_TASK_JREVER-1.6}
 
 # @ECLASS-VARIABLE: ANT_TASK_NAME
 # @DESCRIPTION:
@@ -56,31 +66,18 @@ ANT_TASK_DEPNAME=${ANT_TASK_DEPNAME-${ANT_TASK_NAME}}
 # Version of ant-core this task is intended to register and thus load with.
 ANT_TASK_PV="${PV}"
 
-# special care for beta/RC releases
-if [[ ${PV} == *beta2* ]]; then
-	MY_PV=${PV/_beta2/beta}
-	UPSTREAM_PREFIX="http://people.apache.org/dist/ant/v1.7.1beta2/src;
-	GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	ANT_TASK_PV=$(ver_cut 1-3)
-elif [[ ${PV} == *_rc* ]]; then
-	MY_PV=${PV/_rc/RC}
-	UPSTREAM_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	ANT_TASK_PV=$(ver_cut 1-3)
-else
-	# default for final releases
-	MY_PV=${PV}
-	case ${PV} in
-	1.9.*)
-		UPSTREAM_PREFIX="https://archive.apache.org/dist/ant/source;
-		GENTOO_PREFIX="https://dev.gentoo.org/~tomwij/files/dist;
-		;;
-	*)
-		UPSTREAM_PREFIX="mirror://apache/ant/source"
-		GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-		;;
-	esac
-fi
+# default for final releases
+MY_PV=${PV}
+case ${PV} in
+1.9.2)
+	UPSTREAM_PREFIX="https://archive.apache.org/dist/ant/source;
+	GENTOO_PREFIX="https://dev.gentoo.org/~tomwij/files/dist;
+	;;
+*)
+	UPSTREAM_PREFIX="mirror://apache/ant/source"
+	GENTOO_PREFIX="https://dev.gentoo.org/~fordfrog/distfiles;
+	;;
+esac
 
 # source/workdir name
 MY_P="apache-ant-${MY_PV}"
@@ -101,11 +98,6 @@ if [[ -z "${ANT_TASK_DISABLE_VM_DEPS}" ]]; then
 	DEPEND+=" >=virtual/jdk-${ANT_TASK_JDKVER}"
 fi
 
-# we need direct blockers with old ant-tasks for file collisions - bug #252324
-if ver_test -ge 1.7.1; then
-	DEPEND+=" !dev-java/ant-tasks"
-fi
-
 # Would run the full ant test suite for every ant task
 RESTRICT="test"
 
@@ -130,7 +122,15 @@ ant-tasks_src_un

[gentoo-dev] ant-tasks.eclass patch proposal

2019-01-18 Thread Miroslav Šulc

hi,

i'm preparing bump of apache ant and i found out it would be good to 
clean up ant-tasks.eclass and improve it little bit. there are several 
changes in the patch that i summarize below:


1) increased lowest jdk/jre version to 1.6 as that is the lowest 
source/bytecode supported by jdk 11, which we are getting ready for in 
the main tree (the default values are not used in any ant task ebuild 
afaik, ant-1.9.2 uses 1.5, ant-1.9.13 will use 1.8)
2) at this moment we have only ant version 1.9.2 in the main tree so i 
removed all the obsolete code from the eclass
3) ant-tasks_src_unpack is updated to support patching of build.xml 
along with the original code that replaces build.xml with new one


that's all. i tested the updated eclass with ant-1.9.2 and ant-1.9.13 
(not in tree yet, ant-1.10.5 will follow) and both compile and install 
without issues. any comments or suggestions appreciated.


miroslav

diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
index 31683e682437..567567d15a0b 100644
--- a/eclass/ant-tasks.eclass
+++ b/eclass/ant-tasks.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License, v2 or later
 
 # @ECLASS: ant-tasks.eclass
@@ -23,15 +23,15 @@ EXPORT_FUNCTIONS src_unpack src_compile src_install
 
 # @ECLASS-VARIABLE: ANT_TASK_JDKVER
 # @DESCRIPTION:
-# Affects the >=virtual/jdk version set in DEPEND string. Defaults to 1.5, can
+# Affects the >=virtual/jdk version set in DEPEND string. Defaults to 1.6, can
 # be overridden from ebuild BEFORE inheriting this eclass.
-ANT_TASK_JDKVER=${ANT_TASK_JDKVER-1.5}
+ANT_TASK_JDKVER=${ANT_TASK_JDKVER-1.6}
 
 # @ECLASS-VARIABLE: ANT_TASK_JREVER
 # @DESCRIPTION:
-# Affects the >=virtual/jre version set in DEPEND string. Defaults to 1.5, can
+# Affects the >=virtual/jre version set in DEPEND string. Defaults to 1.6, can
 # be overridden from ebuild BEFORE inheriting this eclass.
-ANT_TASK_JREVER=${ANT_TASK_JREVER-1.5}
+ANT_TASK_JREVER=${ANT_TASK_JREVER-1.6}
 
 # @ECLASS-VARIABLE: ANT_TASK_NAME
 # @DESCRIPTION:
@@ -56,31 +56,18 @@ ANT_TASK_DEPNAME=${ANT_TASK_DEPNAME-${ANT_TASK_NAME}}
 # Version of ant-core this task is intended to register and thus load with.
 ANT_TASK_PV="${PV}"
 
-# special care for beta/RC releases
-if [[ ${PV} == *beta2* ]]; then
-	MY_PV=${PV/_beta2/beta}
-	UPSTREAM_PREFIX="http://people.apache.org/dist/ant/v1.7.1beta2/src;
-	GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	ANT_TASK_PV=$(ver_cut 1-3)
-elif [[ ${PV} == *_rc* ]]; then
-	MY_PV=${PV/_rc/RC}
-	UPSTREAM_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-	ANT_TASK_PV=$(ver_cut 1-3)
-else
-	# default for final releases
-	MY_PV=${PV}
-	case ${PV} in
-	1.9.*)
-		UPSTREAM_PREFIX="https://archive.apache.org/dist/ant/source;
-		GENTOO_PREFIX="https://dev.gentoo.org/~tomwij/files/dist;
-		;;
-	*)
-		UPSTREAM_PREFIX="mirror://apache/ant/source"
-		GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
-		;;
-	esac
-fi
+# default for final releases
+MY_PV=${PV}
+case ${PV} in
+1.9.2)
+	UPSTREAM_PREFIX="https://archive.apache.org/dist/ant/source;
+	GENTOO_PREFIX="https://dev.gentoo.org/~tomwij/files/dist;
+	;;
+*)
+	UPSTREAM_PREFIX="mirror://apache/ant/source"
+	GENTOO_PREFIX="https://dev.gentoo.org/~fordfrog/distfiles;
+	;;
+esac
 
 # source/workdir name
 MY_P="apache-ant-${MY_PV}"
@@ -101,11 +88,6 @@ if [[ -z "${ANT_TASK_DISABLE_VM_DEPS}" ]]; then
 	DEPEND+=" >=virtual/jdk-${ANT_TASK_JDKVER}"
 fi
 
-# we need direct blockers with old ant-tasks for file collisions - bug #252324
-if ver_test -ge 1.7.1; then
-	DEPEND+=" !dev-java/ant-tasks"
-fi
-
 # Would run the full ant test suite for every ant task
 RESTRICT="test"
 
@@ -130,7 +112,11 @@ ant-tasks_src_unpack() {
 cd "${S}"
 
 # replace build.xml with our modified for split building
-mv -f "${WORKDIR}"/build.xml .
+if [ -e "${WORKDIR}"/${PV}-build.patch ] ; then
+	epatch "${WORKDIR}"/${PV}-build.patch
+else
+	mv -f "${WORKDIR}"/build.xml .
+fi
 
 cd lib
 # remove bundled xerces
@@ -168,8 +154,6 @@ ant-tasks_src_install() {
 	java-pkg_register-ant-task --version "${ANT_TASK_PV}"
 
 	# create the compatibility symlink
-	if ver_test -ge 1.7.1_beta2; then
-		dodir /usr/share/ant/lib
-		dosym /usr/share/${PN}/lib/${PN}.jar /usr/share/ant/lib/${PN}.jar
-	fi
+	dodir /usr/share/ant/lib
+	dosym /usr/share/${PN}/lib/${PN}.jar /usr/share/ant/lib/${PN}.jar
 }


[gentoo-dev] last rites: dev-java/jnlp-bin, app-misc/openjnlp, dev-java/netx

2011-10-19 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

all packages are related to following bug:
https://bugs.gentoo.org/show_bug.cgi?id=377967

jnlp-bin has been replaced by jnlp-api.
openjnlp is obsolete and not needed anymore, also depends on jnlp-bin.
netx was a package that we tried to fix the issue, but in the end it
was replaced with jnlp-api.

Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ez0YACgkQB6q7Q15RwyCV6QCcCFCIolHppVui86eppp6UhDj9
c98Ani7j71kaFCYoIlHOGIIwLAR/pwOB
=NxW3
-END PGP SIGNATURE-



[gentoo-dev] Can't update/checkout gentoo-x86 repo

2011-04-07 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

today i tried to update my local copy of gentoo-x86 cvs repo but the
update failed with this error:

cvs [checkout aborted]: Could not map memory to RCS archive
/var/cvsroot/gentoo-x86/profiles/package.mask,v: Invalid argument

so i tried clean checkout instead, but got the same error. any idea what
might be wrong?

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

iEYEARECAAYFAk2dm1oACgkQB6q7Q15RwyBG+gCeIUjyU5zKfCmTVWxlKD4ZheAh
KA4An0TBGkOrBG+2Nt9CtcuYWBe/dzNe
=lDpK
-END PGP SIGNATURE-



Re: [gentoo-dev] Can't update/checkout gentoo-x86 repo

2011-04-07 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

works fine now, thanks.

miroslav

Dne 7.4.2011 15:44, Theo Chatzimichos napsal(a):
 On Thursday 07 of April 2011 15:06:37 Theo Chatzimichos wrote:
 Patrick already reported the issue in #gentoo-infra but unfortunately there
 is none available at the moment with root access in flycatcher, please be
 patient
 
 The issue is now fixed. The file somehow got corrupted on the server, Jeremy 
 restored from last backup. The only commit that got lost was the last one by 
 scarabeus, who re-did it fine.

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

iEYEARECAAYFAk2dwWIACgkQB6q7Q15RwyASXQCeMMWJtGXZaL2d9iphFhLxIPxe
mhMAnRR6zwJ/fY/PsREwhahHnXtnDmO3
=GwjA
-END PGP SIGNATURE-



Re: [gentoo-dev] issue with gentoo-x86 cvs repo

2010-10-02 Thread Miroslav Šulc (fordfrog)
 Dne 2.10.2010 03:35, Robin H. Johnson napsal(a):
 On Sat, Oct 02, 2010 at 03:19:42AM +0200, Miroslav ?ulc (fordfrog) wrote:
  hi,

 yesterday i was able to use the repo but now i get this error (for any
 cvs command):

 $ cvs rm -f apgdiff-2.0.2.ebuild
 Your account has expired; please contact your system administrator
 Connection closed by 81.93.255.6
 cvs [remove aborted]: end of file from server (consult above messages if
 any)

 what does it exactly mean?
 It's fixed already.
 Some lovely lines from the old perl_ldap:
 ===
   my $expiry = convertEpoch(0,0,0,1,9,2010);
   ...
   shadowExpire = $expiry,
 ===
 Which is a date of 2010/10/02, that just rolled up a few hours ago.
 A constant value that was set 5 years ago come up :-).

 All LDAP and the script are fixed now.

Thanks :-)



[gentoo-dev] issue with gentoo-x86 cvs repo

2010-10-01 Thread Miroslav Šulc (fordfrog)
 hi,

yesterday i was able to use the repo but now i get this error (for any
cvs command):

$ cvs rm -f apgdiff-2.0.2.ebuild
Your account has expired; please contact your system administrator
Connection closed by 81.93.255.6
cvs [remove aborted]: end of file from server (consult above messages if
any)

what does it exactly mean?

fordfrog



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/netbeans: ChangeLog netbeans-6.9-r3.ebuild

2010-07-21 Thread Miroslav Šulc (fordfrog)
 Dne 21.7.2010 16:35, Jeremy Olexa napsal(a):
 On Mon, 19 Jul 2010 20:24:40 + (UTC), Miroslav Sulc (fordfrog)
 fordf...@gentoo.org wrote:
 fordfrog10/07/19 20:24:40

   Modified: ChangeLog netbeans-6.9-r3.ebuild
   Log:
   netbeans-6.9-r3: added support for including custom patches when
 building netbeans
 +# Support for custom patches
 +if [ -n {NETBEANS_PATCHES_DIR} -a -d ${NETBEANS_PATCHES_DIR} ] ; 
 then
 +local files=`find ${NETBEANS_PATCHES_DIR} -type f`
 +
 +if [ -n ${files} ] ; then
 +einfo Applying custom patches:
 +
 +for file in ${files} ; do
 +epatch ${file}
 +done
 +fi
 +fi
 +
 Miroslav, You just reinvented the wheel :) Any reason why epatch_user()
 from euitls.eclass doesn't work here?
 -Jeremy
y, i did not expect this function to exist, i only recall that i saw
some custom code for applying patches in some other ebuild few years
back when i needed to tweak some package, so did it the same way.

so this is called automatically for
/etc/portage/patches/category/(PF|P|PN) if i read the code right? i
also tried to search man pages for portage and emerge but there is
nothing about it (or i am blind) ... so this is undocumented feature? i
did not know about this cool feature till now.

m.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/netbeans: ChangeLog netbeans-6.5-r1.ebuild netbeans-6.5.ebuild

2008-11-23 Thread Miroslav Šulc (fordfrog)
Thank you both for the suggestions, I fixed these issues in updated 
netbeans-6.5-r1.


Miroslav Šulc (fordfrog)
Gentoo Java Team

Jeremy Olexa napsal(a):

Peter Volkov wrote:

В Сбт, 22/11/2008 в 18:11 +, Miroslav Sulc (fordfrog) пишет:

fordfrog08/11/22 18:11:25
  Added:netbeans-6.5-r1.ebuild
  Log: netbeans compiles fine even with JDK 1.6 so I dropped the 
restriction on JDK, also commons-fileupload linking fixed



Index: netbeans-6.5-r1.ebuild
===
pkg_setup() {
if use netbeans_modules_apisupport  ! ( use 
netbeans_modules_harness  use netbeans_modules_ide  use 
netbeans_modules_java ) ; then
eerror 'apisupport' USE flag requires 'harness', 'ide' and 
'java' USE flags


Additionally, 'apisupport', 'harness', 'ide' and 'java' are not USE 
flags. You have to set NETBEANS_MODULES, not USE. You can easily test 
this by trying NETBEANS_MODULES=apisupport USE=java emerge -pv 
netbeans and see that netbeans_modules_java does not get set.

-Jeremy


exit 1
fi


Why do you use exit 1 instead of die?


local tmpfileplatform=${T}/platform.txt
cat ${tmpfile} | grep -v libs.jna/external/jna-3.0.2.jar  
${tmpfileplatform}

mv ${tmpfileplatform} ${tmpfile}


grep can read files on it's own so no need for cat file | grep... Also 
possibly


sed -e /libs\.jna\/external\/jna-3\.0\.2\.jar/d -i ${tmpfile}

will work better here and in some other places...








Re: [gentoo-dev] Adding NETBEANS to USE_EXPAND

2008-11-20 Thread Miroslav Šulc (fordfrog)
Ok, it seems there are no objections so I will implement
NETBEANS_MODULES within several hours. We also discussed whether to use
NETBEANS_MODULES in USE_EXPAND at #gentoo-dev and agreed on that it will
be ok to implement it.

Miroslav Šulc (fordfrog)
Gentoo Java Team


Miroslav Šulc (fordfrog) napsal(a):
 Hi,
 
 I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is
 modular IDE with 18 modules (clusters). Users can freely choose what
 support thay want to build in netbeans, though some modules need other
 modules to compile and work. Are there any objections?
 
 Here are the modules/clusters:
 IUSE_NETBEANS=+netbeans_apisupport netbeans_cnd netbeans_groovy
 netbeans_gsf +netbeans_harness +netbeans_ide netbeans_identity
 netbeans_j2ee +netbeans_java netbeans_mobility +netbeans_nb netbeans_php
 netbeans_profiler netbeans_soa netbeans_visualweb netbeans_webcommon
 netbeans_websvccommon netbeans_xml
 
 Btw, there is also request for this in bugzilla:
 http://bugs.gentoo.org/show_bug.cgi?id=211455
 
 I'd like to put the ebuild in the main tree soon as upstream just
 released it and we have in the tree only 5.5.1 which is very old.
 
 Thanks for your comments.
 
 Miroslav Šulc (fordfrog)
 Gentoo Java Team
 



[gentoo-dev] Adding NETBEANS to USE_EXPAND

2008-11-19 Thread Miroslav Šulc (fordfrog)
Hi,

I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is
modular IDE with 18 modules (clusters). Users can freely choose what
support thay want to build in netbeans, though some modules need other
modules to compile and work. Are there any objections?

Here are the modules/clusters:
IUSE_NETBEANS=+netbeans_apisupport netbeans_cnd netbeans_groovy
netbeans_gsf +netbeans_harness +netbeans_ide netbeans_identity
netbeans_j2ee +netbeans_java netbeans_mobility +netbeans_nb netbeans_php
netbeans_profiler netbeans_soa netbeans_visualweb netbeans_webcommon
netbeans_websvccommon netbeans_xml

Btw, there is also request for this in bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=211455

I'd like to put the ebuild in the main tree soon as upstream just
released it and we have in the tree only 5.5.1 which is very old.

Thanks for your comments.

Miroslav Šulc (fordfrog)
Gentoo Java Team



Re: [gentoo-dev] Adding NETBEANS to USE_EXPAND

2008-11-19 Thread Miroslav Šulc (fordfrog)
Just a note to my email, maybe it would be better to use
NETBEANS_MODULES instead of NETBEANS as NETBEANS_MODULES is more
accurate. NETBEANS_MODULES was even suggested by Betelgeuse in the
mentioned bug.

Miroslav Šulc (fordfrog)
Gentoo Java Team

Miroslav Šulc (fordfrog) napsal(a):
 Hi,
 
 I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is
 modular IDE with 18 modules (clusters). Users can freely choose what
 support thay want to build in netbeans, though some modules need other
 modules to compile and work. Are there any objections?
 
 Here are the modules/clusters:
 IUSE_NETBEANS=+netbeans_apisupport netbeans_cnd netbeans_groovy
 netbeans_gsf +netbeans_harness +netbeans_ide netbeans_identity
 netbeans_j2ee +netbeans_java netbeans_mobility +netbeans_nb netbeans_php
 netbeans_profiler netbeans_soa netbeans_visualweb netbeans_webcommon
 netbeans_websvccommon netbeans_xml
 
 Btw, there is also request for this in bugzilla:
 http://bugs.gentoo.org/show_bug.cgi?id=211455
 
 I'd like to put the ebuild in the main tree soon as upstream just
 released it and we have in the tree only 5.5.1 which is very old.
 
 Thanks for your comments.
 
 Miroslav Šulc (fordfrog)
 Gentoo Java Team
 



Re: [gentoo-dev] Adding NETBEANS to USE_EXPAND

2008-11-19 Thread Miroslav Šulc (fordfrog)
I do not know about Eclipse that much but from my point of view there is
a big difference between Eclipse and Netbeans. Eclipse is an IDE where
you have to install plugins after installation of Eclipse to make
yourself productive, whereas Netbeans provides complete working IDE in
single package (with the possibility to include/exclude some modules),
although the option for installing extra modules is available too. So
unless Eclipse external modules are installed with the IDE, it makes no
sense to apply the same logic for Eclipse, as the way Eclipse modules
are distributed is quite different from how Netbeans does it.

Miroslav Šulc (fordfrog)
Gentoo Java Team

Robert Bridge napsal(a):
 On Wed, 19 Nov 2008 19:03:12 +0100
 Miroslav Šulc (fordfrog) [EMAIL PROTECTED] wrote:
 
 I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is
 modular IDE with 18 modules (clusters). Users can freely choose what
 support thay want to build in netbeans, though some modules need other
 modules to compile and work. Are there any objections?
 
 As a sometimes programmer who prefers Eclipse, would it be an option to
 do something similar for that IDE?
 
 This obviously leads to the question of when does a package qualify for
 such an option instead of using a set of regular USE flags...
 
 Just a few thoughts,
 RobbieAB.



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to
http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
it seems to me the versioning is focused on package stability life
cycle. In netbeans case it is _prealpha and definitely not stable
patched release. So _alpha is the closest one to current netbeans 6.0
life cycle phase, though not accurate.

- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team


Mike Frysinger napsal(a):
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
 milestone releases. These are pretty stable and usable since milestone 7
 of netbeans 6.0 with many new features that make sense to use the
 milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
 though I was assured by mkt guy from Sun it is not yet alpha quality. It
 would be fair to the upstream and to users to not use _alpha because it
 is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#
 -mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+6oPRSzWCmqu+0YRAhPAAJ99Et9Uwk/JrpRPkukABgrc3CdLfQCghrm+
noRpxMDQvlxrlLhFUdqb088=
=gC2k
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jakub Moc napsal(a):
 Miroslav Šulc (fordfrog) napsal(a):
 According to
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 it seems to me the versioning is focused on package stability life
 cycle. In netbeans case it is _prealpha and definitely not stable
 patched release. So _alpha is the closest one to current netbeans 6.0
 life cycle phase, though not accurate.
 
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.


Where does this come from? There is nothing about it in devmanual. And
is '_alpha  _alpha_pre' true of false? Anyway I'd rather preffer
_prealpha than _alpha_pre :-)


- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+9m2RSzWCmqu+0YRAt+3AJ9RcqsIgCzlJCygKyRrqEGZY6lmogCffLWl
ZdCUglDhgQAiBaop7G1dXM4=
=14Rp
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
milestone releases. These are pretty stable and usable since milestone 7
of netbeans 6.0 with many new features that make sense to use the
milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
though I was assured by mkt guy from Sun it is not yet alpha quality. It
would be fair to the upstream and to users to not use _alpha because it
is not alpha but there's no appropriate choice available.

- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team


William L. Thomson Jr. napsal(a):
 After reviewing 
 
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 
 
 I still seem to be having to finagle version names for some packages. At
 the moment it would be nice if we also had the following suffixes
 available
 
 _dev
 Apache upstream, specifically Tomcat/mod_jk tends to do developer
 snapshots that they then host out of developer space. People do fetch
 bins and source from there for testing. It's kinda pre-release, so I
 have been using _pre where I would use _dev, but _pre does not make much
 sense.
 
 _build
 Other packages seem to do constant builds (weekly) of the same version.
 For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39.
 So would be nice to be able to do like glassfish-servlet-api-2_build39
 
 _snapshot
 This one is kinda universal in it's name/implication. Would be for any
 sort of upstream snapshot release, that might not be versioned as such.
 Short of the name snapshot being some where.
 
 The above would then follow the rest of the normal schema, where in they
 could still be suffixed by a number, or not.
 
 Hierarchy would be the following
 
 snapshot - dev - build - alpha - beta 
 
 Or at least that's my thoughts on it. Time for others thoughts, much
 less those that will make it so. Not expecting it to get done or be
 available any time soon. Would be suffice if they were just accepted and
 planned for inclusion at some point.
 

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

iD8DBQFF+yssRSzWCmqu+0YRAoQAAJ9XHz0wZL3pdkSzSyxnVRnLsrw4FwCfVMDO
vuDOHvpko+t1nhu1cvx0RfY=
=ZYFd
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Miroslav Šulc (fordfrog)

Thanks for the greetings from Czechoslovakia :-)

Jakub Moc wrote:

Petteri Räty napsal(a):
  

He hails from Beroun, Czech Republic. He owns his own IT company. On the
personal side he is married and has a little daughter. He likes soccer,
taking trips on bikes and hiking.



Yay, the Czech beer conspiracy is growing! Welcome!

*plop*


  

--
Miroslav Šulc (fordfrog)
Java Team

--
gentoo-dev@gentoo.org mailing list