The concept of 'build' is broken for local user builds -- I *agree* with it for release methodology (though it may be overkill and inefficient), but the idea of using build is fundamentally flawed. You (perhaps for brevity) deleted a question in my prior post that build cannot deal with: Cristian Rodríguez wrote:
So build on modern laptops -- maybe would have 200GB total
-- (including OS and a possible windows partition). I asked if this would be 'the choice' for compiling / building rpms on a laptop these days. Also asked:
If you were running a MAC-Book "Air" and Parallels to run OSuse -- and I wanted to patch and rebuild 1 RPM, that I already have the sources installed for -- the suggested solution is to find a 'Hot-Spot', so I can connect to build my rpm?
--- Again...won't work -- you answered:
"build" will setup the chroot using a package set available in your harddisk, it is not mandatory to access the internet.
I just ran an attempt -- two in a row same results. Now 'temporarily ignoring performance configurations... The 'build' of my new openssh.spec (both builds make buildroots 318M buildroot 318M buildroot1 Neither laptop would have a prayer of using build just on the space it takes. Also at issue is where the src DVD's that build would require for building and installing would be located. Maybe you can burn a DVD for each set of RPM's you update, but the air is gonna die over backwards accessing that DVD -- the battery will die before the buildroot gets built. No, admitedly, it "only" took 245 seconds -- a bit over 4 minutes -- nearly all I/O off onto 15K-SAS3.0 RAID-0 drives -- 4GB memory on an x84 machine. That would mean about 12x more on a 2x1GHz-1GB 15K-SCSI-3 P-III -- not state of the art, but to compile one package -- um...about 50 minutes? Oh...and yeah...then it failed. Twice. Executing /sbin/conf.d/SuSEconfig.perl... Executing /sbin/conf.d/SuSEconfig.permissions... Finished. cp: omitting directory `/home/packages/specs/buildroot' ----------------------------------------------------------------- ----- building openssh.spec (user abuild) ----------------------------------------------------------------- ----------------------------------------------------------------- error: File /usr/src/packages/SOURCES/x11-ssh-askpass-1.2.4.1.tar.bz2: No such file or directory Yet .. ( knew someone would not pay attention to rpm macros.....but the source is there: /usr/src/packages/SOURCES/openssh-5.0p1/x11-ssh-askpass-1.2.4.1.tar.bz2 Build doesn't get as far as rpm -- which completes the build (as I added a source patch file to hack around the rpm.specfile bug.
you want to use "build" in that case, however if you are applying a "local patch" there must be a reason why you are doing that, let us to know the reason and then we can figure why the original package is not suitable for you, and improve it.
Yeah. Right. Been there...hasn't happened. I find that avenue of getting an improvement to be ... less than satisfying. Even the idea of putting each source package in a separate directly under SOURCES so that multiple sources could be loaded without fear of them overwriting them -- I got seriously flamed and told how stupid I was and there wasn't a chance in hell that suse would implement something that would completely destroy the way RPM worked. So I added : the following to /etc/rpmmacros: # # could use dirs-by-ver+rel, but likely to be overly complicated -- how # often are we going to need multple "releases" of the same version # unpacked at the same time.... # %_sourcedir %{_topdir}/SOURCES/%{name}-%{version}-%{release} # # so simpler sourcedir name: %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} ------------------------ Yup...just was the end of the world. Sorry, but I really don't need to be told I'm an idiot that knows nothing when I make a suggestion. I file a bug about something that doesn't work -- and am told 'tough'... that's just the way it is. Another tells me rpmbuild for users is no longer supported -- they don't read the 1st bug report, then ask me to 're-explain' it in simple short steps -- I did. They refused to follow them -- they did it a different way *again* the 2nd time, and said my way of duplicating the error for them wasn't supported. Only bugs that are duplicated according to Suse guidelines will be accepted. ... I get *R*E*A*L* tired fighting uphill battles and showing into the wind. Sorry to come off a bit short...I'm tired...and patience is slightly taxed...sorry 99.99 times out of 100, if I subit suggests (RFE's) for projects, they get shot down, or I'm told to do it myself -- submit a patch, etc. So...rather than asking the "open source" community to do a patch for me... I decide I'd try the patches/tests myself -- do some benchmarking and if it looks good -- then champion the patches. I already pointed at the patches I wanted integrated -- both in the bug report and my initial mentioning of this issue on .... But try to understand this, you are saying now:
however if you are applying a "local patch" there must be a reason why you are doing that, let us to know the reason and then we can figure why the original package is not suitable for you, and improve it.
Yet in my email to you on Wed-May21-2008, 13:43:05 -0700 ----- I have a patch (standard linux patch composed of the output of "diff -u") (patch for High performance scp/ssh is from http://www.psc.edu/networking/projects/hpn-ssh/ . ... I'd _like_ it if SuSE included the high-performance work for me, but I think it's probably too late for SuSE 11.0 -- and I'm not sure how easy it would be to convince SuSE, or someone else to include it in 11.1 (or beyond) as I don't know what the demand is for high-speed networking (>100Mb/s data throughput) among other OSuSE users/customers.... ---- My email was never answered. I repeated the request to thew mail-group:
I also mentioned that I had a patch (standard linux patch composed of the output of "diff -u") that I needed to apply to a version, *higher* than the one included in 10.3. The patch for High performance scp/ssh is from: "http://www.psc.edu/networking/projects/hpn-ssh/".
While others responded to the email, my suggestion about the patch I was trying to apply was made quite clear. It's not like I've been keeping it a secret. I even said it'd be great if SuSE did it, but... the response was *OVERWHELMING*.... So I continued to work on it myself -- including setting up build as I was told was the right thing to do -- and is what would cure my 'ills'. Instead build fails even sooner than rpmbuild. This is I think -- part of the problem -- The bug is in the rpmspec (that I can tell). Build uses rpm and rpmbuild (though it isn't fully compatible with rpm specfiles -- so how can build that isn't fully compatible with rpm specfiles build something that rpmbuild cannot -- Possible answer - the bugs in build are canceling out the bugs in the specfile -- a very rare situation, but I've seen stranger. So ...build doesn't work either. And oh...yes. rpmbuild was able to use slightly more than one cpu at times, giving close to a full 100% cpu utilization over the 69 seconds it takes to build openssh. build uses about 15% of one cpu. I know how to get rpm-build to use all 4 of my cpu's, Looks like build is gonna be around 16 or more times lower -- and that's only with a fast hard disk... "Build" is great for *some* things -- like building releases -- but for software development -- it's NOT a solution... So...when you gonna have the high-perf patches in openssh ready? :-) Or...when is the openssh.spec file going to be fixed (the suggested 'fix' for it was closed out as rpmbuild is not supported). Should I reopen it? ;-) Is the build-bug ignoring rpm-macros going to be fixed as well?... Seems like I've raised a few issues...no? (Sorry...my presentation skills sometimes aren't the best...sometimes do ok...such a joy!) .... Or...if I get it to pass my 'anal-retentive' requirements, I might suggest it for inclusion...:-) ..but in case you hadn't noticed -- my standards are a bit more demanding than what most people are used to ... nothing personal... I'm just a bit methodical...that and, unfortunately, slower than I used to be (can't do this full time). --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org