Distribution Packaging - OpenMandriva Lx #303

Greetings.

This is more of a Request than an Issue. I reached out to the dev mailing list to inquire about packaging for the OpenMandriva Lx distribution, and I did not get a reply. Since then, I have been modifying the PCLinuxOS spec files because that distribution is similar. I was wondering if there is a particular point of contact I could reach out to for assistance with this process. We primarily use matrix.org for communication. I would also be interested in helping out with CMake related tasks or other starter issues. I appreciate your attention.

Thanks in advance,

Greetings. This is more of a Request than an Issue. I reached out to the dev mailing list to inquire about packaging for the OpenMandriva Lx distribution, and I did not get a reply. Since then, I have been modifying the PCLinuxOS spec files because that distribution is similar. I was wondering if there is a particular point of contact I could reach out to for assistance with this process. We primarily use matrix.org for communication. I would also be interested in helping out with CMake related tasks or other starter issues. I appreciate your attention. Thanks in advance,

Hi @zeroability,
not sure the mail to the dev list came thorugh or perhaps we missed it.
You can of course reach out here, on the mailing list or the TDE IRC chat (#tde-devs on irc.libera.chat).

If you would like to package TDE for openMandriva and maintain it over time, we could add a openMandriva folder in the TDE packaging repository and the required files can be added there. This is similar to what we do for other distributions. Would that work for your needs?

I would also be interested in helping out with CMake related tasks or other starter issues. I appreciate your attention.

Any help on cmake or any other issue will also be welcome, of course 👍

Hi @zeroability, not sure the mail to the dev list came thorugh or perhaps we missed it. You can of course reach out here, on the mailing list or the TDE IRC chat (`#tde-devs` on `irc.libera.chat`). If you would like to package TDE for openMandriva and maintain it over time, we could add a `openMandriva` folder in the TDE packaging repository and the required files can be added there. This is similar to what we do for other distributions. Would that work for your needs? > I would also be interested in helping out with CMake related tasks or other starter issues. I appreciate your attention. Any help on cmake or any other issue will also be welcome, of course 👍

not sure the mail to the dev list came thorugh or perhaps we missed it.

I'm sure it was probably because I did not formally register for the list or some weirdness with the mail host I use. Of the contact methods you suggested, this one is probably better.

If you would like to package TDE for openMandriva and maintain it over time, we could add a openMandriva folder in the TDE packaging repository and the required files can be added there. This is similar to what we do for other distributions. Would that work for your needs?

We will most likely need a separate folder. OpenMandriva still has macros that intersect with those used in the redhat folder (like %{mdkversion}), but we would need additional macros to sort out things like our dependencies. There are also older things we don't use like epochs, for example. We also use LLVM toolkit so there will be additional condition checks which will just add to spec files that are already massive.

So far, this has been a work in progress so the need to merge is not immediate. I was able to get the stable version of tdebase and its dependencies to build using CMake and Ninja, but there were problems getting TDE to work because it wanted .la files and those were not created. arts, libs, and base also need additional RPATH settings in CMake for Ninja to work. I will keep at it as I have time.

> not sure the mail to the dev list came thorugh or perhaps we missed it. I'm sure it was probably because I did not formally register for the list or some weirdness with the mail host I use. Of the contact methods you suggested, this one is probably better. > If you would like to package TDE for openMandriva and maintain it over time, we could add a openMandriva folder in the TDE packaging repository and the required files can be added there. This is similar to what we do for other distributions. Would that work for your needs? We will most likely need a separate folder. OpenMandriva still has macros that intersect with those used in the `redhat` folder (like `%{mdkversion}`), but we would need additional macros to sort out things like our dependencies. There are also older things we don't use like epochs, for example. We also use LLVM toolkit so there will be additional condition checks which will just add to spec files that are already massive. So far, this has been a work in progress so the need to merge is not immediate. I was able to get the stable version of `tdebase` and its dependencies to build using CMake and Ninja, but there were problems getting TDE to work because it wanted `.la` files and those were not created. `arts`, `libs`, and `base` also need additional RPATH settings in CMake for Ninja to work. I will keep at it as I have time.

We will most likely need a separate folder.
So far, this has been a work in progress so the need to merge is not immediate.

No problem, you can ping us here or the dev IRC chat when you are ready and we can add the folder and add you as packager for openMandriva

also need additional RPATH settings in CMake for Ninja to work

Under debian, all cmake builds use -DCMAKE_SKIP_RPATH="OFF", perhaps the same you need on your end?

> We will most likely need a separate folder. > So far, this has been a work in progress so the need to merge is not immediate. No problem, you can ping us here or the dev IRC chat when you are ready and we can add the folder and add you as packager for openMandriva > also need additional RPATH settings in CMake for Ninja to work Under debian, all cmake builds use `-DCMAKE_SKIP_RPATH="OFF"`, perhaps the same you need on your end?

Also please take note on the collaboration model we use for TDE (branch model rather than fork model). You can find the guidelines here

Also please take note on the collaboration model we use for TDE (branch model rather than fork model). You can find the [guidelines here](https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_contribute_code_changes)

No problem, you can ping us here or the dev IRC chat when you are ready and we can add the folder and add you as packager for openMandriva

~~I just forked the repo and I'll just submit a MR/PR when all the specs have been added and tested. That way my permission set will be least permissive.~~ See below, this has been corrected.

Under debian, all cmake builds use -DCMAKE_SKIP_RPATH="OFF", perhaps the same you need on your end?

I have to add the following block to the CMake options for Ninja to work properly:

  -DCMAKE_SKIP_RPATH=OFF \
  -DCMAKE_SKIP_INSTALL_RPATH=OFF \
  -DCMAKE_INSTALL_RPATH="%{tde_libdir}" \
  -DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF \
  -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=OFF \
  -DCMAKE_NO_BUILTIN_CHRPATH=OFF \

Otherwise an error is generated that this must be specified:
https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html

> No problem, you can ping us here or the dev IRC chat when you are ready and we can add the folder and add you as packager for openMandriva ~~I just forked the repo and I'll just submit a MR/PR when all the specs have been added and tested. That way my permission set will be least permissive.~~ See below, this has been corrected. > Under debian, all cmake builds use -DCMAKE_SKIP_RPATH="OFF", perhaps the same you need on your end? I have to add the following block to the CMake options for Ninja to work properly: ``` -DCMAKE_SKIP_RPATH=OFF \ -DCMAKE_SKIP_INSTALL_RPATH=OFF \ -DCMAKE_INSTALL_RPATH="%{tde_libdir}" \ -DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF \ -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=OFF \ -DCMAKE_NO_BUILTIN_CHRPATH=OFF \ ``` Otherwise an error is generated that this must be specified: https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html

Also please take note on the collaboration model we use for TDE (branch model rather than fork model). You can find the guidelines here

Ahh, okay. I will delete the fork then.

> Also please take note on the collaboration model we use for TDE (branch model rather than fork model). You can find the [guidelines here](https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_contribute_code_changes) Ahh, okay. I will delete the fork then.

Pertaining to this document:

https://developercertificate.org/

I have spoken to the maintainer of hldig, which replaces htdig and have a spec for that already if you are interested. It completely replaces the unmaintained htdig program suite. Here is a link to the project:

https://github.com/solbu/hldig/

Please let me know if there is any further information you need to allow the spec as part of contributing to this repo.

Pertaining to this document: https://developercertificate.org/ I have spoken to the maintainer of hldig, which replaces htdig and have a spec for that already if you are interested. It completely replaces the unmaintained htdig program suite. Here is a link to the project: https://github.com/solbu/hldig/ Please let me know if there is any further information you need to allow the spec as part of contributing to this repo.

I have to add the following block to the CMake options for Ninja to work properly

Thanks for the info. Since openMandriva will have its own folder, that won't be a problem. It will not conflict with packaging files for other distros.

Ahh, okay. I will delete the fork then.

Thanks for reading and following the guidelines

Pertaining to this document [and hldig]

Anything that is release under GPL2+/LGLP is fine. Hldig is a fork of Htdig, which are both released under LGPL, so no issue too.

Btw, please also note we are close to release R14.1.2, so we have soft-freezed code changes till we tag such release. This is likely to take about 2 weeks from now. You can still prepare PRs, but they won't be merged before that. Only critical fixes are allowed in this period.

Also, I added you to the Contributor group, so you should be able to create PR from now.

> I have to add the following block to the CMake options for Ninja to work properly Thanks for the info. Since openMandriva will have its own folder, that won't be a problem. It will not conflict with packaging files for other distros. > Ahh, okay. I will delete the fork then. Thanks for reading and following the guidelines > Pertaining to this document [and hldig] Anything that is release under GPL2+/LGLP is fine. Hldig is a fork of Htdig, which are both released under LGPL, so no issue too. Btw, please also note we are close to release R14.1.2, so we have soft-freezed code changes till we tag such release. This is likely to take about 2 weeks from now. You can still prepare PRs, but they won't be merged before that. Only critical fixes are allowed in this period. Also, I added you to the Contributor group, so you should be able to create PR from now.

Thanks for the info. Since openMandriva will have its own folder, that won't be a problem. It will not conflict with packaging files for other distros.

It's a stop gap until RPATH can be obsoleted and (as far as I know) only matters with Ninja.

Thanks for reading and following the guidelines

You are welcome. Thanks for the information.

Btw, please also note we are close to release R14.1.2, so we have soft-freezed code changes till we tag such release. This is likely to take about 2 weeks from now. You can still prepare PRs, but they won't be merged before that. Only critical fixes are allowed in this period.

I am excited to test the new release with my work thus far. I will add a Watch for the main repo.

Also, I added you to the Contributor group, so you should be able to create PR from now.

I appreciate the prompt adjustment and I look forward to working with you all. :)

> Thanks for the info. Since openMandriva will have its own folder, that won't be a problem. It will not conflict with packaging files for other distros. It's a stop gap until RPATH can be obsoleted and (as far as I know) only matters with Ninja. > Thanks for reading and following the guidelines You are welcome. Thanks for the information. > Btw, please also note we are close to release R14.1.2, so we have soft-freezed code changes till we tag such release. This is likely to take about 2 weeks from now. You can still prepare PRs, but they won't be merged before that. Only critical fixes are allowed in this period. I am excited to test the new release with my work thus far. I will add a Watch for the main repo. > Also, I added you to the Contributor group, so you should be able to create PR from now. I appreciate the prompt adjustment and I look forward to working with you all. :)

Welcome to the project 🙂 We will look forward for your contributions!

Pertaining to this document:

https://developercertificate.org/

I have spoken to the maintainer of hldig, which replaces htdig and have a spec for that already if you are interested. It completely replaces the unmaintained htdig program suite. Here is a link to the project:

https://github.com/solbu/hldig/

Please let me know if there is any further information you need to allow the spec as part of contributing to this repo.

Hello, please, can you share the spec file for hldig ?
It may be a good alternative to htdig for other distributions as well.

> Pertaining to this document: > > https://developercertificate.org/ > > I have spoken to the maintainer of hldig, which replaces htdig and have a spec for that already if you are interested. It completely replaces the unmaintained htdig program suite. Here is a link to the project: > > https://github.com/solbu/hldig/ > > Please let me know if there is any further information you need to allow the spec as part of contributing to this repo. Hello, please, can you share the spec file for hldig ? It may be a good alternative to htdig for other distributions as well.

Here is the spec as well as the rest of the files added to SOURCES in an rpmbuild directory tree. It assumes you already have a compiler installed and compiling with clang is successful. If you plan on adding it as a dependency to TDE, please let me know.

See the following comment:

#303

~~Here is the spec as well as the rest of the files added to `SOURCES` in an `rpmbuild` directory tree. It assumes you already have a compiler installed and compiling with `clang` is successful. If you plan on adding it as a dependency to TDE, please let me know.~~ See the following comment: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/issues/303#issuecomment-51207

Hello, thanks for your reply.

Alas, I do not see the hldig files anywhere. Did you upload to this ticket directly, or elsewhere ?

On my side, I'm currently building openmandriva 5 packages using the common redhat spec files. Most require a few updating, as you pointed out, because development libraries packages and macros have slightly different names in each distribution. Nothing unusual when adding a new distro.

I'm building using clang/clang++/lld and gnu make.

I have all dependencies, all libraries, all core packages, and many applications already built.

Some applications do not build correctly because undefined symbols at link time. This happens only on packages built with autotools (especially koffice). This will need some investigation and fixes in the application source code.

I'll let you know when I have finished all buildable packages (should happen later today). Then I'll open tickets for packages that fail to build.
I will also upload the current packages so that you can test on your machine if you want. I will try in a virtual machine on my side.

Hello, thanks for your reply. Alas, I do not see the hldig files anywhere. Did you upload to this ticket directly, or elsewhere ? On my side, I'm currently building openmandriva 5 packages using the common redhat spec files. Most require a few updating, as you pointed out, because development libraries packages and macros have slightly different names in each distribution. Nothing unusual when adding a new distro. I'm building using clang/clang++/lld and gnu make. I have all dependencies, all libraries, all core packages, and many applications already built. Some applications do not build correctly because undefined symbols at link time. This happens only on packages built with autotools (especially koffice). This will need some investigation and fixes in the application source code. I'll let you know when I have finished all buildable packages (should happen later today). Then I'll open tickets for packages that fail to build. I will also upload the current packages so that you can test on your machine if you want. I will try in a virtual machine on my side.

It does not appear that I can upload files. I tried them as a compressed file and individually. Instead, I will post the contents of the files here since they are relatively small:

hldig-dbgen:

#!/bin/bash
# cron.daily script to run hldig db generation
su - hldig -c "/usr/bin/rundig -a"

hldig-rundiginfos.patch:

--- hldig-0.2.0/installdir/rundig.rh	Wed Apr 21 22:47:58 1999
+++ hldig-0.2.0/installdir/rundig	Wed May 12 12:16:31 1999
@@ -64,11 +64,24 @@
 if [ "`ls -t $COMMONDIR/english.0 $COMMONDIR/word2root.db 2>/dev/null | sed 1q`" = \
 	"$COMMONDIR/english.0" ]
 then
-    $BINDIR/hlfuzzy $opts endings
+      cat <<EOF
+ Warning:
+       The following is a lengthly process, but it is run only
+       the first time you start hl://Dig. Initializing database...
+EOF
+     $BINDIR/hlfuzzy $opts endings
 fi
 
 if [ "`ls -t $COMMONDIR/synonyms $COMMONDIR/synonyms.db 2>/dev/null | sed 1q`" = \
 	"$COMMONDIR/synonyms" ]
 then
+     cat <<EOF
+ Warning:
+       The following is a lengthly process, but it is run only
+       the first time you start hl://Dig. Initializing database...
+EOF
     $BINDIR/hlfuzzy $opts synonyms
 fi
+
+#@BIN_DIR@/hlfuzzy $verbose metaphone
+#@BIN_DIR@/hlfuzzy $verbose soundex

hldig.conf:

u hldig "hldig service account" /var/lib/hldig /sbin/nologin

hldig.spec:

# Special thanks to the project maintainer Johnny A. Solbu for providing some of the
# settings here. https://www.solbu.net/

%global debug_package %{nil}
%define contentdir /var/www

Name:           hldig
Version:        1.0.2
Release:        1
Summary:        A web indexing and searching system for a small domain or intranet
Group:          Networking/WWW
License:        GPLv2
URL:            https://github.com/solbu/hldig/
Source0:        https://github.com/solbu/hldig/archive/refs/tags/%{version}.tar.gz#/%{name}-%{version}.tar.gz
Source1:        hldig.conf
Source2:        hldig-dbgen

Patch0:         hldig-rundiginfos.patch

BuildRequires:  libstdc++-devel
BuildRequires:  pkgconfig(openssl)
BuildRequires:  pkgconfig(zlib)
BuildRequires:  db2-devel
BuildRequires:  gettext
BuildRequires:  php-devel

Provides:       htdig >= 3.1.6

%description
The hl://Dig system is a complete world wide web indexing and searching
system for a small domain or intranet. This system is not meant to replace
the need for powerful internet-wide search systems like Google, DuckDuckGo,
Bing or Baidu. Instead it is meant to cover the search needs for a single
company, campus, or even a particular sub section of a web site. As
opposed to some WAIS-based or web-server based search engines, hl://Dig can
span several web servers at a site. The type of these different web servers
doesn't matter as long as they understand the HTTP 1.0 protocol.

hl://Dig was developed as "ht://Dig" at San Diego State University
as a way to search the various web servers on the campus network.

%package devel

Provides:       htdig-devel >= 3.1.6
Requires:       %{name} = %{version}

Summary:        Development package for %{name}

%description devel
Provides development libraries and debugging info for %{name}.

%package	web
Summary:        Scripts and HTML code needed for using hl://Dig as a web search engine
Group:          Networking/WWW
Requires:       %{name} = %{version}
Requires:       webserver

%description	web
The hl://Dig system is a complete world wide web indexing and searching
system for a small domain or intranet. This system is not meant to replace
the need for powerful internet-wide search systems like Google, DuckDuckGo,
Bing or Baidu. Instead it is meant to cover the search needs for a single
company, campus, or even a particular sub section of a web site. As
opposed to some WAIS-based or web-server based search engines, hl://Dig can
span several web servers at a site. The type of these different web servers
doesn't matter as long as they understand the HTTP 1.0 protocol.

hl://Dig was developed as "ht://Dig" at San Diego State University
as a way to search the various web servers on the campus network.

The %{name}-web package includes CGI scripts and HTML code needed to use
hl://Dig on a website.

%prep
%autosetup -p1
autoreconf --force --install

CXXFLAGS="%{?optflags} -std=c++14" \
LDFLAGS="" \
    ./configure --prefix=%{_prefix} \
        --sysconfdir=%{_sysconfdir} \
        --bindir=%{_bindir} \
        --libdir=%{_libdir} \
        --mandir=%{_mandir} \
        --localedir=%{_datadir}/locale \
        --datarootdir=%{_datadir} \
        --includedir=%{_includedir} \
        --localstatedir=%{_localstatedir} \
        --sharedstatedir=%{_sharedstatedir} \
        --enable-shared \
        --with-common-dir=%{contentdir}/html/%{name} \
        --with-database-dir=%{_sharedstatedir}/%{name} \
        --with-cgi-bin-dir=%{contentdir}/cgi-bin \
        --with-image-dir=%{contentdir}/html/%{name} \
        --with-image-url-prefix=/%{name} \
        --with-search-dir=%{contentdir}/html/%{name} \
        --with-apache=/usr/sbin/httpd \
        --with-default-config-file=%{_sysconfdir}/%{name}/%{name}.conf \

%build
%make_build

%install
%make_install

# install binary that was not included
install -m 755 %{_builddir}/%{name}-%{version}/hlsearch/hlsearch %{buildroot}/%{_bindir}

# add the service account
install -p -m 644 -D %{S:1} %{buildroot}%{_prefix}/lib/sysusers.d/%{name}.conf

# cron job
mkdir -p %{buildroot}/%{_sysconfdir}/cron.daily
cp %{S:2} %{buildroot}/%{_sysconfdir}/cron.daily/%{name}-dbgen

# set up /var/www
chmod 644 %{buildroot}%{contentdir}/html/%{name}/*
ln -sf ./search.html %{buildroot}%{contentdir}/html/%{name}/index.html

# migrate content to /usr/share and link it
mkdir -p %{buildroot}%{_datadir}
mv %{buildroot}%{contentdir}/html/hldig %{buildroot}%{_datadir}
ln -s %{_datadir}/%{name} %{buildroot}%{contentdir}/html/%{name}

%find_lang %{name}

%post web
# Only run this if installing for the first time
if [ "$1" = 1 ]; then
	if [ -f %{_sysconfdir}/httpd/conf/httpd.conf ];then
	SERVERNAME="`grep '^ServerName' %{_sysconfdir}/httpd/conf/httpd.conf | awk 'NR == 1 {print $2}'`"
	fi
	[ -z "$SERVERNAME" ] && SERVERNAME="`hostname -f`"
	[ -z "$SERVERNAME" ] && SERVERNAME="localhost"
	sed 's/^start_url:.*/#&\
# (See end of file for this parameter.)/' %{_sysconfdir}/hldig/hldig.conf > /tmp/hl.$$
	cat /tmp/hl.$$ > %{_sysconfdir}/%{name}/%{name}.conf
	rm /tmp/hl.$$
	cat >> %{_sysconfdir}/%{name}/%{name}.conf <<!

# Automatically set up by hldig RPM, from your current Apache httpd.conf...
# Verify and configure these, and set maintainer above, before running
# /usr/bin/rundig.
# See /usr/doc/hldig*/attrs.html for descriptions of attributes.

# The URL(s) where hldig will start.  See also limit_urls_to above.
start_url:	http://$SERVERNAME/

# This makes sure that we don't spider the web
local_urls_only: true

# These attributes allow indexing server via local filesystem rather than HTTP.
local_urls:	http://$SERVERNAME/=%{contentdir}/html/
local_user_urls:	http://$SERVERNAME/=/home/,/public_html/
!

fi

%files -f %{name}.lang
%license COPYING
%doc README.md ChangeLog
%{_bindir}/*
%{_datadir}/%{name}
%{_mandir}/man1/*.zst
%{_mandir}/man8/*.zst
%{_libdir}/%{name}/*.so
%{_libdir}/%{name}_db/*.so
%config(noreplace) %{_sysconfdir}/%{name}/cookies.txt
%config(noreplace) %{_sysconfdir}/%{name}/hldig.conf
%config(noreplace) %{_sysconfdir}/%{name}/HtFileType-magic.mime
%config(noreplace) %{_sysconfdir}/%{name}/mime.types

%files devel
%{_includedir}/%{name}
%{_includedir}/%{name}_db
%{_libdir}/%{name}/*.a
%{_libdir}/%{name}_db/*.a

%files web
%config(missingok, noreplace) %attr(0755,root,root) %{_sysconfdir}/cron.daily/%{name}-dbgen
%{contentdir}/html/%{name}
%{contentdir}/cgi-bin/*
%{_prefix}/lib/sysusers.d/%{name}.conf

I'm currently building openmandriva 5 packages using the common redhat spec files.

It would be best to use the cooker branch if you are not already. The number versioning is primarily used for Rock which is the stable branch, and cooker has historically been the development/testing branch. We also have a developer chat that can be helpful if you need more realtime support. You can find a link to it on the OpenMandriva website. I hang out in that chat room, as well. As far as I know, it was bridged to other chat services like Libera and Telegram, but I don't think the former bridge is being maintained by Matrix anymore and Libera refuses to.

I will also upload the current packages so that you can test on your machine if you want. I will try in a virtual machine on my side.

The best thing would be to submit the specs so we can build packages in ABF (Automated Build Farm). That is our primary build tool and it makes building and testing packages easier because we don't have to tie up our physical or virtual workstations after a good local build has been achieved. The rest would get sorted out as a part of testing cooker.

It does not appear that I can upload files. I tried them as a compressed file and individually. Instead, I will post the contents of the files here since they are relatively small: hldig-dbgen: ``` #!/bin/bash # cron.daily script to run hldig db generation su - hldig -c "/usr/bin/rundig -a" ``` hldig-rundiginfos.patch: ``` --- hldig-0.2.0/installdir/rundig.rh Wed Apr 21 22:47:58 1999 +++ hldig-0.2.0/installdir/rundig Wed May 12 12:16:31 1999 @@ -64,11 +64,24 @@ if [ "`ls -t $COMMONDIR/english.0 $COMMONDIR/word2root.db 2>/dev/null | sed 1q`" = \ "$COMMONDIR/english.0" ] then - $BINDIR/hlfuzzy $opts endings + cat <<EOF + Warning: + The following is a lengthly process, but it is run only + the first time you start hl://Dig. Initializing database... +EOF + $BINDIR/hlfuzzy $opts endings fi if [ "`ls -t $COMMONDIR/synonyms $COMMONDIR/synonyms.db 2>/dev/null | sed 1q`" = \ "$COMMONDIR/synonyms" ] then + cat <<EOF + Warning: + The following is a lengthly process, but it is run only + the first time you start hl://Dig. Initializing database... +EOF $BINDIR/hlfuzzy $opts synonyms fi + +#@BIN_DIR@/hlfuzzy $verbose metaphone +#@BIN_DIR@/hlfuzzy $verbose soundex ``` hldig.conf: ``` u hldig "hldig service account" /var/lib/hldig /sbin/nologin ``` hldig.spec: ``` # Special thanks to the project maintainer Johnny A. Solbu for providing some of the # settings here. https://www.solbu.net/ %global debug_package %{nil} %define contentdir /var/www Name: hldig Version: 1.0.2 Release: 1 Summary: A web indexing and searching system for a small domain or intranet Group: Networking/WWW License: GPLv2 URL: https://github.com/solbu/hldig/ Source0: https://github.com/solbu/hldig/archive/refs/tags/%{version}.tar.gz#/%{name}-%{version}.tar.gz Source1: hldig.conf Source2: hldig-dbgen Patch0: hldig-rundiginfos.patch BuildRequires: libstdc++-devel BuildRequires: pkgconfig(openssl) BuildRequires: pkgconfig(zlib) BuildRequires: db2-devel BuildRequires: gettext BuildRequires: php-devel Provides: htdig >= 3.1.6 %description The hl://Dig system is a complete world wide web indexing and searching system for a small domain or intranet. This system is not meant to replace the need for powerful internet-wide search systems like Google, DuckDuckGo, Bing or Baidu. Instead it is meant to cover the search needs for a single company, campus, or even a particular sub section of a web site. As opposed to some WAIS-based or web-server based search engines, hl://Dig can span several web servers at a site. The type of these different web servers doesn't matter as long as they understand the HTTP 1.0 protocol. hl://Dig was developed as "ht://Dig" at San Diego State University as a way to search the various web servers on the campus network. %package devel Provides: htdig-devel >= 3.1.6 Requires: %{name} = %{version} Summary: Development package for %{name} %description devel Provides development libraries and debugging info for %{name}. %package web Summary: Scripts and HTML code needed for using hl://Dig as a web search engine Group: Networking/WWW Requires: %{name} = %{version} Requires: webserver %description web The hl://Dig system is a complete world wide web indexing and searching system for a small domain or intranet. This system is not meant to replace the need for powerful internet-wide search systems like Google, DuckDuckGo, Bing or Baidu. Instead it is meant to cover the search needs for a single company, campus, or even a particular sub section of a web site. As opposed to some WAIS-based or web-server based search engines, hl://Dig can span several web servers at a site. The type of these different web servers doesn't matter as long as they understand the HTTP 1.0 protocol. hl://Dig was developed as "ht://Dig" at San Diego State University as a way to search the various web servers on the campus network. The %{name}-web package includes CGI scripts and HTML code needed to use hl://Dig on a website. %prep %autosetup -p1 autoreconf --force --install CXXFLAGS="%{?optflags} -std=c++14" \ LDFLAGS="" \ ./configure --prefix=%{_prefix} \ --sysconfdir=%{_sysconfdir} \ --bindir=%{_bindir} \ --libdir=%{_libdir} \ --mandir=%{_mandir} \ --localedir=%{_datadir}/locale \ --datarootdir=%{_datadir} \ --includedir=%{_includedir} \ --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} \ --enable-shared \ --with-common-dir=%{contentdir}/html/%{name} \ --with-database-dir=%{_sharedstatedir}/%{name} \ --with-cgi-bin-dir=%{contentdir}/cgi-bin \ --with-image-dir=%{contentdir}/html/%{name} \ --with-image-url-prefix=/%{name} \ --with-search-dir=%{contentdir}/html/%{name} \ --with-apache=/usr/sbin/httpd \ --with-default-config-file=%{_sysconfdir}/%{name}/%{name}.conf \ %build %make_build %install %make_install # install binary that was not included install -m 755 %{_builddir}/%{name}-%{version}/hlsearch/hlsearch %{buildroot}/%{_bindir} # add the service account install -p -m 644 -D %{S:1} %{buildroot}%{_prefix}/lib/sysusers.d/%{name}.conf # cron job mkdir -p %{buildroot}/%{_sysconfdir}/cron.daily cp %{S:2} %{buildroot}/%{_sysconfdir}/cron.daily/%{name}-dbgen # set up /var/www chmod 644 %{buildroot}%{contentdir}/html/%{name}/* ln -sf ./search.html %{buildroot}%{contentdir}/html/%{name}/index.html # migrate content to /usr/share and link it mkdir -p %{buildroot}%{_datadir} mv %{buildroot}%{contentdir}/html/hldig %{buildroot}%{_datadir} ln -s %{_datadir}/%{name} %{buildroot}%{contentdir}/html/%{name} %find_lang %{name} %post web # Only run this if installing for the first time if [ "$1" = 1 ]; then if [ -f %{_sysconfdir}/httpd/conf/httpd.conf ];then SERVERNAME="`grep '^ServerName' %{_sysconfdir}/httpd/conf/httpd.conf | awk 'NR == 1 {print $2}'`" fi [ -z "$SERVERNAME" ] && SERVERNAME="`hostname -f`" [ -z "$SERVERNAME" ] && SERVERNAME="localhost" sed 's/^start_url:.*/#&\ # (See end of file for this parameter.)/' %{_sysconfdir}/hldig/hldig.conf > /tmp/hl.$$ cat /tmp/hl.$$ > %{_sysconfdir}/%{name}/%{name}.conf rm /tmp/hl.$$ cat >> %{_sysconfdir}/%{name}/%{name}.conf <<! # Automatically set up by hldig RPM, from your current Apache httpd.conf... # Verify and configure these, and set maintainer above, before running # /usr/bin/rundig. # See /usr/doc/hldig*/attrs.html for descriptions of attributes. # The URL(s) where hldig will start. See also limit_urls_to above. start_url: http://$SERVERNAME/ # This makes sure that we don't spider the web local_urls_only: true # These attributes allow indexing server via local filesystem rather than HTTP. local_urls: http://$SERVERNAME/=%{contentdir}/html/ local_user_urls: http://$SERVERNAME/=/home/,/public_html/ ! fi %files -f %{name}.lang %license COPYING %doc README.md ChangeLog %{_bindir}/* %{_datadir}/%{name} %{_mandir}/man1/*.zst %{_mandir}/man8/*.zst %{_libdir}/%{name}/*.so %{_libdir}/%{name}_db/*.so %config(noreplace) %{_sysconfdir}/%{name}/cookies.txt %config(noreplace) %{_sysconfdir}/%{name}/hldig.conf %config(noreplace) %{_sysconfdir}/%{name}/HtFileType-magic.mime %config(noreplace) %{_sysconfdir}/%{name}/mime.types %files devel %{_includedir}/%{name} %{_includedir}/%{name}_db %{_libdir}/%{name}/*.a %{_libdir}/%{name}_db/*.a %files web %config(missingok, noreplace) %attr(0755,root,root) %{_sysconfdir}/cron.daily/%{name}-dbgen %{contentdir}/html/%{name} %{contentdir}/cgi-bin/* %{_prefix}/lib/sysusers.d/%{name}.conf ``` > I'm currently building openmandriva 5 packages using the common redhat spec files. It would be best to use the `cooker` branch if you are not already. The number versioning is primarily used for Rock which is the stable branch, and `cooker` has historically been the development/testing branch. We also have a developer chat that can be helpful if you need more realtime support. You can find a link to it on the OpenMandriva website. I hang out in that chat room, as well. As far as I know, it was bridged to other chat services like Libera and Telegram, but I don't think the former bridge is being maintained by Matrix anymore and Libera refuses to. > I will also upload the current packages so that you can test on your machine if you want. I will try in a virtual machine on my side. The best thing would be to submit the specs so we can build packages in ABF (Automated Build Farm). That is our primary build tool and it makes building and testing packages easier because we don't have to tie up our physical or virtual workstations after a good local build has been achieved. The rest would get sorted out as a part of testing `cooker`.

Hello, thanks for the hldig spec.

About TDE packages: I will finish building for OMV version 5, then commit the specs in our git repo.
Then I will do another build with OMV cooker, then commit again.

At this stage, you should be able to fork/copy/branch/anything useful for you to the TDE redhat spec files to create the OMV specific spec files, and submit them to the distribution ABF.

Hello, thanks for the hldig spec. About TDE packages: I will finish building for OMV version 5, then commit the specs in our git repo. Then I will do another build with OMV cooker, then commit again. At this stage, you should be able to fork/copy/branch/anything useful for you to the TDE redhat spec files to create the OMV specific spec files, and submit them to the distribution ABF.

About TDE packages: I will finish building for OMV version 5, then commit the specs in our git repo.
Then I will do another build with OMV cooker, then commit again.

Ideally, we would like the ability to test in cooker RC's or even current commits from a SCM for a project so we can spot potential issues for our Rolling release branch, ROME. Rock is basically for production environments that don't want to deal with possible breaking changes to toolsets or other types of focused use cases. I would have to get a final decision for when TDE could be implemented into Rock.

At this stage, you should be able to fork/copy/branch/anything useful for you to the TDE redhat spec files to create the OMV specific spec files, and submit them to the distribution ABF.

I made one of the decision makers aware of your efforts and we look forward to seeing the results. I don't feel confident that my changes are ready for a merge because they are not finished yet. Several of the distribution specific condition statements were removed because the plan was to handle all the spec files and just monitor the repo for version releases. There were also several BuildRequires: that needed to be renamed for OM. I don't know if that is leading to the symbol errors you mentioned. Please let me know what you are seeing and I can work with you to find a solution. I could also find a way to upload a repo (perhaps on SF) so it would be more convenient to share my current progress until it is merge worthy.

The only other issue I was seeing is building with ninja. Obviously, we would prefer faster build times in ABF and, while autotools had their day, we tend to avoid using it unless absolutely necessary. The major roadblock with using ninja when making packages is the RPATH settings. We also would get errors from TDE that the la files could not be found for several elements. I had planned on digging further into that but it may be more productive to find time to help with tqt3 and getting that to use CMake. It would make managing the spec a lot easier and I wouldn't have to modify some of the multiple sed statements to use clang.

> About TDE packages: I will finish building for OMV version 5, then commit the specs in our git repo. Then I will do another build with OMV cooker, then commit again. Ideally, we would like the ability to test in `cooker` RC's or even current commits from a SCM for a project so we can spot potential issues for our Rolling release branch, ROME. Rock is basically for production environments that don't want to deal with possible breaking changes to toolsets or other types of focused use cases. I would have to get a final decision for when TDE could be implemented into Rock. >At this stage, you should be able to fork/copy/branch/anything useful for you to the TDE redhat spec files to create the OMV specific spec files, and submit them to the distribution ABF. I made one of the decision makers aware of your efforts and we look forward to seeing the results. I don't feel confident that my changes are ready for a merge because they are not finished yet. Several of the distribution specific condition statements were removed because the plan was to handle all the spec files and just monitor the repo for version releases. There were also several `BuildRequires:` that needed to be renamed for OM. I don't know if that is leading to the symbol errors you mentioned. Please let me know what you are seeing and I can work with you to find a solution. I could also find a way to upload a repo (perhaps on SF) so it would be more convenient to share my current progress until it is merge worthy. The only other issue I was seeing is building with `ninja`. Obviously, we would prefer faster build times in ABF and, while `autotools` had their day, we tend to avoid using it unless absolutely necessary. The major roadblock with using `ninja` when making packages is the RPATH settings. We also would get errors from TDE that the `la` files could not be found for several elements. I had planned on digging further into that but it may be more productive to find time to help with `tqt3` and getting that to use CMake. It would make managing the spec a lot easier and I wouldn't have to modify some of the multiple `sed` statements to use clang.

The issue of the missing .la files is caused by the brp-remove-la-files cleanup script that is automatically called by packaging.

If you really need the .la files (does anything actually use libltdl?), %undefine __brp_remove_la_files in the spec file should help.

If it's just something in the build system looking for .la files, it would probably better to modify it to look for the .so files instead -- .la files are useless on anything that can handle dependencies between shared libraries (except where needed for interoperability with libltdl, but there it's usually easy, fast and painless to just replace the calls to ltdl_dlopen and friends with calls to regular dlopen).

The issue of the missing .la files is caused by the `brp-remove-la-files` cleanup script that is automatically called by packaging. If you really need the .la files (does anything actually use libltdl?), `%undefine __brp_remove_la_files` in the spec file should help. If it's just something in the build system looking for .la files, it would probably better to modify it to look for the .so files instead -- .la files are useless on anything that can handle dependencies between shared libraries (except where needed for interoperability with libltdl, but there it's usually easy, fast and painless to just replace the calls to ltdl_dlopen and friends with calls to regular dlopen).

If it's just something in the build system looking for .la files, it would probably better to modify it to look for the .so files instead -- .la files are useless on anything that can handle dependencies between shared libraries (except where needed for interoperability with libltdl, but there it's usually easy, fast and painless to just replace the calls to ltdl_dlopen and friends with calls to regular dlopen).

It won't load the DE (properly?) because the la files are not there. I haven't tested a build in a while because I was doing it locally and set up my own local repos so I could shorthand the dnf install commands.

> If it's just something in the build system looking for .la files, it would probably better to modify it to look for the .so files instead -- .la files are useless on anything that can handle dependencies between shared libraries (except where needed for interoperability with libltdl, but there it's usually easy, fast and painless to just replace the calls to ltdl_dlopen and friends with calls to regular dlopen). It won't load the DE (properly?) because the `la` files are not there. I haven't tested a build in a while because I was doing it locally and set up my own local repos so I could shorthand the `dnf install` commands.

The la files are still used in some places. We have been planning to remove their needs for some time. Unfortunately, I still did not find enough time to move forward in this task.

The `la` files are still used in some places. We have been planning to remove their needs for some time. Unfortunately, I still did not find enough time to move forward in this task.

The la files are still used in some places. We have been planning to remove their needs for some time. Unfortunately, I still did not find enough time to move forward in this task.

We both know that feeling. I would like to do more than just packaging, but there never seems to be enough time in the day.

> The `la` files are still used in some places. We have been planning to remove their needs for some time. Unfortunately, I still did not find enough time to move forward in this task. We both know that feeling. I would like to do more than just packaging, but there never seems to be enough time in the day.

Yes, indeed. But either way if the la files are still needed, %undefine __brp_remove_la_files in the spec should be good enough for now.

Yes, indeed. But either way if the la files are still needed, `%undefine __brp_remove_la_files` in the spec should be good enough for now.

t does not appear that I can upload files

@zeroability you are a Contributor, so you should be able to create a PR to submit code changes for review.

> t does not appear that I can upload files @zeroability you are a Contributor, so you should be able to create a PR to submit code changes for review.

Hello, I've finished building on OMV 5, and am currently building on cooker.
Currently I've pushed spec files in 'tde-packaging' repository, in 'r14.1.x' branch.

Packages that are not built on omv5 are:

keximdb (because missing koffice)
kmplayer (because missing koffice)
koffice (FTBFS)
kpilot (FTBFS)
kvirc (FTBFS)
piklab (FTBFS)
polkit-agent-tde (FTBFS)
wlassistant (no 'iw' library in openmandriva, so this package is probably useless anyways)

In order to build the few packages that require autotools, I need to set the following macros:

%dont_remove_libtool_files 1
%_disable_rebuild_configure 1

But I see @bero mentioned brp_remove_la_files , I should probably use that instead ?

Hello, I've finished building on OMV 5, and am currently building on cooker. Currently I've pushed spec files in 'tde-packaging' repository, in 'r14.1.x' branch. Packages that are not built on omv5 are: * keximdb (because missing koffice) * kmplayer (because missing koffice) * koffice (FTBFS) * kpilot (FTBFS) * kvirc (FTBFS) * piklab (FTBFS) * polkit-agent-tde (FTBFS) * wlassistant (no 'iw' library in openmandriva, so this package is probably useless anyways) In order to build the few packages that require autotools, I need to set the following macros: ``` %dont_remove_libtool_files 1 %_disable_rebuild_configure 1 ``` But I see @bero mentioned brp_remove_la_files , I should probably use that instead ?

Now I've installed tdebase in my OMV5 VM.

TDM is working, opening TDE session too.
But in the TDE session, when opening any TDE program, I get a lot of errors popup "Could not find mime type: XXX".

I guess something is wrong with libmagic ?

Now I've installed tdebase in my OMV5 VM. TDM is working, opening TDE session too. But in the TDE session, when opening any TDE program, I get a lot of errors popup "Could not find mime type: XXX". I guess something is wrong with libmagic ?

The following additional packages are failing to build on OMV cooker:

tdegraphics
gwenview
k3b

I've opened the tickets.

The following additional packages are failing to build on OMV cooker: * tdegraphics * gwenview * k3b I've opened the tickets.

@MicheleC:

@zeroability you are a Contributor, so you should be able to create a PR to submit code changes for review.

I'm still not comfortable with the specs as they are. I think @Francois is on the right track. If you want to have conditions for OMV in the already established specs just to keep things confined to one source, that is fine with me. There were only some minor modifications to the suite of packages to get as far as tdebase.

@Francois:

But I see @bero mentioned brp_remove_la_files , I should probably use that instead ?

I don't know what the end result would be. I just went through every spec in the suite for tdebase and either put in a condition to exclude when "%{distribution}" == "OpenMandriva Lx" or eventually just removed them from the specs entirely. It sounds like you have gotten farther with them as they are.

I guess something is wrong with libmagic ?

Our spec is here:
https://github.com/OpenMandrivaAssociation/file/tree/master

I don't really see anything that looks odd.

wlassistant ...

The iw package still exists. It just hasn't been built or updated for some time:
https://abf.openmandriva.org/build_lists/388984

As far as all the FTBFS issues, I will look for the issues and see if I can assist somehow.

@MicheleC: > @zeroability you are a Contributor, so you should be able to create a PR to submit code changes for review. I'm still not comfortable with the specs as they are. I think @Francois is on the right track. If you want to have conditions for OMV in the already established specs just to keep things confined to one source, that is fine with me. There were only some minor modifications to the suite of packages to get as far as `tdebase`. @Francois: > But I see @bero mentioned brp_remove_la_files , I should probably use that instead ? I don't know what the end result would be. I just went through every spec in the suite for `tdebase` and either put in a condition to exclude when `"%{distribution}" == "OpenMandriva Lx"` or eventually just removed them from the specs entirely. It sounds like you have gotten farther with them as they are. > I guess something is wrong with libmagic ? Our spec is here: https://github.com/OpenMandrivaAssociation/file/tree/master I don't really see anything that looks odd. > * wlassistant ... The `iw` package still exists. It just hasn't been built or updated for some time: https://abf.openmandriva.org/build_lists/388984 As far as all the FTBFS issues, I will look for the issues and see if I can assist somehow.

I'm pretty sure libmagic is ok, it works for everything else. If you have any reproducer for a libmagic problem, let me know and I'll take a look.

Undef-ing brp_remove_la_files and setting dont_remove_libtool_files should have the same effect.

Do you have build logs of the failed builds?

I'm pretty sure libmagic is ok, it works for everything else. If you have any reproducer for a libmagic problem, let me know and I'll take a look. Undef-ing brp_remove_la_files and setting dont_remove_libtool_files should have the same effect. Do you have build logs of the failed builds?

@bero:

Do you have build logs of the failed builds?

TDE/koffice#70
TDE/kpilot#25
TDE/kvirc#24
TDE/piklab#18
TDE/polkit-agent-tde#5
TDE/tdegraphics#96
TDE/gwenview#38
TDE/k3b#44

@bero: > Do you have build logs of the failed builds? https://mirror.git.trinitydesktop.org/gitea/TDE/koffice/issues/70 https://mirror.git.trinitydesktop.org/gitea/TDE/kpilot/issues/25 https://mirror.git.trinitydesktop.org/gitea/TDE/kvirc/issues/24 https://mirror.git.trinitydesktop.org/gitea/TDE/piklab/issues/18 https://mirror.git.trinitydesktop.org/gitea/TDE/polkit-agent-tde/issues/5 https://mirror.git.trinitydesktop.org/gitea/TDE/tdegraphics/issues/96 https://mirror.git.trinitydesktop.org/gitea/TDE/gwenview/issues/38 https://mirror.git.trinitydesktop.org/gitea/TDE/k3b/issues/44

I have created meta issue TDE/tde#171 to keep track of all issues and PRs related to adding support for OMV.

Both the .spec and the .pro files hard define the compiler to gcc.
89ebbd272b/redhat/dependencies/tqt3/tqt3.spec (L54)

486211a79e/mkspecs/linux-g++-64/qmake.conf (L14)

486211a79e/mkspecs/linux-g++-64/qmake.conf (L32)

Initiated by:
89ebbd272b/redhat/dependencies/tqt3/tqt3.spec (L1393)

There should probably be a check similar to how I define it in the spec I modified instead of assuming the compiler:

%global c_compiler %(readlink /usr/bin/cc)
%global cpp_compiler %(readlink /usr/bin/cpp || readlink /usr/bin/cc)
...

%if "%{?cpp_compiler}" == "clang" || "%{?c_compiler}" == "clang"
  -e "s|^QMAKE_CXX		=.*|QMAKE_CXX		=	 clang++|" \
  -e "s|^QMAKE_LINK		=.*|QMAKE_LINK		=	clang++|" \
  -e "s|^QMAKE_CC		=.*|QMAKE_CC		=	clang|" \
  -e "s|^QMAKE_LINK_SHLIB		=.*|QMAKE_LINK_SHLIB		= clang++|"
%endif

I have tried removing the option -platform linux-g++-64 but other options break as a result. I also realize these will become trivial when tqt3 is migrated to CMake.

Both the `.spec` and the `.pro` files hard define the compiler to `gcc`. https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/commit/89ebbd272bbf26e75642908900d064ac3ec50cb8/redhat/dependencies/tqt3/tqt3.spec#L54 https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/src/commit/486211a79e4aa9cf6fce7a72676ed3e76ba35a23/mkspecs/linux-g++-64/qmake.conf#L14 https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/src/commit/486211a79e4aa9cf6fce7a72676ed3e76ba35a23/mkspecs/linux-g++-64/qmake.conf#L32 Initiated by: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/commit/89ebbd272bbf26e75642908900d064ac3ec50cb8/redhat/dependencies/tqt3/tqt3.spec#L1393 There should probably be a check similar to how I define it in the spec I modified instead of assuming the compiler: ``` %global c_compiler %(readlink /usr/bin/cc) %global cpp_compiler %(readlink /usr/bin/cpp || readlink /usr/bin/cc) ... %if "%{?cpp_compiler}" == "clang" || "%{?c_compiler}" == "clang" -e "s|^QMAKE_CXX =.*|QMAKE_CXX = clang++|" \ -e "s|^QMAKE_LINK =.*|QMAKE_LINK = clang++|" \ -e "s|^QMAKE_CC =.*|QMAKE_CC = clang|" \ -e "s|^QMAKE_LINK_SHLIB =.*|QMAKE_LINK_SHLIB = clang++|" %endif ``` I have tried removing the option `-platform linux-g++-64` but other options break as a result. I also realize these will become trivial when `tqt3` is migrated to CMake.

Hello, here is the updated status of TDE 14.1.3 packages build on OpenMandriva:

OpenMandriva 5: All packages are buildable, except:
kvirc : TDE/kvirc#24
pinentry-tqt (need to rebase on upstream 1.3.1)
wv2 (koffice is buildable without msword support)

OpenMandriva Cooker: All packages are buildable, except:
keximdb (requires koffice)
kmplayer (requires koffice)
koffice : TDE/koffice#78
kvirc : TDE/kvirc#24
pinentry-tqt (need to rebase on upstream 1.3.1)
wv2

Hello, here is the updated status of TDE 14.1.3 packages build on OpenMandriva: OpenMandriva 5: All packages are buildable, except: kvirc : https://mirror.git.trinitydesktop.org/gitea/TDE/kvirc/issues/24 pinentry-tqt (need to rebase on upstream 1.3.1) wv2 (koffice is buildable without msword support) OpenMandriva Cooker: All packages are buildable, except: keximdb (requires koffice) kmplayer (requires koffice) koffice : https://mirror.git.trinitydesktop.org/gitea/TDE/koffice/issues/78 kvirc : https://mirror.git.trinitydesktop.org/gitea/TDE/kvirc/issues/24 pinentry-tqt (need to rebase on upstream 1.3.1) wv2

Is there a more up-to-date version of wv2 than the official version from 15 years ago?

https://sourceforge.net/projects/wvware/files/

Perhaps there is a better solution.

It also appears that kvirc could have the same fix that koffice does.

Is there a more up-to-date version of `wv2` than the official version from 15 years ago? https://sourceforge.net/projects/wvware/files/ Perhaps there is a better solution. It also appears that `kvirc` could have the same fix that `koffice` does.

@Francois Have you tried wv2 from the extra dependency repo? it is the original debian version + a number of patches. Perhaps it works also for OMV?

Also looking at TDE/tde#171, there are some issues open on k3b, kpilot and tdebindings, but I noticed that you didn't list them as non-buildable in the above comment. Are those open issues still valid?

@Francois Have you tried `wv2` from the extra dependency [repo](https://mirror.git.trinitydesktop.org/gitea/TDE/extra-dependencies/src/branch/master/debian/wv2)? it is the original debian version + a number of patches. Perhaps it works also for OMV? Also looking at TDE/tde#171, there are some issues open on k3b, kpilot and tdebindings, but I noticed that you didn't list them as non-buildable in the above comment. Are those open issues still valid?

Hello @MicheleC , k3b was fixed in TDE/k3b repository, so the ticket and PR can be closed.

kpilot and tdebindings still require the patches that are proposed in respective PRs.

@zeroability, about wv2, I tried source code + patches from various sources (including from our 'extra-dependencies' repo), but it always fails in cmake step during readline library detection. I will open a dedicated ticket for that.

Hello @MicheleC , k3b was fixed in TDE/k3b repository, so the ticket and PR can be closed. kpilot and tdebindings still require the patches that are proposed in respective PRs. @zeroability, about wv2, I tried source code + patches from various sources (including from our 'extra-dependencies' repo), but it always fails in cmake step during readline library detection. I will open a dedicated ticket for that.

I created this issue in case further testing was needed with the version we have in our repos:

TDE/tdegraphics#105

At the moment it is probably just a version issue in the spec, unless there are untested or removed features in newer versions of poppler:

Poppler support enable condition:
e83210ce6f/redhat/core/tdegraphics/tdegraphics.spec (L236-L253)

tdegraphics poppler requirement condition:
e83210ce6f/redhat/core/tdegraphics/tdegraphics.spec (L313-L315)

Poppler packages recipe:
e83210ce6f/redhat/core/tdegraphics/tdegraphics.spec (L964-L1010)

I created this issue in case further testing was needed with the version we have in our repos: https://mirror.git.trinitydesktop.org/gitea/TDE/tdegraphics/issues/105 At the moment it is probably just a version issue in the spec, unless there are untested or removed features in newer versions of poppler: Poppler support enable condition: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/commit/e83210ce6fd02a26ea5ec9c3ac8eb26817453a4b/redhat/core/tdegraphics/tdegraphics.spec#L236-L253 tdegraphics poppler requirement condition: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/commit/e83210ce6fd02a26ea5ec9c3ac8eb26817453a4b/redhat/core/tdegraphics/tdegraphics.spec#L313-L315 Poppler packages recipe: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/commit/e83210ce6fd02a26ea5ec9c3ac8eb26817453a4b/redhat/core/tdegraphics/tdegraphics.spec#L964-L1010

Labels Milestones

Distribution Packaging - OpenMandriva Lx #303