I am currently maintaining freeminda and various other related dependencies
I am now working full-time and not a student any more, so the time I could
devote to work on packaging is reduced a lot.
This is not a problem with packages where you have an easy upstream, which
is not the case for most of my Java packages.
Therefore I am not going to have the time, to put enough effort into
packaging up the new version of freemind and adopt all the changes upstream
made to plugins and various other parts of the package.
This is why I am looking for someone who would like to take over these
packages and work on them. I am not going to orphan them straight away but
if I am not able to update to the latest stable upstream version there's
not a lot of sense in keeping it in fedora.
I hope someone will help me to keep freemind in fedora,
I'm currently the packager for eclipse-ptp. It has a feature that allows for
remote development. Some aspects of this (of which I don't quite understand
all of it) require shipping a bundle of eclipse platform jars and stuff over
to the remote system to run there. The way this is built currently is the
build downloads the prebuilt eclipse code for various platforms to build into
the bundle (since the remote system might be anything). Obviously this
doesn't fly with Fedora.
I starting looking at perhaps grabbing the built code we already have, but two
- I never quite got this working
- It would only have support for the particular platform that the rpm was
For now I've disabled this feature (and it has been disabled for the life of
the package in Fedora). But I'm wondering if there is any possibility of
getting this to work somehow in Fedora. Thoughts?
I've posted to both the packaging list and the java list in the hopes of
getting the different perspectives.
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
In addition to upstream Apache Maven maven package provides some
Fedora-specific modifications that are useful for buidling RPM
packages. Those include mvn-rpmbuild and mvn-local scripts as well as
Maven maintainers in Fedora decided to split Fedora specific parts from
upstream Maven. Since Fedora 19 maven package will be divided into 2
1. maven. This package will contain upstream Maven without any
modifications or with absolutely minimal modifications. This package
will provide /usr/bin/mvn executable.
2. maven-local. This package will contain Fedora-specific extensions for
Maven such as local resolver allowing to build RPM packages from
artifact available in the system instead of downloading it from
central repository. This package will provide /usr/bin/mvn-local and
Packages in Fedora Rawhide that use mvn-rpmbuild during build will need
to start requiring maven-local instead of maven. Packages that use
mvn-rpmbuild but don't have "BuildRequires: maven-local" will likely
fail to build. I will consider automatically migrating all Java packages
from maven to maven-local during a mass-rebuild (this will be announced
later). Packages in older Fedoras (17 and 18) can also start
build-requiring maven-local instead of maven, but that's not
obligatory. It's just a simplification for packagers that want to share
one spec file between multiple Fedora releases.
Besides that internal implementation of mvn-rpmbuild and mvn-local
scripts is going to change soon. Only implementation was changed, public
interface is the same, so there should be no need for any changes in
packages that use mvn-rpmbuild. I have tested the new mvn-rpmbuild
script by rebuilding many major Java packages, but undiscovered bugs are
possible. Any bugs related to new implementation of mvn-local and
mvn-rpmbuild scripts should be reported against maven-local package
(component in Bugzilla: javapackages-tools). We'll try to resolve them
Fedora Maven maintainer
-----BEGIN PGP SIGNED MESSAGE-----
I've got the OpenShift Tools from JBoss Tools for Eclipse ready, and
they seem to work great (lots of fun if you use OpenShift already)!
To get them into rawhide & F18, I need a couple of package reviews
done. If anybody could help me out with those, I'd be very grateful!
If there's anything that you would like me to review, or anything else
that I can do in return, I'll happily oblige.
The first is eclipse-m2e-core (Maven integration for Eclipse). It's
a big one (for me at least). Mikolaj helped me with this one (many
thanks), and did a preliminary check to make sure there's nothing
obvious wrong with it.
The second should be a much easier one: openshift-java-client.
I'm not in any rush to get this in (not on GSOC deadlines any more
:)). I'm using the packages myself, so I'm satisfied. If anyone else
would like to see them in Fedora, then please think about reviewing!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
-----END PGP SIGNATURE-----
On 17 January 2013 14:05, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
> On Thu, Jan 17, 2013 at 09:48:28AM +0000, Mat Booth wrote:
>> However, I tried this on a package I own and I get a ServerError:
>> [mbooth@f17vm ~]$ pkgdb-cli update cobertura watchbugzilla java-sig all
>> FAS password:
>> 500, Internal Server Error)
>> I am using packagedb-cli-1.2.1-1.fc17.noarch
>> Any more clues you can give me?
> Use the git version :)
> I fixed the 'all' recently and I have not done a release with the fix yet.
Fair enough, thanks for your help :-)
On 17 January 2013 00:14, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
> On Tue, Jan 15, 2013 at 08:39:24AM +0000, Mat Booth wrote:
>> On 11 January 2013 20:56, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
>> > On Fri, 2013-01-11 at 20:51 +0000, Mat Booth wrote:
>> >> Happy New Year, java-devel subscribers!
>> > The very same you !
>> >> I noticed that a number of important Java packages don't have the
>> >> "java-sig" alias as co-maintainer in pkgdb that probably should have:
>> >> Is there a way to get this fixed in bulk?
>> > I think packagedb-cli (aka pkgdb-cli) can help with that (I just fixed
>> > the problem with specifying 'all' branches yesterday).
>> Thanks for the suggestion. I installed your package but there is no
>> man page for the command so maybe I'm missing something. I want to
>> request "watchbugzilla" and "watchcommits" for the "java-sig" pseudo
>> user, but I couldn't see how to specify a username when doing a
>> "pkgdb-cli request." Even if I could specify a username, will it still
>> prompt me for a password that I don't know?
>> If so I will probably have to do it the old fashioned way with
>> individual SCM requests.
> Indeed, I should make a man page, all is in --help atm and it does lack some
> I was more thinking along the line of
> pkgdb-cli update <package> commit java-sig all
> But this has to be ran by the owner. You can give rights to someone that didn't
> ask for it, but you can't ask for rights for someone else, so here to make the
> requests it won't quite work.
> Sorry for the confusion.
Aha, thank you, that seems to be command I need. Since the usage was
not obvious to me I raised you a ticket to add a man-page containing
However, I tried this on a package I own and I get a ServerError:
[mbooth@f17vm ~]$ pkgdb-cli update cobertura watchbugzilla java-sig all
500, Internal Server Error)
I am using packagedb-cli-1.2.1-1.fc17.noarch
Any more clues you can give me?
"We have confirmed that VU#625617 can be used to reliably execute code on
Windows, OS X, and Linux platforms." where the linked vulnerability is:
Via Applications, Other, IcedTea-Web Control Panel I do not find a simple
control as provided in the most recent vendor-supplied bits:
Using Add/Remove Programs to accomplish [per yum.log]:
... Erased: icedtea-web-1.3.1-1.fc17.i686
still allows applets to run. Only after killing and restarting the browser
(Firefox; kill rather than close, so that all of the open tabs can be
Restored) does loading a page containing an applet lead to:
A plugin is needed to display this content.
So if one were needing to enable Java for a trusted site, while browsing
conservatively elsewhere, is there anything simpler to do than this cycle
- install icedtea-web-...
- kill and restart web browser
- use Java
- erase icedtea-web-...
- kill and restart web browser
- browse safely
Is there an intent to make this simpler in future versions?
Happy New Year, java-devel subscribers!
I noticed that a number of important Java packages don't have the
"java-sig" alias as co-maintainer in pkgdb that probably should have:
felix-* family of packages
Is there a way to get this fixed in bulk? Are there any other obvious
ones that should be added to the list?