[Xenomai] Xenomai Red Hat packaging
gilles.chanteperdrix at xenomai.org
Tue Apr 22 00:28:53 CEST 2014
On 04/22/2014 12:21 AM, John Morris wrote:
> On 04/20/2014 11:53 AM, Gilles Chanteperdrix wrote:
>> Le 06/01/2014 23:40, John Morris a écrit :
>>> On 01/06/2014 02:52 PM, Gilles Chanteperdrix wrote:
>>>> On 01/06/2014 09:10 PM, John Morris wrote:
>>>>> Here are the packaging materials I've been using on Red Hat Enterprise
>>>>> Linux clones for some time now, also recently updated for Fedora.
>>>>> The packaging is pretty straightforward, and follows the Debian
>>>>> packaging for the xenomai-devel subpackage.
>>>>> A significant addition is the 'xenomai-gid-ctl' script for configuring
>>>>> non-root access to Xenomai services, plus sysv and systemd boot init
>>>> Are these specific to Red Hat, or can we put them in the set of files
>>>> installed by default?
>>> The 'xenomai-gid-ctl' script should work anywhere.
>>> The 'xenomai.default' file (installed into /etc/default/xenomai) works
>>> with RH- & Debian-derivatives, and other distros with the /etc/default
>>> directory. /etc/default/xenomai is only used to override the default
>>> 'xenomai' group, is semi-optional, and may be relocated.
>>> Installing 'xenomai-gid-ctl' (and 'xenomai.default', if /etc/default
>>> exists) from 'make install' could be useful to the end user, since it is
>>> a stand-alone utility.
>>> The EL6 sysv init script needs modification to support Debian's LSB init
>>> system, simple for someone more familiar.
>>> Other projects I'm familiar with often ship system init scripts in a
>>> e.g. 'contrib' directory, and don't include complex makefile logic to
>>> detect distro and install the correct init script. Manual installation
>>> is left up to the end user or the packager.
>>>> I'd appreciate comments on the control script's correctness
>>>>> and the init scripts' utility.
>>>> You do not need to pass --enable-x86-tsc as it is enabled by default
>>>> As for building the doc, xenomai sources contain generated
>>>> documentation, so if you do not enable any option, you will have some
>>>> documentation installed. If you still want to generate the doxygen
>>>> documentation, what is the problem with --enable-dox-doc?
>>> I'll find time to revisit doc generation and report back.
>> Hi John,
>> despite the long response time, I am still interested in merging support
>> for redhat packaging. I guess we coud add a "make rpm" rule which builds
>> the redhat package. However, looking at the spec file, it see that it
>> works by looking for the release tarball on gna download site, so, is it
>> possible to get the spec file to use the sources from the .. directory,
>> or failing that, use a tarball generated locally (we would then simply
>> have to get the rpm target depend on the dist target).
> Hi Gilles,
> Rpmbuild actually doesn't try to download a tarball; that is expected to
> be in the local directory. The URL is for recording the tarball's
> origin, for use by humans and Fedora Project infrastructure, and ignored
> by the rpm-build system.
> When the RPM is built from git, the Release: tag should be changed to
> indicate as much. A little work on the specfile would need to be done
> to make that easier.
> A script could run 'git archive' to build a tarball, tweak the Release:
> in a copy of the specfile, and then perform some annoying acrobatics
> needed to build the packages. Is the purpose of the script for the
"make dist" is better than git archive, as it really generates the
distributed tarball. The idea would be to add a "make rpm" target to the
top makefile that would generate the rpms from the current contents of
the repository. This would allow people wanting to work with rpm
packages to be able to build an intermediate release as an rpm. At the
same time, it would allow to build rpm packages directly from the
released tarball. This is something we have for Debian, I see no reason
not to have it for Red-Hat (unless of course, you think this is useless,
or complicated and not worth the trouble).
> I'm actually setting up a Wandboard right now, and will be building
> Xenomai for it tomorrow. While I'm at it, I'll work some of the changes
> into the specfile itself.
> Additionally, I did finally get that buildbot running for RHEL6 and
> current Fedoras, x86_64 and i686 architectures, but backed down to
> 126.96.36.199 to do so. In the process, most of the issues I identified
> running 2.6.3 were also encountered in 188.8.131.52 and solved (operator
> error, of course :P ), so it might be time to take another stab at
> building against 2.6.3.
Beware the bad latencies on imx6, you may want to backport the following
More information about the Xenomai