Changes

From SME Server
Jump to navigationJump to search
Line 85: Line 85:  
The Koozali Koji server is [https://koji.koozali.org/koji/index here]. Like the gitea server, to do anything useful you need to be able to login in to it. The same username/password will work as for the gitea server.  Koji is a fully featured build system which we will use for creating rpms and also generating ISO for releases. However the latter has not yet been completed.
 
The Koozali Koji server is [https://koji.koozali.org/koji/index here]. Like the gitea server, to do anything useful you need to be able to login in to it. The same username/password will work as for the gitea server.  Koji is a fully featured build system which we will use for creating rpms and also generating ISO for releases. However the latter has not yet been completed.
   −
Information is [[Koji Usage|here]] about setting up your build system to allow the use of Koji.
+
Information is [[Koji Usage|here]] about setting up your build system to allow the use of Koji.  
    
= Editing the Source Code=
 
= Editing the Source Code=
 +
As described above you can pull down the repo for a specific package using the git clone command. Or you can use the gitea web interface to grab which ever file you want and edit it as required, even using the provided gitea editor. You may be able to configure your desktop editor to interact with the remote gitea/git.
 +
 +
My preferred modus operandi is to use a running (and fully updated) SME11 VM to which I have full file access from my desktop using the sshfs package.  This allows me to make any changes using my preferred source code editor (geany in my case) and fully test any changes in place, and then copy the changed files back to the build system ready for local rpm build and test before updating to gitea/git and then doing a koji build.
 +
 +
YMMV.
 +
 
=Local rpm build=
 
=Local rpm build=
 
=Saving the Source code to Gitea=
 
=Saving the Source code to Gitea=
 +
''git status'' is very useful to see what changes have been made as compared to the version in the remote gitea/git server. The changed files are flagged in red before that have been locally staged and green afterwards.
 +
 +
''git pull'' can be used to bring any existing clone directory up to the latest on the server. However if the local version has been changed since the original clone and not pushed back and therefore deviates from the remote version which has been updated itself then an error message is seen and the pull will fail. Unless you have good reason to retain your local changes, the easiest way is to delete the local directory and re-clone. 
 +
 +
''git all --all'' will add all the local changes to the list to be pushed back to the repo. You can also use ''git add'' to just add one file. Also note that the contents of ''.gitignore''  can be edited to cause file types or names to be ignored by the --all parameter.
 +
 
=Tagging and starting a build=
 
=Tagging and starting a build=
 
=Monitoring your build=
 
=Monitoring your build=

Navigation menu