Name: python-GnuPG-Interface
Summary: GnuPG-Interface module for python
URL: http://py-gnupg.sourceforge.net/
Version: 0.3.2
License: LGPL v2 or later
Devproject: home:jimfunk
Description::
GnuPGInterface is a Python module to interface with GnuPG. It
concentrates on interacting with GnuPG via filehandles, providing
access to control GnuPG via versatile and extensible means.
Authors:
Frank J. Tobin <ftobin(a)neverending.org>
Applied Patches:
None
OpenSUSE Integration (init.d, SUSEconfig, permissions.d, etc):
None
Testing Status:
Tested on x86_64
--
James Oakley
jfunk(a)funktronics.ca
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
Name: gle-graphics
Summary: GLE is a graphics scripting language
URL: http://www.gle-graphics.org/
Version: 4.1.1
License: BSD
Devproject: home:mvyskocil
Description:
GLE (Graphics Layout Engine) is a graphics scripting language designed for
creating publication quality graphs, plots, diagrams, figures and slides. GLE
supports various graph types (function plots, histograms, bar graphs, scatter
plots, contour lines, color maps, surface plots, ...) through a simple but
flexible set of graphing commands. More complex output can be created by
relying on GLE's scripting language, which is full featured with subroutines,
variables, and logic control. GLE relies on LaTeX for text output and supports
mathematical formulea in graphs and figures. GLE's output formats include EPS,
PS, PDF, JPEG, and PNG. GLE is licenced under the BSD license.
Authors:
Jan Struyf <jan.struyf(a)cs.kuleuven.be>
Applied Patches:
gle-graphics-strip.patch (make a strip target default and fix some
mistakes - will be send to upstream asap)
OpenSUSE Integration (init.d, SUSEconfig, permissions.d, etc):
desktop files
Testing Status:
Tested on x86_64 and i586
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
This is one the few packages I have that isn't developer-oriented and is
relatively simple. Not that I don't want to see developer-oriented packages in
Contrib. I certainly would, but since this we're trying to come up with a
workflow, I figured we should start with something that has a wider appeal and
can be tested easily by non-developers.
Also, this is a package that used to reside in Factory. I took over
maintainership from cthiel(a)suse.de for the purpose of submitting to Contrib.
Name: duplicity
Summary: Encrypted bandwidth-efficient backup using the rsync algorithm
URL: http://duplicity.nongnu.org/
Version: 0.4.12
License: GPL v3 or later
Devproject: home:jimfunk
Description::
Duplicity incrementally backs up files and directory by encrypting
tar-format volumes with GnuPG and uploading them to a remote (or local)
file server. In theory many remote backends are possible; right now
local, ssh/scp, ftp, rsync, HSI, WebDAV, and Amazon S3 backends are
written.
Because duplicity uses librsync, the incremental archives are space
efficient and only record the parts of files that have changed since
the last backup. Currently duplicity supports deleted files, full unix
permissions, directories, symbolic links, fifos, etc., but not hard
links.
Authors:
Ben Escoto <bescoto(a)stanford.edu>
Kenneth Loafman <kenneth(a)loafman.com>
Applied Patches:
duplicity_noencfix.patch - Fixes upstream bug #23985: --no-encryption
option does no more work
OpenSUSE Integration (init.d, SUSEconfig, permissions.d, etc):
None
Testing Status:
Tested local and ssh backends on x86_64
--
James Oakley
jfunk(a)funktronics.ca
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
Hi,
I did some cleanup of http://en.opensuse.org/Contrib/Adding_new_packages
[0], in short:
* Let's not create a contrib-staging at the moment
* Don't require an ack from two reviewers, if there are no objections
and at least someone reviewed the package, the package simply goes in.
Now we are at zero question marks ;). Comments? If you think the article
is OK, we should spam^Winvite interested opensuse-packaging readers to
prepare their packages for contrib and refer to this article.
[0]
http://en.opensuse.org/index.php?title=Contrib%2FAdding_new_packages&diff=7…
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
Hi,
Let's identify the real issues and tackle them asap. From
http://en.opensuse.org/Contrib#Open_issues_and_packages:
# Security - perhaps Novell security guys can give us basic guidelines.
This has two parts
1) The hard part - monitoring upstream changelogs, bugtraq and the like
to identify security bugs. Should be probably maintainers'
responsibility.
2) Fixing security bugs: As not every package maintainer has to be a
programmer, we should allow version updates where it makes sense.
===
# Upstream vs. patched. (easy example: KVM from Alexander Graf, or from
Sourceforge.net - difference is big)
That should really be up to the package maintainer. If he is willing to
maintain the patches, there should be no problem.
-> not an issue
===
# Bugzilla integration (we need another discussion on that topic)
This is not specific to contrib, better bugzilla integration would be
beneficial for any build service project. For now, let's stick to
<person role="bugowner" userid="xxx"/>.
-> not an issue
===
# Who will be allowed to do what, see #Permissions
It seems that everybody agreed on the reviewers/maintainers model (at
least, I heard no objections)
-> not an issue
===
# What about updates for single packages in that repository? If the
repository is frozen after the release, we need an additional repository
just for packages containing bugfixes and security fixes. Who will
maintain this additional repository? Who will review the packages
submitted there? Should there be patches like for the official openSUSE
packages available? Related: [opensuse-factory] Contrib: Progress
Patches are not possible right now, having two repositories is not a
good idea. Let's just update packages in the repository.
===
# Forks ( fork is similar to duplicate packages; Think of Cinepaint and
GIMP. Should we allow forks? )
As long as the package follows the rules (esp. the one about no
conflicts with Factory packages), I see no problem here.
-> not an issue
===
I'll remove the non-issues from the wiki page and try to write some
rules about post-release updates, which is what the remaining two issues
are about (but we should be able to start even without these rules in
place).
Michal
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
Hi All !
This is 3rd attempt to review a package.
There was old topic, but I decided to create a new one, to stay focused.
I have a proposal package review - and proposal package review procedure.
Example package review:
===============================================
"iperf" - IP Performance benchmark
Description:
Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of
various parameters and UDP characteristics. Iperf reports bandwidth, delay
jitter, datagram loss.
This package is in OBS.
Current maintainer: James Oakley (James also interested in
contributing to "contrib" repo, so he may become a package maintainer)
Alternative maintainer: me (Alexey Eromenko "Technologov") (if James
don't wan't or can't support his child package)
URL : http://dast.nlanr.net/Projects/Iperf/
URL 2 : http://sourceforge.net/projects/iperf
License: custom OSS-compatible, BSD-like
(http://dast.nlanr.net/Projects/Iperf/ui_license.html)
Latest update: v2.0.4 Apr 2008 (which means, that package is maintained)
OBS URL: http://download.opensuse.org/repositories/home:/jimfunk/openSUSE_11.0/src/
Testing: Package received some testing from me. Everything tested
found to work. No crashes.
===============================================
1. What do you think of the review process
2. What do you think of the package
--------------------------
In the previous set no one had any objection over the package - except
maintenance.
I think if no objection will happen now we will link (or copy) this
package right from James Oakley OBS into contrib.
--
-Alexey Eromenko "Technologov"
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
Maintainer's tasks
1. * The package should follow the SUSE Package Conventions, it
has to build on both ix86 and x86_64 and you should test it at least
on ix86 (??? OK if the maintainer has no x86_64 machine for testing?).
You should be prepared to fix build errors, which sometimes occur due
to changes in Factory (this is especially true for Kernel Module
Packages). See also Contrib#Rules for inclusion of packages in Contrib
for further restrictions and requirements.
I think packages need to be tested on either x86 or x86-64, not both.
For kernel packages, we need to test on both architectures.
2. #
# (??? Add the package to a staging repository first? See
http://lists.opensuse.org/opensuse-factory/2008-08/msg00264.html)
What do you mean ? "contrib-devel" repo ?
Ahh I see - it is more like "temp".
I don't see any advantage of that versus User OBS, but I may be wrong. Opinions.
====================================================
Reviewers' Tasks
1. #
# If the package is actively maintained upstream (??? Relax this rule
for packages with little or no security risks, like games without
multiplayer mode?)
Yes, I think we can relax this rule for non-network packages.
--
-Alexey Eromenko "Technologov"
--
To unsubscribe, e-mail: opensuse-contrib+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-contrib+help(a)opensuse.org
