September 2008 - openSUSE Contrib - openSUSE Mailing Lists

[Review Request] python-GnuPG-Interface
by James Oakley 29 Sep '08

29 Sep '08

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

5 12

[Rewiev Request] gle-graphics
by Michal Vyskocil 29 Sep '08

29 Sep '08

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

2 5

[Review Request] Duplicity
by James Oakley 27 Sep '08

27 Sep '08

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

3 5

cleaning up Contrib/Adding_new_packages
by Michal Marek 18 Sep '08

18 Sep '08

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

2 1

open issues
by Michal Marek 18 Sep '08

18 Sep '08

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

3 8

Contrib: Packages Review: "iperf"
by Alexey Eremenko 17 Sep '08

17 Sep '08

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

3 5

Contrib: Review of the "Adding new packages" process
by Alexey Eremenko 15 Sep '08

15 Sep '08

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

3 4