On Wed, Jul 18, 2012 at 11:48 AM, Foolish Ewe
Hi All:
I don't mean to inject myself into the debate, but I have a question. Although I frequently build stuff for work using my OpenSuse environment, it would be nice to know how to edit and build packages for OpenSuse (say for example I'm considering a bug report but want to try a potential fix/workaround) for private testing.
Anders is suggesting an approach, is it documented? If so, could the existing documentation be improved?
For kernel building the kernel git documentation at opensuse is a help, but nowhere does it mention what should/shouldn't be installed chroot, etc. Also I'm not clear on how to get the branch names and cloning the configuration settings on the production kernel that I use before tweaking the kernel build options. Would that be sufficient to correctly build, package and install a kernel? There are times when this is useful, e.g. recently I got a laptop and my hardware was sufficiently new that not all drivers were published when I got it.
Does anything similar exists for applications (actually anything that runs strictly in user space)?
With best regards:
Bill
Bill, openSUSE has gone to a lot of work to obsolete the process that has been discussed here. The normal local build tool (osc) creates a chroot environment for you and installs exactly what is installed for the official builds based on the contents of the specfile. If you want to do it the openSUSE way you need to get familiar with OBS (opensuse build system) at build.opensuse.org. There is a tutorial at: http://en.opensuse.org/openSUSE:Build_Service_Tutorial I suggest you pick a small package, branch it to your OBS home project, then use OSC to make a local copy of your private branch, then figure out how to create a patch that makes some small change like a printf() or something, then figure out how to update the specfile to get it applied, then do a local build and local install to see if you did it right. Then once you're happy with your local build, use "osc add" and/or "osc commit" to push it back to OBS and verify all of the various repos build. If it was a real fix, this is when you would do a SR (submit request) to the devel project and hopefully the package maintainer would accept it. If there is a bugzilla associated with your patch, reference it in the SR. I find the patch create process the most cumbersome. I normally untar the main tarball, then rename it *.orig and untar it a second time. Then I make my edits to the second untar'ed version. Then I create a patch by comparing those 2 dirs. And of course I update the specfile to apply my local patch. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org