On 2017-08-18 22:55, Dave Howorth wrote:

On Fri, 18 Aug 2017 22:25:02 +0200 "Carlos E. R." <> wrote:

...

Er... wait. You do not need the source code of mysql for this; what you need is a package that could be named mysql-devel or mariadb-devel or something like that. It should contain the header files that you need, and in the proper directories for the Bacula configure script to find them.

One might hope it was in a package suggested or recommended by the bacula source package?

No... I have never seen that. You will need a number of *-devel packages that you will have to guess their names. Consider that Bacula doesn't know if you are going to modify the sources of the other packages; ie, doesn't know if you need -devel or sources. Yes, the hints by configure are sometimes very obscure. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Hello,

On Fri, 18 Aug 2017, Carlos E. R. wrote:

...

On 2017-08-18 21:56, Marc Chamberlin wrote:

...

I am not sure if I should ask these questions here or on the developers mail list, but will start here and will move this over to the other mail list if told that it would be more appropriate. (I don't want to bother the developers with beginner's questions)

I am attempting to build Bacula (a backup server) from source code and in order to do so, the build configuration for Bacula requires that I give it the path to the source code files for mysql. (or in the case of openSuSE mariadb) I figured out that I could use zypper si mariadb to fetch the source code from the openSuSE repositories. (for some reason YaST is unable to fetch source code packages, which I posted and earlier query about, Er... wait. You do not need the source code of mysql for this; what you need is a package that could be named mysql-devel or mariadb-devel or something like that. It should contain the header files that you need, and in the proper directories for the Bacula configure script to find them.

Try that way, and undo the other things you did ;-) Right!

Marc, just install the needed -devel packages, and all will be fine. Thanks for the responses Carlos, Dave Howorth, and David Haller. Normally I would agree with all of you that all I should need to compile Bacula is to install the needed -devel packages and in fact that was exactly what I tried in my first attempts. That is the normal modus operandi. But I kept getting errors when I would run either the Bacula configuration script or the Bacula make. And on investigation I discovered that Bacula's build process wants all the source .c files for mysql and it is indeed trying to compile them as part of the build

On 08/18/2017 03:48 PM, David Haller wrote: process for Bacula. I too was surprised by this. The -devel packages alone are insufficient, and in fact the Bacula documentation says that I have to download the source code files for mysql, install them somewhere, and then tell the Bacula config where they were installed. I don't want the source code to be inconsistent with what openSuSE installs for mariadb so I am trying to install the source files in the YaST/zypper way. Question - If I have to build mariadb from source, is there documentation/instructions on how to do so for Leap42.3? I am finding generic instructions but I am not sure those instructions are applicable to the way the source code directories are laid out after I expanded the tar.gz file I downloaded from the openSuSE repository. David Haller - I am totally impressed that you made such an effort and took the time to try and explain autotools to me. It will take me awhile to grok everything you said but you certainly have me intrigued! I am not sure where you are headed though, are you saying that mariadb/mysql was built using autotools? From my preliminary glance at the source code it seems to me that it was built using cmake. But my eyes are not trained or up to speed on C/C++ build processes any more so take that comment with a chunk of salt! I guess another way to ask my question is -are you inferring that because there are .h.in files in the mariadb source code directories that mariadb was built using autotools? Or are you saying that I should try and use autotools to create a build process for Bacula? Thanks again for all your helpful suggestions, Marc...

But about those .in, .am or even the .in.in files (usually in the po/ subdir), it goes basically like this:

autoheader generates config.h.in from stuff in configure.ac, Automake/whatnot generate .in files from .am, autoconf generates configure (and .in from .in.in, IIRC) from configure.ac, and configure generates Makefiles, config.h and stuff from the .in files.

Actually, for once, I've no idea what the .in stands for. It is a template though, where usually configure replaces @FOO@ by the expansions of the variables concering foo, as it has determined it while it ran. It's just a big e.g.

[..] ac_cv_FOO = foo [..] ac_cv_BAR = bar [..] sed -e "s/@FOO@/${ac_cv_FOO}/" -e "s/@BAR@/${ac_cv_BAR}/" ...

at the end of the configure script running over all AC_OUTPUT files.

All that gets put into config.h[.in] is derived from configure.ac by autoheader, as you check there for specific headers with the AC_HEADER macros.

So, what starts out as e.g. three few-line files (configure.ac/Makefile.am/actual source) can generate a _selfcontained_ build supporting the classic

configure && make && make install

Heck, even a make dist works and produces a hello-0.1.tar.gz in the case shown below.

E.g.:

$ ls -l -rw-r----- 1 dh dh 21 Aug 18 22:44 Makefile.am -rw-r----- 1 dh dh 85 Aug 18 22:47 configure.ac -rw-r----- 1 dh dh 77 Aug 18 22:42 hello.c

$ for f in *; do echo " === $f ==="; cat "$f"; done; echo " ===" === Makefile.am === bin_PROGRAMS = hello === configure.ac === AC_INIT([hello], [0.1]) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_OUTPUT(Makefile) === hello.c === #include <stdio.h> int main(void) { printf("Hello World\n"); return 0; } ===

Jep, 5 lines of "build-system"... Were it more source-files build and the *.o then linked, I'd just add _one_ extra line, to Makefile.am:

hello_OBJS := $(patsubst %.c, %.o, $(wildcard *.c))

In both cases, follow it by

$ autoreconf -fi $ ./configure $ make

and check it out:

$ ./hello Hello World

$ make dist $ tar tzf hello-0.1.tar.gz

's all as if by Magic ;)) Yep, 5-6 lines of "code" (4 "m4" macros and 1-2 make variables) is all it takes. Compare that to cmake and whatnot...

Usually, when you see "huge" configure.ac, they're almost always reinventing the wheel somewhere, usually as something more like an oktogon or something even cruder, as seen in the Flintstone cartoons... Basic rule: big configure.ac -> bad configure.ac.

Using the intended macros for finding stuff from the package via aclocal? Using the pkg-config macros? Naahh, NIH!!!!! .... they're too hip for that.

cmake-itis is what springs to my mind at that, each package has it's own "FindFoo.cmake" bullshit. Which usually does not work (too old or too new), be it on current Leap 42.2, on oS 12.1 or bleeding edge Gentoo. *GAH*. Only works occasionally.

Those who do not understand autotools are doomed to reinvent it. Badly... and have been doing so. Never been so true than with all those newfangled buildsystems. Well, ok, I'm glad imake/xmkmf is dying out, that was crude and inflexible[0]. But apart from that? *bwah*

Yes, autotools can be a PITA, but, used right and as intended, it's very efficient and manageable, esp. also for "downstream" packagers, who just need to call configure with an option, export a variable like CFLAGS for configure (or make) or some such. It's easy for downstream to mangle if need be. At least as easy as a plain Makefile'd be. A clean autotools setup is much more manageable that a convoluted Makefile forest. Darn, what's that project I dug through recently? Just plain Makefiles, but scatterd included files, some generated, some not all over the tree... Probably some Mozilla and/or LibreOffice or something else ;)

Anyway, when autotools is used correctly (e.g. using (predefined or locally defined) macros via aclocal), it is very efficient (for the dev and the packager, not sooo much for the user, the configure does take a bit of time firing up all those external processes to check for stuff ;)

The only real improvement I can come up with though is how "AC_OUTPUT()" can be defined, e.g. I miss wildcarding there. Haven't looked into that for about a decade though). And then again, that can be generated if need be via something like "find . -type f \( -name '*.in' -o -name '*.am' \) .....

Actually, to be "über"-correct, I should have tested for stdio.h availabiliy and printf in the above minimal sample. The former would be done via AC_CHECK_HEADER, and the result of that check would land in config.h (via config.h.in).

Just try it out ;) For functions, it's not surprisingly AC_CHECK_FUNC.

So, two more lines, but for such basic stuff as stdio.h and printf?

Hey, if _THAT_ is missing, the user has quite different problems. Well, maybe check the header, as the user might not have the -devel package installed etc.

All AC_* documented in 'info autoconf', all AM_* in 'info automake', generally, the autotools use info. Use any info-reader like pinfo, emacs, tkinfo, konqueror, whatever.

And with cmake, I've been forced to patch "Module" files in /usr/{share,lib*}/cmake/modules or wherever it is, or vice versa prune/patch package supplied .cmake module-files. I'ts just a mess from the get-go. With autotools, worst case is "patch and run aclocal (the "local" in the name, could that have a reason?? ;) (or just autoreconf to catch all). And with autotools, you can patch _any_ stage. I've e.g. _never_ had to touch any system aclocal files. Ever. And don't get me started on qmake.

With autotools, all you'd possibly need to patch is _inside_ the target-source tarball. End of story. At times it takes a bit of digging (use mc for stuff like that!), but often it's just as trivial as exporting a variable before calling configure or make.

Anyway: I understand _everybody_ that does not like autotools. But then I ask: what are the alternatives? And I as both a (small-stuff for private use) developer and routined packager, I hate autotools the least. On a scale from 1 to 10 of "hate", I'd say autotools is about a 2. Perl's ExtUtils::MakeMaker and Build about a 1.75, but everything else well exceeds the 6. And cmake is right at the top. at, say, 9.5, with the .5 for the fancy progress in percent feature. imake/xmkmf would be an 8ish, qmake a flat-out 10 ... You get the gist. Oh, and that uber-newfangled stuff barging in along nodejs and other crap?

That stuff would make the scale explode (20+ minimum). Just have a look at what "gradle" needs to just run ... And using nodejs is basically bending over in prison and shouting "atta boys!", without even the "dropping the soap" act... But if you like that kind of stuff, be me guest, but leave me out of it (and that's not because I can't dig "kinky"... You might consider stuff I do as quite kinky. But I'm not that kinky. Or not that kind of. ;)

-dnh, building packages for well over 15 years, locally and (when it became available) in the OBS, often with quite some years out of "sync" stuff in either direction (e.g. new libs on old platform or old stuff on new platform). And oftentimes helping others build stuff. E.g. mangle a KDE foo thingy qmake build to actually build as wanted. What a tiring exp. that was. Wildly patching .pri, .pro, .whatnot ... That must've been quite an exceptional(ly ...) mind that has come up with all that...

[0] as opposed to autotools. Those might still be considered crude and "bruteforce", generating those tons of shell-code, but they're very flexible, manageable, malleable, patchable, env-overridable ...

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 18 Aug 2017, Marc Chamberlin wrote:

On 08/18/2017 03:48 PM, David Haller wrote:

...

On Fri, 18 Aug 2017, Carlos E. R. wrote:

...

On 2017-08-18 21:56, Marc Chamberlin wrote:

...

I am attempting to build Bacula (a backup server) from source code and in order to do so, the build configuration for Bacula requires that I give it the path to the source code files for mysql. (or in the case of openSuSE mariadb) I figured out that I could use zypper si mariadb to fetch the source code from the openSuSE repositories. (for some reason YaST is unable to fetch source code packages, which I posted and earlier query about,

See below for that.

Question - If I have to build mariadb from source, is there documentation/instructions on how to do so for Leap42.3?

Just get the source-package, and rpm-rebuild it. But you do not need that for bacula. For bacula, you could have a look at existing builds, e.g.: https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/b...

David Haller - I am totally impressed that you made such an effort and took the time to try and explain autotools to me. It will take me awhile to grok everything you said but you certainly have me intrigued! I am not sure where you are headed though, are you saying that mariadb/mysql was built using autotools? From my preliminary glance at the source code it seems to me that it was built using cmake. But my eyes are not trained or up to speed on C/C++ build processes any more so take that comment with a chunk of salt!

You're quite correct, it's just that .in files are typical of autotools. But actually, mariadb uses cmake (but got tons of third-party stuff using autotools bundled), and the template is not named config.h.in but config.h.cmake ;) So, instead of "./configure" you'd have to run "cmake ." (just look at the specs of each package for how exactly. Bacula though does use autotools, and I hope my little "rant" helps you to start to understand how _bacula_ is being built. As a user though, you just need to run './configure && make && make DESTDIR=foo install' But when you're building packages, it helps a lot to understand how stuff works, be it autotools, cmake, qmake or whatnot. They all suck.

I guess another way to ask my question is -are you inferring that because there are .h.in files in the mariadb source code directories that mariadb was built using autotools?

Nope. But there's a bunch of sub-dirs and third_party stuff that is build using autotools. Or at least has .in files. Or even .cmake.in... Quite complex stuff.

Or are you saying that I should try and use autotools to create a build process for Bacula?

Nope, it already has one, though the source files (configure.{ac,in} etc.) are moved off to the './autoconf/' subdir of the sources. E.g.: bacula-9.0.3/autoconf/config.h.in bacula-9.0.3/autoconf/configure.in etc. And I don't think you actually need the mariadb source, just all the -devel packages (including mysql.h and mysql_version.h). libmysqlclient18-10.0.30-21.1.x86_64 libmysqlclient-devel-10.0.30-21.1.x86_64 libmysqlclient_r18-10.0.30-21.1.x86_64 I've just tried, I got the home:Ximi1970:openSUSE:Extra/bacula package, added the current bacula-9.0.3.tar.gz, changed the version in the bacula.spec to 9.0.3 and ran 'osc build ...' for 42.3... Built just fine. I haven't looked at anything more in the .spec file, there might be some more work in order ;) Yeah right, e.g. dvd-handler is not installed anymore, and stuff is installed but not packaged. No idea what it's all for, so I just stuffed it in the -common package, just so _those_ packaging errors are "ignored", but those should be properly looked over, so I don't mail these changes. And, lo and behold, except that "mispackaging" I just mentioned, the package builds (not the first build, but with "--no-init" and "ccache" active, that's why it's so fast ;) [ 78s] 11 packages and 0 specfiles checked; 0 errors, 121 warnings. $ ls -1 /data/build/openSUSE_Leap_42.3-x86_64-root/home/abuild/rpmbild/RPMS/x86_64/ bacula-client-9.0.3-1.x86_64.rpm bacula-common-9.0.3-1.x86_64.rpm bacula-console-9.0.3-1.x86_64.rpm bacula-console-bat-9.0.3-1.x86_64.rpm bacula-director-9.0.3-1.x86_64.rpm bacula-lang-9.0.3-1.x86_64.rpm bacula-mysql-9.0.3-1.x86_64.rpm bacula-postgresql-9.0.3-1.x86_64.rpm bacula-sqlite3-9.0.3-1.x86_64.rpm bacula-storage-9.0.3-1.x86_64.rpm For all the nitty gritty details of properly packaging these new/non-installed files right, I'd say asking on opensuse-packaging is in order, and/or expressly ask Ximi1970 for assistance. Maybe you two can maintain the package together ... Anyway, your problems have nothing to do with not having the mariadb sources (and those configured via calling 'cmake')... Feel free to ask on -packaging, for details about the bacula stuff, but also about build-systems like autotools, cmake etc. generally... HTH, -dnh -- If you're looking for me, I'll be the quivering pile of jelly wobbling pitifully in the corner over there. -- Stuart Lamble -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2017 12:59 AM, Per Jessen wrote:

Marc Chamberlin wrote:

...

I am not sure if I should ask these questions here or on the developers mail list, but will start here and will move this over to the other mail list if told that it would be more appropriate. (I don't want to bother the developers with beginner's questions) There is also an opensuse-programming list, but it's not very active.

...

I am attempting to build Bacula (a backup server) from source code and in order to do so, the build configuration for Bacula requires that I give it the path to the source code files for mysql. If you want to compare notes, this is what I just did - on a vanilla 423 system:

download bacula tarball from sourceforge, version 9.0.3 untarred into ~/workspace/

installed gcc, gcc-c++,libmysqlclient-devel,libacl-devel, gcc, gcc-c++ (with zypper)

in ~/workspace/bacula-9.0.3 I ran

./configure --prefix=/usr --with-mysql make -j4

Takes about 50seconds to builds

Thanks Pers, well I think you might have put me on the right track, nice to see it done through a fresh set of eyes! I had been using the default config file (with modified paths that suited my environment) that Bacula supplies in their example directory, that their installation instructions recommended. Within that config file there were two options -     --enable-static-tools \     --disable-libtool \ and on a hunch, after seeing how you had successfully built Bacula, I decided to remove these two options. And it worked! (at least it compiles OK) I don't grok what these options do exactly, or why Bacula recommends using them, I was simply doing my best to follow their recommended procedures. (blind monkey doing what told!)  With these options, it appears that their makefile wants to compile mysql. Without them it doesn't. Go figure... Doesn't appear that their default set of recommended configure parameters has been well tested... Anywise, thanks so much, I will carry on with trying to install Bacula and getting it back up and running on my systems. I think it is a really wonderful tool and it has saved my tail many times in the past. I have already been tasked with trying to maintain it for openSuSE and as soon as I get it all figured out, I will attempt to get it's latest version back in the openSuSE repositories. That is why I am rather intrigued by the autotools that David Haller mentioned and perhaps I can work my way towards using them down the road.     Marc.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2017 12:36 AM, Per Jessen wrote:

Marc Chamberlin wrote:

...

Thanks Per, well I think you might have put me on the right track, nice to see it done through a fresh set of eyes! I had been using the default config file (with modified paths that suited my environment) that Bacula supplies in their example directory, that their installation instructions recommended. Within that config file there were two options -

--enable-static-tools \ --disable-libtool \

and on a hunch, after seeing how you had successfully built Bacula, I decided to remove these two options. And it worked! (at least it compiles OK) I don't grok what these options do exactly, or why Bacula recommends using them, A wild guess - they enable the building of static versions, i.e. monolithic blobs that you can run anywhere because they don't depend on loading any local libraries. For a backup tool, that's not a bad idea.

...

I was simply doing my best to follow their recommended procedures. (blind monkey doing what told!) With these options, it appears that their makefile wants to compile mysql. possibly the same reasoning - to get object code for building static versions.

You know, I like your thinking/reasoning Pers... For now I think I will just try and get Bacula running without these options, but for putting it back in the openSuSE repos later, and supporting it for openSuSE, I may want to revisit this issue and figure out how to get it working with mysql built in.. I will ask on the Bacula forums about it and what they recommend when I get that far... Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/08/2017 20:36, Marc Chamberlin wrote:

Anywise, thanks so much, I will carry on with trying to install Bacula and getting it back up and running on my systems. I think it is a really wonderful tool and it has saved my tail many times in the past. I have already been tasked with trying to maintain it for openSuSE and as soon as I get it all figured out, I will attempt to get it's latest version back in the openSuSE repositories. That is why I am rather intrigued by the autotools that David Haller mentioned and perhaps I can work my way towards using them down the road.

    Marc.... Hi Marc, I maintained bacula for quite a while until other packages took up most of my time. If you have any future problems or wish for personal guidance building bacula for obs, email me davejplater@gmail rather than my list address and I will do what I can to help you maintain bacula. You should start with learning to build bacula using the spec file and rpmbuild. A good starting point for creating a spec file is to install rpmdevtools and use rpmdev-newspec which will create a skeleton spec file that you can edit. The current spec file in Archiving:Backup/bacula is very complex because it gives many different options for distributions and data bases it also splits bacula into many sub packages, you need to get experience before attempting to emulate this. A good starting point and a wealth of information is: https://en.opensuse.org/Portal:Packaging but it can be overwhelming to a beginner. It has a link to The RPM-Guide by Eric Foster-Johnson which is a good start, skip to "Chapter 8. Creating RPMs: An Overview". Regards Dave P

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org