going Posted February 10, 2021 Author Posted February 10, 2021 1 hour ago, Igor said: What you mean by that? You mean if we want to pack commit history and all that stuff? Today, the source kernel package includes the '.git' folder. "Is this a simple build error or is someone using this? This is most likely a syntax error
Igor Posted February 10, 2021 Posted February 10, 2021 54 minutes ago, going said: Today, the source kernel package includes the '.git' folder. "Is this a simple build error or is someone using this? IMO we don't need to pack .git.
going Posted February 10, 2021 Author Posted February 10, 2021 13 minutes ago, Igor said: IMO we don't need to pack .git. Yes, we need a normal source package, which is installed and removed as standard by the package manager. For the 'linux-source, linux-headers' packages, there is one caveat. They make symbolic links to their installation directory in the modules folder of the corresponding kernel. And when removing this kernel, these packages should be considered obsolete (unused) and removed with the «sudo apt autoremove» command. Where is this mechanism registered? I haven't found it yet.
Igor Posted February 10, 2021 Posted February 10, 2021 9 minutes ago, going said: Where is this mechanism registered? I haven't found it yet. Don't know. If not a part of the postinst script check /etc/kernel ?
going Posted February 10, 2021 Author Posted February 10, 2021 56 minutes ago, Igor said: Don't know. If not a part of the postinst script check /etc/kernel ? Yes. In VM: ~$ ls -R /etc/kernel /etc/kernel: install.d postinst.d postrm.d preinst.d /etc/kernel/install.d: /etc/kernel/postinst.d: apt-auto-removal initramfs-tools unattended-upgrades update-notifier zz-update-grub /etc/kernel/postrm.d: initramfs-tools zz-update-grub /etc/kernel/preinst.d: intel-microcode ~$ cat /etc/kernel/postinst.d/apt-auto-removal #!/bin/sh set -e # Mark as not-for-autoremoval those kernel packages that are: # - the currently booted version # - the kernel version we've been called for # - the latest kernel version (as determined by debian version number) # - the second-latest kernel version # # In the common case this results in two kernels saved (booted into the # second-latest kernel, we install the latest kernel in an upgrade), but # can save up to four. Kernel refers here to a distinct release, which can # potentially be installed in multiple flavours counting as one kernel. eval $(apt-config shell APT_CONF_D Dir::Etc::parts/d) test -n "${APT_CONF_D}" || APT_CONF_D="/etc/apt/apt.conf.d" config_file="${APT_CONF_D}/01autoremove-kernels" eval $(apt-config shell DPKG Dir::bin::dpkg/f) test -n "$DPKG" || DPKG="/usr/bin/dpkg" list="$("${DPKG}" -l | awk '/^[ih][^nc][ ]+(linux|kfreebsd|gnumach)-image-[0-9]+\./ && $2 !~ /-dbg(:.*)?$/ && $2 !~ /-dbgsym(:.*)?$/ { print $2,$3; }' \ | sed -e 's#^\(linux\|kfreebsd\|gnumach\)-image-##' -e 's#:[^:]\+ # #')" debverlist="$(echo "$list" | cut -d' ' -f 2 | sort --unique --reverse --version-sort)" if [ -n "$1" ]; then installed_version="$(echo "$list" | awk "\$1 == \"$1\" { print \$2;exit; }")" fi unamer="$(uname -r | tr '[A-Z]' '[a-z]')" if [ -n "$unamer" ]; then running_version="$(echo "$list" | awk "\$1 == \"$unamer\" { print \$2;exit; }")" fi # ignore the currently running version if attempting a reproducible build if [ -n "${SOURCE_DATE_EPOCH}" ]; then unamer="" running_version="" fi latest_version="$(echo "$debverlist" | sed -n 1p)" previous_version="$(echo "$debverlist" | sed -n 2p)" debkernels="$(echo "$latest_version $installed_version $running_version $previous_version" | sort -u | sed -e '/^$/ d')" kernels="$( (echo "$1 $unamer"; for deb in $debkernels; do echo "$list" | awk "\$2 == \"$deb\" { print \$1; }"; done; ) \ | sed -e 's#\([\.\+]\)#\\\1#g' -e '/^$/ d' | sort -u)" generateconfig() { cat <<EOF // DO NOT EDIT! File autogenerated by $0 APT::NeverAutoRemove { EOF for package in $(apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages'); do for kernel in $kernels; do echo " \"^${package}-${kernel}$\";" done done echo '};' if [ "${APT_AUTO_REMOVAL_KERNELS_DEBUG:-true}" = 'true' ]; then cat <<EOF /* Debug information: # dpkg list: $(dpkg -l | grep '\(linux\|kfreebsd\|gnumach\)-image-') # list of installed kernel packages: $list # list of different kernel versions: $debverlist # Installing kernel: $installed_version ($1) # Running kernel: ${running_version:-ignored} (${unamer:-ignored}) # Last kernel: $latest_version # Previous kernel: $previous_version # Kernel versions list to keep: $debkernels # Kernel packages (version part) to protect: $kernels */ EOF fi } generateconfig "$@" > "${config_file}.dpkg-new" mv -f "${config_file}.dpkg-new" "$config_file" chmod 444 "$config_file" I want to deal with this. But maybe someone knows this mechanism well and will be able to do it faster.
lanefu Posted February 11, 2021 Posted February 11, 2021 On 2/9/2021 at 6:20 PM, Igor said: @martinayotte @TonyMac32@piter75 @gprovost @5kft @jock@SteeMan@lanefu If we agree, before or after big desktop merge. still trying to understand the proposal
going Posted February 11, 2021 Author Posted February 11, 2021 6 hours ago, lanefu said: still trying to understand the proposal A package has a number of attributes: 1) Name of the package file 2) the name of the package 3) Package version 4) Provides (usually short name, old name) The day before yesterday, yesterday, today I built three kernel packages on the current branch. kernel versions respectively: (5.9.8) (5.10.3) (5.10.10). All three packages have the same file name, the same package name, and the same package version. You won't be able to put them in the same folder and then make a local repository out of it. How will the package manager handle this situation if it uses these attributes?
jock Posted February 12, 2021 Posted February 12, 2021 I am a bit confused too, I'm not a package manager master so can't really be of any help here
Igor Posted March 12, 2021 Posted March 12, 2021 tl;dr; Filename: linux-image-current-meson64_21.05.0-trunk_arm64.deb -> linux-image-5.10.19-meson64_21.02.0-trunk-7.0177_armhf.deb Package: linux-image-current-meson64 -> linux-image-5.10.19-meson64 https://github.com/The-going/armbian-build/commits/wip/packaging We are also working on two other changes in this area. @Myy is adding new desktop related package which will contain board specific things: added -> bsp-desktop-$BOARD.deb While doing this, a regular BSP will be changed from linux-${RELEASE}-root-${DEB_BRANCH}${BOARD} -> bsp-cli-$BOARD.deb As a third option, there might be change in branch naming: DEV -> EDGE which is already prepared as a pull request https://github.com/armbian/build/pull/2704 Do we see any potential problems? Upgrade path(s), possible changes to armbian-config has to be inspected.
going Posted March 12, 2021 Author Posted March 12, 2021 I have been studying the documentation for creating debian ubuntu packages for several days now. It turned out to be quite difficult for me to rebuild my brain convolutions from the ideology of the RPM to a different style of creating packages. I haven't dug this deep in Debian in 12 years. My repository is currently in a non-working state. Today I am trying to follow all the canons and recommendations of the official Debian documentation. For the experiment, I chose one library that should be collected in armbian. Work in progress. 7 hours ago, Igor said: As a third option, there might be change in branch naming: DEV -> EDGE Change one letter to another? The essence has not changed. I would prefer another option to do this with symbolic links to folders for example: legacy -> linux-5.4 current -> linux-5.10 dev (edge) - > linux-5. XXL after a year: legacy -> linux-5.10 current -> linux-5.24 dev (edge) - > linux-6.2 long term kernel patch folders are saved in visible space, even if they are no longer supported in armbian. I propose to consider this option.
going Posted March 13, 2021 Author Posted March 13, 2021 10 hours ago, going said: Change one letter to another? The essence has not changed. I would prefer another option to do this with symbolic links to folders for example: legacy -> linux-5.4 current -> linux-5.10 dev (edge) - > linux-5. XXL after a year: legacy -> linux-5.10 current -> linux-5.24 dev (edge) - > linux-6.2 long term kernel patch folders are saved in visible space, even if they are no longer supported in armbian. I propose to consider this option. I was wrong here. In this case, the replacement has a sacred meaning. In addition to this, it would be good to add the following: In dir build/patch/kernel/ drwxrwxr-x sunxi-5.10 drwxrwxr-x sunxi-5.4 lrwxrwxrwx sunxi-current -> build/patch/kernel/sunxi-5.10 lrwxrwxrwx sunxi-legacy -> build/patch/kernel/sunxi-5.4
Igor Posted March 13, 2021 Posted March 13, 2021 13 hours ago, going said: I propose to consider this option. Yes, that's better! I'll rework.
going Posted April 5, 2021 Author Posted April 5, 2021 Continuation of the conversation and implementation of the plan. @Igor, I reworked the 'megause' patches from the orangepi-5.10 branch and implemented their use in my repository. They're here. On the wip/rework_kernel_compile branch, all patches are applied without errors to the v5.10.26 kernel versions. Partially fixed warnings and errors in whitespace characters. Added a new apply_patch_series function that uses the series.conf file. Build Options ./compile.sh BOARD=orangepipc2 BRANCH=current RELEASE=focal BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=yes KERNEL_CONFIGURE=yes lib.config: KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git' KERNELBRANCH=tag:v5.10.26 KERNELPATCHDIR="sunxi-5.10.26" Next steps: - Complete set of patches ready for packaging. - Creating a kernel source code package for sunxi. Then I will build binary kernel packages from this package. This approach ensures that the build results are repeatable.
Igor Posted April 5, 2021 Posted April 5, 2021 37 minutes ago, going said: Added a new apply_patch_series function that uses the series.conf file. OK. It is important that this doesn't break patch creation process with ./compile.sh CREATE_PATCHES="yes" ... that has to be checked. Also full backward compatibility and include patches within same structure under userpatches/kernel/* This https://github.com/The-going/armbian-build/blob/wip/rework_kernel_compile/lib/compilation.sh#L868 is here with a reason. It would be perhaps better to make use of current patching function.
going Posted April 5, 2021 Author Posted April 5, 2021 1 hour ago, Igor said: CREATE_PATCHES="yes" Yes, you're right. This should be checked. I have not used this functionality once. I have my own more complex system of working with numerous patches. 1 hour ago, Igor said: It would be perhaps better to make use of current patching function. This option, which is intended only for debugging, I have shown as desirable in the future. The mechanism using the 'series' file has a number of advantages. By editing a single file, we can change the sequence of applying patches, disable some, and leave comments. This is convenient and it is used when creating packages, both 'deb' and 'rpm'. But this assumes that everything is working flawlessly and a lot of work has been done. Your 'advanced_patch' function works brilliantly. I sincerely admire its functionality. But it is less strict than the one used in debuild or rpmbuild. Maybe try to provide a choice. If the file 'series.conf' exists then the new option, if it doesn't, then the current one?
Igor Posted April 5, 2021 Posted April 5, 2021 1 hour ago, going said: If the file 'series.conf' exists then the new option, if it doesn't, then the current one? If series file exists its used for determining order and patch used, otherwise it just proceed as now. That would probably be fine. But it will complicate the situation - currently we have internally maintained patches and user patches. User only need to add a patch and it become a part of the patches. Naming set its execution order. Simple logic, internal and external = the same ... but clearly a downside is that one needs to deal with naming to get order. For internal patches, series file is cool ... what about user patch logic? series there acts as an override of internal (perhaps best) or merge. If series exists, user patch is applied at the end. When user ads a patch he has to edit series file when send a MR, right?
going Posted April 6, 2021 Author Posted April 6, 2021 Good. You're right. There are two lines of action: 1) Rules and procedures for the maintainer, which have two main goals. - First of all, this is the correct operation of the build system, which makes the right packages. - And only secondarily the functionality of the programs contained in the package. 2) Rules and procedures for the user who decided to add functionality or fix an error. Let's assume that you are the maintainer, and I am the user. I found and fixed the bug, made a patch and return it to you with the name zzz-0001-NAME_BUGFIX. patch. It is clear that the patch is applied last, but I have informed you that this is a fix for a patch that adds functionality and is applied (queued) at number 65. You will probably want to put this patch in the queue with the number 66. And if the build is successful, combine 65 and 66 using the combinediff command. Or ask me to fix another problem related to the file that is being modified. Normal current work. A much worse situation is when there was a big wave of changes in the source repository, the build system tracked it and all our patches are floating in different directions. I accepted all your comments and take off my T-shirt with the inscription "user". I'll put on my maintainer uniform and continue.
going Posted April 11, 2021 Author Posted April 11, 2021 On 4/6/2021 at 12:50 AM, going said: If the file 'series.conf' exists then the new option, if it doesn't, then the current one? On 4/6/2021 at 2:26 AM, Igor said: But it will complicate the situation - currently we have internally maintained patches and user patches. User only need to add a patch and it become a part of the patches. Naming set its execution order. The need to name patches is a big drawback. The user should only apply their patches last, otherwise they will get problems. And this is not the primary problem. Let's look inside the 'debuild' logic of the build process: ..... At some stage, we need to put all the patches in the '${kerneldir}/debian/patches/' folder. ..... How can we do this? Next, part of the formatted patch application log: ??????>>>>>> patch/misc/general-packaging-5.10.y.patch patch/misc/bootsplash-5.8.10-0001-Revert-vgacon-remove-software-scrollback-support.patch patch/misc/bootsplash-5.8.10-0002-Revert-fbcon-remove-now-unusued-softback_lines-curso.patch patch/misc/bootsplash-5.10.y-0003-Revert-fbcon-remove-soft-scrollback-code.patch patch/misc/0001-bootsplash.patch patch/misc/0002-bootsplash.patch patch/misc/0003-bootsplash.patch patch/misc/0004-bootsplash.patch patch/misc/0005-bootsplash.patch patch/misc/0006-bootsplash.patch patch/misc/0007-bootsplash.patch patch/misc/0008-bootsplash.patch patch/misc/0009-bootsplash.patch patch/misc/0010-bootsplash.patch patch/misc/0011-bootsplash.patch patch/misc/0012-bootsplash.patch patch/misc/kali-wifi-injection-1-v5.9-post.patch patch/misc/kali-wifi-injection-2.patch patch/misc/kali-wifi-injection-3.patch cache/sources/aufs5/aufs5.10/aufs5-kbuild.patch cache/sources/aufs5/aufs5.10/aufs5-base.patch cache/sources/aufs5/aufs5.10/aufs5-mmap.patch cache/sources/aufs5/aufs5.10/aufs5-standalone.patch patch/misc/wireless-rtl8811cu.patch patch/misc/wireless-rtl8188eu.patch patch/misc/wireless-rtl8723ds.patch patch/misc/wireless-rtl8723du.patch ??????<<<<<< patch/kernel/sunxi-current/0001-Fix-broken-ethernet-on-Orangepi-2.patch patch/kernel/sunxi-current/0001-Revert-leds-axp20x-Support-charger-LED-on-AXP20x-lik.patch patch/kernel/sunxi-current/0001-arm64-allwinner-a64-enable-Wi-Fi-for-Pine64.patch You can't see adding files from third-party git repositories here. These added files introduce errors in the compilation process and patches that fix problems are located in different places and are applied in an arbitrary order. The only way to solve this problem is to add additional code to the build system, which creates a commit at each iteration of adding files and applying each patch. And then 'git format-patch v5. 10. 28..HEAD -o ${kerneldir}/debian/patches/' Everything is simplified if you have a separate repository for the final set of patches, where there are branches of sunxi-5.10, etc.
Igor Posted April 12, 2021 Posted April 12, 2021 21 hours ago, going said: The need to name patches is a big drawback. True. But it need to have a name Name should have association with where fixing what. But yet again we have to deal with exceptions. 21 hours ago, going said: The user should only apply their patches last That is expected, yes. 21 hours ago, going said: You can't see adding files from third-party git repositories here. As they are added manually. https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L159-L163 I would say those exceptions should rather stay as is. We can't cover everything with the same logic. Or we can? 21 hours ago, going said: are located in different places AUFS for example has it own logic. We set apply from this and that kernel version. 21 hours ago, going said: Everything is simplified if you have a separate repository for the final set of patches, where there are branches of sunxi-5.10, etc. This part I don't quite understand. How to deal with AUFS as an example. It has some "complicated" logic https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L135-L142
going Posted April 12, 2021 Author Posted April 12, 2021 1 hour ago, Igor said: 23 hours ago, going said: The need to name patches is a big drawback. True. But it need to have a name Sorry. I meant that the need to name patches to put in the right place in the queue.... 2 hours ago, Igor said: We can't cover everything with the same logic. Or we can? We can do anything. The main thing is to adhere to the logic of building packages by the debuild build system itself. First we need to build the source package as it requires debuild. Why is this necessary? So that users do not ask questions - "How do we build this directly on the board?". Download the source package as described in the instructions and follow the steps.... After that, the armbian build system will only need to build binary packages for the architecture and board according to the standard procedure. It is assumed that we have compiled the correct debian source package. On 4/11/2021 at 10:21 PM, going said: At some stage, we need to put all the patches in the '${kerneldir}/debian/patches/' folder. I believe that we simply take the original archive from the site kernel.org one way or another, but patches (patches and not files), we will first have to decompose them into thematic folders (group). Next to each folder, we will create a small thematic file of the series. For example: patches.orangepi-5.10/ series.orangepi-5.10.conf patches.armbian/ series.armbian.conf patches.drivers.extrawifi/ series.extrawifi.conf We put the patch that fixes wifi in the theme folder, and not somewhere at the end of the list at the time when it came. And added a line in the series file. Patches should be applied without errors by the 'git am' command. In order for the armbian build system to be able to make a git source repository.
Igor Posted April 12, 2021 Posted April 12, 2021 2 hours ago, going said: The main thing is to adhere to the logic of building packages by the debuild build system itself. First we need to build the source package as it requires debuild. Why is this necessary? You mean a debian src package? https://en.wikipedia.org/wiki/Debian_build_toolchain#Source_packages 2 hours ago, going said: So that users do not ask questions - "How do we build this directly on the board?". Well, this already works ... but not standard way. And users will always ask - even when works by the book 2 hours ago, going said: Next to each folder, we will create a small thematic file of the series. For example: patches.orangepi-5.10/ series.orangepi-5.10.conf patches.armbian/ series.armbian.conf patches.drivers.extrawifi/ series.extrawifi.conf We put the patch that fixes wifi in the theme folder, and not somewhere at the end of the list at the time when it came. And added a line in the series file. This logic has to be brainstormed. I would go slow into any direction. @martinayotte @tparys @5kft 2 hours ago, going said: Patches should be applied without errors by the 'git am' command. Don't understand what you mean by that? Patches - if not broken - do apply without errors. Why do we need git am here? Do we need to create a git patch history?
going Posted April 13, 2021 Author Posted April 13, 2021 10 hours ago, Igor said: You mean a debian src package? https://en.wikipedia.org/wiki/Debian_build_toolchain#Source_packages Yes! I read the documentation here: https://www.debian.org/doc/devel-manuals#policy https://www.debian.org/doc/manuals/debmake-doc/#what-debmake https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#what-debuild 10 hours ago, Igor said: Don't understand what you mean by that? Patches - if not broken - do apply without errors. Why do we need git am here? Do we need to create a git patch history? The "git am" command is more strict than the built-in "debuild", which means that patches will be guaranteed to be applied. I will write more details later. This requires neatness. And working with patches should not be part of the build system itself, but only a nice addition in the form of separate scripts that are typical for armbian for manual work, for example, in a separate tools folder.
Igor Posted April 13, 2021 Posted April 13, 2021 12 hours ago, going said: The "git am" command is more strict than the built-in "debuild", which means that patches will be guaranteed to be applied. I will write more details later. Aha - I know what you mean ... one time job / script to make them cleaner. And request only supply patches this way? 12 hours ago, going said: This requires neatness. Also represent stress which we have to minimise if possible - stretch over longer period. I propose to throw out warnings about patch quality if not met, but apply anyway the classical way? One can easily lost a lot of time not seeing warnings that patch hasn't been applied. 12 hours ago, going said: And working with patches should not be part of the build system itself, but only a nice addition in the form of separate scripts that are typical for armbian for manual work, for example, in a separate tools folder. Patches, user patches and patch creating are important part of the Armbian. So we should not kill any functionality or make it more complicated from any point of view.
going Posted April 14, 2021 Author Posted April 14, 2021 11 hours ago, Igor said: Aha - I know what you mean ... one time job / script to make them cleaner. And request only supply patches this way? Yes, that's the way it is. And it already exists in armbian. userpatch_create() { # create commit to start from clean source git add . git -c user.name='Armbian User' -c user.email='user@example.org' commit -q -m "Cleaning working copy" ..... git commit -s -m "$COMMIT_MESSAGE" git format-patch -1 HEAD --stdout --signature="Created with Armbian build tools https://github.com/armbian/build" > "${patch}" PATCHFILE=$(git format-patch -1 HEAD) ..... My work today on patch processing uses this git tool. Step by step, I check how each patch is applied. apply_patches () { local t_dir="${1}" local series="${2}" local bzdir="$(dirname $series)" list=$( gawk '{ if($1 ~ /s/) print $2 if($0 !~ /^#.*|^-.*|^s.*/) print $0 }' "${series}" ) skiplist=$(gawk '$0 ~ /^-.*/' "${series}") stop=$(gawk '$1 ~ /s/{print $2}' "${series}") # TODO cd "${t_dir}" || exit 1 for p in $list; do echo "I try to apply $p" patch --dry-run -N -p1 -i $bzdir/"$p" flag_p=$? if [ "$flag_p" == "0" ]; then echo "I apply it $p" git am $bzdir/"$p" flag_a=$? if test "$flag_a" == "0"; then git_obj=$(git -C ${t_dir} log --format="%H" -1) fi echo "" if [ "$flag_a" != "0" ]; then echo "Error flag [$flag_a] $p" echo "I apply it..." patch --no-backup-if-mismatch -p1 -N -i $bzdir/"$p" echo -e "\n\t Edit it" kwrite $bzdir/"$p" & wait At the end, a simple command "git format-patch <revision range> -o <dir>" And we have a good series of patches. This situation is not considered an error: patching file fs/proc/task_mmu.c Hunk #2 succeeded at 1866 (offset 8 lines). But in this case: Hunk #1 succeeded at 2184 with fuzz 1. the git am command considers it an error Yesterday, I had one hunk applied with fuzz 3 And this generated an error in the source code. If we regularly skip the entire set of patches in a circle (patch --dry-run, git am, git format-patch), we will make our life much easier. P.S. I wrote it in detail to avoid ambiguous machine translation.
going Posted April 15, 2021 Author Posted April 15, 2021 Based on the results of yesterday's work: In some patches that fix the '*.dts *. dtsi ' files, individual chunks are applied with fuzz 2 and introduce bugs. Two lines of code are placed in another function. And this situation requires special attention. These patch files have no context.
going Posted April 18, 2021 Author Posted April 18, 2021 This line " lsdiff -s --strip=1 "${patch}" | grep '^+' | awk '{print $2}' | xargs -I % sh -c 'rm -f %' " On 4/5/2021 at 9:11 PM, Igor said: is here with a reason. In this revision, if any file already exists and the patch creates this file, the file will be deleted before the patch is applied. Keyword any file. This is not correct.
Igor Posted April 18, 2021 Posted April 18, 2021 1 hour ago, going said: In this revision, if any file already exists and the patch creates this file, the file will be deleted before the patch is applied. Keyword any file. This is not correct. Why not? Don't see any reason.
going Posted April 19, 2021 Author Posted April 19, 2021 19 hours ago, Igor said: Why not? Don't see any reason. This file was created by you at a time when it did not exist in the kernel. But in the current version 5.10.31 it exists. They differ. Obviously, we need to combine the functionality of both files and make a patch. Then check the performance on the board. I don't have this board and if I do the necessary things I still won't be able to verify the correctness. Today, the file "arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts" is being replaced. And the patch piece creates an extra line in the Makefile. Which is a gross mistake. This is just one example. I have to read the final file corrected by the patch very carefully. And I changed this line: # detect and remove files which patch will create lsdiff -s --strip=1 "${patch}" | grep '^+' | awk '{print $2}' | xargs -I % sh -c 'rm -f %' to this: # Detect and remove files as '*.patch' which patch will create. # So we need to delete the file before applying the patch if it exists. lsdiff -s --strip=1 "$bzdir/$p" | \ awk '$0 ~ /^+.*patch$/{print $2}' | \ xargs -I % sh -c 'rm -f %' Now only the patch files created by other patches are deleted. In itself, the fact that there are patches that create other patches is very controversial. This is definitely not necessary for creating kernel packages. They are needed for use in the build system itself.
Igor Posted April 19, 2021 Posted April 19, 2021 On 1/28/2021 at 7:12 PM, going said: Filenames obtained from the packaging branch: linux-dtb-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-headers-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-image-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-libc-dev-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb The number 19 indicates the number of times I built this core The packaging branch currently collects only packages and does not collect the entire image. Only for the test . BRANCH information on the board is needed at least for showing warnings that user is on "EDGE" kernel ... New BSP packages will be one for all, so it can't hold this information. Is it possible to add to postinst to create some file containing that info? We have to store branch information to those packages
Igor Posted April 19, 2021 Posted April 19, 2021 5 hours ago, going said: This file was created by you at a time when it did not exist in the kernel. But in the current version 5.10.31 it exists. They differ. Aha. Here we need to be warned since some manual procedure is needed and its usually not urgent.
Recommended Posts