Replicant

I remember having a similar issue when trying to sign the build for the first time..
The issue is in the key generation process.

I vaguely remember tweaking the build script somehow to make it compliant to my environment, and then being able to successfully generate keys. Or maybe I had to change something in environment variables..

Unfortunately, I can't remember exactly what I did, I'm sorry.

Maybe you can try by generating your signing keys without a wrapping passphrase, just as a test.
Also, try and take a look inside the script, maybe some hints will come out of it..

But I can tell you, it must be related to something in the signing script that is not perfectly fitting your building environment.

What's the configuration of your building machine?
I had that issue inside a Debian Stretch chroot on a Trisquel7 machine..

I vaguely remember tweaking the build script somehow [...]

Thanks to pointing me in this direction. I just thought about code of the Java stuff, I did not take the script itself into account.
I will have a look later and report it here.

Maybe you can try by generating your signing keys without a wrapping passphrase, [...]

I already did this before posting the first time.

What's the configuration of your building machine?

It is a Debian as well: Current testing (buster), running inside Qemu.

I have just realised that these two lines

replace:  ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904 test-keys
with:  ro.build.display.id=replicant_i9300-userdebug 6.0.1 MOI10E eng.replicant.20180122.125904

Please forget my last comment... ;)

Short update:
I was able to strip it down to the call of signapk.jar. I passed the original and some other APKs, no difference. Since the same also occur if some non-existent filename is used, it seems it is not related to the APK but to some prior code.

I did a small Internet research, the error message is known. Let's see if I find the matching problem/solution.

Okay, I got it working. I will post the (correct) fix later...

Indeed, using passphrases do not work.

Using keys without passphrases failed for me, too, but for a different reason: Some fields are not allowed to be empty, but the script does not provide failure proof defaults.
Sadly I have missed the failure messages on the very first run, since the script itself lackes proper error handling for that case as well.

It works for me now (without passphrases). I improved the script a little (proper defaults, error handling) and sent patches to the mailing list.
Nevertheless, this issue is still valid.

Regards,
doak

Thanks for taking the time to look into this issue..
I haven't had the chance to look into your patch, but thanks anyway for working on it!

The patches for this issue can be found from https://lists.osuosl.org/pipermail/replicant/Week-of-Mon-20180129/thread.html. Also this issue caused the problem in #1876 which I have now closed so we can keep track of things more easily.