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 or invalid 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.
Missing or invalid package section
The package is missing a value for the
Section field, or appears to use an invalid value.
Section field to one of the following:
Addons: Add-on packages that extend the functionality of another package
Applications: Applications that can be run on the device
Carrier Bundles: Carrier bundles that provide carrier-specific functionality
Data Storage: Packages that provide data storage functionality
Developer: Packages targeted towards providing developer functionality
Development: Packages that facilitate development tools
Education: Packages that provide educational functionality
Entertainment: Packages that modify or provide entertainment functionality
Fonts: Packages that provide fonts
Games: Packages that provide games
Keyboards: Packages that provide keyboard alternative keyboards
Localization: Packages that provide localization functionality
Messaging: Packages that modify the messaging functionality
Multimedia: Packages that provide multimedia functionality
Navigation: Packages that modify or provide location and navigation functionality
Networking: Packages that modify or extend the networking-stack on the device
Productivity: Packages that aim to target productivity suites
Ringtones: Packages that provide additional ringtones
Scripting: Packages that primarily consists of scripts or other code that can be executed
Security: Packages that modify or extend the security functionality on the device
Site-Specific Apps: Packages that provide site-specific functionality and modifications
Social: Packages that modify or provide social functionality
Soundboards: Packages the bundle soundboards
System: Packages that modify or extend the system functionality on the device
Terminal Support: Packages that extend terminal capabilities on device
Themes: Packages that provide visual themes
Toys: Packages the interface with physical devices like toys
Tweaks: Packages that modify the functionality of the device through runtime injection
Utilities: Packages that provide utility functionality
Wallpapers: Packages that provide additional wallpapers
Widgets: Packages that provide additional widgets
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
iphoneos-arm64: Supported on iOS rootless jailbreaks
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 architecture does not match file prefix
The value of the
Architecture field does not match the prefix of the file(s) in the package. With the introduction of the Rootless scheme, any iOS targeted packages with an
iphoneos-arm64 architecture must move all files to the
If you are targeting the rootfull system, your architecture target should be
iphoneos-arm and files should be located in the root of the package. If you are targeting the rootless system, your architecture target should be
iphoneos-arm64 and files should be located in the
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.