Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
I would opt for option 2 or maybe 3. About option 2, I could split x11vnc into x11vnc and x11vnc-data packages. x11vnc-data package will contain all jars (/usr/share/x11vnc/classes) and will be platform-independent (architecture all). So when a user installs the x11vnc package then by default the x11vnc-data will automatically installed as well? Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
yes, x11vnc will have a dependency on x11vnc-data package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
The options aren't particularly good, but you have some: 1) Create your own keystore that is compatible with this jarsigner, and use that instead of the included one. Note that this jarsigning going on here in x11vnc has nothing to do with security or authentication, in fact the opposite: it is only to provide a signed jar that a user can accept and have it run as an application rather than an applet to enable local file saving or getting a socket connection through a web proxy. 2) Build (or borrow) the signed jar files built on a different architecture that has sun's jarsigner. Or send them to another machine to be signed. There is no intrinsic reason these jars need to be built or signed on the platform they will be deployed on (they are really just platform-independent 'data' files that will be served and run on jvm's elsewhere, not hppa.) I understand debian build rules may get in the way of this. 3) Don't ship the signed jars in the hppa package. It is not the end of the world. Better to provide the regular and SSL-enabled applets which I imagine are used much more often than the signed ones. That's all I can think of. I would opt for option 2 or maybe 3. About option 2, I could split x11vnc into x11vnc and x11vnc-data packages. x11vnc-data package will contain all jars (/usr/share/x11vnc/classes) and will be platform-independent (architecture all). About option 3, it means default-jdk build-dependency removal on hppa and hurd architectures so all jars won't be built/shipped on these architectures too. thoughts ? cheers, Fathi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
On Fri, Dec 04, 2009 at 08:17:01PM -0500, Karl J. Runge wrote: Does it still fail when using Sun's java/jarsigner? Sun's java/jarsigner isn't available on the hppa architecture. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
Sun's java/jarsigner isn't available on the hppa architecture.
Oh, I see now.
Looking around I found these implementation files:
http://docjar.org/html/api/gnu/javax/crypto/jce/keyring/GnuKeyring.java.html
http://docjar.org/html/api/gnu/java/security/Registry.java.html
The former appears to be the one throwing the error; it is checking the
first 4 bytes of the keystore against GKR_MAGIC[] defined in the latter
to be:
byte[] GKR_MAGIC = new byte[] { 0x47, 0x4b, 0x52, 0x01 };
I'm guessing 'GKR' stands for Gnu Key Ring, but I could be wrong.
In any event I think it is incompatible with other jarsigners.
The options aren't particularly good, but you have some:
1) Create your own keystore that is compatible with this jarsigner,
and use that instead of the included one.
Note that this jarsigning going on here in x11vnc has nothing to
do with security or authentication, in fact the opposite: it is
only to provide a signed jar that a user can accept and have it
run as an application rather than an applet to enable local file
saving or getting a socket connection through a web proxy.
2) Build (or borrow) the signed jar files built on a different
architecture that has sun's jarsigner. Or send them to another
machine to be signed. There is no intrinsic reason these
jars need to be built or signed on the platform they will be
deployed on (they are really just platform-independent 'data'
files that will be served and run on jvm's elsewhere, not hppa.)
I understand debian build rules may get in the way of this.
3) Don't ship the signed jars in the hppa package. It is not the
end of the world. Better to provide the regular and SSL-enabled
applets which I imagine are used much more often than the signed
ones.
That's all I can think of.
Karl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
Does it still fail when using Sun's java/jarsigner? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559088: FTBFS [hppa]: jarsigner error: incorrect magic
Package: x11vnc Version: 0.9.8-2 Severity: important User: debian-h...@lists.debian.org Usertags: hppa x11vnc_0.9.8-2 reliably fails to build on hppa: https://buildd.debian.org/build.php?pkg=x11vncver=0.9.8-2arch=hppafile=log From the most recent build log: [...] adding: TextViewer$1.class (in=564) (out=564) (stored 29%) adding: TextViewer$2.class (in=542) (out=542) (stored 31%) adding: TextViewer.class (in=4,282) (out=4,282) (stored 44%) adding: TrustDialog.class (in=6,073) (out=6,073) (stored 44%) adding: VncCanvas.class (in=22,974) (out=22,974) (stored 47%) adding: VncViewer$1.class (in=870) (out=870) (stored 35%) adding: VncViewer.class (in=19,951) (out=19,951) (stored 46%) cp -p VncViewer.jar SignedVncViewer.jar cp -p UltraViewerSSL.jar SignedUltraViewerSSL.jar jarsigner -keystore ./keystore0 -storepass abcdef SignedVncViewer.jar swkey jarsigner error: gnu.javax.crypto.keyring.MalformedKeyringException: incorrect magic make[2]: *** [all] Error 1 make[1]: *** [override_dh_auto_configure] Error 2 make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 make[2]: Leaving directory `/build/buildd-x11vnc_0.9.8-2-hppa-naqoPa/x11vnc-0.9.8/classes/ssl/src' make[1]: Leaving directory `/build/buildd-x11vnc_0.9.8-2-hppa-naqoPa/x11vnc-0.9.8' Build finished at 20091127-0205 FAILED [dpkg-buildpackage died] Purging /var/lib/schroot/mount/sid-hppa-sbuild-405c47a2-af3c-4b89-9fb1-97d4a3c66cf2/build/buildd-x11vnc_0.9.8-2-hppa-naqoPa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
