IzzySoft RPM releases
Filename Size Date Description
* dbahelper-0.2.7-izzy1.noarch.rpm 88.2 kB 11.07.2008 dbahelper v0.2.7-1
DBAHelper is a collection of scripts to ease the daily maintenance work of Oracle database administrators. Examples are moving objects between tablespaces, analyzing schemata, and rebuilding invalid indices. Additionally included is a little framework to simplify the use of RMAN (this framework depends on the use of Oracle 10g with the Recovery Area enabled and properly sized, so all backups go here).
Architecture: ALL
* debbuild-0.9.140-izzy2.noarch.rpm 27.7 kB 01.06.2008 debbuild v0.9.140-2
debbuild was written to be able to create packages that will install cleanly on Debian systems without going through the head-beating I found was required to follow the Debian New Maintainer's Guide, and pretty much any other Debian packaging guide. It uses the build process and command-line options of rpmbuild, but produces packages that will install on Debian systems. Please note, it is theoretically possible to create Debian Packages with debbuild, however no effort was made in this direction.
As an interesting bonus, if you're careful about filesystem paths, commands, pre/post/(un)install scripts, etc, etc, you may be able to write one spec file that you can use to create packages that will install and work correctly on both Debian and RedHat systems - and any derivatives or relatives that follow FHS guidelines.
Architecture: ALL
Requires: perl, findutils, tar, dpkg, gzip, pax, make
Suggests: pkgmake, relman
* debbuild-0.9.165-izzy1.noarch.rpm 29.9 kB 10.04.2012 debbuild v0.9.165-1
debbuild was written to be able to create packages that will install cleanly on Debian systems without going through the head-beating I found was required to follow the Debian New Maintainer's Guide, and pretty much any other Debian packaging guide. It uses the build process and command-line options of rpmbuild, but produces packages that will install on Debian systems. Please note, it is theoretically possible to create Debian Packages with debbuild, however no effort was made in this direction.
As an interesting bonus, if you're careful about filesystem paths, commands, pre/post/(un)install scripts, etc, etc, you may be able to write one spec file that you can use to create packages that will install and work correctly on both Debian and RedHat systems - and any derivatives or relatives that follow FHS guidelines.
Architecture: ALL
Requires: perl, findutils, tar, dpkg, gzip, pax, make
Suggests: pkgmake, relman
* ext3undel-0.1.6-izzy1.noarch.rpm 35.2 kB 25.07.2008 ext3undel v0.1.6-1
ext3undel is a collection of scripts to help you recover files from ext2/ext3 file systems, where you (accidentally) deleted them from.
Though most pages in the InterNet state it is impossible to undelete such files, this is simply wrong. Correct is: It is not that easy as to simply take them out of some trash folder. Using forensic tools, as e.g. Sleuthkit, PhotoRec and foremost, the task is possible - but may require a lot of manual work. ext3undel tries to automate most of this - so it is possible to recover a single specified file - or all data on a given disk.
Architecture: ALL
Requires: sleuthkit, testdisk | foremost
* histview-0.1.8-izzy1.noarch.rpm 67.8 kB 13.10.2009 histview v0.1.8-1
As a software developer, you will maintain a list of changes. This is mostly refered to as "history file" or "ChangeLog", and is - again in most cases - a plain text file. Now when you release a new version, it would be nice to put the "list of changes" on your website, so the users can look whether they need the update or not. This is the time for HistView.
The most common syntax I found on these ChangeLog files is: Some "header" telling the version affected, followed by some "underlining", and then every change preceded by a modifier mark like "+" (new feature), "!" (bugfix), a.s.o. If your ChangeLog has this syntax - great, you're ready! Otherwise, it may be easier to bring it to this syntax than to convert it manually to HTML on each and every release...
Architecture: ALL
Requires: libapache2-mod-php5 | libapache-mod-php5 | php5-cgi | php5 | libapache2-mod-php4 | libapache-mod-php4 | php4 | php4-cgi, httpd
* ifaqmaker-0.1.4-izzy1.noarch.rpm 63.7 kB 19.03.2008 ifaqmaker v0.1.4-1
iFAQMaker is a simple PHP class to ease the managments of FAQs. Basically, it is a rewrite of the code I used in the online help system of phpVideoPro (and, besides, this rewrite partially goes back there to replace the old code) - and that is where the, on a first glance - strange-looking syntax for the input files comes from. The main topics iFAQMaker is intended to cover are:
  • Inserting/Deleting/Moving single topics (within the same FAQ file) without the hazzle of reorganizing indices, numberings and links
  • Use of templates to display the FAQ corresponding to the web site design
  • Use of user-definable makros for frequently used formatings etc.
Architecture: ALL
Requires: libapache2-mod-php5 | libapache-mod-php5 | php5-cgi | php5 | libapache2-mod-php4 | libapache-mod-php4 | php4 | php4-cgi, httpd
* izmigration-0.1.0-izzy1.noarch.rpm 35.3 kB 07.08.2007 izmigration v0.1.0-1
IZ_Migration is a PL/SQL package to help you migrating your database(s) to UTF8. Not everything can be done automatically (otherwise we'ld lose our jobs ;) - but Oracle gives us possibilities to script certain things. Provided the necessary information, the procedures stored within the package will ease the conversion process a lot.
While the usual migration process as recommended by Oracle uses the EXP and IMP (export and import) utilities to transfer the data, the IZ_Migration package runs a different path: We use Oracle Database Links to transfer the data and adjust the settings, while EXP and IMP are used for the structures (and stored procedures etc.) only.
Architecture: ALL
* namcap-2.0.0-izzy1.i386.rpm 33.0 kB 03.07.2008 namcap v2.0.0-1
Pacman package analyzer: namcap analyzes pacman packages as they are used e.g. on ArchLinux.
The Debian package does work with Feisty and later Ubuntu releases (i.e. those shipping with Python 2.5) - the RPM is still untested.
Requires: python >= 2.5
* orarep-0.3.5-izzy1.noarch.rpm 130.9 kB 08.10.2007 orarep v0.3.5-1
OraRep is an Oracle Report Generator, used to create reports about your database activity statistics in a nice, human readable format - which in this case is HTML. The generated report provides you with information on the physical database design (tablespaces, datafiles, memory), users and their privileges (such as e.g. quotas and profiles), statistical values on your databases efficiency and more. It is highly configurable concerning the report elements you need. Due to its modular design, only the needed code (depending on the options you chose in the config file) will be build and executed, to save your database from unnecessary load.
Architecture: ALL
* osprep-0.4.7-izzy1.noarch.rpm 212.0 kB 16.10.2011 osprep v0.4.7-1
OSPRep is an Oracle Statspack Report Generator, used to create reports about your database activity statistics in a nice, human readable format - which in this case is HTML -, based on the data collected by Oracle Statspack and, optionally, some plugins shipped with OSPRep. The generated report provides you with information on the physical database design (tablespaces, datafiles, memory), statistical values on your databases efficiency and more. It is highly configurable not only concerning the report elements you need. Due to its modular design, only the needed code (depending on the options you chose in the config file) will be build and executed, to save your database from unnecessary load.
Architecture: ALL
* phpdivelog-0.4.6-izzy1.noarch.rpm 312.6 kB 13.10.2013 phpdivelog v0.4.6-1
phpDiveLog displays the information of your Aqua DiveLog LogBook - based on CSV files you generate with the Java Conduit shipped with Aqua DiveLog. A template engine allows you to modify the look and feel easily. As for now, phpDiveLog offers you no facilities to edit these data.
Architecture: ALL
Requires: libapache2-mod-php5 | libapache-mod-php5 | php5-cgi | php5, httpd
Recommends: tcpdf-api, tcpdf-fonts-basic | tcpdf-fonts-full
* phpvideopro-0.9.7-izzy1.noarch.rpm 622.2 kB 09.05.2010 phpvideopro v0.9.7-1
phpVideoPro is a program to manage your collection of DVDs and video tapes. It stores all data in a database, and provides you with features for adding/changing entries (information for this can be retrieved from the IMDB automatically on demand), displaying lists, print labels, and more. A built in filter function also supports the user to comfortably handle larger collections. phpVideoPro is template driven - so you can adopt the look-and-feel to match your own requirements with absolutely no PHP knowledge (HTML knowledge is however required for this). Same applies to language support (but this even requires no HTML knowledge; some language files, including those for German and English, are already contained within the distribution archiv; translations can be created/edited using the intgrated translation editor) plus label printing. Additionally, phpVideoPro is multi-user capable thanks to session- and usermanagement.
Requirements are Webserver, PHP >= 4.1 with MySQL or PostgreSQL support built in, MySQL or PostgreSQL server (most Linux distributions come with this features). Tested with Apache/MySQL under KUbuntu Dapper (2006-06 - PHP 4.4.2 & MySQL 4.1.15) & Hardy (2008-04 - PHP 5.2.4 & MySQL 5.0.51).
Architecture: ALL
Requires: libapache2-mod-php5 | libapache-mod-php5 | php5-cgi | php5 | libapache2-mod-php4 | libapache-mod-php4 | php4 | php4-cgi, httpd, imdbphp >= 0.9.5
* pkgmake-0.1.8-izzy1.noarch.rpm 44.4 kB 14.07.2008 pkgmake v0.1.8-1
pkgmake is just a simple shell script to create RPM *.spec files and per default (which is optionally) calls the packager rpmbuild/debbuild to create the package. For not-too-complex packages, a single spec template can serve for all packages to build, since most information (as e.g. packager, target architecture) do not change (and thus are hold as default values in the configuration) - while others (like package name and version) can be passed to the script on the command line.
Its target is to be simple to use, and save the developer from the need to study all the details and specifications concerning the package management with RPM and Debian. Instead, in most cases you will be able to build the RPM and the DEB package with the same SPEC file and configuration.
Architecture: ALL
Requires: findutils, sed, awk, tar, gzip, debbuild
Recommends: relman
* relman-0.1.6-izzy1.noarch.rpm 33.6 kB 02.02.2009 relman v0.1.6-1
While just being a simple shell script, relman has not much requirements. But still it can be a powerful helper for the developer, freeing him/her from some boring routine jobs on distributing the software. It will be most interesting for developers having a bunch of small projects.
In the relman configuration file, you define application-wide defaults valid for all projects - plus for each project the information special to them (e.g. the source directory, package name and the like). If everything is set up, on each release you just have to call relman with the name given to the project plus the version to release (optionally you can pass more parameters), and lean back: relman calls pkgmake to handle your source (building distribution .tar.gz, .deb and .rpm files), and then distributes them using ftp and/or scp, all in one run.
Architecture: ALL
Requires: pkgmake >= 0.1.8
Generated using the HistView DL Class v0.1.4 © 2003 - 2007 by Itzchak Rehberg & IzzySoft