What is "dpkg-deb: warning: deprecated compression type 'lzma'; use xz instead"?

[Dershowitz]

dpkg-deb: warning: deprecated compression type 'lzma'; use xz instead

Any fix for this? Or it's just supposed to be ignored?

[kirb]

This is due to a limitation in the old version of dpkg included with Cydia. The warning assumes that you'll be installing on a device with a version of dpkg more recent than Cydia's, which makes sense if you're making a package for Debian (or derivatives like Ubuntu), but not for us.

While the warning has always been there since dpkg-deb made xz the default, until a few days ago Theos would null redirect dpkg-deb’s stderr output (that is, it’d prevent any warnings/errors from appearing). Reasoning behind the change is because if there’s a fatal error, you won’t see it unless you do make package messages=yes. They don’t typically turn up often, and messages=yes should always be the first thing to try if something seems odd, but I’ve still had a fair few people ask me why the packaging step was failing with no visible error.

This change was made in bb5626b. Admittedly it could have done with more warning (somehow… I need to work out some sort of news system).

Going to leave this issue open for a bit in case other people come here to ask the same question.

TL;DR: Ignore it, lzma is required for Cydia’s dpkg to be able to read it.

[Dershowitz]

I saw in a couple of posts in github which said a line in deb.mk (theos/makefiles/package/)
internal-package::
$(ECHO_NOTHING)COPYFILE_DISABLE=1 $(FAKEROOT) -r $(_THEOS_PLATFORM_DPKG_DEB) -lzma -b "$(THEOS_STAGING_DIR)" "$(_THEOS_DEB_PACKAGE_FILENAME)"$(ECHO_END)

to

internal-package::
$(ECHO_NOTHING)COPYFILE_DISABLE=1 $(FAKEROOT) -r $(_THEOS_PLATFORM_DPKG_DEB) -Zgzip -b "$(THEOS_STAGING_DIR)" "$(_THEOS_DEB_PACKAGE_FILENAME)"$(ECHO_END)

Added zgzip instead of lzma. Is that a proper solution and I am not getting that warning ever since!!

[kirb]

Gzip is old and doesn’t compress as well as newer formats such as lzma and lzma2 (xz). The fact that dpkg-deb doesn’t warn about it is most likely a bug. Don’t rely on it.

Again, there is nothing wrong with this warning. The only problem is that the warning is ugly to see, but dpkg-deb provides no way to ignore it.

[Dershowitz]

Right! Moving on from this, Swift is open sourced! Any chances theos would be able to compile swift? That'd be really amazing!

[kirb]

Swift has been supported for a while, actually! The way it’s structured is that you hopefully have the Swift runtime libraries in /usr/lib/libswift/<version>. You can grab those from Xcode easily – see the FAQ entry.

However, do not use Swift in a tweak, bundle, or any other dynamic library. Swift is not yet at a stage that you can mix different versions of it in a single process; if there are different Swift runtimes loaded into the process, they will conflict and cause instability. Even if it’s something like a preference bundle, if someone opens a preferences page from a bundle that links against Swift 2.0, and then they open from another bundle that links Swift 2.1, that won’t work. And of course there are breaking changes to the ABI (application binary interface) in each version of Swift, so you can’t simply force everything to use the latest version of Swift. (This isn’t just a pain for us – all frameworks used in an App Store app also must use the same version of Swift as the app. If a dependency hasn’t been updated for the latest Swift, you’re out of luck.)

That rules out anything particularly interesting, but it’s still perfectly fine to use Swift for an app, tool, etc. – anything that’s an executable and not a dynamic library. This is also why there aren’t yet Swift runtimes available in Cydia; because apps, as opposed to tweaks, are relatively uncommon. Optimo is reluctant to host Swift on BigBoss if it won’t see much use.

Apple has announced that Swift 3 will stabilise the API/ABI, so there won’t be any breaking changes after Swift 3.0. That makes it safe for Swift releases to be tied to the OS release, like how the Objective-C runtime is today. Of course that’s not going to be released until iOS 10/OS X 10.12 are out at the end of next year, so aside from maybe helping out with the Swift development process all we can really do is sit and wait.