going

In the continuation of the conversation: PR #1836

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?

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.

Thank you all. All fixed.

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

Ok. The first one is ready.

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

Quite well. Try another option.

Oh-Ho-Ho. No one wants to test!

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.

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.

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.

0002-Check-that-to-understand-what-it-is-talking.patch

After many inspections, it is possible to fix this problem. 0001-Fix-incomplete-cleaning-of-the-source-code.patch

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.

" 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.

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.

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

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.

I am somewhere in the Siberian province and use 3G modem.

large overhead when downloading. git reset --hard HEAD # First, return the modified files. git clean -df # Then delete all new, added files. This code is guaranteed to work correctly. I use it for a month. "Clean slate" before you start the compilation, and no issues with the new patches.

I wish you all good health. Using the "Armbian" build system, I noticed two bad points: 1 - incomplete cleaning of the source code before starting a new compilation, seen when patches add new files to the tree. 2 - Debian kernel source package includes the git directory. 1) All I do I'm fixing the version kernel (KERNELBRANCH="tag:v4.14.40") and collect several variants for one Board, changing the patchset for each version, adding or removing some. Before each new compilation I'm doing a test of the purity of the source. clean_repo() { display_alert "clean_repo $PWD" #git status -s git reset --hard HEAD # First, return the modified files. git clean -df # Then delete all new, added files. #git status } compile_kernel() { # A simple check ensures that we start with a clean slate. cd $SRC/cache/sources/$LINUXSOURCEDIR if [ "X$(git status -s)" != "X" ]; then clean_repo fi # ... ... } 2) Manufacturer's code Debian package: (--exclude='./.git/') if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude='./.git/' --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude=='./.git/' | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi can be changed to view: (--exclude="[.]git") if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi