September 2012 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] local package does not override global package
by Olaf Hering 18 Sep '12

18 Sep '12

In devel:languages:ocaml I changed the BuildRequires in the ocaml-findlib package from 'ocaml-camlp4-devel' to 'camlp4' to make it compatible with the binary names within sles11*. The new ocaml-camlp4-devel package provides and obsoletes camlp4. Now the buildservice has trouble to understand that ocaml-camlp4-devel from the same project provides camlp4.rpm, instead it wants to use the older standalone camlp4.rpm as shipped with 11.4 and 12.1. obs/devel:languages:ocaml/ocaml-findlib $ obs r -v openSUSE_11.4 i586 unresolvable: nothing provides ocaml = 3.12.0-2.1 needed by camlp4 openSUSE_11.4 x86_64 unresolvable: nothing provides ocaml = 3.12.0-2.1 needed by camlp4 openSUSE_12.1 i586 unresolvable: nothing provides ocaml = 3.12.0-11.1.2 needed by camlp4 nothing provides ocaml(Arg) = 877340141c0babb58b3aaef2f5b70fc9 needed by camlp4 openSUSE_12.1 x86_64 unresolvable: nothing provides ocaml = 3.12.0-11.1.2 needed by camlp4 nothing provides ocaml(Arg) = 877340141c0babb58b3aaef2f5b70fc9 needed by camlp4 I can certainly add a conditional BuildRequires, but: How can this be fixed properly? Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] No upstream changelog available
by Nelson Marques 18 Sep '12

18 Sep '12

One of the crap things about Cinnamon is that there's no changelog available from upstream; The Debian packages from upstream have no changelog also beyond the 'update to version x.y.z'... what should I write in the changelog ? NM --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] Marketing Jur�dico | Newsletter Inrise Consultoria | Edi��o 27 | Ano 05
by Inrise RH 18 Sep '12

18 Sep '12

1 0

[opensuse-packaging] package versioning
by Nelson Marques 18 Sep '12

18 Sep '12

Dear all, I have a simple question; Let's imagine we have a package 'foobar'; which the latest stable release is 1.0. Someone decides to to update to git snapshot and uses a version based on the date, for example: 20121017, where the NEVRA goes into something like: Name: foobar Epoch: 0 Version: 20121017 Release: 0 Arch: noarch Now after two years of git snapshotting we get an official release, lets say, 1.1; Would it normal to suppose that version wise: 20121017 > 1.1 Eventually my guess was that we should enforce Epoch to get back into track and make sure 1.1 would replace the former packages; If I understood correctly it is not wise to use Epoch within openSUSE and it should be banned... So... How do we get this update going ? This is just an hipotetical case, though I can remember of few examples currently in production, which don't for this case; I'm mainly interesting in knowing how to deal with this in openSUSE. Thanks. NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] required perl modules not included in package Requires
by Olaf Hering 17 Sep '12

17 Sep '12

Is there a reason why the required modules of a perl script are not encoded in the Requires of a package? In the example below I would expect a Requires: perl(Data::Dumper) to be included in inst-source-utils to pull in all required packages to actually run the script. Olaf root@carron:~/X # sed -n '/^[[:blank:]]*use[[:blank:]].*::/p' /usr/bin/createpatch use Data::Dumper; use File::stat; use File::Temp qw/ tempdir /; use Time::localtime; use Getopt::Long; root@carron:~/X # rpm -qf /usr/bin/createpatch inst-source-utils-2012.2.3-0.5.1 root@carron:~/X # rpm -qf --requires /usr/bin/createpatch gpg2 recode rpmlib(VersionedDependencies) <= 3.0.3-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/bash /bin/sh /usr/bin/perl rpmlib(PayloadIsLzma) <= 4.4.6-1 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 8

[opensuse-packaging] Adding openSUSE 12.2 repository for devel:languages:pascal
by Kirill Kirillov 15 Sep '12

15 Sep '12

Hello, all Could you please add openSUSE 12.2 repository in openSUSE Build Service - devel:languages:pascal project. It is needed by 'hedgewars' game, which aggregates 'fpc' package from this repository, so for now this game cannot be built for oS 12.2 due to this fact. Thanks. -- Kirill Kirillov <>< -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Conflicting C and C++ declarations?
by Ilya Chernykh 15 Sep '12

15 Sep '12

What should I do? [ 49s] ./main.h:38:15: error: previous declaration of 'char** environ' with 'C++' linkage [ 49s] In file included from util.cpp:45:0: [ 49s] /usr/include/unistd.h:546:15: error: conflicts with new declaration with 'C' linkage https://build.opensuse.org/package/rawlog?arch=x86_64&package=xxdiff&projec… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Sub packaging or extra
by Togan Muftuoglu 15 Sep '12

15 Sep '12

Hi, It is a general question actually, but what is the recommended approach when one is packaging more then one source package? I have a main package with its' source file and then small source packages that would enhance the main package and some of them have different licenses in relation to the main source. These small packages do need the main package as otherwise they are useless. Currently I am inclined to create sub packages so when eventually the package goes in to Factory, I don't have to submit X number of packages but only one ;). However, experience has taught me as well when the package is maintained for different releases then there are lots of if/else/endif blocks going on and with these sub-packages it means more work to keep them building and functioning as the spec file itself becomes big. On the other hand if I create separate packages that would mean I need to submit each one separately and still need to maintain for the different releases. It probably is a taste issue, but would like to hear others' thoughts as well Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] vdr, lirc, dvb looking for new maintainer
by Ludwig Nussel 14 Sep '12

14 Sep '12

Hi, Due to lack of hardware I no longer actually use lirc nor vdr so I shouldn't be maintaining the packages anymore either. I hardly invested any time in those packages the last years but still had no complaints. So either noone uses them either or the software is just perfect :-) Anyone willing to take over maintainership? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 11

[opensuse-packaging] Why this package fails without even starting build?
by Ilya Chernykh 13 Sep '12

13 Sep '12

https://build.opensuse.org/package/show?package=xxdiff&project=home%3AAnsus… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] plan for 12.3 - multiple Python runtimes
by Jan Matejek 13 Sep '12

13 Sep '12

fellow openSUSErs, with the advent of Python 3 and still almost unnoticeable decline of Python 2, i have come to a realization that the way we separate them into "python" and "python3" is less than ideal. The granularity of this can be often too coarse (you can't run two apps requiring two different python2 versions, unless they are specifically packaged and bring their own python runtime package), and too fine at the same time (there are already packages that don't actually care whether they run in python 2 or 3) In the spirit of fixing what ain't broken, I humbly propose a grand plan: let's turn "python" into "python2.7", "python3" into "python3.3", and tinker with Provides until it all works just fine. Then, as a last step, symlink /usr/bin/python into /etc/alternatives and let the users pick whichever runtime they like better. This would probably go better if broken into several phases. My current idea is this: Phase 1: - rename "python" to "python2.7", providing "python = 2.7" - rename "python3" to "python3.3", providing "python3 = 3.3" - install the update-alternatives symlink Impact: - Unsure of what would happen on package upgrade. Would we need Obsoletes/Provides combo for this? Perhaps we'd have to create the metapackages outlined in the following phases at this point already. Phase 2: - unify RPM macros - python3 will have %py_(something) macros as well as %py3_(something) macros, the %py3_ versions being aliases to the %py_ versions - make python2.7 provide "python2 = 2.7" instead of "python = 2.7" - make a "python" meta-package requiring, at this time, python2 - each pythonX.Y package now only installs /usr/bin/pythonX.Y binary, python2 and python3 are alternatives for python2.Y and python3.Y respectively, and python is an alternative for either python2, python3, or a specific version. I don't know update-alternatives too well - is this even viable? Impact: - this should mark a clear upgrade path for each of the python variants and for the systemwide "default python" as well - at this phase, i would like to make it possible to build a package for any python (2 or 3 or 50) from the same specfile. i'm not sure that these outlined steps are enough, though. Originally I thought that every python would provide "python = X.Y" and the packages could select which "Requires: python" to pick through package or project meta. But that would result in a horrible breakage, and we need "python" as a separate package for upgrading in any case. We could use "python(abi)" symbol for this, or do the same just with "python-devel"? Any other options? Phase 3A: - when python 3.4 comes out, introduce a new package "python3.4", new meta-package "python3" requiring "python3.4", and corresponding alternatives Impact: - This is the other difficult one. What about lifetime of the pythonX.Y packages? What happens with old systems on perpetual-upgrade? Such as tumbleweed - will the old python runtimes rot there forever-and-ever, or can we force uninstall at some point? Perhaps "Obsoletes: python3 < 3.x" in the "python3" metapackage? Which versions do we support? The newest and the most popular, probably? I know we do something similar with gcc, how does it work there? Phase 3B: - steal and improve Debian's python-central (or however they call it these days) - designate /usr/lib/python-central or something similar for packages that don't want to depend on a specific python runtime version - introduce %post/%postun scriptlet macros for packages that would compile bytecode in /usr/lib/python-central for all known python runtimes on the system, and for pythons so that they compile every package for their versions. This is now actually fully supported by upstream, we can have as many different versions of bytecode for the -same- .py file as we want. Impact: - package can specify "Requires: python" and Just Work(tm) from now until eternity, or until it runs into a deprecated API. Or specify a range of pythons it wants to support - by the time we get here, I'm sure RPM will allow that ;e) With a limited ABI in python3, this can even work for arch-based packages across python minor versions. Phase 4: - when we decide to switch to python3 system-wide, make "python" require "python3" instead of "python2", change default alternative, and be done with it Impact: - breakage of packages still incompatible at that time. that will help us see what needs fixing and what needs to explicitly specify that it wants python2. Somewhere in this is lurking a possibility of supporting different python runtimes such as Jython, Cython, PyPy and whatever else crops up. That's neat, too. Thanks for your attention. Comments, questions? regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] So I packaged up darcs; now what do I do with it?
by Damien Radtke 13 Sep '12

13 Sep '12

Darcs is a version control system written in Haskell, and in order to learn more about packaging, I decided to try and package it up. As luck would have it, I now have a fully packaged version sitting in my home repository: https://build.opensuse.org/package/show?package=darcs&project=home%3Akog13 It has build dependencies on packages in devel:languages:haskell and devel:languages:haskell:next, but the program itself can be used for more than Haskell development. So my question comes in several parts: 1) Where would the ideal place to submit this package be? Is it too late to get it in one of the default repos for 12.2, or would Packman be better? 2) Am I correct in thinking that the repos holding build dependencies (in this case, the haskell development repos) aren't necessary to be subscribed to when a user installs it? 3) What are some things to keep in mind when trying to submit new packages to a repository? I'm pretty new at this, so any help or advice is welcome. Thanks, ~Damien -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 7

[opensuse-packaging] Where do screenshots come from?
by Greg Freemyer 12 Sep '12

12 Sep '12

All, I recently packaged httrack and I see on http://software.opensuse.org/search?q=httrack there is a screenshot. I'm just curious where that came from. Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] SLE11 and libgomp
by Claudio Freire 11 Sep '12

11 Sep '12

Hi. Another issue with SLE11 I cannot find information about. I have a package that requires libgomp, but a specific version of it. All other opensuse versions work by BuildRequiring "libgomp.so.1(GOMP_2.0)". But SLE11 doesn't seem to get the hint. Thing is, the build log[0] says libgomp46 is being installed, which ought to be right (libgomp45 works). But somehow, it isn't. I could find the gcc packages in OBS for openSUSE, to try to see what may be wrong with the BuildRequires, and in fact that's how I came up with that buildreq. But not for SLE. Any idea guys? [0] https://build.opensuse.org/package/live_build_log?arch=x86_64&package=octav… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 5

[opensuse-packaging] Packaging Guidelines documentation in need of TLC
by Togan Muftuoglu 11 Sep '12

11 Sep '12

Hi, I was going to update couple of lua packages but I could not found any relevant information of lua packaging in <http://en.opensuse.org/openSUSE:Packaging_guidelines>. Now Fedora has a draft documentation at <http://fedoraproject.org/wiki/PackagingDrafts/Lua> and Debian has <http://pkg-lua.alioth.debian.org/policy.html> But the problem is not limited lua only, as currently openSUSE has no packaging policy for Lisp, Haskel, R. So looks like the documentation is neeeding TLC (Tender Love Care) if the goal is to have a higher packaging quality (ie. well documented patches and etc) Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] python-bindings ?
by Greg Freemyer 10 Sep '12

10 Sep '12

All, I was looking at the upstream sample specfile for one of my packages (libewf) and it has a python bindings sub-package that I don't currently have. The sample has: %files python %defattr(644,root,root,755) %doc AUTHORS COPYING NEWS README %{_libdir}/python*/site-packages/*.la %{_libdir}/python*/site-packages/*.so I don't think I've ever packaged a .la file, so it seems I should exclude that. Is that right? Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] Problem building an appliance
by Ilya Chernykh 07 Sep '12

07 Sep '12

When trying to build an appliance in Suse Studio I receive the following message: === Nothing provides package libxine1-codecs which is needed by package providing libxine1-codecs Remove providing libxine1-codecs === The entire "providing libxine1-codecs" is bold as a package name. When I click to remove it does nothing and the error message remains. No selected package has "xine" in name. I wonder what should I do to bypass this error. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Architecture question (noarch or i586/x86_64?)
by Karl Ove Hufthammer 06 Sep '12

06 Sep '12

Dear list members, I’m creating my first package, but I’m not sure if it should be considered noarch or i586/x86_64, and the documentation varies on the exact definition of noarch. Basically, my package *is* architecture-neutral, as the exact same package should work on all architectures, without any need for recompiling. Some features of this package: – Contains no binary (compiled) executable files. – Does contain a no-binary executable file – a shell script, which *uses* other binaries, like grep and awk and coreutils stuff. – Contains *data* files that are ‘built’. So, should it be considered noarch (rpmlint thinks so) or i586/x86_64? This is the package (and I’d appreciate any comments, as this is my first package): https://build.opensuse.org/package/show?package=ordbanken&project=home%3Ahu… -- Karl Ove Hufthammer http://huftis.org/ Jabber: karl(a)huftis.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 9

[opensuse-packaging] Dangling symblink warnings
by Togan Muftuoglu 06 Sep '12

06 Sep '12

Hi, I am trying to use rc* symlink for systemd services as outlined in <http://lists.opensuse.org/opensuse-factory/2012-07/msg00066.html> for Factory builds rctargets="shorewall shorewall-lite shorewall6 shorewall6-lite" for i in $rctargets; do %if 0%{?suse_version} > 1220 ln -sf /sbin/service %buildroot%_sbindir/rc${i} %else ln -sf %_initddir/${i} %buildroot%_sbindir/rc${i} %endif done but I am getting these warnings " shorewall6-lite.noarch: W: dangling-symlink /usr/sbin/rcshorewall6-lite /sbin/service horewall6.noarch: W: dangling-symlink /usr/sbin/rcshorewall6 /sbin/service shorewall.noarch: W: dangling-symlink /usr/sbin/rcshorewall /sbin/service shorewall-lite.noarch: W: dangling-symlink /usr/sbin/rcshorewall-lite /sbin/service The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain." How can I fix this warning as /sbin/service is in aaa_base Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] spec-cleaner breaking SLES build compatibility?
by Greg Freemyer 05 Sep '12

05 Sep '12

All, I noticed that security:srm was failing to build for OS 12.2. As part of doing the trivial clean up to make it work I ran spec-cleaner. It made this change in the install section: -make DESTDIR=$RPM_BUILD_ROOT install +%make_install Now srm in my home project no longer builds for SLES. The relevant error is "line 23: fg: no job control" Is that expected? Should I worry that in fixing OS 12.2 to build I broke SLES? My version of the project is at: https://build.opensuse.org/package/show?package=srm&project=home%3Agregfree… Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] To %make_install or to %makeinstall (spec-cleaner)
by Joop Boonen 05 Sep '12

05 Sep '12

Hi all, I have been using spec cleaner for while. What I notice it that it uses macro %make_install instead of %makeinstall. Both macros are OK for openSUSE but the first one breaks the build for SLE. <quote> + %make_install /var/tmp/rpm-tmp.59594: line 45: fg: no job control </quote> I wonder if this should be fixed, in either spec-cleaner (use%makeinstall in stead of %make_install) or in the buildserver (add macro %make_install for SLE)? Regards, Joop. See also: https://bugzilla.novell.com/show_bug.cgi?id=712171 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 12

[opensuse-packaging] Не знаю что делать
by Соболевская Галюся 04 Sep '12

04 Sep '12

Хай ты симпотяжка, если скучно и есть желание подружиться заходь ко мне на страничку http://demsac.org/media.php -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Changes in the openSUSE Review team
by Andreas Jaeger 01 Sep '12

01 Sep '12

The review of packages to openSUSE Factory and the released openSUSE distributions have been done in the past by an SUSE internal team. Sascha Peilicke, who's currently on paternal leave, did the vast majority of reviews in the past months. We have now properly formed a review team and started discussing our guidelines and best practices. We created a couple of wiki pages to describe what we are doing (use http://en.opensuse.org/openSUSE:Factory_submissions) If you like to reach the review team directly, please send an email to review(a)opensuse.org. In general, policy discussions and changes will happen on the opensuse-packaging mailing list. The team currently consists of Andreas Jaeger, Berthold Gunreben, Craig Gardner, Dominique Leuenberger, Lars Vogdt, Marcus Rückert, Michal Vyskocil, Rüdiger Oertel, Sascha Peilicke. We'd like to grow the team slowly over time with packagers that have shown good review and packaging skills. Our goal is to document our guidelines - and do a good review to improve the quality of openSUSE's packages. If we err, please tell us - we cannot know everything and might sometimes be too cautious if we do not understand what and why something gets changed. Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 15

[opensuse-packaging] updating desktop files?
by Greg Freemyer 01 Sep '12

01 Sep '12

All, Someone packaging a SLES version of httrack advised this should work in the specfile without patching the code: %suse_update_desktop_file WebHTTrack-Websites Network WebBrowser %suse_update_desktop_file WebHTTrack Network WebBrowser httrack in the security repo currently has the below patch instead. When I try the above in the httrack version in my home project (home:gregfreemyer:Tools-for-forensic-boot-cd), it fails to build. Is there an openSUSE way to handle this in the specfile and not with a patch? ============ --- html/server/div/WebHTTrack.desktop 2011-07-16 20:07:20.000000000 -0500 +++ html/server/div/WebHTTrack.desktop.orig 2011-07-16 20:03:59.000000000 -0500 @@ -1,9 +1,9 @@ [Desktop Entry] Version=1.0 Type=Application -Categories=Network; +Categories=Network;WebBrowser; Terminal=false Name=WebHTTrack Website Copier Comment=Copy websites to your computer Exec=webhttrack -Icon=/usr/share/httrack/icons/webhttrack.xpm +Icon=webhttrack --- html/server/div/WebHTTrack-Websites.desktop 2011-07-16 20:02:26.000000000 -0500 +++ html/server/div/WebHTTrack-Websites.desktop.orig 2011-07-16 20:04:28.000000000 -0500 @@ -1,9 +1,9 @@ [Desktop Entry] Version=1.0 Type=Application -Categories=Network; +Categories=Network;WebBrowser; Terminal=false Name=Browse Mirrored Websites Comment=Browse Websites Mirrored by WebHTTrack Exec=webhttrack browse -Icon=/usr/share/httrack/icons/webhttrack.xpm +Icon=webhttrack Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3