This is a list of technical errors you may receive after delivering a deb package to Chariz. Such an error will cause our service to be unable to process your delivery. You will be required to correct the issue and deliver a new build in order to proceed.
Package is corrupted or invalid
The package was unable to be read as a Debian package file. This can occur in a variety of situations. The error message will explain the specific issue our system had in reading your package.
Make sure the package can be installed on a device you own without any issues. Depending on the cause of the issue, you may consider using the “Restore System” or “Restore Root Filesystem” feature of your jailbreak tool to confirm that it can be understood by a standard installation with no updates or additional packages installed.
Try rebuilding the package, then try uploading it again.
Package version is older than current release
The value of the
Version field in the package you have delivered is not recognized as being a greater version than a release previously made for this package. As a result, when released, this version will not be offered as an upgrade to existing users, and will only appear as a downgrade option even to new users.
Change the value of the
Version field on your package to a version dpkg recognizes as being newer. You can use
dpkg --compare-versions to confirm your new package version is recognized as newer. For example:
dpkg --compare-versions 1.1 gt 1.0; echo $?
0 indicates the comparison is true; any other number indicates it is false.
If you are trying to upload an older version of your package to provide a downgrade option for users, let us know so we can make an exception for this delivery.
For further information, refer to Debian Policy Manual § 5.6.12. Version.
Missing package description
The package is missing a value for the
Description field, or appears to use a placeholder value.
Description field, and supply a short description of your package. For example:
Description: Does awesome things with your FlorpPhone.
This string is expected to fit on a single line. Review it in your package manager to confirm that it fits.
Package architecture not supported
The value of the
Architecture field is missing, or not set to a value Chariz supports.
Architecture field to one of the following:
iphoneos-arm: Supported on iOS
darwin-arm64: Supported on Apple Silicon macOS
darwin-amd64: Supported on Intel macOS
appletvos-arm64: Supported on tvOS (Apple TV 4th generation and later)
watchos-arm: Supported on watchOS (Apple Watch Series 3 and earlier)
watchos-arm64: Supported on watchOS (Apple Watch Series 4 and later)
all: Supported on all platforms – this should only be used for packages that do not contain binary code
Package contains noisy files
Files were found in the package that appear to be generated by an application such as Finder or Windows File Explorer. Such files should not exist in a package, and have the ability to cause conflicts with other packages that also have the same issue. The error message will list where the file(s) appeared in your package.
Review the process you use to generate your package, and ensure no unexpected files are being added. Using the
find command to display a file tree may be useful in determining where in your process the files are being added.
find . -name .DS_Store -or -name Thumbs.db
Package contains debug binaries
Binaries were found in your package that have debugger functionality enabled, or your package version contains the string
+debug. This is likely due to submitting a debug package rather than a release package.
If you use Theos, add
FINALPACKAGE=1 when building to create a release build:
make package FINALPACKAGE=1
If you are already doing this, or the equivalent for your build tools, review whether this is being overridden. For instance, in the case of a C, C++, Objective-C, or Swift-based project, it is possible the
-g flag has been added to your build.
Package contains dangerous permissions
Files or directories were found in your package with permissions that may pose a risk to end-user device security. Chariz strictly ensures all files and directories in a package are owned by
root:wheel, and are not writable by any user except the owner (
Review your package for files or directories where the “group” or “world” bits have a value higher than
5. In other words, users other than the file owner (
root) should not be able to overwrite files or create files in directories owned by your package. Additionally, also review for files or directories where any user does not have read access (
0). Hiding packaged files this way is not recommended.
If your package contains files that are expected to be modified during typical use of the product, such as default versions of configuration files, note that this is not advised as your package would be overwriting the user’s configuration when they update/reinstall your package. Instead, move these default files to a different location, and consider it a read-only template file. When your code needs to access the configuration file, if the normal user-writable path to the file doesn’t exist, make a copy of your template to the user-writable path.
If you are using Windows as part of your development process, you may have unintentionally reset permissions on your files. Windows is not aware of the Unix permissions model. These bad permissions carry onto packages you build on this system, and may carry onto other operating systems you develop the project on.
If you use Windows Subsystem for Linux, by default when using the
/mnt/c mountpoint, Unix file permissions will be lost. You may consider either mounting the C: drive inside Linux with the
metadata option set (here is a blog post on this), or move your project to your default home directory within WSL, and access it from Windows via File Explorer integration and/or Visual Studio Code Remote. You will still need to manually review and fix permissions if they have been reset by Windows.
If you are using Cygwin, switching to WSL is recommended.
For further information on permissions, refer to Debian Policy Manual § 10.9. Permissions and Owners.
Package contains privileged binaries
This is a warning only. Your package will be reviewed manually to confirm that the use of an identified privileged binary is secure.
If your delivery is not approved, consider whether your intended functionality can be achieved without using a privileged binary. Alternatively, you may be requested to review the security of your privileged binary, in order to minimize potential risk to end-user device security.
Missing PreferenceLoader dependency
A common mistake is to add a preference bundle to a package, and not add a dependency for PreferenceLoader. This error has been found in your package.
preferenceloader to your
Depends: list. For example:
Depends: mobilesubstrate, preferenceloader, com.example.otherdependency
Missing bash dependency
Scripts were found in your package that depend on bash. Some jailbreak distributions no longer install the
bash package by default, preferring to have the user (or a package they install) manually opt into installing it. The dash shell, an implementation of a POSIX-compliant Bourne shell (
sh), is installed by default.
Consider whether you need bash for this script. Test your script by changing the hashbang/shebang line to
#!/bin/sh – or add it if it’s missing. If this fails, review whether it is possible to port the script to not rely on “bashisms” – in other words, be Bourne shell-compatible. Distributions that use bash will remain fully compatible with your script. Use the
checkbashisms script, available in the devscripts package on Debian/Ubuntu and checkbashisms on Homebrew, to automatically scan for bashisms.
If this does not seem feasible, you can add a pre-dependency on
Take note that this is distinct from the standard
Depends: field you would be familiar with. The package manager needs to be aware that bash must be installed beforehand for the installation of your package to succeed.
Here are some useful resources for porting a script to Bourne-compatible:
- Debian Policy Manual § 10.4. Scripts documents guidelines for maintenance scripts, and the
shfunctionality they can rely upon.
- Advice from Ubuntu Wiki
Missing hashbang in maintenance script
A maintenance script was found in your package that doesn’t have a hashbang/shebang line indicating the shell to use. This may cause the package to incorrectly be executed using
sh rather than
bash, in which case installation or uninstallation could fail.
Add a hashbang/shebang line to the affected script(s). While doing so, refer to the above Missing bash dependency section to determine whether you may also require a dependency on bash.
Package contains binaries that may not run on earlier OS versions
The compatibility data you have specified on your Chariz product indicates support for a minimum operating system version that binaries in your package do not appear to support. This can cause the binaries to not run on those earlier operating systems, or rely on behavior that may be undefined on earlier operating systems.
There are multiple reasons why this error can appear. It can be triggered if your binary has been built without setting the deployment version, or setting it to a value inconsistent with compatibility data specified on Chariz. It may also be triggered by building binaries for the
arm64e platform (used by Apple A12 CPUs and newer) that use the newer ABI that breaks support with operating systems before iOS 14.0, or building binaries that do not contain a “slice” for the
armv7 platform (used by Apple A6 CPUs and older) when supporting operating systems before iOS 11.0.
If the compatibility data on your product with Chariz is incorrect, correct it now, and then deliver your package again.
If you use Theos, ensure
TARGET is set in your top-level Makefile, before
common.mk is included. An example of this might look like:
export TARGET = iphone:latest:13.7
This would indicate that your package supports iOS, should be built using the latest iOS SDK, and is intended to run on iOS 13.7 and newer.
If you support iOS versions before 14.0, you must currently build your release using Xcode 11.7. You can download it via xcodereleases.com. Then, use
xcode-select or Xcode Preferences → Locations → Command Line Tools to switch to Xcode 11.7 as your toolchain. Alternatively, if you are confident that arm64e support is not necessary, you can manually specify architectures. In the case of Theos, this might look like:
export ARCHS = arm64
If you have intentionally created a binary with higher OS support than your listed compatibility, for instance to support functionality your product only supports on newer OS versions, let us know. We will make an exception for this binary.