BugLink: https://bugs.launchpad.net/bugs/2089411
This currently doesn't work for derivatives because there's a level
of indirection missing and the top-level wrapper is looking in the
wrong place for the .so library.
It should be like this:
foo -> linux-tools/<abi>-<flavor>/foo -> <source>-tools-<abi>/foo
The previous commit took care of the missing indirection. This commit
fixes the wrapper to look in the correct directory for the library.
While at it, run it through black and make the wrapper and the .so
library non-executable.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(backported from commit e3092e36b13ccf423258b2232cff0c4d5841d426 plucky:linux)
[juergh: Changed $(DEB_SOURCE) -> $(src_pkg_name)]
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Kevin Becker <kevin.becker@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2089411
The python perf library needs a symlink from the unflavored to the
flavored package directory, just like any of the other tools binaries.
However, it's somewhat special in that the link target name cannot be
determined easily and reliably (python-version- and host-architecture-
specific). To work around that, link the subdirectory that contains it.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Kevin Becker <kevin.becker@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2050083
armhf does not have working BTF for now, so create an empty header file
like Debian does for now, to be dropped once that issue is fixed.
Follow-up for aefbe1e1a9a1d3ed84bceac7e9739a92e1345f58
Signed-off-by: Luca Boccassi <bluca@debian.org>
[ add do_tools_bpftool_stub to avoid hardcoding the arch in rules ]
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry-picked from commit 0c32444afa9bd036e66cbc8c05dbd8df8388bc6f oracular:linux)
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2050083
Add a new binary linux-bpf-dev package that ships a generated vmlinux.h
header. This can be used by packages building CO-RE BPF programs instead
of generating it at build time based on the kernel running on the package
build system, which might or might not match the kernel that is actually
shipped. It ensures that a matching header can always be used.
Matches changes in Debian, including the package name and header installation
location, so that we do not have to ifdef:
https://salsa.debian.org/kernel-team/linux/-/commit/f52d006f3915ac4358dc8c98aa417477ebee026e
This is already used by systemd to build various CO-RE programs, and
right now on Ubuntu due to the lack of this package the header is
generated from sysfs in the build system where the systemd packages are
built.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
(cherry-picked from commit 6032cf45d201ec539a8efa493989366bde75fd96 oracular:linux)
Signed-off-by: Luca Boccassi <bluca@debian.org>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2051560
The perf python module is required by some tools (e.g., tuned) and we
are not currently providing it.
Enable it to be able to support tools that require this module.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
On Ubuntu, /bin/sh is a symlink to /bin/dash by default.
While this is a rare use case, when /bin/sh is a symlink to /bin/bash,
the annotation check fails due to a mismatch of CONFIG_UBUNTU_ODM_DRIVERS.
debian/scripts/misc/arch-has-odm-enabled.sh always fails with bash.
You can see it if you directly execute it.
[with dash]
$ dash debian/scripts/misc/arch-has-odm-enabled.sh amd64
cat: debian/scripts/misc/../../../debian.master/rules.d/hooks.mk: No such file or directory
$ echo $?
0
[with bash]
$ bash debian/scripts/misc/arch-has-odm-enabled.sh amd64
cat: debian/scripts/misc/../../../debian.master/rules.d/hooks.mk: No such file or directory
debian/scripts/misc/arch-has-odm-enabled.sh: line 26: return: can only `return' from a function or sourced script
$ echo $?
2
Bash provides stricter checks, hence the 'return' statement outside
a function leads to an error.
While it is trivial to fix, I wonder if we need this script in the
first place. Its purpose is to make CONFIG_UBUNTU_ODM_DRIVERS a
user-unconfigurable option.
Given debian.*/config/annotations specifying the CONFIG set for each
arch/flavour, why not handle CONFIG_UBUNTU_ODM_DRIVERS just like
other normal CONFIG options? Users are still allow to toggle it from
menuconfig etc., but I do not see a significant issue, as any trouble
comes to users' responsibility when they change CONFIG options by
themselves.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Both Debian kernel and Ubuntu kernel provide a linux-source package,
but a difference is that Debian's one does not include the debian/
directory, while Ubuntu's one includes debian/ and debian.*/ directories.
Including a debian/ directory in a binary package is odd.
If you want to rebuild the kernel in the Ubuntu way, you can get the
source package by 'apt-get source'. It is not what the linux-source
package should offer.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2048183
The following packages may only be built for the main linux source
package. Similar to linux-libc-dev, move the packaging stubs to
debian/control.d and only include them if the source package name is
indeed 'linux':
- linux-tools-common
- linux-cloud-tools-common
- linux-host-tools
Also change the package names in the rules to linux-* to further make
sure that we don't accidentially build linux-<variant>-* packages should
a derivative's control file contain incorrect package stanzas.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Remove the update-dkms-versions script from the tree, it's replaced by
'cranky update-dkms-versions', move the dkms-versions file and fix all
references to the old location.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
This was missed in the below commit, fix it.
Fixes: af3f324f1cb3 ("UBUNTU: [Packaging] Remove do_full_source variable")
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
linux-buildinfo packages are now externally compared by swm, with
results approving or rejecting updates based on the stable
tracker. Those checks also allow hints and overrides to accept
intentional changes.
Also these are done on the correct pair-wise comparisons, especially
when two streams are being cranked.
The above eliminates the need to identify previous build abi,
download, extract it, vendor it in, and assert it at build time.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
We should make a decision about linux-libc-package when constructing
debian/control.
Once debian/control is generated, builders must follow it. In other
words, we should not re-evaluate the do_libc_dev_package variable at
the build time.
Debian kernel commit fdd6dadb4aee ("Use dh_listpackages to determine
which packages to build") [1] introduced the if_package macro.
Import it to consult dh_listpackage to check if linux-libc-package is
listed in debian/control.
[1]: https://salsa.debian.org/kernel-team/linux/-/commit/fdd6dadb4aeea81342effdebd5edbf4bc19ccf4d
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Now 'variants' is no longer used for building packages.
It is true that the 'variants' is used in linux-meta, but there is
no good reason to have it in linux-main.
Only the remaining function is to check the variants from
'debian/rules printenv', but it is not so useful.
Remove it.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
The linux-libc-dev package provides UAPI headers. The Linux kernel
promises backward compatibile API to userspace. That is the reason
why there exists only one linux-lib-dev per series. Its package name
does not contain any ABI number or flavour string since there is no
point in installing multiple instances of linux-lib-dev.
This leads to an obvious conclusion; only the master kernel should
provide linux-libc-dev.
Currently, it is checked at compile-time. If you attempt to build
linux-libc-dev on a non-master kernel, it errors out with
"non-master branch building linux-libc-dev, aborting".
When constructing debian/control, the linux-libc-dev enablement is
determined by do_libc_dev_package, which is set to true if the
'variants' variable contains '--'. This is tricky, and it is difficult
to understand the intention. In fact, do_libc_dev_package is true for
most kernels except linux-unstable. Derivative kernels disable
linux-libc-dev by removing linux-libc-dev.stub.
This commits adopts a simpler logic; enable linux-libc-dev if
debian/debian.env contains DEBIAN=debian.master.
Please note this commit changes the behaviour of linux-unstable.
linux-unstable previously disabled linux-lib-dev because it defined
variants=-wip, but it is enabled now. It should not be a big deal
since we do not publish linux-unstable.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2035971
Currently we ship tools for every kernel flavour and backport, and
each one of them may have new features in cpupower &
libcpupower. Statically link those in, such that there are no
installation conflicts. This resolves all current file conflicts
between multiple kernel flavours in the Ubuntu Archive.
Separately, a public libcpupower1 & libcpupower-dev for non-kernel /
non-linux-tools use cases will be provided separately, under a stable
soname (not flavour or kernel version specific).
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Acked-by: You-Sheng Yang <vicamo.yang@canonical.com>
Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Sometime between bionic and focal, linux-doc build became
broken. Meaning it has stopped producing sphinx html build, and was
only doing compressed installation of the Restructured Text
documentation. But such compressed restructured text is not readable,
navigatable or searchable by any edoc readers.
Separately, our tree doesn't actually contain any Ubuntu-delta
specific documentation, meaning the upstream linux/linux-next docs
that are published at https://kernel.org/doc/html/ are directly
applicable to the Ubuntu kernel. And provide a much nicer experience
in terms of searching, rendering, reading.
If we do have any significant Documentation delta, we are better off
linking to correct upstream documentation, and publishing delta-only
Documentation on our public instance of read-the-docs. Or point users
at our source package and/or git repo to read Documentation/ from
there.
Droping this build doesn't save any significant build-time (as it was
already practically doing nothing). But it does save a lot of
disk-space due to reduced build-dependencies on the full TeX Live
installation. In minimal noble chroot, build dependencies installation
goes down from requiring 1,269 MB to just 542 MB. Thus significantly
reducing the size of all our chroots (locally on developer machines,
during launchpad builds, during outside of launchpad builds).
Manpages (generated using asciidoc & rst2man) are preserved and are
still produced. As those are genuinely useful, and are republished to
manpages.ubuntu.com as well.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Acked-by: Magali Lemes <magali.lemes.do.sacramento@canonical.com>
Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Since commit ("UBUNTU: [Packaging] bpftool: always use vmlinux to
generate headers"), tools/bpf/bpftool/vmlinux must be created before
building the bpftool.
This is not guaranteed because the $(stampdir)/stamp-build-perarch
target does not depend on build-arch.
Running 'debian/rules binary' results in the following build error:
mv [...]/linux/debian/build/tools-perarch/tools/bpf/bpftool/vmlinux [...]/linux/debian/build/tools-perarch/vmlinux
mv: cannot stat '[...]/linux/debian/build/tools-perarch/tools/bpf/bpftool/vmlinux': No such file or directory
This potential issue has been hidden, relying on build drivers such as
dpkg-buildpackage running 'debian/rules build' and 'debian/rules binary'
as separate steps.
Without rootless builds, the (fake) root privilege is required for the
binary target, hence dpkg-buildpackage splits the build process into
three stages:
- fakeroot debian/rules clean
- debian/rules build
- fakeroot debian/rules binary
To support rootless builds, you need to specify all dependencies
correctly without such an assumption.
Once we transition to rootless builds, the 'binary' target will not
require the root privilege any more, so dpkg-buildpackage will merge
'build' and 'binary' into a single step. We need to assume only the
following two will be executed:
- debian/rules clean
- debian/rules binary
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Acked-by: Thibault Ferrante <thibault.ferrante@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Sub-flavors were a concept in Maverick and earlier. In fact, it was
removed later in Maverick but that commit was not carried forward to
Natty so it's still here. Finally get rid of it.
(forwardported from commit db54f0fec701e97b829f0abb2750c30464b38dec maverick/linux)
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
do_full_source was introduced in Lucid but hasn't been used in ages,
so remove it.
This reverts commit 11fe82b00ff2428967c83055ba7ae8102f4140a6
("UBUNTU: add configuration option for a full source build tree -- master")
from lucid/linux.
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2044512
The kernel module compression step is run for every binary package,
not just the modules packages. This results in a build failure when
run in a console for packages that don't contain any .ko files:
\# Compress kernel modules
find debian/linux-unstable-tools-6.6.0-12 -name '*.ko' -print0 | xargs -0 -n1 -P 8 zstd -19 --quiet --rm
stdout is a console, aborting
make: *** [debian/rules.d/2-binary-arch.mk:769: binary-perarch] Error 123
Basically, if find returns nothing, zstd tries to read from stdin:
$ echo | xargs zstd
stdout is a console, aborting
$ echo $?
123
To fix that, tell xargs not to run the command if stdin is empty:
$ echo | xargs -r zstd
$ echo $?
0
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Acked-by: Thibault Ferrante <thibault.ferrante@canonical.com>
Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Kernel 6.5 requires rustc-1.68, but this version is not currently
available in the archive, so disable Rust support for now.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Make sure to use clang/libclang-15 for Rust, since the default
clang/libclang-16 has some build incompatibilities with gcc-13,
triggering the following error:
BINDGEN rust/bindings/bindings_generated.rs
thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident',
+/build/rust-bindgen-0.56-DgAMvF/rust-bindgen-0.56-0.56.0/debian/vendor/proc-macro2-1.0.24/src/fallback.rs:693:9
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The header installation is somewhat complex; 'make headers_install'
installs headers to debian/tmp-headers, then cpio copies them to
debian/linux-libc-dev, pruning '.*' files.
My best guess for the reason of this indirection is to avoid garbage
files contained in the packages.
In fact, "make headers_install" used to create dot files '.install'
and '.check' in the install destination.
Since Linux 5.3 (or more specifically since commit 59b2bd05f5),
headers_install does not install any dot files.
Specify the final destination to INSTALL_HDR_PATH, and you can get
clean installation.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
There is no good reason to use a different variable only for
'make headers_install'.
Just use $(kmake) like the other targets.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Our debian build scripts only work in a pristine source tree.
If you build the packages second time, the following code
mkdir $(headers_dir)/usr/include/$(DEB_HOST_MULTIARCH)
... will fail with this message:
mkdir: cannot create directory '...': File exists
Irrespective of the error, $(headers_dir) should be removed because
garbage files from the previous build might be remaining.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
$(build_arch) and $(header_arch) are always the same.
As far as I know, there is no situation where 'make headers_install'
uses a different ARCH=.
Signed-off-by: Masahiro Yamada <masahiro.yamada@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Compress modules with zstd, this significantly reduced install-size of
the linux kernel, but also improves initrd creation time and boot
speed with the upcoming initramfs-tools changes.
Note that upstream modinst compression is not used. During our package
build time the modules are copied and processed multiple times. If
they are compressed during modinst time, it will mean they will all be
uncompressed, again, during processing. Separately 3rd-party module
signing performed by various tools relies on uncompressed modules as
well. For Zstd higher compression level is used.
BugLink: https://bugs.launchpad.net/bugs/2028568
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
rust-1.62 and bindgen-0.56 were build against llvm-14, continue to use
the same llvm at runtime. As bindgen-0.56 has not yet been fixed to
use clang-16 at runtime.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
[ we do not use rust-1.62 anymore, but we still use bindgen-0.56 ]
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
With longer kernel names (such as linux-lowlatency-hwe-5.15) we may
exceed the dkms directory prefix limit of 100 characters, used when we
build zfs for example.
Simply increse this limit to 140 to prevent dkms from multiple flavours
clashing on each other.
Ignore: yes
(backported from focal:linux-lowlatency-hwe-5.15)
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Introduce the new variable do_lib_rust to enable or disable the
packaging of linux-lib-rust and enable it only on the generic amd64
kernel.
This allows to avoid building any kind of Rust artifact in other
kernels, except for the generic one and only on amd64.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger
Luca Boccassi
Bethany Jamison
Noah Wager
Magali Lemes
Andrea Righi
Masahiro Yamada
Dimitri John Ledkov
Stefan Bader