Hi Luca,<div><br>First off, thanks to Steffen for forwarding this as I was not subscribed to the pkg-eucalyptus-maintainers list, just pkg-eucalyptus O_O.<br><br>Second, big thanks to you Luca (and the unnamed trainee!)<br>
<br>I will comment inline below:<br><br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">source:<br>=======<br> * libhamcrest1.2-java | libhamcrest-java (>=1.2)<br> The former is Ubuntu-only, Debian has libhamcrest-java only. This<br>
would result in autobuilders failing to build the source if they do<br> not resolve alternatives in build-deps. Would you mind switching the<br> order of the two build-dependencies?</blockquote><div><br></div><div>
<br></div><div>Yes, this was done for Ubuntu - not a problem. I will change this straight away.</div><div><br></div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">copyright file<br>==============<br> debian/copyright has a License: Apache section, where the license<br>
itelf is Apache-2.0. The short license abbreviationshould be<br> Apache-2.0 too, according to my reading of the machine readable<br> copyright format.<br><br><br></blockquote><div>Rudy added this - I'll ping him about it.</div>
<div><br></div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">eucalyptus-cc<br>=============<br>* Depends on dhcp3-server, which is a transitional package, which was<br> aiding in the lenny->squeeze upgrade.<br>
The correct dependency would be isc-dhcp-server.<br><br></blockquote><div><br></div><div>Yes, this another holdover for Lucid compat; Will change it.</div><div><br></div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
eucalyptus-admin-tools<br>======================<br>* Lots of missing man pages. Are there plans to provide some?<br><br><br></blockquote>At the moment, no :-(</div><div><br><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>eucalyptus-cloud</div><div>================</div><div><br></div><div>Recommends postfix | m-t-a. While minor, I believe it's good manners</div><div>to recommend the default MTA first. But that's arguable, and most</div>
<div>definitely a minor thing.</div><div><br></div></blockquote><div><br>Worksforme, will change it.</div><div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>eucalyptus-java-common</div>
<div>======================</div><div><br></div><div>Depends on libhamcrest1.2-java | libhamcrest-java (>= 1.2), probably</div><div>for Ubuntu compatibility. The first is not satisfiable by debian,</div><div>though. While it will work, as apt will resolve alternatives, it's</div>
<div>still nicer to list the only valid candidate first.</div><div><br></div></blockquote><div><br></div><div>Same ordering as the build-dep above - will change it.</div><div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>Looking at this snippet:</div><div><br></div><div> if dpkg --compare-versions "$2" lt "3.0~"; then</div><div> if [ -f /tmp/eucaback.dir ]; then</div><div> BACKDIR=`cat /tmp/eucaback.dir`</div>
<div> if [ -d "$BACKDIR" ]; then</div><div> if [ -f "$BACKDIR/etc/eucalyptus/eucalyptus-version" -a -f "/etc/eucalyptus/eucalyptus-version" ]; then</div><div> export OLDVERSION=`cat $BACKDIR/etc/eucalyptus/eucalyptus-version`</div>
<div> export NEWVERSION=`cat /etc/eucalyptus/eucalyptus-version`</div><div> if [ "$OLDVERSION" != "$NEWVERSION" ]; then</div><div> rm -f /usr/share/eucalyptus/eucalyptus-*$OLDVERSION*.jar</div>
<div> fi</div><div> fi</div><div> fi</div><div> fi</div><div> fi</div><div><br></div><div>A bigger problem is that *any* user can write to /tmp/eucaback.dir,</div><div>and using the tempfile this way might open up the postinst to</div>
<div>attack. So, it is an unsafe use, although differently so than the</div><div>common case, I believe.</div><div><br></div></blockquote><div><br></div><div>I had worried about this section :-) This is hairy upgrade code that precedes my time here. It isn't safe, as you mention, but not a true race condition threat either as we simply read the file created there. Even if a bogus file is inserted there, our upgrade procedure would simply abort. I hesitated to remove this only because, despite it being hairy, has been tested for quite some time and I didn't want to introduce the risk of breaking the upgrade process by improving the packaging. Is this a must? If it is, I already have untested code to fix it.</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Why is /usr/sbin/eucalyptus-cloud in this package, and not in eucalyptus-cloud?</div><div><br></div></blockquote><div><br>This is an unfortunate side effect of the fact that the init script eucalyptus-cloud not only controls the cloud process, but also the nc, cc, etc... It could have been placed in -common, but was placed in -java as it depends on JARs located there. Unfortunately, this can't be mitigated easily :-(</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Also, could you comment about the following lintian warnings?</div><div><br></div><div>W: eucalyptus-java-common: codeless-jar usr/share/eucalyptus/eucalyptus-bootstrap-3.1.0.jar</div>
<div><br></div></blockquote><div><br></div><div>I'll have to check with engineering on this one.</div><div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>W: eucalyptus-java-common: missing-classpath libpostgresql-jdbc-java, libjboss-common-java, libhibernate-commons-annotations-java, libactivemq-java, libasm3-java, libavalon-framework-java, libaxiom-java, libbackport-util-concurrent-java, libbatik-java, libbcel-java, libbcprov-java, libbsf-java, libcommons-beanutils-java, libcommons-cli-java, libcommons-codec-java, libcommons-collections3-java, libcommons-digester-java, libcommons-discovery-java, libcommons-fileupload-java, libcommons-httpclient-java, libcommons-io-java, libcommons-jxpath-java, libcommons-lang-java, libcommons-logging-java, libcommons-pool-java, libdnsjava-java, libdom4j-java, libehcache-java, libexcalibur-logkit-java, libezmorph-java, libgeronimo-activation-1.1-spec-java, libgeronimo-ejb-3.0-spec-java, libantlr-java, libgeronimo-javamail-1.4-provider-java, libgeronimo-javamail-1.4-spec-java, libgeronimo-jms-1.1-spec-java, libgeronimo-jpa-2.0-spec-java, libgeronimo-jta-1.1-spec-java, libgeronimo-stax-1.2-spec-java, libguava-java, libhamcrest1.2-java, libhamcrest-java, libhsqldb-java, libitext-java, libjavassist-java, libjaxen-java, libjaxp1.3-java, libjboss-marshalling-java, libjcip-annotations-java, libjettison-java, libjetty-extra-java, libjetty-java, libjgroups-java, libjibx1.2-java, libjna-java, libjsch-java, libjson-java, libjug-java, liblog4j1.2-java, libmule-java, libnetty3.1-java, libnetty-java, libproxool-java, libquartz-java, libregexp-java, libservlet2.5-java, libslf4j-java, libspring-beans-java, libspring-context-java, libspring-context-support-java, libspring-core-java, libspring-web-java, libstax2-api-java, libwsdl4j-java, libwss4j-java, libxalan2-java, libxerces2-java, libxml-security-java, libxom-java, libxpp3-java, libaxis-java, libhibernate3-java, libcommons-compress-java, libbtm-java, libjasperreports3.7-java, libwoodstox-java, libcglib-java, libclean-crypto-java, libgeronimo-j2ee-connector-1.5-spec-java, libjboss-cache3-java, libha-jdbc-java, libgroovy1.7.2-java, libgroovy1.7-java, libhibernate-jbosscache-java, libhibernate-validator-java, libspring-expression-java</div>
<div><br></div></blockquote><div><br></div><div>I'm showing my Java ignorance here as I'm not sure how to remedy this or I would have. Is this a showstopper? Rudy, any ideas here?</div><div><br></div><div><br></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>W: eucalyptus-java-common: possibly-insecure-handling-of-tmp-files-in-maintainer-script postinst:14</div><div><br></div></blockquote><div><br></div><div>Same issue here - part of the hairy upgrade process.</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>eucalyptus-walrus</div><div>=================</div><div><br></div><div>This has a heavy set of dependencies (on lvm2 and drbd8-utils), but</div>
<div>the effective contents are a drbd config example. Are there some missing</div><div>files from this binary?</div><div><br></div><div><br></div></blockquote><div>No, by design (I'm not saying it's a good one) all JARs are thrown into java-common as even though Walrus may not be installed on a given machine (i.e.e the lvm2 and drbd8-utils packages aren't needed there) the JARs are still needed by other components to communicate with Walrus. Again, this is not one that will be easily mitigated :-(</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>eucalpytus-nc</div><div>=============</div><div><br></div><div>N: helper, will never have manpage</div><div>O: eucalyptus-nc: binary-without-manpage usr/sbin/euca_test_nc</div>
<div><br></div><div>If it's a helper, why is it in usr/sbin, and not under</div><div>/usr/lib/eucalyptus or some other private directory?</div><div><br></div></blockquote><div><br></div><div>Another that I will have to check with engineering on as it was added before my time. I see no reason in it being there either though as we sorely lack manpages and it is something we need to address at some point.</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>eucalyptus-common</div><div>=================</div><div><br></div><div>It is a little bit uncommon to have a -common package to be arch:any, this is</div>
<div>probably because of the /usr/lib/eucalyptus/euca_* binaries.</div><div><br></div><div>W: eucalyptus-common: possibly-insecure-handling-of-tmp-files-in-maintainer-script postrm:4</div><div>W: eucalyptus-common: possibly-insecure-handling-of-tmp-files-in-maintainer-script postinst:27</div>
<div>W: eucalyptus-common: possibly-insecure-handling-of-tmp-files-in-maintainer-script preinst:11</div><div><br></div><div>If one wants to back up the data, back it up under /var seems a much</div><div>better option than the one implemented here.</div>
<div><br></div></blockquote><div><br></div><div>Correct, it is marked any (should technically probably be amd64 as we don't certify on any other platform, even i386) due to the binaries that are needed by the various processes. As for the tmp stuff, this was addressed above.</div>
<div><br></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Misc</div><div>====</div><div><br></div><div>By the way, someone else filed an ITP: eucalyptus bug recently:</div><div> <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680589">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680589</a></div>
<div><br></div></blockquote><div><br></div><div>Apologies here. Rudy thought I had filed one but I hadn't, so he filed one after the fact just to ensure one existed. Better communication on our team is definitely needed. Please comment on the upgrade scenario response I provided above.<br>
</div></div><div><br>Aside from that, there don't appear to be any potential showstoppers in the list above. Is there any way this package can be accepted into Sid as-is so that I (I am only a DM and not a full maintainer yet so have been relying on the very minimal free time from Rudy for my uploads) may make changes myself. I realize the package isn't one that would be used to show a new dev the ideal way of packaging things, but it's certainly better than the 1.6 version that was accepted years ago :-)</div>
<div><br></div><div>Many thanks for your efforts,</div><div><br></div><div>Brian</div><div><br></div><div>P.S. As I wasn't subscribed to the list, I copied/pasted this and did some indent-fu in gmail for inline responses. My apologies if your client doesn't render it well :-( I added double line breaks to try to ease this a bit.</div>