Bug in TRB140: custom tarballs in Package Manager

Hello,

I’m trying to make TRB14x SDK 00.07.20.01 to generate a custom package tarball, which can be installed on “Package Manager” webpage. A synthetic example:

I have three packages: “aaa”, “bbb” and “ccc”, where “bbb” depends on “aaa” and “ccc” depends on “bbb”. Each package installs just a single file (named as the package) into /etc/abc. The packages source trees are symlinked into ./packages/ subdir. The SDK successfully compiles them into .ipk. Installing them manually one by one via opkg command works correctly.

The customer wants to have the update made user friendly, so I need to create the Package Manager tarball. When I edit ipk_packages.json file into:

{
    "aaa": {
        "base_dep": "aaa bbb ccc",
        "name": "abc_7_20_01"
    }
}

and run (-j1 because the command had problem with make parallelism):

make -j1 pm-clean
make -j1 pm

I will get a file:

./bin/packages/arm_cortex-a7_neon-vfpv4/zipped_packages/abc_7_20_01.tar.gz

which I can upload via web interface Package Manager → Upload package. This will install the tarball and all .ipks, but when I reload the page the manager shows each .ipk as a singular item:

and when I select them all and click “remove”, the Package Manager will fail and end up in this state:

Sometimes I can uninstall these packages when I click “remove” in correct order of dependecies, but a real world project is a tarball with several .ipk packages and have a complex dependencies, so one by one is not very practical.

Is there a way to make the Package Manager consider these three .ipks as a single item like it does with Teltonika’s tarballs?

Or is there a way to fix the Package Manager to correctly evaluate the dependency tree and uninstall all .ipks from the tarball correctly?

Hello,

Since this looks to be a custom-SDK related question, and is out of our technical support scope - I’ll reach out to our R&D to ask whether they’d be able to provide support with these questions. I’ll get back to you as soon as possible; until then, perhaps other users who’ve worked with something similar will be able to help you out.

Regards,
M.

1 Like

Hi, Petr,

Would it be possible to see your makefiles? Our R&D suspect that there might be something missing in them.

Let me know if you’d like to share them privately instead of here, I’ll send you a form in that case.

Regards,
M.

Hi,

The original example doesn’t contain any private data so I can send it here. However it seems my account is too new to upload any files. I’ve stored the files on a google drive.

I can send you a patch file with everything changed from TRB1_R_GPL_00.07.21.tar.gz.

However if the SDK is built natively it fails due to cmake dropping support for old versions and gcc having more strict code checking. Additionally the 7.21 version seems to have a missing file and ipk_packages.json don’t like a duplicated .ipk name (I’ve had the “aaa” as object key and as a dependency for “base_dep”). It took me few tries, so it isn’t a “dry” run patch.

Contents of the attached patch:

  • Missing package/teltonika/site_manager/Config_siteman.in
  • Added -DCMAKE_POLICY_VERSION_MINIMUM=3.5 into include/cmake.mk
  • Added -std=c1x into toolchain/python2/Makefile
  • Newer version which compiles tools/bison/Makefile
  • Newer version which compiles tools/e2fsprogs/Makefile
  • Newer version and -std=c1x into tools/gmp/Makefile
  • Newer version which compiles tools/m4/Makefile
  • GCC checking for incompatible pointers tools/squashfskit4/Makefile
  • A minimal .config
  • ipk_packages.json changed to only build the testing abc tarball example

The testing example packages are attached too. They needs to be copied or symlinked into:

  • package/aaa/
  • package/bbb/
  • package/ccc/

After running:

make -j$(nproc)
staging_dir/host/bin/usign -G -p key-build.pub -s key-build
make -j1 pm-clean	#failed on older SDK version when called with -j$(nproc)
make -j1 pm			#failed on older SDK version when called with -j$(nproc)

I get attached bin/packages/arm_cortex-a7_neon-vfpv4/zipped_packages/abc_7_21.tar.gz tarball.

P.S. The eventual product (in the future) may use a vuci page, so I tried to build a vuci API/UI example located in an external custom feed which can be defined in feeds.conf.default:

src-link customfeed /home/telt/t00_tempfeed

but it fails at scripts/prepare_tlt_pm_packages.sh as the code seems to not support external feeds and also because vuci core makefiles (ex. package/feeds/vuci/api.mk) use relative paths.

Hello,

Thank you for sharing everything in so much detail. Once again, I’ll get back to you as soon as I have further details.

Regards,
M.

Hi, @petr_cvek ,

Here’s what our R&D had to say:

  1. Only the main package Makefile should have PKG_TLT_NAME - it is used to display the package in package manager page.
  2. From your Makefiles it looks like the main package is ccc because the depends go like ccc → bbb → aaa, so the ipk_packages.json file should be like this:
"ccc": {
        "base_dep": "bbb aaa",
        "name": "abc_7_20_01"
}

Kindly let me know if this helps,
M.

1 Like

Thanks! It seems it is working in a real application too. I think I’ve also had to remove PKG_ROUTER from supporting packages.

Would it be possible to update readme in some future SDK release about this requirement?

Hi!

Glad it worked. I’ll ask them to get this updated.

Have a great day,
M.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.