going

For only sunxi & EDGE use the configuration file for this: cp userpatches/config-example.conf userpatches/config-test.conf echo "KERNEL_VERSION_LEVEL=5.19" >> userpatches/config-test.conf echo "KERNELSWITCHOBJ='tag=v5.19.14' >> userpatches/config-test.conf echo "EXPERT=yes" >> userpatches/config-test.conf echo "BRANCH=edge" >> userpatches/config-test.conf ./compile.sh test See more config/sources/families/include/sunxi* files

I see two ways. 1) You can turn the user's @hoov manual into a debian/rule file. Mount the already patched kernel into the build environment and assemble the kernel module. Take my branch. https://github.com/The-going/armbian-build/tree/chroot_build_pkg Use the parameter mount_linux_src=yes https://github.com/The-going/armbian-build/blob/1e9a7a1b24e5d5aead730f58ad910124782b5576/lib/chroot-buildpackages.sh#L313 Here I help the user to build a debian package in a chroot environment, bypassing many unnecessary steps. 2) I wanted to try to rework the debian rules directly from the original ubuntu repository: /gituser/ubuntu-kernel> mkdir jammy /gituser/ubuntu-kernel> cd jammy/ /gituser/ubuntu-kernel/jammy> git init /gituser/ubuntu-kernel/jammy> git remote add origin git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy /gituser/ubuntu-kernel/jammy> git fetch /gituser/ubuntu-kernel/jammy> git checkout -b hwe-5.19-next origin/hwe-5.19-next I'll take that as a basis. Everything is available here. We only need to choose what we will take.

Your gratitude can be made in the form of a description of the problems you encountered when interacting with the build system. What functionality could be added? Any opinion matters. I fixed this bug in my branch. Please pull.

I have added debugging code to view the temporary directory, which is deleted at the end of the process. Pull the updates and run with the additional parameter DEBUG_TMP= true You will see a message and when you are done browsing, delete this temporary folder manually.

Unfortunately, the build mechanism assumes that you already have a working debian directory for your project. If you need a debugging environment, then this is something else. Can I look at your project? Unfortunately, the build mechanism assumes that you already have a working debian directory for your project. If you need a debugging environment, then this is something else. Can I look at your project? If not, then show the debian/rules file and write what debugging information you want to see. I'll try to add functionality.

Without a doubt, this is the best option. If I understand correctly, your package is going as pkg-name.deb? but is there something missing inside? The output/debug/pkg-name.log file is exist? What does it contain?

1) The BUILD_CHROOT global variable contains a list of packages that the chroot_build_packages function takes as arguments. https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L172 2) Next, the find utility searches for the full path for the configuration file of the corresponding name. https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L251 - Then, in the for loop, the configuration file is read and becomes part of the script for the period of one cycle. https://github.com/The-going/armbian-build/blob/a99d4c51ff5592995ffe3098220a56b737d93ec6/lib/chroot-buildpackages.sh#L260 It contains local variables and functions necessary for operation. Example: leo@vm-jammy:~/armbian$ cat packages/extras-buildpkgs/90-hostapd-realtek.conf # hostapd-realtek local package_name="hostapd-realtek" local package_repo="http://w1.fi/hostap.git" local package_ref="tag:hostap_2_5" local package_upstream_version="3:2.5-4" local package_install_target="hostapd-realtek" local package_component="${release}-utils" package_checkbuild() { true } package_checkinstall() { false } package_repo - the repository will be cloned from the address package_ref - the corresponding tag will be extracted to the working directory. You can specify a branch:master. package_upstream_version - If it exists, then during the build process, the package version will be installed larger than this one. In order for your assembled package to be newer than the one that exists in the system. package_checkbuild() - a function that checks various conditions and returns true or false. If false, the package will be skipped and will not be built. package_install_target - A strange entity. Must contain a name. By which the existence of the collected package is checked. If it exists then the build is skipped. To rebuild a package, you must first delete it. package_component - the template is part of the path where the built package will be moved package_checkinstall - If true, then the newly built package will be installed before the next package is built. 3) NCPU_CHROOT - A global variable that contains the number of dedicated processors for building a package in a chroot environment. Can be defined at the very beginning. If not defined then it will be equal to 2

While I'm fixing the found parts of poorly connected logic, you can use my branch: https://github.com/The-going/armbian-build/tree/chroot_build_pkg I use it to work on one package in a chroot environment. It will always be rebased relative to the master armbian branch. You can immediately start creating packages and see something similar: leo@vm-jammy:~/armbian$ ./compile.sh test BUILD_CHROOT='htop sunxi-tools' [ warn ] This script requires root privileges, trying to use sudo [sudo] password for leo: [ o.k. ] Using config file [ /home/leo/armbian/userpatches/config-test.conf ] [ o.k. ] Command line: setting BUILD_CHROOT to [ htop ] [ .... ] Extension being added [ sunxi-tools :: added by main.sh:381 -> configuration.sh:173 -> config/sources/families/sun50iw1.conf:2 -> config/sources/families/include/sunxi64_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. ] Creating build chroot [ jammy/arm64 ] I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C) I: Retrieving Packages I: Validating Packages I: Retrieving Packages I: Validating Packages I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://localhost:3142/ports.ubuntu.com... I: Checking component universe on http://localhost:3142/ports.ubuntu.com... I: Retrieving adduser 3.118ubuntu5 I: Validating adduser 3.118ubuntu5 ...... ...... [ o.k. ] Debootstrap complete [ jammy/arm64 ] [ o.k. ] Create a clean Environment archive [ jammy-arm64-v7.tar.xz ] 758MiB [14.1MiB/s] [============================================================================================================>] 100% [ o.k. ] Unpack the clean environment [ jammy-arm64-v7.tar.xz ] [ o.k. ] selected_packages= [ htop sunxi-tools ] [ o.k. ] Building packages [ htop jammy/arm64 ] [ o.k. ] Checking git sources [ extra/htop 2.2.0 ] A clean build environment will be created. It will be packed and will be unpacked each time for the next package. You will need to register the build dependencies in the debian/control file. They will be installed automatically.

I'm not familiar with this. But it seems that the build system does not understand this and does not set some variables correctly. E: Couldn't download http://localhost:3142/ports.ubuntu.com/dists/focal/main/binary-amd64/Packages Please check for your VM: Restart VM. Add to cmdline: NO_APT_CACHER=yes And look carefully at `output/debug/*'. I am using a Qemu/KVM VM based on libvirt.

Is this environment running in some kind of virtual machine? Is the package installed? distcc --version I found another problem. And this is due to some recent fixations. The error is implicit. I apologize. I'll have to wait until I find it and fix it.

Most likely, some packages are not installed. To catch this bug, I install a clean environment and try to run it.

What environment are you running in now? If you running in focal then Try to fix it RELEASE=focal

It tries for amd64 but should for arm64

I'll check it out now. What environment are you running in now?

The right way is to build a debian package for your application. Then, at the stage of creating the image, install it. To create additional packages in armbian, there is a chroot environment mechanism that will assemble the package in the native environment with all the necessary dependencies. If this is your personal project, you need to create a debian folder in the root of the project and fill it with the necessary files. How to do this correctly is described in great detail in the documentation: debmake-doc, maint-guide Next, you simply add the necessary "in the image and likeness" to the "armbian-build/packages/extras-buildpkgs/" folder necessary for the build. And run the build system with the EXTERNAL_NEW=compile parameter. There is really not enough documentation on this part, but I hope that it will appear as a result of our conversation. Ask anything you want. I will guide you along this path.

30 GB is not enough for a virtual machine. You may run out of free space at the very end of the process. https://github.com/armbian/build/blob/d57777caade0e3751d759b75239c5a66c3b28728/lib/debootstrap.sh#L78-L80 # stage: user customization script # NOTE: installing too many packages may fill tmpfs mount customize_image That's the first thing that came to mind. I have a 45 GB virtual machine image. This script is a template for the user and is copied to the userpatches folder. After that, in this folder, you can change it at your discretion. It is only your property and you can write whatever you want there. Add debugging code there something like this: apt-get install -y build-essential cmake gfortran |& tee -a $DEST/${LOG_SUBPATH}/custom.log pip3 install dlib |& tee -a $DEST/${LOG_SUBPATH}/custom.log See output/debug/custom.log

No! These are some popular services in Russia that are blocked in some other countries for users who try to reach them. Conversely, I have no problems getting through to anywhere in the world.

No! The problem is on the side of the provider of another country! And it should be solved in a different way. There are no problems with the Yandex service.

@TheDude The question remains relevant? Or have you already figured out how to do it correctly?

You can manually edit the source list file and specify there the mirror closest to your location or the best in speed. In this case, apt will pull updates only from this mirror. The list of mirrors for Debian and Ubuntu is published.

If I understand correctly, everything is fine and nothing else is required?

You have all the tools. Start Banana PiM 3 with a 16GB card. Insert a 250GB card via a usb adapter into the BananaPi M3. The card should be defined as /dev/sda. sudo fsck /dev/sda help: man fsck

Most likely, your sd card has finished its life cycle. You can check this using the utility fsck

I have looked carefully at the build scripts of the original ubuntu kernel package. The scripts are configured for both cross compilation and native assembly. If there is a very big desire, then it will be possible to implement this for the armbian build system. It is assumed that this will be a significantly reduced version.

In a sense, it is a build server for the target architecture in the target operating system environment. I have not come up with a simpler and more correct way at the moment. I am building a library and an application using kernel sources in a chroot environment by mounting them in the following way. From 29990c7edb920a7c5be3b898716f48d8bbc29dec Mon Sep 17 00:00:00 2001 From: The-going <48602507+The-going@users.noreply.github.com> Date: Fri, 13 May 2022 21:31:51 +0300 Subject: [PATCH] Mount bind linux source if necessary --- lib/chroot-buildpackages.sh | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/lib/chroot-buildpackages.sh b/lib/chroot-buildpackages.sh index 9471ee3a3..b4b52fc18 100644 --- a/lib/chroot-buildpackages.sh +++ b/lib/chroot-buildpackages.sh @@ -258,7 +258,7 @@ chroot_build_packages() for plugin in $config_for_packages; do unset package_name package_repo package_ref package_builddeps package_install_chroot package_install_target \ - package_upstream_version needs_building plugin_target_dir package_component "package_builddeps_${release}" + package_upstream_version needs_building plugin_target_dir package_component "package_builddeps_${release}" mount_linux_src source "${plugin}" # check build condition @@ -312,11 +312,19 @@ chroot_build_packages() fetch_from_repo "$package_repo" "extra/$package_name" "$package_ref" + if [ "$mount_linux_src" == "yes" ];then + mkdir -p $target_dir/root/linux + linuxsrc=$(realpath "${SRC}"/cache/sources/${LINUXSOURCEDIR}) + # redefine mount_linux_src + mount_linux_src="--bind-ro ${linuxsrc}/:/root/linux" + fi + eval systemd-nspawn -a -q \ --capability=CAP_MKNOD -D "${target_dir}" \ --tmpfs=/root/build \ --tmpfs=/tmp:mode=777 \ --bind-ro "$(dirname $plugin)"/:/root/overlay \ + $mount_linux_src \ --bind-ro "${SRC}"/cache/sources/extra/:/root/sources /bin/bash -c "/root/build.sh" 2>&1 \ ${PROGRESS_LOG_TO_FILE:+' | tee -a $DEST/${LOG_SUBPATH}/buildpkg.log'} -- 2.35.3