dpkg error: archive has premature member

[johdah]

I have used sbt native packager for a while to build our play projects to a deb package. But after updating the packages in Debian today I started to get this error when installing the application on our Ubuntu 14.04 server.

dpkg-deb: error: archive 'RestAPI_SNAPSHOT_all.deb' has premature member 'control.tar' before 'control.tar.gz', giving up

Information

sbt native packager version: 1.3.2
sbt version: 0.13.16
dpkg version: 1.19.0.4

[muuki88]

Thanks for your bug report 😀

What was the previous native-packager version you used that worked?

Can you take a look inside the Debian file an see if there are any differences between the working and new version?

[johdah]

Last dpkg version that worked was 1.17.5 and then it worked so I'm pretty sure it's related to changes in dpkg. But it's a good idea to dig deeper into the deb file and see what's different. I will do that.

[johdah]

control.tar.gz is 1822 bytes big in the one generated by dpkg 1.19 and 20480 in the one generated by 1.17. But I can't see any difference in the content of the extracted folders.

[muuki88]

Thanks for checking. Have you found any stackoverflow questions regarding this error message?
We haven't changed anything in the control file order since a very long time. And if there is a breaking change in dpkg we surely need to fix that in native packager.

What you can also do ist to do the following

$ sbt debian:stage

should generate a staging folder in target/.. that contains everything to run dpkg-build. You could check the content there.

[johdah]

The binary is different but the same byte size and the "DEBIAN/conffiles" is in a different order. But other than that I haven't managed to find any difference.

[muuki88]

Thanks for digging further into this.

This [bug request|https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1730627] seems to capture this error. Does your system configuration looks similar?

[muuki88]

Thanks for digging further into this.

This bug request seems to capture this error. Does your system configuration looks similar?

[GreyCat]

I have similar issue, and, indeed, it looks like dpkg --build have changed format of generated control file.

With older dpkg versions, I was getting control.tar.gz. What's even weirder is that now, with dpkg 1.19.0.4, I'm getting:

• a deb package named package_1.2.3_all.deb with control.tar inside, while building using sbt debian:packageBin
• a deb package named package-1.2.3.deb with control.tar.xz inside, while building using sbt debian:stage and then running dpkg --build jvm/target/package-1.2.3 manually

It looks like there could be some way to tell dpkg which control.tar / control.tar.gz / control.tar.xz to generate?

[muuki88]

Thanks a lot @GreyCat
I hadn't had the time to tackle this one.

There should be some way to configure the generated control file format. What I forgot to ask:
Are there any issues with JDebPackaging, the java Debian implementation?

The plan is to find the configuration parameter for dpkg-build that configures the control file format. We should add setting for Debian build parameters ( if not already present ), add the required parameter and document why and how this works.

[muuki88]

I found something interesting:

https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/debian/DebianNativePackaging.scala#L42

We already have debianNativeBuildOptions and we set the compression to None. Can you try to set these options to

debianNativeBuildOptions := Seq.empty

and see if the issue remains?

[GreyCat]

I've experimented with dpkg-deb --build -Z... options: indeed, it can be "gzip", "xz" or "none" now, and it results in different control.tar formats being generated. There's also --uniform-compression (which is turned on since ~mid 2016) and --no-uniform-compression options that also affect what's generated.

[muuki88]

Thanks for investigating this. I'm not sure what we should put as a sensible default. Maybe we turn off the -Znone by default and document the various options. WDYT?

[GreyCat]

Looks like it's all extremely messy :( Deb packages undergone several major revisions in the last few years, which uncovered that there were quite a few different implementations of tools that work with debs, and many have compliance problems — https://wiki.debian.org/Teams/Dpkg/DebSupport

I've stumbled upon this by trying to submit a .deb package built by newer sbt-native-packager on a box with a newer dpkg-deb to BinTray. After talking to their support them, it turned out that they only support control.tar.gz format debs — and that's probably only the tip of the iceberg.

My best bet would be to document this as a known problem and let the end-user decide. Probably the sanest default would be just sticking to whatever default settings a particular dpkg-deb installation has — i.e. newer versions would generate control.tar.xz, and older would generate control.tar.gz, but at least that would be in line with defaults suggested by Debian upstream.

[muuki88]

You are awesome 🤩 @GreyCat
This is not really good news, but we know that the dpkg mess is the root cause.
Would you like to make a pull request removing the -Znone parameter and a Known Issues section to the debian.rst?

[JoolsF]

I wasn't able to resolve the issue using the debianNativeBuildOptions in Debian := Nil option. However, I managed to resolve by getting the packager to create the control.tar.gz instead of the control.tar.xz debianNativeBuildOptions in Debian := Seq("-Zgzip", "-z3")

[cleary]

FYI this is on it's way to being resolved with dpkg 1.17.5ubuntu5.8

Link to source packages for testing follows:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1730627

[muuki88]

Thanks for the information 🤗

[betesh]

Upgrading dpkg to 1.17.5ubuntu5.8 worked for me!

[muuki88]

Thanks for sharing.