going

  • Content Count

    36
  • Joined

  • Last visited

About going

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well. I will think in this direction. My fresh thoughts will be in this branch: wip/packaging
  2. Yes, I did not write very clearly. To build packages in the chroot environment there are patches for example for htop: packages/extras-buildpkgs/htop/debian/patches But in the build script: chroot_build_packages() there is no mechanism for applying patches. Could this mean that this is part of the future work plan and needs to be added.
  3. I have given these two files 'packages/armbian/builddeb, packages/armbian/mkdebian' to the current view for today. After I finally check the functionality, I will commit the 'packaging' branch for a while. To build packages in a chroot environment, there are patches, but I don't see a mechanism for applying them. @Igor you can share the development plan for this script.
  4. I don't understand what you mean by that? Can you elaborate better? Name pkg: linux-image-current-sunxi64_21.02.0-trunk_arm64.deb What kernel version does this package contain? Name img: Armbian_21.02.0-trunk_Orangepipc2_focal_current_5.9.14_minimal.img In this title you can see everything. I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name. These package names have been around for quite some time. @5kft I assume this is due to reinstalling the package to a new one.
  5. This topic is not a special case with WIFI drivers. There can be no simple solution. The decision depends on the goal we set for ourselves. A look at the root of the situation
  6. While I am working on version 5.9. y, there was an upward movement of 5.9.7 - 5.9.14. How to quickly understand which version is in the package, if the name is the same. I wonder why the package name style was chosen without specifying the trunk version. I keep track of patches for building the kernel (general-packaging -*. patch). Once I tried to fix the installation or removal of a package in a patch. To do this, I had to take the following steps: 1 Assemble the core. - it is necessary that patches are applied. 2 Make changes to the code 3 make the appropriate patch 4 mak
  7. Today is December 15, 2020 I brought the code to the top of armbian master. Built for different kernel versions (5.4 5.9 5.10). debs> ls -gGhR .: итого 807M -rw-r--r-- 1 43K дек 15 22:05 armbian-config_21.02.0-trunk_all.deb -rw-r--r-- 1 6,6M дек 15 22:05 armbian-firmware_21.02.0-trunk_all.deb -rw-r--r-- 1 142M дек 15 22:05 armbian-firmware-full_21.02.0-trunk_all.deb drwxrwxr-x 1 0 дек 15 22:05 extra drwxrwxr-x 1 436 дек 15 22:05 focal -rw-r--r-- 1 77K дек 15 22:05 linux-dtb-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 80K дек 15 22:05 linux-dtb-dev-sunxi64_2
  8. Redesigned the branch packaging. 'NEWPKG', 'FORCE_CHECKOUT' and 'IGNORE_UPDATES' variables is no longer used. Added a new ability to work offline. ./compile.sh OFFLINE_WORK=yes and sources will simply return to their original state without checking on the Internet.
  9. As of today, may 11, the following packages are being built, installed, and uninstalled without errors: 43K - armbian-config_20.05.0-trunk_all.deb 6,2M - armbian-firmware_20.05.0-trunk_all.deb 101M - armbian-firmware-full_20.05.0-trunk_all.deb 56K - linux-dtb-current-sunxi64_20.05.0-trunk_arm64.deb 11M - linux-headers-current-sunxi64_20.05.0-trunk_arm64.deb 29M - linux-image-current-sunxi64_20.05.0-trunk_arm64.deb 1,1M - linux-libc-dev-current-sunxi64_20.05.0-trunk_arm64.deb 123M - linux-source-current-sunxi64_20.05.0-trunk_all.deb 269K -
  10. For the past 10 years, I have been moving evenly and rectilinearly in an inertial frame of reference called OpenSUSE. I had to first read about creating Debian packages and look here: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/ Both Ubuntu and OpenSUSE distributions start with the kernel source package, which contains a set of scripts and rules for further build. This has a sacred meaning. To get started, I took two scripts from the v5.7-rcX core as a basis and put them in packages/armbian/builddeb packages/armbian/mkdebian check
  11. Sorry, colleagues. Work in progress. I have a number of problems and can't allocate enough time to finish.
  12. An option that works but needs to be tested: https://github.com/The-going/armbian-build/tree/packaging I didn't do PR, I want You to look at it.
  13. In the continuation of the conversation: PR #1836
  14. I have a great desire to get this package starting from version 5.4. and so on. I can make corrections for this if YOU give the green light. Most probably ... What are the artefacts left ? symbolic link ? It doesn 't really matter what changes occurred in the target directory after the package was installed. A simple prerm script that simply clears the target directory will solve the problem . To make corrections?