7.0.9

[daykin]

#36, #38 and #39 serve two purposes:

1. Incorporate the full history from 3.15.9 up to 7.0.9
2. Update the latest version to 7.0.9 (for upcoming Debian Trixie)

[daykin]

@chrschroeder Are you planning on using this repo or the Debian Science Team version? If this one, would you be able to test this revision on your end to make sure it builds OK?

[chrschroeder]

@daykin Thanks for the update! I can still successfully build 7.0.8.1. For 7.0.9 a merge from upstream to the master branch and an update of the configuration is missing though. Will you do another pull-request for that?

Our next upgrade will be Debian 13, where we want to deploy EPICS 7 instead of 3.15.9. We have not yet decided which version we will use, but there are some issues with the version in the Debian repository. Besides the different package structure, which will probably require adjustments in depending packages, the epics-dev packages seems to be incomplete. Most of the stuff we used to have in /usr/lib/epics is missing. I don't think it's possible to build other packages like edm against this at all. So unless the Debian Science Team will change this, we strongly tend to use your version.

[daykin]

Thanks for your feedback, Christoph. We observed most of the same issues you described with the DST version. I will fix the merge structure for 7.0.9 as well.

[daykin]

#40 fixed to add a merge commit relating upstream to master. Please give it a try on a trixie machine.

[chrschroeder]

Hi Evan. Thanks for the update! You probably got spam about epics-debhelper during my build. Sorry for that! I had to update epics-debhelper to the new version made by you due to the new requirement in the epics-base package and forgot to replace the mail address. Note that we still build for Debian 11. We have to update our build infrastructure for Debian 13 which is not fully done yet.

I have two problems so far to build 7.0.9:

1. dh_epics_lintian returns an error.

/tmp/buildd/epics-base-7.0.9# dh_epics_lintian -O-Sepicsmake
Version string '2.104.0
' contains invalid data; ignoring: '
' at /usr/bin/dh_epics_lintian line 61.

The problem is the remaining '\n' in the version string. We could use tr to fix this.

my $lintian_version = `dpkg -s lintian | grep "^Version:" | cut -d' ' -f2 | tr -d '\n'`;

2. 0048-skip-non-loopback-iface-tests.patch

The channel monitor test has to be optional too. This can't be done in the pbuilder chroot environment during build process. Unfortunately github fails to upload the modfied patch, but the relevant part could look like this:

-TESTPROD_HOST += testPVAServer
-testPVAServer_SRCS += testPVAServer.cpp
-testHarness_SRCS += testPVAServer.cpp
-TESTS += testPVAServer
-
-TESTPROD_HOST += testChannelMonitor
-testChannelMonitor_SRCS += testChannelMonitor.cpp
-testHarness_SRCS += testChannelMonitor.cpp
-TESTS += testChannelMonitor
+# If there's an available interface to do this on
+ifneq ($(shell ip addr | grep MULTICAST | wc -l),0)
+ TESTPROD_HOST += testPVAServer
+ testPVAServer_SRCS += testPVAServer.cpp
+ testHarness_SRCS += testPVAServer.cpp
+ TESTS += testPVAServer
+
+ TESTPROD_HOST += testChannelMonitor
+ testChannelMonitor_SRCS += testChannelMonitor.cpp
+ testHarness_SRCS += testChannelMonitor.cpp
+ TESTS += testChannelMonitor
+endif

[daykin]

OK, I think I got both of those issues if you'd like to try again. Also removed perl files used by epics-dev (DBD stuff, EpicsHostArch) from epics-perl.

[chrschroeder]

Hi Evan. Thanks! I can build the package now, but I had to add lintian as build-depency. This is a side effect because of the changes in epics-debhelper. The build stopped with the following error:

dh_epics_lintian -O-Sepicsmake
dpkg-query: package 'lintian' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.
Invalid version format (version required) at /usr/bin/dh_epics_lintian line 61.

Normally lintian is not a build-dependency. In our buildsystem it is installed via hook by pbuilder at a certain stage of the build process to check the package.

I think we have 3 options to solve this:

1. Add it as build-dependency inside the debian packages. This is a bit of a hassle since we would have to do this for every single package that uses epics-debhelper.
2. Add it as install dependency of the epics-debhelper package. This would be the easiest solution, but since lintian pulls a lot of packages this might disguise dependency issues.
3. Do a more complicated check in dh_epics_lintian. My concern with this is that there might be different versions available, e. g. from the installed package, the one in the main repository and one in the backports. The following code might be a solution, but only considers an installed package or the install candidate.

my $lintian_version;
if (system('dpkg -s lintian > /dev/null 2>&1') == 0) {
    $lintian_version = qx(dpkg -s lintian | grep "^Version:" | cut -d' ' -f2 | tr -d '\n');
} else {
    $lintian_version = qx(apt-cache policy lintian | grep "Candidate" | cut -d' ' -f4 | tr -d '\n');
}

Not sure if this is the proper way. What do you think about this?

[daykin]

Thank you for trying it again. We also encountered the 'lintian not found' thing, but worked around it by adding lintian to the cowbuilder base image, which also doesn't fix the 'disguising dependency issues' problem. (3) is fine with me, but I have another proposal (4): Break compatibility with older debhelper and get rid of this version check entirely in epics-debhelper. Might make the most sense since all of this is designed to build on trixie+.

P.S. another problem I'm seeing is that EPICS is now building versioned shared libraries with their submodule versions rather than the EPICS version (e.g. dbRecStd wants to be called dbRecStd.so.3.23.1). The debian package is still installing them as libxyz.so.7.0.9, but the EPICS build system is creating symlinks to the version it thinks it should see. Right now I have a patch to just overwrite the versions the EPICS build system sees (in module/configure/CONFIG_module_VERSION). Thoughts?

[chrschroeder]

We intend to go for Trixie too. Will this break builds on Bookworm? Should be fine since I could just install older versions of epics-debhelper for that if needed.

About the Libs, the current status looks like this to me: CONFIG_DATABASE_VERSION sets version 3.24.0 for libdbRecStd but SHRLIB_VERSION overwrites this with the base version 7.0.9. During the build both versions seem to end up in lib/linux-x86_64, but links are pointing to libdbRecStd.so.3.24.0 instead of libdbRecStd.so.7.0.9. The links are ignored though. Overwriting the version directly in CONFIG_$(MODULE)_VERSION is pobably the cleaner approach, but the current one also works fine or are there problems with that? What are the down-sites if we just install the libs as they are? I don't think it's against the policy to use a SOVERSION that differs from the Debian package version and currently it is not intended to install multiple base packages at the same time.

[daykin]

On bookworm, buster, etc. You'd typically point CI at one of the debian/7.0.8* or 3.15* release tags, and epics-debhelper at a debian/8.* tag rather than master. So my rationale is as long as the major version is bumped to indicate it's breaking old systems, it is OK.

The problem with leaving libs as they are is that it's flagged by piuparts and thus marking our builds as unstable. Our lab policy is that production builds must be piuparts clean, or have a reasonable justification for why each specific problem is overridden. It is usually pertaining to some stock debian package (openjpeg2!) having dangling symlinks confirmed to be harmless. I think manually messing with the link creation process is more fragile than just patching CONFIG_$(MODULE)_VERSION to match the old behavior.