Bug#918437: ring-clojure: FTBFS randomly due to filesystem ordering

[Apollon Oikonomopoulos]

Hi,

Thanks a lot for looking into this!

On 14:06 Fri 08 Feb     , Cyril Brulebois wrote:
> Hi,
> 
> Santiago Vila <sanvila at debian.org> (2019-01-06):
> > This happens because the "find path | xargs clojure" construction
> > which was common in many clojure packages is prone to error as its
> > success or not depends critically on the output order of the find
> > command.
> > 
> > Cyril Brulebois has already fixed several similar packages so I'm
> > just Cc:ing him.
> 
> I don't seem to have received a copy but I was chased down on IRC
> anyway. Pushed a commit to fix this but I'm now hitting issues with
> jh_classpath that I'm not sure how to fix:
> |    jh_classpath
> | error: Can't rename /usr/share/java/ring-core-1.6.2.jar as /usr/share/java/ring-core-1.6.2.zbk Permission denied 
> |  at /usr/share/perl5/Archive/Zip/Archive.pm line 471.
> | 	Archive::Zip::Archive::overwriteAs(Archive::Zip::Archive=HASH(0x563056bf7140), "/usr/share/java/ring-core-1.6.2.jar") called at /usr/share/perl5/Archive/Zip/Archive.pm line 439
> | 	Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x563056bf7140)) called at /usr/bin/jh_manifest line 342
> | 	main::update_jar("/usr/share/java/ring-core-1.6.2.jar", undef) called at /usr/bin/jh_manifest line 147
> | jh_manifest: Writing modified jar (/usr/share/java/ring-core-1.6.2.jar) failed: Permission denied
> | jh_classpath: jh_manifest -plibring-core-clojure "--classpath=/usr/share/java/clojure.jar /usr/share/java/tools.reader.jar /usr/share/java/ring-codec.jar /usr/share/java/commons-io.jar /usr/share/java/commons-fileupload.jar /usr/share/java/clj-time.jar /usr/share/java/crypto-random.jar /usr/share/java/crypto-equality.jar" /usr/share/java/ring-core.jar returned exit code 13
> | make: *** [debian/rules:10: binary] Error 13
> 
> Trying to remove the leading slash in debian/*.classpath makes this
> issue (EPERM) go away but I'm seeing this now which doesn't seem very
> reassuring:
> | jh_classpath: Cannot find usr/share/java/ring-servlet.jar: skipping
> | jh_classpath: Cannot find /usr/share/java/ring-jetty-adapter.jar: skipping

Apparently there are two bugs in jh_classpath:

  foreach my $package (@{$dh{DOPACKAGES}}) {
          my $tmpdir = tmpdir($dh{FIRSTPACKAGE});
          my $pkgfile = pkgfile($package, 'classpath');
          if (not $pkgfile and -f 'debian/classpath') {
                  $pkgfile = 'debian/classpath';
          }
          next if not $pkgfile;
          my @lines = filedoublearray($pkgfile);
          for my $line (@lines) {
                  my ($jar, @classpath_parts) = @{$line};
                  my $classpath = join(' ', @classpath_parts);
                  if (not -f $jar) {
                          my $jar_in_tmp = "${tmpdir}/${jar}";
                          if (not -f $jar_in_tmp) {
                                  warning("Cannot find $jar: skipping");
                                  next;
                          }
                          $jar = $jar_in_tmp;
                  }
                  doit('jh_manifest', "-p$dh{FIRSTPACKAGE}", "--classpath=${classpath}", $jar)
          }
  }

The first one is that if /usr/share/java/blah.jar exists (which can 
happen if you have a version of the package already installed on the 
build system), it will try to update the classpath of that jar file, 
even though it lies outside the build root. Now, stripping the initial 
slash from the filename prevents this from happening, but…

… $tmpdir always points to the first package's temporary directory, so 
jh_classpath won't be able to find any of the jars in the second and 
subsequent packages.

I'll try to work around this by invoking jh_classpath separately for 
each package and will file bugs afterwards.

Cheers,
Apollon