Jump to content

going

Members
  • Posts

    806
  • Joined

  • Last visited

Everything posted by going

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. Most likely, some packages are not installed. To catch this bug, I install a clean environment and try to run it.
  10. What environment are you running in now? If you running in focal then Try to fix it RELEASE=focal
  11. I'll check it out now. What environment are you running in now?
  12. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

OSZAR »