[opensuse-factory] Re: openSUSE build & testing procedure and faulty pruning of builds causing build failures
Marcus Meissner wrote:
On Fri, Jul 20, 2012 at 06:14:53AM -0400, Greg Freemyer wrote:
On Fri, Jul 20, 2012 at 12:17 AM, Linda Walsh <suse@tlinx.org> wrote:
What it *sounds* like is that openSuSE is no longer a development / build environment -- that is supported to work to build it's own RPM's. Linda,
You are tilting a windmills and you know it.
openSUSE has moved to a new build paradigm and you are complaining the old one no longer works and you can't use it to build the distro pieces.
This paradigm you describe is the one we live for ... I do not know ... over 10 years now, at least for as long as I am with SUSE (10 years).
That rpmbuild works within a system was always optional. Patches are welcome btw.
Could you point the sources and documentation for the tools you use to produce binary & source RPM's, *OTHER* than rpmbuild? What packages don't need to have rpmbuild installed in the buildroot in order to build their RPM's? Unless you show evidence to the contrary, I would submit that rpmbuild is currently used to build rpm's as part of the OBS. I don't think there has ever been any question whether or not rpmbuild was used or supported. The issue is about what is already installed in your build environment. [Open]SuSE, if you remember, rarely used BuildRequires before suse10. Separate "-devel" packages weren't widely used if at all sometime before 10 or 9. It was assumed they were included by installing the product. Only by stripping out what packages normally include not including what the original "product/project" produces with it's configure and make do you run into to these problems. For that matter, it used to be that doc packages were usually not separate either. If OSC/OSB is required to build a distro, why is it not included in the shipped distro binaries and source rpms? What version of OSC/OSB is required to build each release: 11.1 => 12.2? Is this documented and made available for each release? If you don't ship the tools on the distro disks, then you are committing to keeping them online. You may not support SuSE 9.0, However, I don't believe the requirements for supplying the tools and sources to build that release expire -- as the GPL doesn't say that sources to binaries can be unavailable if it is more than 'n' years past their initial release date. That wouldn't be in the spirit of including (or making available) all the sources and tools necessary to build something. At what point did openSuse stop shipping complete sources to build the distro, with the distro? I.e. at what point did you require obs/osc to be the build environment? If isn't already a GPL license issue, is could soon become one if past distro build tools become no longer available. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 21 July 2012 07:32:42 Linda Walsh wrote:
to build that release expire -- as the GPL doesn't say that sources to binaries can be unavailable if it is more than 'n' years past their initial release date.
It actually does. Sections 3a and b a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, so you can either ship it immediately, with the binaries, in which case it doesn't have to be made available in any other way for any amount of time, or you can make it available on request, in which case it expires after 3 years, at a minimum. Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jul 21, 2012 at 4:32 PM, Linda Walsh <suse@tlinx.org> wrote:
Marcus Meissner wrote:
On Fri, Jul 20, 2012 at 06:14:53AM -0400, Greg Freemyer wrote:
On Fri, Jul 20, 2012 at 12:17 AM, Linda Walsh <suse@tlinx.org> wrote:
What it *sounds* like is that openSuSE is no longer a development / build environment -- that is supported to work to build it's own RPM's.
Linda,
You are tilting a windmills and you know it.
openSUSE has moved to a new build paradigm and you are complaining the old one no longer works and you can't use it to build the distro pieces.
This paradigm you describe is the one we live for ... I do not know ... over 10 years now, at least for as long as I am with SUSE (10 years).
That rpmbuild works within a system was always optional. Patches are welcome btw.
--- Could you point the sources and documentation for the tools you use to produce binary & source RPM's, *OTHER* than rpmbuild?
For such a skilled person you are mighty bad with teh google. http://en.opensuse.org/openSUSE:Build_Service https://github.com/openSUSE/open-build-service http://www.open-build-service.org/documentation/
Unless you show evidence to the contrary, I would submit that rpmbuild is currently used to build rpm's as part of the OBS.
Beginning with your first post, you arrogantly behave as if this list had to do the legwork for you, making claims indicating you haven't educated yourself. Use as much laywerspeak as you like to try to sound like a professional ass, you sound just like a regular ass.
The issue is about what is already installed in your build environment.
Yes. And it is best practice (generally, not only for openSUSE) to include only the very minimal set of packages. In fact, the default and reasonable rpm(build) behavior is to use only a) the packages specified as BuildRequires, and b) those already present in the build environment. (Since oS uses fresh, dedicated VMs for this, they are especially minimal and fit to spot errors in the build process. Also, of course your *build* environment is not your *test* environment -- the latter might include all kinds of "dirt" that is part of your site's infrastructure.) If your build environment is already dirty, for example when you don't use a dedicated build env, this can cause all kinds of side effects. These *could* indicate missing dependencies in the openSUSe spec file, but as S. Seyfried has demonstrated, this seems not to be the case. Ignoring whenever somebody proves you wrong doesn't help your cause (unless it is trolling or being ignored). You're also especially skilled in making vague claims to bugs in oS, but never being specific enough so that one could help with your build problem.
[Open]SuSE, if you remember, rarely used BuildRequires before suse10.
Separate "-devel" packages weren't widely used if at all sometime before 10 or 9. It was assumed they were included by installing the product. [...] For that matter, it used to be that doc packages were usually not separate either.
Yes, people did dark things in the dark ages. They have been corrected. People want a minimal selection of packages. If they need extra docs, they install them, too. If they want to build software themselves, they install devel packages. (Building packages is a very specific use case, much more unlikey than, f.e., running a web server or even a web browser. But oS doesn't come with Firefox or X by default, unless you select a graphical install, or with apache installed and running by default. Why? Because these are *use* cases, not the minimum required to install and run the operating system.)
Only by stripping out what packages normally include not including what the original "product/project" produces with it's configure and make do you run into to these problems.
I'm unsure what you're trying to say, but I guess it is "if I build the upstream package with the default options in my build env, I get different results than the openSUSE packages". So what? It has been the practice of distros to choose their own options since forever. Maybe a GUI program includes configure switches for different GUI toolkits, so the distro might decide to provide packages for each. Or provide a package only for the not-default toolkit. Or maybe the package has a lot of extra options, so some might not be built at all, while others are put into new packages, like f.e. vim-base and vim-enhanced. As a user these choices might not be intuitive and you might not even like them. But chances are, the people who made the decisions have a lot more experience than you with the topic, and have put a lot more thought (and trial-and-error) into them than you. (If not, you do not help your case by being an ass anyway.)
If OSC/OSB is required to build a distro, why is it not included in the shipped distro binaries and source rpms?
See above -- this is a very special *use* case. (Also, obviously, OBS/osc aren't needed to build oS as long as you replicate the basic setup.)
What version of OSC/OSB is required to build each release: 11.1 => 12.2?
Try the current one. If it doesn't work, try the release from the same date. Also, read the docs. Should be common sense, don't you think?
Is this documented and made available for each release?
(Disclaimer: I am not openSUSE and IANAL.) The general package building procedure and oS testing workflow is mostly documented and can be read from the sources in cases where it is not. Of course, not every single detail might be documented, but then again the GPL doesn't require this: Why should, f.e., the openSUSE RPM reference teach you every detail of RPM -- such things are *pre*requisites to understanding the docs.
If you don't ship the tools on the distro disks, then you are committing to keeping them online. You may not support SuSE 9.0, However, I don't believe the requirements for supplying the tools and sources to build that release expire -- as the GPL doesn't say that sources to binaries can be unavailable if it is more than 'n' years past their initial release date.
This has already been corrected. Feel free to act as if you've never claimed it.
At what point did openSuse stop shipping complete sources to build the distro, with the distro? I.e. at what point did you require obs/osc to be the build environment?
The complete sources weren't shipped with oS before that. There are news posts, wiki pages and changelogs where you can find the latter info yourself. (Or somebody might know it by chance, but since your point is moot, why bother?)
If isn't already a GPL license issue, is could soon become one if past distro build tools become no longer available.
Please, educate yourself about the GPL, too. Thank you. -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
--- Could you point the sources and documentation for the tools you use to produce binary & source RPM's, *OTHER* than rpmbuild?
There's a lot of them... The Apache OpenOffice for example is distributed in RPMs and those are build in an Ubuntu system (the rpm build host is actually named 'ubuntu-desktop'). People who work with Ruby have rgem2rpm to make nice gem packages in rpm; There's tools in perl and python which can do the same... Java people also have a few tools in the bag of tricks... You are an engineer, learn to do some research or get a slave to do it for you.
What packages don't need to have rpmbuild installed in the buildroot in order to build their RPM's?
Do you know what a 'buildroot' is? :) I'm pretty sure you don't. There's no rpmbuild in the buildroot unless you building the rpm-build package.
Unless you show evidence to the contrary, I would submit that rpmbuild is currently used to build rpm's as part of the OBS.
Engineers should know how to do research. If I'm not mistaken rpmbuild is actually a part of RPM and not of OBS, or is it not? mental note: research vs functional analphabetism
I don't think there has ever been any question whether or not rpmbuild was used or supported.
You should address that to RPM upstream, no?
The issue is about what is already installed in your build environment. [Open]SuSE, if you remember, rarely used BuildRequires before suse10.
Previous versions of RPM (< 4.10) don't support native LZMA; Are you going to bash down RPM upstream too because they didn't have implemented it on the past ? Shame on them.
Separate "-devel" packages weren't widely used if at all sometime before 10 or 9. It was assumed they were included by installing the product.
Keep those also on servers with compilers :) I'm sure a few skilled persons will love that... Honestly why would a Desktop user or a Server need development packages, specially when it's RPM managed (be it yum, zypper or any other)? People who need devel packages know they exist, so if they need them, install them. If you don't like, Slackware works in a different way, and they see that as a feature. Move to Slackware.
Only by stripping out what packages normally include not including what the original "product/project" produces with it's configure and make do you run into to these problems.
You never used RHEL in your life did you! Red Hat has twice the number of RPMs in 'optinals' (> 6000) repository than you have on the base distro (~3300). Guess what... the optionals repository is mainly devel packages from the packages on the distro... So they even do it in a more complicated. Your problem is that you don't know the tools you want to use and you expect that by an act of a superior entity things will magically happen... Take my word, it doesn't work like that. Research... basic stuff for any engineer.
For that matter, it used to be that doc packages were usually not separate either.
This might be controversial, but I do tend to agree with the splitting. On a production server or Desktop most people will never require the API documentation of the components. While developers do need that documentation. So the developers should know how to install the documentation. Not everyone wants useless documentation (for their tasks) installed by default. It's a feature and it's quite nice.
If OSC/OSB is required to build a distro, why is it not included in the shipped distro binaries and source rpms?
[nmarques@gangrena ~]$ osc --version && cat /etc/redhat-release 0.135 Red Hat Enterprise Linux Server release 6.3 (Santiago) I don't even have openSUSE installed and I had no problems finding the tools, the sources and whatever else... And guess what, on my archaic RHEL6 I can build software with the tools for any supported platform :) I don't even require an openSUSE install to rebuild openSUSE in total or partially. Nagging about the lack of competencies or will to investigate the subject won't help a bit.
What version of OSC/OSB is required to build each release: 11.1 => 12.2?
I don't know 11.1, but the only issue I can forsee that might cause problems is that in the past RPMs used md5 and nowadays they use sha256, this to say that if you pick a 12.2 srpm and try to build it on a system which still uses md5 it will trigger an error and you require extra parametrization to be able to install the srpm (ex: --nomd5). That's another of the nice things about building in chroot environments; you won't crash yourself against this kind of issues...
Is this documented and made available for each release? If you don't ship the tools on the distro disks, then you are committing to keeping them online. You may not support SuSE 9.0, However, I don't believe the requirements for supplying the tools and sources to build that release expire -- as the GPL doesn't say that sources to binaries can be unavailable if it is more than 'n' years past their initial release date.
Functional Analphabetism is the inability that one has (regardless of his/hers academical formation) to interpret texts, phrases, tables, etc. The OECD (Organisation for Economic Co-operation and Development) wants to replace the old 'anaphabetism' index by the 'functional analphabetism' in the medium future. This will produce a lot of cool statistics :)
That wouldn't be in the spirit of including (or making available) all the sources and tools necessary to build something.
import rpm ts = rpm.TransactionSet() a = ts.parseSpec('myspec.spec') for s in a.sources(): print s print a.sourceHeader('Url') In other words... if you read the spec file you can pretty much take the upstream Url and check the sources. It's all there. Even if you don't trust our stuff you can compare them with the origin, except maybe for 'ftp' which upstream and the sources seem to have disappeared from the internet, so even in this case, OBS is an added value because we still have copies of it :)
At what point did openSuse stop shipping complete sources to build the distro, with the distro? I.e. at what point did you require obs/osc to be the build environment?
31st of February
If isn't already a GPL license issue, is could soon become one if past distro build tools become no longer available.
All the stuff you complain about is available on OBS Project openSUSE:Tools. For the future, I would advice your at least to do some research before firing your guns... By the way use a bigger caliber if you really want to do damager, because the .9 nanometre caliber isn't really doing any damage :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jul 21, 2012 at 1:39 PM, Nelson Marques <nmo.marques@gmail.com> wrote:
If isn't already a GPL license issue, is could soon become one if past distro build tools become no longer available.
All the stuff you complain about is available on OBS Project openSUSE:Tools.
For the future, I would advice your at least to do some research before firing your guns... By the way use a bigger caliber if you really want to do damager, because the .9 nanometre caliber isn't really doing any damage :)
I disagree. It's filling up google's mail servers pretty efficiently. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I disagree. It's filling up google's mail servers pretty efficiently.
Yeah... imagine if someone used heavy calibers like Tirpitz, Yamato or Missouri main batteries... Google was a gonner by now :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Nelson Marques wrote:
--- Could you point the sources and documentation for the tools you use to produce binary & source RPM's, *OTHER* than rpmbuild? ^^^^^^^ (i.e. opensuSE uses to build the source and binary RPM's)...
There's a lot of them... The Apache OpenOffice for example is distributed in RPMs
--- If opensuse distributes Apache OO, then why are the binary and source RPM's not part of the 12.1 distribution directories? and those are build in an Ubuntu system (the rpm
build host is actually named 'ubuntu-desktop'). People who work with Ruby have rgem2rpm in rpm; There's tools in perl and python which can ^^^^
So far you and at least multiple others didn't answer my question and seem to have an impaired ability to read. I'm not asking what *can* be done. I'm asking what products are built in OpenSuSE NOT using rpmbuild at any point during their build? You mention perl -- if that's a representative example, You build tons of perl packages --- many of which are built using perl make and such... but they are all packaged at the end by rpmlib.
Engineers should know how to do research. If I'm not mistaken rpmbuild is actually a part of RPM and not of OBS, or is it not?
More than research, the ability to read a flow chart is probably more vital. rpmbuild is a separate program from rpm, so no it's not part of rpm, it runs off the rpmlib library. So you are saying that rpmbuild is not used at any point in the OBS process that produces an openSuSE release? I have alot of src rpms that say otherwise.
I don't think there has ever been any question whether or not rpmbuild was used or supported.
You should address that to RPM upstream, no?
??? the RPM project should address whether or not Osuse uses or supports building with rpmbuild? I don't think you are responding to what I am saying.
The issue is about what is already installed in your build environment. [Open]SuSE, if you remember, rarely used BuildRequires before suse10.
Previous versions of RPM (< 4.10) don't support native LZMA; Are you going to bash down RPM upstream too because they didn't have implemented it on the past ? Shame on them.
???? Huh?...Can you describe a situation where you want to build something requiring lzma where it wouldn't be available on the distro sources you are building?
Separate "-devel" packages weren't widely used if at all sometime before 10 or 9. It was assumed they were included by installing the product.
Keep those also on servers with compilers :)
--- You mean where you would be *building products*?
I'm sure a few skilled persons will love that... Honestly why would a Desktop user or a Server need development packages, specially when it's RPM managed (be it yum, zypper or any other)?
We are only talking people who use their systems to build or rebuild current packages and whether or not a current system with all the devel packages installed should work or not... If they aren't building, it's a moot point. I'm not suggesting that it is wrong to separate them. But to only be able to generate packages on systems where you don't have specific devel packages installed sounds more than a little arcane.
People who need devel packages know they exist, so if they need them, install them. If you don't like, Slackware works in a different way, and they see that as a feature. Move to Slackware.
Again, you miss the point.
You never used RHEL in your life did you! Red Hat has twice the number of RPMs in 'optinals' (> 6000) repository than you have on the base distro (~3300). Guess what... the optionals repository is mainly devel packages from the packages on the distro... So they even do it in a more complicated.
---- It was the first distro i used in it's 5.0 era, mandrake in the 6.x era, and suse since ~ 6.8 I wanna say, but 7.x for sure... it's been a while, ok?
Your problem is that you don't know the tools you want to use and you expect that by an act of a superior entity things will magically happen... Take my word, it doesn't work like that. Research... basic stuff for any engineer.
---- You are tilting at strawmen. You are arguing points and claiming things that don't respond to what I wrote. Please try again. I did my research... Just did it again. Nope..no openoffice packages available for 12.1... I think there was in the 11 series... but I see libreoffice, goffice, & koffice. http://download.opensuse.org/distribution/12.1/repo/oss/suse/x86_64/ Don't see the sources for it under the source tree either (http://download.opensuse.org/source/distribution/12.1/repo/oss/suse/src/)...
For that matter, it used to be that doc packages were usually not separate either.
This might be controversial, but I do tend to agree with the splitting. On a production server or Desktop most people will never require the API documentation of the components. While developers do need that documentation. So the developers should know how to install the documentation. Not everyone wants useless documentation (for their tasks) installed by default. It's a feature and it's quite nice.
---- I am not saying those are bad practice, I'm talking about what used to be common practice and expectations. Sterile systems were all but impossible 10 years ago for a distro build.
If OSC/OSB is required to build a distro, why is it not included in the shipped distro binaries and source rpms?
[nmarques@gangrena ~]$ osc --version && cat /etc/redhat-release 0.135 Red Hat Enterprise Linux Server release 6.3 (Santiago)
I don't even have openSUSE installed and I had no problems finding
--- I didn't say I couldn't find them, I said why are they not shipped with the distributions they build? Show me the packages under the above URL's where the distro is located. If OBS/osc is required to build openSUSE, then it is part of the required tool chain -- and the words of the license of the GPL were posted on the factory list earlier, saying that the toolset to generate the the build must also be included. Binary distribution (online) has been listed as 'fine'... but it requires you stay in business and the sources STAY on line. It also require knowing what tools you used to build a *given* distribution... (not just the latest copy)...
That's another of the nice things about building in chroot environments; you won't crash yourself against this kind of issues...
Unless you are building and installing kernels, you shouldn't be crashing yourself on a build anyway. Installing ?? you get what you install...but when rpmbuilds it does not build in a chroot env... and it has never caused any system corruption or crashes "/var/tmp/BUILDROOT/packagename/" is not a chrooted pathname -- For that matter, I can look in /usr/packages/build/package-version and see the build that was just done.
Functional Analphabetism is the inability that one has (regardless of his/hers academical formation) .
That you would be familiar with this term is not surprising. Thank you for informing me. I should read up on how to communicate to such people. Interpersonally -- 1:1 I do alot better, but writing 'at a group', seems like there are always people who completely misinterpret what is written -- while others can see it plain as day. Maybe has to do with the differences in how english is taught and learned -- especially in other countries -- and as filtered through their own mental language. I'm sorry if my writing was unclear. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 21 July 2012 12:53:49 Linda Walsh wrote:
If OSC/OSB is required to build a distro, why is it not
included in the shipped distro binaries and source rpms?
rpmbuild is used by the obs. The obs is not needed. It is what is used, but it is not in any way required. rpmbuild is not broken. I can use it. Everyone except you can use it. Beyond this, I am now officially leaving this thread. I've had enough Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/21/2012 4:30 PM, Anders Johansson wrote:
On Saturday 21 July 2012 12:53:49 Linda Walsh wrote:
If OSC/OSB is required to build a distro, why is it not
included in the shipped distro binaries and source rpms?
rpmbuild is used by the obs. The obs is not needed. It is what is used, but it is not in any way required. rpmbuild is not broken. I can use it. Everyone except you can use it.
Beyond this, I am now officially leaving this thread. I've had enough
Anders
I think the main reason any of us are in this thread are just to make sure untruths are refuted on record. If she claims some garbage, and 50 people happen to know it's not true, and the rest don't know enough to be sure either way, and none of the people who know the facts speak up, then passers-by could assume she made a valid accusation. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I'm not asking what *can* be done. I'm asking what products are built in OpenSuSE NOT using rpmbuild at any point during their build?
all of them are. rpmbuild is used in the end for building. The "build" script sets up the chroot with the defined set of packages inside (and nothing more), copies the sources and then calls "rpmbuild". The "build" script can be called manually or is called by "osc" or by the OBS Worker engine. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Could you point the sources and documentation for the tools you use to produce binary & source RPM's, *OTHER* than rpmbuild?
^^^^^^^ (i.e. opensuSE uses to build the source and binary RPM's)...
I've said it in the previous email, everything is on the openSUSE:Tools project on OBS; The tools from openSUSE. 'rpmbuild' is a part of the RPM package and is maintained with a few other tools by rpm upstream, so for those you need to check RPM upstream. Useful tip: $ rpm -qd <PACKAGE>
There's a lot of them... The Apache OpenOffice for example is distributed in RPMs
--- If opensuse distributes Apache OO, then why are the binary and source RPM's not part of the 12.1 distribution directories?
What I was trying to say is that a lot there are a lot of tools to build RPM's. The Apache OpenOffice isn't available on openSUSE, it's on their website, distributed in the form of RPM and generated in a system without RPM and rpmlib, still it's still an RPM package. Tip: If you can't work it out with the tools we use, then pick another from the hundreds available in the wilderness.
build host is actually named 'ubuntu-desktop'). People who work with Ruby have rgem2rpm in rpm; There's tools in
perl and python which can
^^^^ -------------- So far you and at least multiple others didn't answer my question and seem to have an impaired ability to read.
I'm not asking what *can* be done. I'm asking what products are built in OpenSuSE NOT using rpmbuild at any point during their build?
None ?
You mention perl -- if that's a representative example, You build tons of perl packages --- many of which are built using perl make and such... but they are all packaged at the end by rpmlib.
Perl has bindings to the rpmlib, so you can pretty much make a script to make RPMs using perl-rpm (or whatever it's called) without the need of using any of the tools we use.
Engineers should know how to do research. If I'm not mistaken rpmbuild is actually a part of RPM and not of OBS, or is it not?
---- More than research, the ability to read a flow chart is probably more vital.
Since I have a degree on Marketing Management, I can do far more than just reading flow charts, I can even create complex market studies; perform potent data mining operations and even popcorn. Though what I really love is paint Warhammer 40K Black Templars.
rpmbuild is a separate program from rpm, so no it's not part of rpm, it runs off the rpmlib library. So you are saying that rpmbuild is not used at any point in the OBS process that produces an openSuSE release?
I have alot of src rpms that say otherwise.
No, I'm saying that rpmbuild is a tool maintained and created by the RPM upstream and not openSUSE; The RPM upstream is Red Hat (and the community). 'rpmbuild' is actually built alongside rpm and other tools. If you have doubts, feel free to take a look: http://rpm.org/gitweb?p=rpm.git;a=tree;f=build;h=08e785c5b310f6451f2a56d4f04... See where rpmbuild comes from ? :) You still claiming it's not a part of rpm ?
I don't think there has ever been any question whether or not rpmbuild was used or supported.
You should address that to RPM upstream, no?
--- ??? the RPM project should address whether or not Osuse uses or supports building with rpmbuild? I don't think you are responding to what I am saying.
No, if rpmbuild isn't working for you, file a bug with rpm upstream, since they maintain rpmbuild; openSUSE is just a downstreamer which has found no problems with it. You are the only one having problems, right ?
The issue is about what is already installed in your build environment. [Open]SuSE, if you remember, rarely used BuildRequires before suse10.
Previous versions of RPM (< 4.10) don't support native LZMA; Are you going to bash down RPM upstream too because they didn't have implemented it on the past ? Shame on them.
???? Huh?...Can you describe a situation where you want to build something requiring lzma where it wouldn't be available on the distro sources you are building?
You are not following me; Base point: things evolve with time; 5 years ago you had a few features, nowadays you have some of those, a set of new ones...
Separate "-devel" packages weren't widely used if at all sometime before 10 or 9. It was assumed they were included by installing the product.
Keep those also on servers with compilers :)
--- You mean where you would be *building products*?
You missed the base point; Why do you need the 'devel' packages for a server that runs for example just a huge fat PostgreSQL database? Of course you need the devel packages for building stuff. If the devel packages weren't splitted then for example the big fat PosgreSQL server would also get them... add a compiler and you will make the day for any attacker who managed to get through. Next step is only 5 lines of assembly for kernel exploit and then you have root ;) This was about splitting of 'devel' packages not security ;)
I'm sure a few skilled persons will love that... Honestly why would a Desktop user or a Server need development packages, specially when it's RPM managed (be it yum, zypper or any other)?
---- We are only talking people who use their systems to build or rebuild current packages and whether or not a current system with all the devel packages installed should work or not...
A system with __ALL__ the available devel packages isn't really a good place to build reliable packages and experience will tell you the same. I gave you one example in the past, I will give it again to you... You have installed a generic Linux x86_64; after you install all the development packages for x86_64 and ix86; if you do build of a system library on that system and you change the target for ix86, in the vast majority of cases you will get a broken RPM because the dumb internal dependency generator will add x86_64 dependencies to ix86 packages. This will break any ix86 system. That's one of the reasons why we use chroot environment. Another thing are the env vars which might bring conflicts and a huge lot of factors. Most people on the list already told you, the best way to build packages is to have an environment only with the packages that you trully needed.
But to only be able to generate packages on systems where you don't have specific devel packages installed sounds more than a little arcane.
The absence of build requirements doesn't allow you to build; more packages than needed might lead you to problems also.
People who need devel packages know they exist, so if they need them, install them. If you don't like, Slackware works in a different way, and they see that as a feature. Move to Slackware.
---- Again, you miss the point.
You never used RHEL in your life did you! Red Hat has twice the number of RPMs in 'optinals' (> 6000) repository than you have on the base distro (~3300). Guess what... the optionals repository is mainly devel packages from the packages on the distro... So they even do it in a more complicated.
---- It was the first distro i used in it's 5.0 era, mandrake in the 6.x era, and suse since ~ 6.8 I wanna say, but 7.x for sure... it's been a while, ok?
That's not what I meant, what I meant is that if you were a RHEL user (RHEL != Red Hat Linux) you would know that devel packages aren't easy to find since they are scattered through a lot of repositories (some layered). Everything in openSUSE that ships with the distro is available on the same repository. So all your claims that we are not complying with GPL or that we use some obfuscated stuff are petty.
Your problem is that you don't know the tools you want to use and you expect that by an act of a superior entity things will magically happen... Take my word, it doesn't work like that. Research... basic stuff for any engineer.
---- You are tilting at strawmen. You are arguing points and claiming things that don't respond to what I wrote.
Please try again. I did my research... Just did it again. Nope..no openoffice packages available for 12.1... I think there was in the 11 series... but I see libreoffice, goffice, & koffice.
That wasn't the point. The point is that there are a lot of tools to build RPMs, not everyone uses the same as we do :) In fact I know the perfect tool for you to build RPMs... it's called 'fpm': *https://github.com/jordansissel/fpm/ If that doesn't also work for you, then I don't know what will...
http://download.opensuse.org/distribution/12.1/repo/oss/suse/x86_64/
Don't see the sources for it under the source tree either
Maybe because we don't ship that package and because it was an example that there are other tools that can be used to build RPMs? (in this case from the Apache Foundation / Apache OpenOffice). The source and binaries in RPM form are distributed by Apache Foundation.
For that matter, it used to be that doc packages were usually not separate either.
This might be controversial, but I do tend to agree with the splitting. On a production server or Desktop most people will never require the API documentation of the components. While developers do need that documentation. So the developers should know how to install the documentation. Not everyone wants useless documentation (for their tasks) installed by default. It's a feature and it's quite nice.
---- I am not saying those are bad practice, I'm talking about what used to be common practice and expectations.
common practice: rpm -qd <PACKAGE> All online documentation from a package.
If OSC/OSB is required to build a distro, why is it not included in the shipped distro binaries and source rpms?
[nmarques@gangrena ~]$ osc --version && cat /etc/redhat-release 0.135 Red Hat Enterprise Linux Server release 6.3 (Santiago)
I don't even have openSUSE installed and I had no problems finding
--- I didn't say I couldn't find them, I said why are they not shipped with the distributions they build?
The clients at least are. The rest of the stuff is available on the openSUSE:Tools; There's an appliance for OBS which works out of the box and stuff's all around :)
Show me the packages under the above URL's where the distro is located.
http://download.opensuse.org/repositories/openSUSE:/Tools/ As you can see above, I don't use openSUSE, so I don't know, but if you run 'zypper install osc' I'm pretty sure it's there. If by some wicked reasons it's not, then just install the repo I told you already.
If OBS/osc is required to build openSUSE, then it is part of the required tool chain -- and the words of the license of the GPL were posted on the factory list earlier, saying that the toolset to generate the the build must also be included.
They are available and you don't require OBS/OSC; you can just use rpmbuild if you like... or you can bootstrap a kernel and a few components and build everything from scratch :)
Binary distribution (online) has been listed as 'fine'... but it requires you stay in business and the sources STAY on line. It also require knowing what tools you used to build a *given* distribution... (not just the latest copy)...
http://download.opensuse.org/repositories/openSUSE:/Tools/ Potential cause: failed research.
That's another of the nice things about building in chroot environments; you won't crash yourself against this kind of issues...
--- Unless you are building and installing kernels, you shouldn't be crashing yourself on a build anyway.
I do package a few kernel modules and I never had real issues, one of them is for example DAHDI, others are proprietary stuff from my employers hardware, and so far no customer complained about my builds :) If you grab a src.rpm from openSUSE 12.2 and try: rpmbuild --rebuild <SOURCE_RPM> in an old system you will get into lots of problems, the one I mentioned above is one of them.
Installing ?? you get what you install...but when rpmbuilds it does not build in a chroot env... and it has never caused any system corruption or crashes.
I've already mentioned a few examples of situations that can go wrong. Not going to waste more time on this.
"/var/tmp/BUILDROOT/packagename/" is not a chrooted pathname --
-I/usr/include and /dev/brain
For that matter, I can look in /usr/packages/build/package-version and see the build that was just done.
If you want take this off-list I'll demonstrate you a few things that can go wrong if you are willing to place some time in experiments. Then you can compare with the same experiments on chroot environment.
Functional Analphabetism is the inability that one has (regardless of his/hers academical formation) .
That you would be familiar with this term is not surprising. Thank you for informing me. I should read up on how to communicate to such people.
If you want to start a venture in a foreign country, that index is a nice one to look for; Like I said I'm not a computer engineer, I'm a marketing manager ;)
Interpersonally -- 1:1 I do alot better, but writing 'at a group', seems like there are always people who completely misinterpret what is written -- while others can see it plain as day. Maybe has to do with the differences in how english is taught and learned -- especially in other countries -- and as filtered through their own mental language.
I'm sorry if my writing was unclear.
Nothing to apologize for, dealing with international communities and non-native speakers is not easy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jul 21, 2012 at 6:36 PM, Nelson Marques <nmo.marques@gmail.com> wrote:
add a compiler and you will make the day for any attacker who managed to get through. Next step is only 5 lines of assembly for kernel exploit and then you have root ;)
If only for the simple reason of not installing useless things, I agree that splitting devel packages is good. However, that statement there has never found favor with me. Having done security workshops and having successfully exploited buffer overruns, sql injection and the like, I have never needed the target system to have a compiler. I usually injected machine code, and if I needed to build complex programs and deliver them, I'd build them in my own system, not the target system. So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why?
I'm not a security experts, but compilers are banned in production servers in nearly all places I know; Kernel modules are handled with 'weak-updates' and so far it's doing the job well. The closest to a compilar that we allow in production is JDK, other than that, no gcc or friends :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Nelson Marques wrote:
So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why?
I'm not a security experts, but compilers are banned in production servers in nearly all places I know; Kernel modules are handled with 'weak-updates' and so far it's doing the job well. The closest to a compilar that we allow in production is JDK, other than that, no gcc or friends :)
It depends on site policy. Most security people I know say that if the person has gotten as far as being able to login to your system, it's game over -- compilers make little difference at that point. The incremental security benefit of not having compilers on a system, is minor -- NOT that I would advise putting development tools on a outward facing web server -- BUT, I'd generally advise against putting any software on it not needed for it's job, as each piece adds exponential complexity. I've never worked on a system that's been hacked into and all of them have had full development tools on them, but my security policy doesn't for the most part, doesn't provide services for untrusted clients. They got interactive shell? They can download premade binaries for your machine or attack tools not needing compilation. With security, it's never '1 thing', everything is about mitigation, with overlapping with a minimum of 3 overlapping layers per vector. I'd say that was far more important than whether or not the machine has compilers or not. The three layers ideally should be by different vendors and run on different HW -- i.e. no interdependencies. You could go so far as to disallow interactive users to running a shell, with updates to the webserver done via shared files run over a VPN over IPSEC. Again, a factor of 10x or more in risk reduction vs. disallowing compiler presence. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Nelson Marques wrote:
So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why?
Security is not only about threats from outside...
See it more generally: never install things you don't really need in the first place. Secondly, if you are doing "production" either paid or unpaid, then building and testing should be done on another machine altogether Only after testing of binaries AND configuration is a suc-6, you copy them to your production machine. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jul 22, 2012 at 1:54 PM, Linda Walsh <suse@tlinx.org> wrote:
I'm not a security experts, but compilers are banned in production servers in nearly all places I know; Kernel modules are handled with 'weak-updates' and so far it's doing the job well. The closest to a compilar that we allow in production is JDK, other than that, no gcc or friends :)
---- It depends on site policy. Most security people I know say that if the person has gotten as far as being able to login to your system, it's game over -- compilers make little difference at that point.
My point exactly.
The incremental security benefit of not having compilers on a system, is minor -- NOT that I would advise putting development tools on a outward facing web server -- BUT, I'd generally advise against putting any software on it not needed for it's job, as each piece adds exponential complexity.
That's the justification not to install them - ie, the same justification not to install image processing if you don't need it. No point in adding entry vectors you don't need. A compiler, if you don't need it, is like gimp (if you don't need it) - a useless, possibly vulnerable program. But, then again, any non-suid program is uploadable by an attacker that could build programs from source if gcc was there, so, from an information security theoretical standpoint, there is absolutely no difference in the security afforded by a gcc-less system.
They got interactive shell? They can download premade binaries for your machine or attack tools not needing compilation.
You need less than an interactive shell. They got the ability to build with gcc? Then they got the ability to upload gcc itself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/7/24 Claudio Freire <klaussfreire@gmail.com>:
On Sun, Jul 22, 2012 at 1:54 PM, Linda Walsh <suse@tlinx.org> wrote:
I'm not a security experts, but compilers are banned in production servers in nearly all places I know; Kernel modules are handled with 'weak-updates' and so far it's doing the job well. The closest to a compilar that we allow in production is JDK, other than that, no gcc or friends :)
---- It depends on site policy. Most security people I know say that if the person has gotten as far as being able to login to your system, it's game over -- compilers make little difference at that point.
My point exactly.
The incremental security benefit of not having compilers on a system, is minor -- NOT that I would advise putting development tools on a outward facing web server -- BUT, I'd generally advise against putting any software on it not needed for it's job, as each piece adds exponential complexity.
That's the justification not to install them - ie, the same justification not to install image processing if you don't need it. No point in adding entry vectors you don't need. A compiler, if you don't need it, is like gimp (if you don't need it) - a useless, possibly vulnerable program. But, then again, any non-suid program is uploadable by an attacker that could build programs from source if gcc was there, so, from an information security theoretical standpoint, there is absolutely no difference in the security afforded by a gcc-less system.
They got interactive shell? They can download premade binaries for your machine or attack tools not needing compilation.
You need less than an interactive shell. They got the ability to build with gcc? Then they got the ability to upload gcc itself.
It's not the same; The more time an attacker takes to exploit the kernel for uid/suid 0, the more opportunities someone has to block the attack or even fight back :) So the more nicer people are to him in having available the tools for him to accomplish his task faster, more please he will be ;) That's the whole, and you can still get root and burn down a system without an interective shell ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 24, 2012 at 11:18 AM, Nelson Marques <nmo.marques@gmail.com> wrote:
2012/7/24 Claudio Freire <klaussfreire@gmail.com>:
On Sun, Jul 22, 2012 at 1:54 PM, Linda Walsh <suse@tlinx.org> wrote:
I'm not a security experts, but compilers are banned in production servers in nearly all places I know; Kernel modules are handled with 'weak-updates' and so far it's doing the job well. The closest to a compilar that we allow in production is JDK, other than that, no gcc or friends :)
---- It depends on site policy. Most security people I know say that if the person has gotten as far as being able to login to your system, it's game over -- compilers make little difference at that point.
My point exactly.
The incremental security benefit of not having compilers on a system, is minor -- NOT that I would advise putting development tools on a outward facing web server -- BUT, I'd generally advise against putting any software on it not needed for it's job, as each piece adds exponential complexity.
Agreed (and I do some intrusion response work, so I have some real-world knowledge) First from what I've seen the bad guys normally attack windows boxes for the simple reason that it has a stable ABI and that lets them have a pre-compiled toolbox sitting out on the Internet where they can pull down tools as needed and not have to look around for a compiler etc. Specifically, I've never seen an intruder even interrogate a system to see if a compiler is available. Given that linux has both a significant server market share and a fairly stable ABI even between distros, if I were a bad guy I world create a toolkit with statically linked libraries as much as possible. Note there are some linux distros that make that fairly easy. (openSUSE does not.) Then simply maintain a linux toolkit repository on the web where I can FTP down my tools and put them to use. For machines with less common ABI's (like HP/UX, AIX, or even Solaris) I might not keep a working set of tools available, but for Linux I would be highly surprised if a reasonably good intruder that was able to target linux server boxes didn't maintain a set of pre-compiled linux attack tools. fyi: My last significant (windows server) intrusion case was: - Jboss vulnerability left in place in test network on a supposedly unimportant server and server left exposed to internet - Jboss package uploaded via vulnerability to allow command command-line interpretation of future post commands - Remote http post command issued to have server reach out to FTP site and pull down a reverse ssh app - reverse ssh application launched with IP of a computer under the control of the intruder - Interactive command-line control now in place - further tools downloaded and used to probe/penetrate the local environment The attacker did not depend on having local tools available. His attack toolkit was just sitting on the Internet waiting to be used. That is consistent with other attacks I've analyzed. The attackers get their ducks in a row with an external attack toolkit before they start interacting with a system.. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2012-07-22 at 17:24 +0100, Nelson Marques wrote:
So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why?
I'm not a security experts, but compilers are banned in production servers in nearly all places I know;
I know of at least one Unix server machine, in the 6 million € per machine range, that had a C compiler. Not gcc, certainly. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAlAN2r4ACgkQtTMYHG2NR9WFDQCdEo3ytvLREYMMNSxT9GYOqLaj HKQAnA83Gl0XfQ+D1H2Mg1J34Xgh8LZl =UnWO -----END PGP SIGNATURE-----
Hi, On Tue, 24 Jul 2012, Carlos E. R. wrote:
On Sunday, 2012-07-22 at 17:24 +0100, Nelson Marques wrote:
So... really... I'd like to understand... does any security expert also believe installing a compiler into a system to be a security issue? Why?
I'm not a security experts, but compilers are banned in production servers in nearly all places I know;
I know of at least one Unix server machine, in the 6 million € per machine range, that had a C compiler. Not gcc, certainly.
My servers have all the compilers I need, but no local users. It is a matter of concept, not only security - only login servers are an exception. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------
participants (11)
-
686f6c6d -
Anders Johansson -
Brian K. White -
Carlos E. R. -
Claudio Freire -
Eberhard Moenkeberg -
Greg Freemyer -
Hans Witvliet -
Linda Walsh -
Marcus Meissner -
Nelson Marques