Re: [PATCH 0/1] libevl: Add debian package config

Am 20.07.26 um 16:30 schrieb Jan Kiszka:
> Hi Hannes,
> 
> thanks for carrying this over.

Thanks for all the feedback.

> 
> On 17.07.26 22:58, Hannes Diethelm wrote:
>> This patch adds a debian package config that allows to build a deb's
>> using dpkg-buildpackage -b -uc.
>>
>> The packages are libevl / libevl-test similar to[1]. However, latmus
>> is placed in libevl. One might not need the tests but still want to
>> use latmus.
> 
> For the purpose of tuning the core, or what is the reasoning here?

Yes exactly. One might need latmus but won't care about the tests.

Based on the comment from Florian, it would probably make more sense to create more packages:

- libevl (only library)
- libevl-bin (evl / latmus / oob-* tidbits)
- libevl-test (tests)
- libevl-dev (headers / libevl.a)

> 
>>
>> Additionally, libevl installs /usr/lib/udev/rules.d/90-libevl.rules which sets all evl
>> device files to group evl, g+rw. libevl.postinst adds this group and triggers an udev reload.
>>
>> This allows to use libevl without root. However, using SCHED_FIFO still
>> needs either root or setcap cap_sys_nice+ep and possibly some other tweaks.
>> Some tests and my application work with cap_sys_nice+ep. However, for example latmus fails
>> due to unknown reasons. The debian packages sets no capabilities but this could be added
>> if desired.
>>
>> Caveats:
>>
>> The test ptrace-sync fails with <timeout waiting for gdb>. dh_strip -Xptrace-sync from[1]
>> does not help and it is not needed: When libevl-test-dbgsym is installed, the symbols are
>> available but the test still fails. With dh_strip -Xptrace-sync, the symbols are not found:
>> warning: could not find '.gnu_debugaltlink' file for /usr/libexec/evl/tests/ptrace-sync
> 
> But the package built by xenomai-images does not have this problem and
> runs the ptrace test successfully. Already dug into the key differences?

Not yet. Might be just a different gdb version or path issue. I am using Debian Trixie.

Is there a way to download this images? I've seen there is a way to build them locally, i can also try this.

> 
>>
>> If linux-evl is also built and installed as a debian package, linux-libc-dev can not be
>> installed due to /usr/include/evl/*-abi.h are both installed by libevl and linux-libc-dev
>> from the kernel build. However, installing linux-libc-dev from debian trixie works fine.
> 
> This looks wrong: The kernel is providing us with a different UAPI, thus
> also needs to deliver an alternative linux-libc-dev package. It should
> be the role of libevl to deliver those headers as it has no knowledge
> about the actual kernel in use here. That's why xenomai-images is
> generating a new linux-libc-dev and is not relying on libevl here.
> 

Yes, Philippe sent me the hint with the -Dinstall-uapi=false switch, thanks.

One remaining issue is the versioning / dependency's. For now, to keep it simple, I just used the libevl tag
as the version. And it doesn't recommend a xenomai4 kernel.

For now, the packages are:
libevl_59_amd64.deb
libevl-test_59_amd64.deb dep libevl >= 59
linux-image-6.12.90-cip24-xenomai4-r59_6.12.90-3_amd64.deb (Withouth PREEMT_RT)
linux-image-6.12.90-cip24-xenomai4-r59-rt_6.12.90-3_amd64.deb (With PREEMT_RT)

I am working here [1] on creating Debian xenomai4 packages for linuxcnc. Not perfect but does the job. It's still WIP
but a few people got this already working without knowledge how to build kernels.
I did not yet push the latest version and I have to change from pushing the binary's to github releases.

With the uapi installed with linux-libc-dev, libevl has to depend on the right linux-libc-dev.

Version 59 is not really correct. The kernel has EVL ABI 45. Libevl has API 36, needs API >= 45.
For kernel dependency's, the ABI version is important, right?

For libevl, it could be either the API = 36 / dso_version = 8.0.0 / version = 0.59.

Variant with API/ABI as version:
- libevl 36 recommends linux-image-xenomai4 >= 45 or linux-image-xenomai4-rt >= 45
- libevl-bin 36 dep libevl >= 36
- libevl-test 36 dep libevl >= 36
- libevl-dev 36 dep libevl >= 36 linux-libc-dev >= 1:45

Dependency packages, needed to convert the ABI versioning into kernel versioning:
- linux-image-xenomai4 45 dep linux-image-6.12.90-cip24-xenomai4-45 or other kernel versions
- linux-image-xenomai4-rt 45 dep linux-image-6.12.90-cip24-xenomai4-rt-45 or other kernel versions
- linux-libc-dev 1:45 dep linux-libc-dev-xenomai4-45

Kernel packages:
- linux-image-6.12.90-cip24-xenomai4-45 6.12.90
- linux-image-6.12.90-cip24-xenomai4-rt-45 6.12.90
- linux-libc-dev-xenomai4-45 6.12.90

To create a linux-libc-dev-xenomai4-45 package, I would have to add a patch for linux-evl, the standard
kernel debian package system doesn't support custom names for linux-libc-dev. But this should be not to
complicated.

It's the first Debian package I am working on that's not only for me. I have to read a bit more in the
doc's how this dependency's are normally created properly.

Also linux-libc-dev 1:45 is a bit dirty: Using the epoch to replace the standard linux-libc-dev by a dependency
package that will not be replaced by the latest stock one. It should work tough.

Alternatives:
-Install the abi with libevl
-Create a linux-libc-dev-xenomai4 package from linux-evl and depend on that / remove the evl headers from linux-libc-dev
  so linux-libc-dev stock can be installed together with linux-libc-dev-xenomai4. I compared the content, most evl related files
  are new, only fnctl.h has
  #define O_OOB		010000000000
  added. However, I don't see any usage in libevl. So this should work.
-Leave the dependency's on the kernel packages away and solve this by documentation
  However, you would have to place a hold on linux-libc-dev so it doesn't get replaced as soon as your OS has a newer kernel.

Do you have other ideas how to solve the version / dependency's / linux-libc-dev issue?

For now I named the kernel packages -xenomai4 but I am thinking about changing to -evl or xenomai-evl. What is more appropriate?

> Jan
> 

[1] https://github.com/hdiethelm/xenomai4-linuxcnc