Ozmydis

Your fix has allowed me to download and install the packages that were breaking now. Still get an error back from the build process though inside the output/debug/install.log file: openpgp: Passphrase is required to unlock private key "Armbian builder (Temporary key for installing packages during Armbian image creation) <root@localhost>" openpgp: 2048-bit RSA key, ID 92B90DE1925644A6, created 2016-08-05 Loading packages... Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). OK Ign:1 http://localhost:8189 jammy InRelease Hit:2 http://ports.ubuntu.com jammy InRelease Hit:3 http://ports.ubuntu.com jammy-security InRelease Hit:4 http://ports.ubuntu.com jammy-updates InRelease Hit:5 http://ports.ubuntu.com jammy-backports InRelease Hit:6 http://ppa.launchpadcontent.net/saiarcot895/chromium-beta/ubuntu jammy InRelease Hit:7 http://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy InRelease Hit:10 https://ppa.launchpadcontent.net/jonathonf/zfs/ubuntu jammy InRelease Hit:11 http://deb.volian.org/volian scar InRelease Hit:8 https://cli.github.com/packages stable InRelease Hit:9 http://armbian.systemonachip.net/apt jammy InRelease Ign:1 http://localhost:8189 jammy InRelease Ign:1 http://localhost:8189 jammy InRelease Err:1 http://localhost:8189 jammy InRelease Could not connect to localhost:8189 (::1). - connect (111: Connection refused) Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused) Reading package lists... W: Failed to fetch http://localhost:8189/dists/jammy/InRelease Could not connect to localhost:8189 (::1). - connect (111: Connection refused) Could not connect to localhost:8189 (127.0.0.1). - connect (111: Connection refused) W: Some index files failed to download. They have been ignored, or old ones used instead. Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package helloworld Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). OK Checking that no-one is using this disk right now ... OK Which is unusual since it seems to download the package fine in the BUILD_CHROOT environment... I think that a good amount of my issues came from misunderstanding the build system, and good documentation would be helpful in that regard. This conversation started with me suggesting to do this all in the customize-image.sh file, so some information on when and when not to use this file would be useful. Beyond documentation, here's a short list of things I think might be improvements: A warning message for new users might be nice if they attempt to run the build environment on something which is not officially supported by Armbian. Some example files in the packages/extras-buildpkgs directory which contain comments and details on how to lay out the configuration file for a package would be helpful (maybe something similar to the userpatches/config-example.conf file?). Another solution would be to create something similar to Yocto's devtool for generating and testing packages to be put onto the image. The process might be much easier for users with something like this. The BUILD_CHROOT parameter's functionality might be a part of the testing functionality for example. In customize-image.sh it might be better to give the chroot and host environment variables instead of using userpatches/overlay and /tmp/overlay. customize-image.sh might be better off being spread across multiple files? I imagine someone who might have multiple releases would have quite a large file here if they're doing a lot of customization to the image before unmounting.

Ok, I am currently on holiday so I will get around to providing feedback and using your new commits in a couple of weeks.

Thank you. I was able to debug the issues with my Debian package. Using your chroot_build_pkg branch I can build the .deb file into what I expect it to look like. package_checkbuild() and package_checkinstall() are both set to true for my package so I expect that the package will be installed to the image when the EXTERNAL_NEW=compile parameter is applied. Of course when I do add the EXTERNAL_NEW=compile parameter, I still have the original issue where my system tries to download amd64, when it should download arm64, so the image build fails before it reaches my package. Need to figure out some sort of way to get around this...

I've created a .conf file for my package now. It seems to recognise it as it performs the build when I call the package from the BUILD_CHROOT parameter, but does not actually put the executable into the deb package; it only puts the documentation files in there. To solve this I was hoping to base my package layout in Armbian off the htop package which already exists in the repository, however htop also fails during the build process: ./compile.sh BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no NO_APT_CACHER=yes NCPU_CHROOT=4 BUILD_CHROOT='htop' Output: [ warn ] This script requires root privileges, trying to use sudo [ o.k. ] Using config file [ /home/user/going-armbian-repo/armbian-build/userpatches/config-example.conf ] [ o.k. ] Command line: setting BOARD to [ orangepi-r1plus-lts ] [ o.k. ] Command line: setting BRANCH to [ current ] [ o.k. ] Command line: setting RELEASE to [ jammy ] [ o.k. ] Command line: setting BUILD_MINIMAL to [ yes ] [ o.k. ] Command line: setting BUILD_DESKTOP to [ no ] [ o.k. ] Command line: setting KERNEL_ONLY to [ no ] [ o.k. ] Command line: setting KERNEL_CONFIGURE to [ no ] [ o.k. ] Command line: setting NO_APT_CACHER to [ yes ] [ o.k. ] Command line: setting NCPU_CHROOT to [ 4 ] [ o.k. ] Command line: setting BUILD_CHROOT to [ htop ] [ .... ] Extension being added [ rkbin-tools :: added by main.sh:381 -> configuration.sh:173 -> config/sources/families/rockchip64.conf:1 -> config/sources/families/include/rockchip64_common.inc:1 ] [ o.k. ] Extension manager [ processed 3 Extension Methods calls and 3 Extension Method implementations ] [ o.k. ] Starting package building process [ jammy/arm64 ] [ o.k. ] Unpack the clean environment [ jammy-arm64-v7.tar.xz ] [ o.k. ] selected_packages= [ htop ] [ o.k. ] Building packages [ htop jammy/arm64 ] [ o.k. ] Checking git sources [ extra/htop 2.2.0 ] [ .... ] Up to date Failed to mount /etc/localtime (type n/a) on /home/user/going-armbian-repo/armbian-build/.tmp/build-VYOYl/jammy-arm64-v7/usr/share/zoneinfo/UTC (MS_BIND ""): No such file or directory [ .... ] Copying sources ... checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating htop.1 config.status: creating config.h config.status: executing depfiles commands make[1]: Leaving directory '/root/build/htop' dh_auto_build make -j4 make[1]: Entering directory '/root/build/htop' ./scripts/MakeHeader.py AvailableColumnsPanel.c ./scripts/MakeHeader.py AvailableMetersPanel.c ./scripts/MakeHeader.py CategoriesPanel.c ./scripts/MakeHeader.py CheckItem.c make[1]: Leaving directory '/root/build/htop' [ error ] Failed building [ htop jammy/arm64 ] [ o.k. ] Build time htop [ 149 sec. ] [ warn ] Following packages failed to build [ .... ] htop:jammy/arm64 [ o.k. ] Runtime [ 2 min ] Some problem with python maybe? I'm not quite sure. It might be easier to resolve the original issue with my package if I knew where the executable was being compiled to, since I assume "/root" must be a mount somewhere on my build machine...

Thanks, I can build using this when the EXTERNAL_NEW=compile parameter is omitted. BUILD_CHROOT doesn't seem to use my debian package when I give its name, which might mean I have an issue with how I'm setting up the package... 1) Does BUILD_CHROOT throw any errors if it cannot find the package name it has been given? 2) Is a .conf file in the extras-buildpkgs directory required for detecting package names/configuration for Armbian? 3) Are there any ways of speeding up the build times when debugging for problems such as this? I'll take a further look into this at a later date.

Yes, this is all running in a proxmox server VM. distcc is installed, output: $ distcc --version distcc 3.3.5 x86_64-pc-linux-gnu (protocols 1, 2 and 3) (default port 3632) built Jan 13 2022 19:12:28 ...etc. I've installed a new VM from a fresh 22.04 ISO, just waiting to see what comes of it. Ok, thanks for letting me know.

I updated my build environment to Jammy 22.04.1 before seeing your message, but I get the same issue as I did originally unfortunately. I was using Focal 20.04 beforehand. $ uname -a Linux build-env 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux $ dpkg --print-architecture amd64 Any suggestions?

My mistake, I somehow missed that the build environment must be Ubuntu Jammy 22.04.x amd64.

Thanks for your reply, I've created a debian package now. However, when I run: sudo ./compile.sh BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img EXTERNAL_NEW=compile I receive the following error: [ o.k. ] Creating build chroot [ focal/amd64 ] I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C) I: Retrieving Packages I: Retrieving Packages I: Retrieving Packages E: Couldn't download http://localhost:3142/ports.ubuntu.com/dists/focal/main/binary-amd64/Packages [ error ] ERROR in function create_chroot [ main.sh:595 -> main.sh:552 -> chroot-buildpackages.sh:194 -> chroot-buildpackages.sh:68 -> general.sh:0 ] [ error ] Create chroot first stage failed [ o.k. ] Process terminated I assume this is some sort of other issue, since it occurs even when I remove my package from the packages/extras-buildpkgs/ directory. I'm basing my build off the master branch (commit 31ac6383e tag 22.11.0-trunk.0048).

Just started with creating custom images for an Orange Pi R1+ LTS board. In my build I'd like to compile some custom C++ applications using CMake, then install them onto the root file system to run on the board. Couldn't find much on this on the docs, though maybe I haven't looked hard enough! A couple of questions: I noticed the customize-image.sh script in the build repository - would amending this script be the intended method for this kind of functionality or is there another, better way? How would I provide CMake the relevant info to compile correctly for the board. Thanks in advance.