On Fri, Oct 18, 2024 at 2:01 PM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > > Hi Sedat, > > On Fri, 18 Oct 2024 at 11:48, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > Have you tested the resulting files, or you're just building testing? > In case of the latter we already have CI which covers Debian so > :shrug: > Hi Emil, Great, you consider Debian/unstable builds in your CI. Thanks. > > looks like etc directory was not copied to $PREFIX. > > > > Yes, meson behaves differently wrt /etc - not much we can do there. > Ideally you can check how other Debian packages using meson deal with > this and borrow the approach. > Hmmm, can this be somehow documented - say in README.md? > > meson setup --prefix $PREFIX --sysconfdir $PREFIX/etc --native-file > > build-dev.ini ../build > > > > The build-dev.ini is a configuration file for kmod _developers_, so it > for packaging purposes seems off IMHO. > Yupp. Did upgrade to latest kmod-git and moved to a custom ini file - see below. [ Documentation ] README.md requires some hints to manpages and docs build requirements: manpages: scdoc docs: gtk-doc-tools (/usr/bin/gtkdoc-scan) Link: https://packages.debian.org/sid/all/gtk-doc-tools/filelist I see some more improvements to README.md. Offer: I can cook up a patch and send for review. > If you want to help with the Debian side, you can reach out to their > maintainer Marco (CC'd) via the debian bug tracker, email or salsa[1]. > > HTH > Emil > [1] https://salsa.debian.org/md/kmod Ah Marco :-)! I did an install from kmod-git with overwriting the kmod binary and libkmod library. Renew my initrd.img file: KVER="6.12.0-rc3-1-amd64-clang19-kcfi" ; update-initramfs -c -k $KVER -v 2>&1 | tee log_update-initramfs_$KVER.txt Booted fine! I saw some other things like: file /usr/lib/x86_64-linux-gnu/libkmod.so* /usr/lib/x86_64-linux-gnu/libkmod.so: symbolic link to libkmod.so.2 /usr/lib/x86_64-linux-gnu/libkmod.so.2: symbolic link to libkmod.so.2.5.0 /usr/lib/x86_64-linux-gnu/libkmod.so.2.5.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3990121244ac36f617b2d289712054ecb1e390ba, with debug_info, not stripped Or an ASAN complaint is displayed requiring a LD_PRELOAD when "b_sanitize = 'address,undefined'" is used (when running update-initramfs). I have done my own INI file: --- build-dev.ini 2024-10-19 13:24:58.806312629 +0200 +++ build-dileks.ini 2024-10-19 13:26:05.332670566 +0200 @@ -4,15 +4,15 @@ ; SPDX-License-Identifier: LGPL-2.1-or-later [project options] -build-tests = true -debug-messages = true -docs = true +build-tests = false +debug-messages = false +docs = false zstd = 'enabled' xz = 'enabled' zlib = 'enabled' openssl = 'enabled' werror = true -b_sanitize = 'address,undefined' +;b_sanitize = 'address,undefined' [built-in options] -buildtype = 'debugoptimized' +;buildtype = 'debugoptimized' ^^ What buildtype other than above exists? Thanks for the helpful hints, Emil. Best regards, -Sedat-
