going

Members
  • Content Count

    28
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by going

  1. 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.
  2. 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 - linux-u-boot-current-orangepipc2_20.05.0-trunk_arm64.deb The disk image has been assembled, and the locale with native languages is working. 1000M - Armbian_20.05.0-trunk_Orangepipc2_bionic_current_5.4.38_minimal.img Started checking the health of packages on the Board - linux-source, linux-libc-dev, linux-headers
  3. 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 checked the build process for bionic current core v5.4.y This initial state can serve as a starting point. How it works? In armbian/build git remote add armbian-build https://github.com/The-going/armbian-build.git git fetch armbian-build packaging git checkout -b packaging armbian-build/packaging ./compile.sh NEWPKG="true" NEWPKG="true" - no longer used This repository branch changes its commit history by following the flight of thought and eliminating garbage. Update it with the -f, --force key git pull -f armbian-build packaging Please test and write your wishes and thoughts here. At this stage, we can opt out of general-packaging-5.X.X.patch
  4. Sorry, colleagues. Work in progress. I have a number of problems and can't allocate enough time to finish.
  5. 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.
  6. In the continuation of the conversation: PR #1836
  7. 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?
  8. Two questions about this patch. 1 - we add a line to the scripts/package/builddeb file +libc_headers_packagename=linux-libc-dev-"$BRANCH$LOCALVERSION", but we don't actually build this package. That's how it should be, or it's just not finished. 2 - the postinstall script in the linux-headers package performs actions in the installation directory. Therefore, the package cannot be deleted cleanly using the standard 'dpkg -r' method. Perhaps the work is not finished here either. If you need to modify it, I can offer my own version.
  9. I apologize if I seem rude. I use automatic translation. Sometimes the meaning can turn over. And thank you. I started working with github. Now I understand why you don't accept the patches as a patch file
  10. Igor, let's try to open the eyes of users. Please apply these two patches. 0001-Correction-stderror-to-file.patch 0002-Install-to-see-the-status.patch
  11. Thanks. I saw the applied patches for testing. I read your links and realized that it is customary to make changes in a separate branch and then pull request. Of course, first we need to discuss with the community the need to develop new functionality. I will do so in the future. I'm currently laying out a number of patches that I think are the most important. Although it is not a tradition. You can apply them on your own behalf, after testing, if you see them reasonable. I don't claim authorship. Thank you for your understanding.
  12. In fact, I'm good with the Internet and all the necessary repositories are on a nearby SSD. There can be several reasons: - Slow Internet and unwillingness to clean sources every time. - Inattention, forgetfulness, typo. - Ignorance of documentation. In any negative scenario, the source directories must be clean before compiling.
  13. Igor, sorry but the automatic translation does not allow me to understand, you must also send the patches somewhere else? Or is it just enough to put them here? I did not find a description of the patch acceptance procedure in the documentation. I have a lot of fixes. Well tested I want to send for consideration to acceptance.
  14. 0002-Check-that-to-understand-what-it-is-talking.patch
  15. After many inspections, it is possible to fix this problem. 0001-Fix-incomplete-cleaning-of-the-source-code.patch
  16. Thanks. It turned out two topics on one big question: How to do better? I will prepare an explanatory note and patch, or as you said: I think then the two topics can be combined.
  17. " Cleaning methods and options: CLEAN_LEVEL (comma-separated list): defines what should be cleaned. Default value is "make,debs" - clean sources and remove all packages. Changing this option can be useful when rebuilding images or building more than one image “make” = execute make clean for selected kernel and u-boot sources, “images” = delete output/images (complete OS images), “debs” = delete packages in output/debs for current branch and device family, “alldebs” = delete all packages in output/debs, “cache” = delete cache/rootfs (rootfs cache), “sources” = delete cache/sources (all downloaded sources), “extras” = delete additional packages for current release in output/debs/extra " Options for wrong actions: Forgot, inattentive, syntax error. There is no desire to pull all sources when the goal is to add or remove support for a single kernel driver or module. But, in any case, the Assembly script works, we must ensure the purity of the source that every time you start with a clean slate. This is a very important point. I am trying to handle possible user errors and negative work options. I have studied this document well: https://docs.armbian.com/Process_Contribute/ And translated it into his native language. P.S. Build system armbian works very well. I want it to be the perfect tool.
  18. For me, these three points are a big problem. If the founding fathers and users feel similar, I can provide a patch that fixes these issues.
  19. 1. What is the purpose when compilation errors are sent to a common output and then branched to a file? It turns out a million lines. It is reasonable to have only compiler error messages. 2. What is the purpose when the kernel-source package is built with include the folder /.git/? It is not traditional 3. Why folder with sources not cleared fully before compilation? git commands: git reset --hard HEAD; git clean -df guarantee a clean sheet before starting work
  20. I noticed this problem after I stopped the kernel version from moving up on a particular tag and started to change patches to remove errors. Turned off a few patches to clear the field for observation. And saw that the big aufs patch (it adds a lot of new files) partially applied, causing even more errors, but my fixes have no effect.
  21. I am somewhere in the Siberian province and use 3G modem.