Anders Johansson wrote:
On Sunday 15 July 2012 13:14:23 Linda Walsh wrote:
Malcolm wrote:
On Sun, 15 Jul 2012 11:25:08 -0700
Linda Walsh
wrote: Malcolm wrote:
rpmbuild is not supported as far as I know, use osc and OBS.....
They do not comply with the GPL -- they require accounts and
off-machine "permissions" (i.e. a form of "licensing") to build...and do not support a local build. Besides the fact that they don't easily install and did not install under 11.4 and have not installed under 12.1. Apparently I don't have the correct extra -required- proprietary information needed to build those packages.
That's violates the GPL. Install a local instance of OBS and build away.....
Have tried under 11.4 and 12.1 neither built.
I pursued it under 11.4, but have not under 12.1, as the OBS system is a boondoogle that requires building and installing a separate build root for software that is supposed to be able to be "config'ed" and built anywhere. Suse has broken that system.
This is absolute nonsense. The packages are the same.
I never said it worked under 11.4 - I said I pursued it trying to figure out why.
The reason for the chroot build environment (which by the way was *always* there, it isn't new for the build service)
This is incorrect. rpmbuild uses a BUILDROOT, but not a chroot. Did you look at the error messages?? Samba as an example: /var/tmp/rpm-tmp.fcG8ke#78> rm -r /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/python2.7/site-packages /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/ldb/libtalloc.so.2 /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/ldb/libtalloc.so.2.0.5 /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/ldb/libtevent.so.0 /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/ldb/libtevent.so.0.9.11 '/usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/ldb/libp*' /usr/src/packages/BUILDROOT/samba-3.6.3-34.6.1.x86_64//usr/lib64/tevent ---- That's not a chrooted path, that's building under BUILDROOT and it's giving full pathnames.
is to guarantee consistency. It is fundamentally impossible to write a spec file that takes into account all variations of software people have installed ==== You don't write spec files for ALL variations... you write it for a particular release with requirements from that release.
SuSE and OSuSE have did it for years before the build system came out. So that type of FUD won't work. On top of that, 'configure', has done a damn close job to doing exactly what you are claiming for years as well. It runs into situations it can't handle, but I never have had something where i've had pre-reqs install, that configure couldn't handle -- and spec files use configure. So again, your argument doesn't hold water.
so in the chroot there is a clean build environment, which means you know what to expect when writing the spec file.
Spec files that fragile should have their developer drawn and quartered. If the spec file doesn't work on a released system, then it's broken. My system dependencies verify -- I can run zypper verify, and it says everything is complete.
It used to be called build. Now it's obs. The principle is the same.
--- Broke and more Broke?
You are of course able to build the package without it, if you know what you're doing. As I said before, I do it all the time.
---- Me too -- up to 11.4 where had a few problems that I worked out, but at 12.1 I've hit stone walls with proof submitted in logfiles. I don't trust your build environment -- how's that -- if it is working, then it is broken, because there's no way the build from samba removing files that were never there could work. And note -- I didn't ASK it to build samba4 -- it just did. I normally only build samba3 -- I run configure, and it builds and installs fine. Samba4 is officially in BETA, (or maybe alpha).... it's not ready for release -- should the default build samba4 as well? I know they have intermixed source deps, so it may not be practical.. but if they could be built separately, IT, at least might have built. Why perl doesn't build... another issue... dbm_open isn't there. I asked for a log file so I could see why it worked in one case and not here -- but the fact that none has been provided and the same people keep claiming it works leads me to believe they can't produce a clean build w/log file. Believe me -- I REALLY did NOT want to open this can of worms... if there had been any other way... I don't need the love this type of issue gets me... But at least large rpms I rebuild regularly the kernel, samba, perl and squid... if I can't rebuild them it's not because it's my first time and I don't know how. I've been rebuilding my own copies for over 10 years -- don't even think that I wouldn't know, at least, the basics... My kernels are config'ed for my HW -- I don't rebuild everything -- same with most of the other utils...I'll optimize them and throw out parts I don't need. I did this from the very first suSE I used (6.8? something <7.0) that was optimized for a pentium -- and not my P-II or P-III machine. This isn't new stuff to me. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org