Closed JacobTDC closed 3 years ago
How did you create the package/where is it from?
@Grimler91
How did you create the package/where is it from?
Well, the program is built by me from http://traceroute.sourceforge.net, but the manifest is as follows:
{
"name": "traceroute",
"version": "2.1.0",
"description": "a modern implementation of the traceroute utility",
"homepage": "http://traceroute.sourceforge.net/",
"arch": "aarch64",
"maintainer": "JacobTDC",
"conflicts": ["tracepath"],
"files": {
"./source/traceroute/traceroute": "bin/traceroute",
"./manpages/traceroute.8.gz": "share/man/man8/traceroute.8.gz"
}
}
The only change I made to the downloaded source is removing -lm
from line 142 in Make.rules
On which system did you build and package it? Termux? Mac? Windows? GNU/Linux?
I built and packaged it in Termux.
Here's my neofetch
:
-o o- u0_a138@localhost
+hydNNNNdyh+ -----------------
+mMMMMMMMMMMMMm+ OS: Android 7.1.2 aarch64
`dMMm:NMMMMMMN:mMMd` Host: KYOCERA E6810
hMMMMMMMMMMMMMMMMMMh Kernel: Linux 3.10.84-perf
.. yyyyyyyyyyyyyyyyyyyy .. Uptime: 3 days, 21 hours, 43 minutes
.mMMm`MMMMMMMMMMMMMMMMMMMM`mMMm. Packages: 320 (dpkg), 1 (pkg)
:MMMM-MMMMMMMMMMMMMMMMMMMM-MMMM: Shell: fish 3.0.2
:MMMM-MMMMMMMMMMMMMMMMMMMM-MMMM: CPU: Qualcomm MSM8952 (8)
:MMMM-MMMMMMMMMMMMMMMMMMMM-MMMM: Memory: 1569MiB / 2808MiB
:MMMM-MMMMMMMMMMMMMMMMMMMM-MMMM: Battery: 55% [CHARGING]
-MMMM-MMMMMMMMMMMMMMMMMMMM-MMMM- Locale: en_US.UTF-8
+yy+ MMMMMMMMMMMMMMMMMMMM +yy+
mMMMMMMMMMMMMMMMMMMm
`/++MMMMh++hMMMM++/`
MMMMo oMMMM
MMMMo oMMMM
oNMm- -mMNs
However, I can install it like so:
$ dpkg-deb -R traceroute_2.1.0_aarch64.deb traceroute
$ dpkg-deb -b traceroute
$ apt install ./traceroute.deb
I'm experiencing the same issue. As a quick workaround, I've been unpacking the faulty .deb and then repacking it with dpkg-deb --build
.
It looks like there's an issue with the way termux-create-package
is using the tarfile module to create control.tar.xz and data.tar.xz.
A cursory comparison of the faulty control.tar.xz and working repacked control.tat.xz is as follows:
$ tar -tf ./original/control.tar.xz
./control
$ tar -tf ./fixed/control.tar.xz
./
./control
It's a similar story with data.tar.xz.
This issue should be fixed now with pull #21.
After a little bit digging, I found that the error produced is because of the tar format generated by the tool is incompatible with dpkg
.
According to this similar issue from another repository (I've translated the reply, thanks to Google Translate :smile: ):
dpkg: error processing archive /var/root/MonkeyDevPackages/xxx_0.1-1_iphoneos-arm.deb (--install): corrupted filesystem tarfile in package archive: unsupported PAX tar header type 'x'
... After checking, the reason is that /opt/MonkeyDev/bin/md uses macOS's own tar, that is, bsdtar, and after the jailbreak, Cydia's Tape Archive and Debian Packager are GNU dpkg and gnutar, which are not fully compatible. ...
And also the Python docs says (tarfile.DEFAULT_FORMAT):
The default format for creating archives. This is currently PAX_FORMAT. Changed in version 3.8: The default format for new archives was changed to PAX_FORMAT from GNU_FORMAT.
The default generated tarfile format was changed to PAX which is incompatible with dpkg
's GNU tar.
So to fix that, you need to change the lines that creates the control.tar.xz
and data.tar.xz
into this:
def write_control_tar(tar_path, manifest):
...
with tarfile.open(tar_path, mode='w:xz', format=tarfile.GNU_FORMAT) as control_tarfile:
def write_data_tar(tar_path, installation_prefix, package_files):
...
with tarfile.open(tar_path, mode='w:xz', format=tarfile.GNU_FORMAT) as data_tarfile:
Add the
format=tarfile.GNU_FORMAT
to the arguments (see TarFile Objects).
Totally unrelated, but... regarding to my opened issue: #20. The default behavior of the tool will only target individual files. That is problematic for large number of files, i.e, you'll have to manually map each files to their destination path. So if you want to just include an entire directory and recursively add all its contents, you can change the line:
def write_data_tar(tar_path, installation_prefix, package_files):
...
data_tarfile.add(input_file_path, arcname=output_file, recursive=True)
Change the
recursive=False
toTrue
(see TarFile.add)
Example package structure:
.
├── bin
│ └── script
└── manifest.json
Include the directory bin
in the manifest.json
:
{
...
"files": {
"bin": "bin"
}
}
When built and installed will result to this:
${PREFIX}/bin/script
I observe this issue when I build packages on Arch Linux. Python 3.9.1 termux-create-package 0.7
termux-create-package 0.7
There v0.10 already.
https://github.com/termux/termux-create-package/releases/tag/v0.10
There v0.10 already.
Dear @xeffyr, I have to install this manually with:
pip uninstall termux-create-package
pip install https://github.com/termux/termux-create-package/archive/v0.10.zip
But after installation, the version 0.7 is displayed, despite the fact that it is actually 0.10 Could you please update the version to 0.10 in setup.py at least? I'm not even talking about adding this to PyPI. Thank you
Ah, ok I will fix setup.py.
But about publishing on PyPI thats question probably to @fornwall as I do not manage its releases.
Thank you again!
Attempting to install the package using either
apt install
ordpkg --install
results in an error.