Jump to content

creating packages in the armbian build system


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

10 hours ago, Igor said:

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines