Bug#663342: /usr/lib/ruby/vendor_ruby now in $LOAD_PATH

2015-05-27 Thread Potter, Tim (Cloud Services)
It looks like this has been fixed, at least in sid:

root@56264f4d8fa9:/Source/pkg-java/jruby# cat /etc/issue
Debian GNU/Linux 8 \n \l

root@56264f4d8fa9:/Source/pkg-java/jruby# ruby -v
ruby 2.1.5p273 (2014-11-13) [x86_64-linux-gnu]

root@56264f4d8fa9:/Source/pkg-java/jruby# irb
irb(main):001:0 puts $LOAD_PATH
/usr/local/lib/site_ruby/2.1.0
/usr/local/lib/x86_64-linux-gnu/site_ruby
/usr/local/lib/site_ruby
/usr/lib/ruby/vendor_ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0
/usr/lib/ruby/vendor_ruby
/usr/lib/ruby/2.1.0
/usr/lib/x86_64-linux-gnu/ruby/2.1.0
= nil



smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#779112: closed by Tim Potter t...@hp.com (Bug#779112: fixed in jnr-constants 0.8.6-3)

2015-03-05 Thread Potter, Tim (Cloud Services)
On 6/03/15 6:37 AM, Andreas Beckmann a...@debian.org wrote:

On 2015-03-05 04:21, Debian Bug Tracking System wrote:
* Change dependency on libconstantine-java to Conflicts, from
  Breaks. (Closes: #779112).

No. Breaks should have been sufficient, but you are still missing a
Replaces.

  Selecting previously unselected package libconstantine-java.
  Preparing to unpack .../libconstantine-java_0.8.5-1_all.deb ...
  Unpacking libconstantine-java (0.8.5-1) ...
  dpkg: error processing archive
/var/cache/apt/archives/libconstantine-java_0.8.5-1_all.deb (--unpack):
   trying to overwrite '/usr/share/java/jnr-constants.jar', which is also
in package libjnr-constants-java 0.8.6-3
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libconstantine-java_0.8.5-1_all.deb

Or wait, the changelog wording mislead me. The versioning is wrong:

Replaces: libconstantine-java ( 0.8.5-1)
Provides: libconstantine-java
Conflicts: libconstantine-java ( 0.8.5-1)

In your case you either want unversioned Conflicts+Replaces
or (= 0.8.5) instead.

Nuts - thanks for pointing that out, and sorry for not actually testing my
fix since it's trivially easy to do so.  Changing the versioning as you
describe does the job and I've verified this is the case before uploading
it again.


Regards,

Tim.


smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#776081:

2015-01-26 Thread Potter, Tim (Cloud Services)
The current version of the libconstantine-java package is in the (old?) 
pkg-java subversion repository.  Let’s move it to git, and update to 0.8.6.  

However the package has been renamed to jnr-constants in 2011-2012.  View the 
git commit log to see the gradual deprecation of the name constantine in favour 
of jnr-constants.

Anyway, I’ve pushed my version of the packaging for the 0.8.6 version to 
http://anonscm.debian.org/cgit/pkg-java/jnr-constants.git, which can be 
merged/updated/deleted depending on what we decide to do.


Tim.
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#773131:

2015-01-23 Thread Potter, Tim (Cloud Services)
On 24 Jan 2015, at 1:57 am, Miguel Landaeta nomad...@debian.org wrote:

 On Fri, Jan 23, 2015 at 06:21:34AM +, Potter, Tim (Cloud Services) wrote:
 Just a quick update for the dependencies I’m working on. 
 
 [...]
 
 * jnr-enxio, jnr-unixsocket, packaged and pushed to pkg-java
 
 While these packages all build, there’s still a bunch of work to do on the 
 usual suspects - d/copyright, javadocs as appropriate, and fixing lintian 
 warnings and errors.  I’ll start this next week.
 
 Do you need sponsoring for jnr-enxio and jnr-unixsocket?

Hi Miguel.  Yes that would be great - thanks.  There’s still a couple of hours 
work to do yet though but I’ll let you know when they’re ready.

I submitted a DM application last week at a conference with lots of Australian 
DD’s.  Hopefully I can do a bit more of this myself when it comes through.


Regards,

Tim.

 -- 
 Miguel Landaeta, nomadium at debian.org
 secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
 Faith means not wanting to know what is true. -- Nietzsche

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#773131:

2015-01-22 Thread Potter, Tim (Cloud Services)
Just a quick update for the dependencies I’m working on. 

* jffi, packaged version 1.2.7 and pushed to the pkg-java repo as jffi-1.2.7.  
Waiting for some direction on whether to merge over the old version, which I 
expect will be the way to go  This is a dependency for the remaining jnr-* 
packages.

* jnr-jffi, closed as a duplicate of jffi, above

* jnr-ffi, jnr-constants, packaged and pushed to pkg-java as they’re 
dependencies for the two packages below

* jnr-enxio, jnr-unixsocket, packaged and pushed to pkg-java

While these packages all build, there’s still a bunch of work to do on the 
usual suspects - d/copyright, javadocs as appropriate, and fixing lintian 
warnings and errors.  I’ll start this next week.


Tim.
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#773131: jruby: Update it to 1.7.17 or more recent release

2015-01-19 Thread Potter, Tim (Cloud Services)
On 19/12/14 12:11 PM, Miguel Landaeta nomad...@debian.org wrote:

Thanks for info, Tony and Tim!

When I begin to work on those dependencies I'll ping you again to let
you know to coordinate and avoid work duplication.

Hi Miguel.  I've just been going over the status of jruby1.7  and the work
that's still required.  Looking in the core/pom.xml file there are a bunch
of jnr-* dependencies that Tony and I have started on, but if you want
some easy wins there are a handful of libraries by headius that are also
needed.

* invokebinder
* coro-mock
* unsafe-mock
* options
* jsr292-mock

These are all available under https://github.com/headius/ but I haven't
checked each pom.xml file for unpackaged dependencies so there may be some
surprises.


Would you be interested in packaging these libraries?


Regards,

Tim.


smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#773131: jruby: Update it to 1.7.17 or more recent release

2014-12-16 Thread Potter, Tim (Cloud Services)
On 16/12/14 3:48 PM, tony mancill tmanc...@debian.org wrote:

On 12/14/2014 12:39 PM, Miguel Landaeta wrote:
 Package: src:jruby
 Version: 1.5.6-9
 Severity: wishlist
 
 I need a recent jruby version so I'll give a try to update this
 package.
 
 It's going to take time as anything related with Maven and missing
 dependencies can take.

Hi Miguel,

Hi and welcome Miguel!

Just so you're aware, and to try to facilitate coordination, Tim Potter
is also working on this and the packaging of the necessary r-deps.  An
updated jnr-x86asm is now in experimental as part of that effort.

Here are the r-dep ITPs I'm aware of, and I think that #771271 is
already covered by the existing jffi package (but which also needs an
update):

 #771267 [w|  |  ] [wnpp] ITP: jnr-unixsocket -- Java access to native
libraries for unix sockets
 #771268 [w|  |  ] [wnpp] ITP: jnr-enxio -- Java extended native
cross-platform I/O library
 #771269 [w|  |  ] [wnpp] ITP: jnr-ffi -- Java library for loading
native libraries without writing writing JNI code
 #771271 [w|  |  ] [wnpp] ITP: jnr-jffi -- Low-level library
implementing the JNR Java foreign function interface
 #771272 [w|  |  ] [wnpp] ITP: jnr-constants -- Java library to
encapsulate constants in native libraries

These packages are nearly ready to go - there's some technical reason why
the jffi (aka jnr-jffi) package doesn't quite work and it's a dependency
for everything else.  I've also been working on an update to version 1.0
for the yecht package but it has some native JAR weirdness going on that I
don't understand.

I haven't looked at anything else, so if you want to get started there's
plenty of places that need work.

Nice to have multiple folks interested in this.

Yup.  It's a big project as the build system and dependencies have change
considerably since the 1.5 packages were made.


Tim.


smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#759736: elasticsearch: CVE-2014-3120

2014-09-01 Thread Potter, Tim (Cloud Services)
On 30/08/14 5:37 AM, Salvatore Bonaccorso car...@debian.org wrote:

Source: elasticsearch
Severity: grave
Tags: security upstream fixed-upstream

Hi Hilko,

I see elasticsearch entered unstable now. Some time ago the following
vulnerability was published for elasticsearch.

CVE-2014-3120[0]:
| The default configuration in Elasticsearch before 1.2 enables dynamic
| scripting, which allows remote attackers to execute arbitrary MVEL
| expressions and Java code via the source parameter to _search.  NOTE:
| this only violates the vendor's intended security policy if the user
| does not run Elasticsearch in its own independent virtual machine.

If I understand it correctly, the value or this defaults to false,
more references are in Red Hat's Bugzilla[1]. Could you check
elasticsearch for this?

Hi Salvatore.  I've checked the current version in the archive and it
definitely is vulnerable.  I've made a patch and am just running some
build tests now.

I'm hoping that Hilko can make an upload as I'm not on the uploaders list,
and don't really know how anyway.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities  Exposures) id in your changelog entry.

Done.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3120
https://security-tracker.debian.org/tracker/CVE-2014-3120
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1124252
[2] https://github.com/elasticsearch/elasticsearch/issues/5853
[3] https://github.com/elasticsearch/elasticsearch/commit/81e83cca

These were great resources - thanks for including them in the message.


Tim Potter
Cloud Systems Engineer
HP Cloud Services

timothy.pot...@hp.com
M +61 419 749 832
Hewlett-Packard Australia Pty Ltd

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorised to receive for the recipient), please contact the sender by
reply e-mail and delete all copies of this message.



smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#759736: elasticsearch: CVE-2014-3120

2014-09-01 Thread Potter, Tim (Cloud Services)
On 2/09/14 2:19 AM, tony mancill tmanc...@debian.org wrote:

 CVE-2014-3120[0]:
 | The default configuration in Elasticsearch before 1.2 enables dynamic
 | scripting, which allows remote attackers to execute arbitrary MVEL
 | expressions and Java code via the source parameter to _search.  NOTE:
 | this only violates the vendor's intended security policy if the user
 | does not run Elasticsearch in its own independent virtual machine.

Hi Salvatore.  I've checked the current version in the archive and it
 definitely is vulnerable.  I've made a patch and am just running some
 build tests now.
 
 I'm hoping that Hilko can make an upload as I'm not on the uploaders
list,
 and don't really know how anyway.

Hi Tim,

Thanks for helping out with this bug.  If you could attach your patch
(the debdiff tool can be helpful here) to the bug report, either Hilko
or I (or any DD) can rebuild and upload.

Attached.  I didn't know about debdiff - what a great tool!

Tim Potter
Cloud Systems Engineer
HP Cloud Services

timothy.pot...@hp.com
M +61 419 749 832
Hewlett-Packard Australia Pty Ltd

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorised to receive for the recipient), please contact the sender by
reply e-mail and delete all copies of this message.




deb.diff
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740955: no subject

2014-07-23 Thread Potter, Tim (Cloud Services)
This is bugging me as well, and I've figured out the root cause.  The maven2 
package runs update-alternatives with a priority of 200, and maven (3) with a 
priority of 150.  If you install maven2 and maven at the same time, you will 
always get maven2.  Since maven2 is a dependency for maven-debian-helper this 
will nearly always be the case.

# apt-get install –y maven maven2
# mvn -v
Apache Maven 2.2.1 (rdebian-15)
Java version: 1.7.0_65
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: linux version: 3.15.3-tinycore64 arch: amd64 Family: unix
# update-alternatives --config mvn
There are 2 choices for the alternative mvn (providing /usr/bin/mvn).

  SelectionPath   Priority   Status

* 0/usr/share/maven2/bin/mvn   200   auto mode
  1/usr/share/maven/bin/mvn150   manual mode
  2/usr/share/maven2/bin/mvn   200   manual mode

A more sensible default might be setting the priority of maven (3) to 250 so it 
becomes the default, but this may have some unexpected side effects.

Tim Potter
Cloud Systems Engineer
HP Cloud Services

timothy.pot...@hp.com
M +61 419 749 832
Hewlett-Packard Australia Pty Ltd

This e-mail may contain confidential and privileged material for the sole use 
of the intended recipient. Any review, use, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or 
authorised to receive for the recipient), please contact the sender by reply 
e-mail and delete all copies of this message.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.