FYI:
---------- Forwarded message ----------
From: Robert Rati <rrati(a)redhat.com>
Date: Tue, Mar 3, 2015 at 3:25 PM
Subject: Looking for co-maintainers for hadoop and friends
To: Fedora Java Development List <java-devel(a)lists.fedoraproject.org>,
Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
I'm looking for people who are interested in being co-maintainers for
the following packages:
apache-log4j-extras
greenmail
hadoop
hbase
jamon-api
jamon-java-parent
jamon-maven-plugin
jamon-nodegen-plugin
jamon-parent
jamon-processor
jamon-runtime
jung
oozie
Most of these are pretty simple and don't change too much. The big
ones are hadoop, hbase, and oozie. I don't have as much time as I used
to to put into maintaining these packages.
Rob
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
hi
if there are no objections i would like to upgrade jets3t to version 0.9.3
jets3t 0.9.3 require java-xmlbuilder 1.0 (is also available 1.1)
regards
gil
Hello I would like share with you the current status of Flume package.
Gil Cattaneo is working in many of the package dependencies, great
work!
The package builds with this assumptions (we are working on this issues):
1. The code is not ready for Thrift v0.9.1 available in Fedora 21,
however Flume code can builds using legacy Thrift built-in code
available in the upstream Flume TGZ.
2. Disable ElasticSearch Sink
3. Disable Morphline Solr Sink
4. Disable Twitter Source
5. Disable Kite Dataset Sink
In order to build Flume with full features those are the dependency
packages and status:
1. Package: irclib [https://bugzilla.redhat.com/show_bug.cgi?id=976049] (flume)
Pushed to the Fedora 21 testing repository.
2. Package: mapdb [https://bugzilla.redhat.com/show_bug.cgi?id=1178861] (flume)
submitted as an update for Fedora 21
3. Package: asynchbase (flume)
No added for revision in bugzilla.
4. Package: suasync (asynchbase)
No added for revision in bugzilla.
5. Package: parquet [https://bugzilla.redhat.com/show_bug.cgi?id=1073017] (kite)
Requesting review!
6. Package: parquet-format
[https://bugzilla.redhat.com/show_bug.cgi?id=1073014] (parquet)
Requesting review!
7. Package kite [https://bugzilla.redhat.com/show_bug.cgi?id=1179355] (flume)
The package need a patch in order to support Fedora Guava version.
8. maxmind-db-java [https://bugzilla.redhat.com/show_bug.cgi?id=1179309] (kite)
Pushed to the Fedora 21 testing repository.
9. Package ua-parser-java
[https://bugzilla.redhat.com/show_bug.cgi?id=1179342] (kite)
Pushed to the Fedora 21 testing repository.
Another question about default files in Flume package. Hortonworks and
Cloudera (Bigtop tools for packaging) are shipping default
configuration files in /etc/default, for example
/etc/default/flume-agent. I don't know if this is a good practice from
a Fedora packaging guidelines, what do you think?
A help with the package reviews are welcome!
Many thanks.
--
Javi Roman
There are 2 upcoming online courses that may be of interest to people.
1 - edX - Introduction to Big Data with Apache Spark, a 5 week course
starting Feb 23rd, teaching will done using Python and PySpark
https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-…
2 - Coursera - Mining Massive Datasets, 7 weeks, starts January 31st.
Not as direct as the Spark one, this one appears to be more general
covering MapReduce and algorithms.
https://www.coursera.org/course/mmds
Hello!
I'm working on some packages in my personal Github account [1] (Apache
Storm, Apache Kafka and Apache Flume). Maybe it could be useful for
this SIG when they are ready :-)
Meanwhile I have run into a problem and I need some advice:
The Apache Flume upstream code is using a old library (Apache Thrift
v0.8.0) however Fedora packages are using Apache Thrift 0.9.1 since
log time ago [2]. The problem is the v0.9.1 version breaks the
upstream building [3], and nobody is working in the issue right now.
The question is about the steps or procedure from a Fedora packager
point of view:
1. Try to fix the break code by myself, or working with the upstream
people in order to fix it (probably complex task).
2. Try to package the older version of the library and make it
available in the fedora packages repository.
any advice about this?
Many thanks!
[1] https://github.com/fedora-bigdata-rpms
[2] https://apps.fedoraproject.org/packages/thrift
[3] https://issues.apache.org/jira/browse/FLUME-2531
--
Javi Roman
es.linkedin.com/in/javiroman
Hi,
I want retire: seam-conversation, seam-parent, seam-solder
I do not have many reasons to keep them still
And if someone can take care of openjpa package or can give a help as
co-maintainer.
https://issues.apache.org/jira/browse/OPENJPA-2386
Unusable and not buildable with Java8. As last resort I will have to
pick up too, and the
packages that require it.
regards
- gil
Hello!
Are the repositories hosted on Github [1] deprecated?
I would like checkout the source of some packages listed on
SIGs/bigdata/packaging.
[1] https://github.com/fedora-bigdata
--
Javi Roman
> Begin forwarded message:
>
> Date: December 18, 2014 at 12:30:02 AM EST
> From: Mikolaj Izdebski <mizdebsk(a)redhat.com>
> To: Fedora Java Development List <java-devel(a)lists.fedoraproject.org>
> Subject: [fedora-java] Removing depmap support in Fedora 23
>
> I hereby announce that in Fedora 23 XMvn will remove support for depmaps
> and depmap fragments.
>
> For those lucky that don't know what depmaps are: Depmaps are legacy
> files, which used to be installed with Java packages to enable Maven to
> resolve artifacts. Depmaps were replaced with a new metadada format in
> Fedora 21.
>
> In Fedora 21 all standard tooling (including %add_maven_depmap) have
> been modified to produce the new metadata format. Fedora 21 and 22 have
> deprecated, read-only support for depmaps for compatibility reasons, but
> this code will be removed in Fedora 23. Once that happens, artifacts
> installed in packages that still use depmaps will stop being resolved by
> Maven.
>
> Great majority of packages were already migrated to the new metadata
> format. Most of those that were not are FTBFS packages (with .fc20 dist
> tag) that couldn't be rebuilt in mass rebuild. Rebuilding them before
> the above XMvn change lands in Fedora 23 should "fix" them.
>
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> --
> java-devel mailing list
> java-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel