On Thu, Jul 19, 2012 at 2:39 AM, Andreas Jaeger
On 07/19/2012 01:17 AM, Greg Freemyer wrote:
On Wed, Jul 18, 2012 at 11:48 AM, Foolish Ewe
wrote: 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, I suggest you look into quilt.
If you have an existing package already, it's as easy as: # this untars the tarball and does some magic quilt setup glibc.spec # chdir to sources cd glibc-2.16 # apply all patches quilt push -a # add new patch quilt new testing-for-greg.patch # add a file to the patch quilt add some-file vi some-file # or alternatively: quilt edit some-file # and finally quilt refresh -p1 # and now handle the spec file cd .. vi glibc.spec # Add patch to it osc add testing-for-greg.patch # add changes file osc vc -m "Fix some typos." # and test everything osc build
Andreas --
Thanks Andreas, I've started expand that into a full example: http://en.opensuse.org/openSUSE:Build_Service_Tutorial#A_start_to_end_exampl... Is there by chance a package in OBS that is relatively trivial to do this with. It would be best if it didn't have a maintainer getting notification emails about SRs. That way the tutorial example above could end by having a SR submitted, then revoked by the budding OBS user and no one would have to be in the loop but them. fyi: All, please feel free to update / correct what I wrote on the wiki. Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org