help Slackware maintainers to package XQF

[illwieckz]

Reading the very old documentation I found that there was a Slackware packager for XQF in the past.

It seems the current Slackware package is stuck on 1.0.5.

[Xylemon]

I found an old SlackBuild (I think it came from SlackBuilds.org) that I actually fixed up for 1.0.6. It has a patch which adds custom icons, but I can remove it. When XQF 1.0.7 releases, just let me know and I'll look into it (since you guys seems to be changing the build process and all that nonsense).

[illwieckz]

Ah, it's nice if you can help on that! Are you using Slackware yourself?

I've sent an email to Erik Jan Tromp (the one the documentation said he has packaged XQF in the past), but I don't know if he will be interested on it today!

[Xylemon]

Yes I run Slackware 14.1 with current packages. I would not have problems with submitting a SlackBuild to SlackBuilds.org starting with 1.0.7. Not a package exactly, but a convenient way to build it (similar to Arch's pkgbuild or Gentoo's emerge but more manual).

[Xylemon]

Update on this, I've gotten the latest commit to compile nicely into a Slackware package. I have some questions though, since this uses cmake and the compiling options are different, how would I add these to the cmake command:
--sysconfdir=/etc
--mandir=/usr/man
?

[vorot93]

--sysconfdir=/etc

Hm, what do you need this for? XQF does not store any settings there.

--mandir=/usr/man

See #160

[Xylemon]

"Hm, what do you need this for? XQF does not store any settings there."

This was a configured option in the original SlackBuild, but it seems all XQF configurations are in the home folder so I suppose it's unnecessary.

I also have a WIP SlackBuild: http://pastebin.com/NiuMTCGH

Note: This doesn't seem to actually copy any of those files into the "doc" folder. Need to investigate as to why. I haven't made my custom icons optional yet, and I'm only naming the version "20150622" because I'm just testing each git commit. Whenever 1.0.7 releases I'll add that as the version to compile. There also needs to be compile options for 32-bit users.

Any critiques are welcome.

[illwieckz]

Hmm @skybon, the copying of README files in a doc/ directory must be done by cmake too. 😉

[jmallach]

I don't think so. It's not the usual behaviour at least...

On 23 juny de 2015 6:37:25 CEST, Thomas Debesse [email protected] wrote:

Hmm @skybon, the copying of README files in a doc/ directory must
be done by cmake too. 😉

---

Reply to this email directly or view it on GitHub:
#152 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[illwieckz]

It's not the usual behaviour at least...

Hi Jordi, 😀

Previously, autotools made some implicitely stuff about AUTHORS, NEWS, COPYING an README files. Because of this by-default implicit behavior I've wrote some workaround in the past since some files does not have today the name expected by autotools (like NEWS.md instead of NEWS), this implicit behavior was annoying because we were not really controlling what were done.

Before running autogen.sh:

$ grep -R README .
./.gitignore:README
./autogen.sh:if ! test -e README; then
./autogen.sh:   ln -s README.md README

After running autogen.sh

$ grep -R README .
./src/zip/Makefile.in:DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in
./.gitignore:README
./autogen.sh:if ! test -e README; then
./autogen.sh:   ln -s README.md README
./Makefile.in:DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
./INSTALL:more-detailed instructions are generic; see the `README' file for
./INSTALL:diffs or instructions to the address given in the `README' so they can
./INSTALL:`README' should mention any `--enable-' and `--with-' options that the

After running generated configure:

./src/zip/Makefile.in:DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in
./src/zip/Makefile:DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in
./.gitignore:README
./autogen.sh:if ! test -e README; then
./autogen.sh:   ln -s README.md README
./Makefile.in:DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
./Makefile:DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
./INSTALL:more-detailed instructions are generic; see the `README' file for
./INSTALL:diffs or instructions to the address given in the `README' so they can
./INSTALL:`README' should mention any `--enable-' and `--with-' options that the

As you see, the only lines about README installation before running autotools were about to workaround autotools default behavior. After running autotools, there was an explicitly README related line in Makefile.in, and an INSTALL file were created, naming explicitly the README file (so the README file is implicitly needed by autotools).

Without my workaround, autogen.sh ended up like that:

Makefile.am: installing `./INSTALL'
Makefile.am: required file `./NEWS' not found
Makefile.am: required file `./README' not found
Makefile.am: required file `./AUTHORS' not found

But if these files were needed bu autotools, it seems that installation of these files were not needed by autotools but by the xqf.spec file itself (so it seems it was an usual feature).

So, it was usual to install them (in /usr/share/doc/xqf/), but yes it seems that Debian never installed them and we can decide to never install them, I'm fine with that.

[Xylemon]

After reviewing some other SlackBuilds and templates off SBo, I can safely say I have a SlackBuild ready for the next XQF release. I can also go on a clean machine and compile a package (if desired) for 64-bit machines.

Just two questions, is GeoIP an optional or required dependency? And besides minizip, what other dependencies are there?