Optional configuration file about snoopy

[bostjan]

Done, in 2.0.0rc6.

[jwbrown77]

Hi Bostjan,

I've been attempting to build an RPM from your latest sources for a few days now, and in RC7 and RC9, the install phase fails because it cannot locate snoopy.ini in the sources.

The file exists on Github under /etc/snoopy.ini. But if I decompress the rc9 tarball manually, that file doesn't exist in /etc.

Am I missing something or should the file be included in the tarball?

Thanks

[bostjan]

Whoa, an obvious bug. I was sure I included it in Makefile.am, I guess I was just thinking about it very hard too many times AFK.

Fixed in freshly-released 2.0.0rc10.

PS: Also: fixed the outstanding issue of config file being installed despite not being enabled by ./configure flag.

[bostjan]

Please do report back with the result.

[bostjan]

Also, a question:
Which distro are you using? Are you using contrib/sles/snoopy.spec, spec file from snoopy-1.7.10-1.el6.src.rpm or did you brew your own?

I would not mind having redhat snoopy.spec file in contrib/redhat/snoopy.spec. SuSE is already there, Debian/Ubuntu build is being prepared, RH and derivates are another major distribution for which having spec file at hand would be - well - handy :)

b.

[jwbrown77]

Hi Bostjan,

Thank you for your prompt fix. I have successfully built an RPM and have verified it works. I am only testing this on CentOS 7.0.

FYI, I have also requested that someone maintain Snoopy in EPEL-7, as it is currently not included there. Until then, I guess I will build my own RPMs. Here is the link: https://bugzilla.redhat.com/show_bug.cgi?id=1154859

I'd be happy to share my SPEC file. Do you want it as a pull request, or should I e-mail it to you?

Thanks

[bostjan]

Hi Jeremy,

I prefer pull requests, as it clearly shows who is the contributor of specific feature. And thanks for your contribution ;)

Also, please make sure that uninstall method removes snoopy from ld.so.preload, otherwise loads of errors are displayed. I will add this to snoopy distribution now (make disable and additional snoopy-disable script) so you can use those tools for it.

B.

[jwbrown77]

Hi Bostjan,

I personally have it setup where on install, it doesn't modify ld.so.preload at all, as I personally feel that should be done manually on an as needed basis. I can see your point where if you were to remove snoopy, it would cause errors if you forgot to also disable it in ld.so.preload.

What do you think is the ideal way to handle both install and uninstall?

Thanks

[bostjan]

Well, for uninstall it is clear: first it should remove entry from /etc/ld.so.preload, followed by files removal.

For installation it is more the matter of opinion. Generally if user finds snoopy and likes its functionality, doing "PKGMANAGER install snoopy" most likely means that user want functional snoopy installed (that is: installed+enabled). Generally user that uses these package managers wants hassle-free installation. Personally I hate that I have to "chkconfig service X" after I have already installed all packages relevant to that service.

My opinion?

1. distro-based package managers should also enable it, by default
2. if custom compilation is done from sources, then it should not be enabled by default

b.

[jwbrown77]

Hi Bostjan,

Fair enough. Thanks for your input.

Can you please confirm there is no existing script that "enables" and "disables" snoopy so I don't duplicate effort?

Thanks

[bostjan]

There WAS no existing enable/disable scripts, but there are now, in rc11, and also a 'make disable' target.

Scripts get installed as PREFIX/sbin/snoopy-enable and snoopy-disable.

b.

[jwbrown77]

Hi Bostjan,

Thank you for taking care of that. I just wanted you to know I saw your change, but my work today has precluded me from looking at it.

I'll either let you know if I have trouble, or submit a pull request with a SPEC file, as soon as I can.

Thanks

[bostjan]

Cool, no need to hurry, the repo is not going anywhere :)

b.

[jwbrown77]

Hi Bostjan,

Sorry for the late reply. I've been working on this today and have run into a snag. /usr/sbin/snoopy-enable fails because the LIBDIR variable in the script is empty:

### Where is the library installed?
#
LIBDIR=""

Unfortunately, I'm not well versed in autoconf and can't make out why it's not being set in my build environment (CentOS 7.0). All I can see is that SNOOPY_LIBDIR is supposed to be populated off a variant of the libdir variable, but I can't tell why that's not being set.

For what it's worth, the library path in my environment winds up in /usr/lib64.

I could fairly easily fix the variable with sed, but I don't know if that's the preferable way to do it.

Let me know if you have any input. If you think it's ok for me to perform a fixup with sed right in the RPM spec, that's ok for me too.

Thanks

[bostjan]

Jeremy,

What ./configure arguments are you using?

[bostjan]

Found the faulty SED expression, fixed, pushed. Sorry for inconvenience, should be working now.

Though I would still like to see your configure line, if possible.

Autotools: yeah, they did cost me more-a-than-single-digit hours to understand them (a bit) and bind them towards snoopy architecture. They are quite useful once you are familiar with them, but up to that point it was a bit hellish :) If I may be so bold, snoopy is fairly trivial program and thus autoX configurations are quite simple.
Usually the first time you see all the files in some package, you think "whoa!". But in reality all you need to pay attention to is configure.ac and Makefile.am(s), and autogen.sh (lately the only important part is autoreconf). Everything else is generated from there.
With snoopy, autotools configuration occupies around 500 lines of code. If newlines were not used for each list item everywhere, it would be probably around 300.

b.

[jwbrown77]

Hi Bostjan,

I'm just using the "%autosetup" SPEC value, so I'm not setting the configure line manually. But according to the config.log, the result winds up being:

./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info

I'll wait for you to release a new RC then re-try building. Thanks for the tips on autotools; I'll keep them in mind when debugging in the future.

Thanks

[bostjan]

rc12 out.

b.