Errors

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.

Solution

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.

Solution

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 $?

Output of 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.

Solution

Add a 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.

Solution

Set the 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

For example:

Section: Tweaks

Package architecture not supported

The value of the Architecture field is missing, or not set to a value Chariz supports.

Solution

Set the 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

For example:

Architecture: iphoneos-arm

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 /var/jb directory.

Solution

If you are targeting the rootful 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 /var/jb directory.

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.

Solution

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.

Solution

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 (root).

Solution

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 (1 or 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.

Solution

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.

Solution

Add 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.

Solution

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 bash:

Pre-Depends: bash

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 sh functionality 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.

Solution

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.

Solution

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.