Files changed (1)
+Since the beginning, the goal for this application has been to make it easy for ordinary users to install and compile software from source. The new vpackager does this like no other release.
-A long time ago I started developing this idea of a linux application to help newcomers install new applications to their linux systems even if they had no idea how the process is actually done. The initial result was an interactive bash script that the user could launch and answer a few questions, after which their new application would be compiled.
+The job queue displays a list of jobs waiting to be processed by vpackager. Jobs can be added by clicking the 'New Job' button at the bottom of the job queue tab. When jobs are present in the job queue, you may right-click on any job to see available options like view job details, edit the job, or remove it from the queue.\\\\
+**NOTE: Adding a new job does not automatically start the build process. After adding a job, you still need to click the 'Start' button towards the top-right corner of the window to start the build processes.** \\\\You may continue to add jobs while the queue is being processed.
-The application proved to be useful, so I decided to learn gambas to create a graphical interface that did the same thing. This produced a nice GUI and even added support for building from cruxports4slack. The gambas gui works, but I always felt it could be improved. And so the story continues...
+When you click on "New Job" a new window appears asking for information about the application to be compiled. Below is a list of the components of this window and the acceptable values to be entered there.
-New development of the application is now being done in python. Python offers great support for most things vpackager does, along with gtk integration and threading support which turn this thing into a really nice, useful application while keeping it really small.
+ ** The source archive field will accept a valid absolute path to a compress source archive or an URL to a direct download of the source code.
+ *** When the 'Browse' feature is used to select a local source archive, the 'Application' and 'Version' fields are automatically filled in, However, if a correction is necessary, you may change the values on these fields as necessary.
+ ** Again, you may enter a URL to the direct download link of the slack-desc or use the 'Browse' button to select a local file.
+ ** Name of the application to be compiled. ( If the source was selected using the 'Browse' button, this should already be filled in.) This field must be manually filled in when using an URL as the source.
+ ** Version number of the application to be compiled. ( If the source was selected using the 'Browse' button, this should already b e filled in.) This field must be manually filled in when using an URL as the source.
+ ** Select a package release number from the drop-down menu. Values should be between 1 and 4 at the present time.
+ ** Select the type of source code contained in the source package. This value defaults to 'Auto' which means that vpackager will try to determine the correct source type when you use the 'Browse' button to select a source archive. Most packages will build fine with this option, because the default and most common source type is the type that builds using the GNU autotools set of tools.
+ ** When using an URL in the source archive field, you must find out what type of source code is in the tarball, and select the appropriate value from this dropdown list. Leaving it at the default value will make vpackager assume it needs to run ./configure && make && make install.
+ As the term suggests, this section is for rare cases where you may need to do something out of the ordinary to build a package. This section is completely optional and not needed in most cases. The advanced options expander contains provisions to do the following
+This option is useful when you are building a series of packages that depend on others. For instance, if you have to build package X, but package X depends on package A, you would check this option for package A so that when vpackager gets to build package X, the dependency is filled.
-The goal for this application has always been to help newcomers easily install new applications on their systems. At the same time, the new development branch also puts more focus aiding packagers for the project and thus speed up the process of building applications to host in the distro's repositories. Here is how it works.
+The job history is just like the job queue, except it displays a list of jobs that have already been processed. Towards the bottom of the list, you can click 'Wipe History' to delete the entire job history, or you can filter the visible jobs by result.
-To standadize as much as possible, vpackager relies on sbbuilder, a tool written to generate build scripts for several source types. By doing this, vpackager is able to easily build just about any application while at the same time produce a package and source tree that meets the requirements for submission to the online repositories.
+You can right-click on any job listed in the history to view the build log, view all details about that particular job, or you may select to 'rebuild' the job. This feature is handy when you are building a new version of a package that has already been built before. You just update the 'Source Archive' field to point to the new version, you may leave the description in place, and update the 'Version' field. After that, your new job is ready to be processed.
-Furthermore, vpackager extends sbbuilder by automatically detecting the source type to be built and generating the appropriate script (limited to local source archives only). For source archives to be downloaded, the user can specify a source type if necessary and still generate the appropriate script.
+This is just the stout of the job that is currently running (if any). Meant for observation only (because I enjoy watching lines of text scroll down my screen). Everything that goes through this window is logged after the job is complete. This text area will clear up every time a new job starts processing.
-Coupled with sbbuilder, vpackager uses a sqlite3 database backend for job queueing and to keep a history of built packages. This allows the user to build a series of packages at once. The to-do list is stored in the database, and vpackages launches a worker process that queries this database going down the list one by one.
+If you click on Edit -> Preferences from the menu, you see a new window that allows you set some global configuration settings. The vpackager configuration is kept in /etc/vpackager.cfg
+ ** Enter your packager name here. Every package you build is tagged with your packager name. This helps keep record of who maintains what.
+ ** This is where the sources are built. It really makes no difference to vpackager, so it defaults to /tmp/vpackager but you may choose to build stuff in a different place.
+ ** vpackager uses a sqlite database to maintain the job queue and job history. This setting tells vpackager where you want this database kept in your system. Defaults to /tmp.