- openSUSE Packaging

dropping and renaming plan for GNOME1 (GTK1)
by Stanislav Brabec 19 May '06

19 May '06

Hallo. After four years after GNOME2/GTK2 release, the last "killer" application - gnucash, will be finally ported to GNOME2. So we are ready to drop GNOME1 from SuSE Linux. There is a proposal of the dropping plan: Phase 1 (August 2003): Drop everything not needed for gnucash 1, rename foo2 to foo, if applicable. Status: Done Phase 2 (May 2006): Drop everything except core GNOME1. Status: Done Packages for dropping: bonobo control-center gconf gnome-print gnome-spell gnome-vfs gtkhtml oaf Affected packages: none Phase 3 (May 2006): Think about robust naming scheme of packages, where can coexist in more major versions without confusion and often renaming. See below for discussion summary. Phase 4 (near future): Drop core GNOME1. Status: Little work needed Packages for dropping: libglade libxml orbit gnome-libs Affected packages: loki_setup, loki_update (installer) Proposed solution: http://www.icculus.org/loki_setup/ frontline (frontend for autotrace) Proposed solution: drop coriander (IEEE-1394 Digital Camera Controller) Proposed solution: Replace, drop or port soundtracker (sound tracker) Proposed solution: Replace, drop or port bombermaze (game) Proposed solution: Replace or drop gdk-pixbuf (image library) Proposed solution: do not package GNOME1 extension perl-Gtk-Perl (perl bindings) Proposed solution: do not package GNOME1 bindings unixODBC-gui-gtk Proposed solution: do not package GNOME1 interface and popular third party ogle (DVD player) Phase 5 (sometimes in future): Drop GTK1. Status: A lot of work needed Packages for dropping: gtk, glib, gdk-pixbuf, gtk-engines imlib Affected packages: ami gal gau xmms-jack evms-gui pcsx surf xmms xzgv xmms-gnome2 winetools flac-xmms fvwm2 gqcam smpeg-gtv swami bidwatcher loki_uninstall powertweak-gtk python-xmms wmakerconf Xdialog manedit perl-Xmms WindowMaker-applets sylpheed-claws amarok-xmms ardour gbuffy gentoo squaroid gtkzip nicolatter glchess kanji-lookup pcpmon perl-Gtk-Perl alsaplayer TeX-Guy unison procmeter usbview xdelta xmorph sipset xlogmastergoom2k4 xmms-plugins xarchon and popular third party mplayer Proposed solution: Use gtk1-compat-devel (and extend it to cover more), drop, port, turn different frontend instead of GTK1, if available. Naming schemas: Desired properties: - only rename if absolutely not avoidable - use same name as upstream if possible - we can only have one package with an identical name Possible naming schemes: 1) mainline stable without number, old branches with number. Advantage: - use same name as upstream if possible for the head version Problems: - BuildRequires must not use package name but some feature virtual - The moment, when devel branch becomes stable, needs ugly renames - Will cause undefined RPM dependencies Result: Probably not acceptable 2) keep old branch as is and add suffix for new one Advantage: - simple Problems: - having branch number for half of packages is irritating. - additional rename is also not comfortable Result: Confusing use of branch numbers 3) keep old branch as is and add suffix for new one. Rename back, when old branch is dropped (It's the actually used approach.) Advantage: - simple Problem: - having branch number for half of packages is irritating. - many package renames Result: Current solution, ugly, partially confusing use of branch numbers 4) all branches with numbers deduced from, say .pc files names (maybe with dots and trailing zeroes removed). Advantage: - never rename package which does not change API Problems: - packages has names different from upstream - most packages will have untrivial name and version, e. g. gnome-vfs-2.0-2.12.3 (resp. gnome-vfs2-2.12.3) and also gtkmm24-2.8.2. Result: Needs to think twice before using this scheme. 5) ??? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec(a)suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/

1 0

Packaging style guidelines: %configure, %optflags, %buildroot etc.
by andreas.hanke＠gmx-topmail.de 19 May '06

19 May '06

Hi, are there any generic packaging "style" guidelines for SUSE Linux packages? More precisely, I have the following questions: - Is %buildroot preferred over $RPM_BUILD_ROOT? I'm asking because I see more and more packages switching from $RPM_BUILD_ROOT to %buildroot, but this macro is an implementation detail according to Red Hat's rpm-list: http://www.redhat.com/archives/rpm-list/2002-July/msg00121.html The environment variable is the documented thing. The same is the case with %optflags vs. $RPM_OPT_FLAGS IIRC. - Is %configure preferred over ./configure? IIRC until recently, no package in the distro used it and everything worked well without it. I'm asking that because %configure IMHO sucks terribly. It sets questionable values for --libexecdir, --localstatedir and --sharedstatedir for packages whose prefix is /usr, requires even more macros to be redefined for packages whose prefix is not /usr (/opt/kde3, /opt/gnome and /usr/X11R6 come to mind) and always sets --libdir to %{_prefix}/%{_lib} although it must remain %{_prefix}/lib for some packages. So what's the exact benefit of %configure? It makes some autoconf calls shorter by adding the right options and others longer by adding wrong ones, which have to be corrected manually, so we end up adding options manually in either case. - %optflags / $RPM_OPT_FLAGS again: Are they "nice to have" things or is not using them a bug that should be reported? - run-time and -devel packages Is there a general rule for splitting or not splitting library packages into run-time and -devel subpackages? Is this decided according to the size of a library, the number of header files, other criteria? I'm asking that because IMHO always splitting them is an interesting approach even for tiny packages as it allows third party people to package another version of the same library that has a different SONAME without having to worry about conflicts. The -devel packages would still be clashing in most of such cases, but the run-time packages can be installed in parallel. Andreas Hanke -- Mobile Internet - E-Mail und Internet immer und �berall! GMX zum Mitnehmen: http://www.gmx.net/de/go/pocketweb

3 4

FYI: Unresolveable dependencies
by Andreas Schneider 15 May '06

15 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've downloaded the 10.1 tree to compile my Packman packages for 10.1. The problem is there are really strange errors with y2pmbuild. It's a problem with the old packagemanager and rpm package alternatives. BuildRequires: kdebase3-devel unresolvable dependencies: *** Conflicts *** Name: avahi-compat-mDNSResponder Edition: 0.6.5-27 Referers: kdelibs3-3.5.1-47 requires libdns_sd.so()(64bit), kdelibs3-3.5.1-47 requires libdns_sd.so()(64bit) Conflicts-With: mDNSResponder-lib-107.5-8 conflicts with avahi-compat-mDNSResponder, mDNSResponder-lib-107.5-8 conflicts with avahi-compat-mDNSResponder, avahi-compat-mDNSResponder-0.6.5-27 conflicts with mDNSResponder-lib, avahi-compat-mDNSResponder-0.6.5-27 conflicts with mDNSResponder-lib Remove-To-Solve-Conflict: kdebase3-devel, kdelibs3-devel, mDNSResponder-devel, mDNSResponder-lib mDNSResponder-lib and avahi-compat-mDNSResponder provide libdns_sd.so, so you need as BuildRequires BuildRequires: mDNSResponder-lib kdebase3-devel -- andreas - -- http://www.cynapses.org/ - cybernetic synapses -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEZe2Qf94+j/M+P8YRAqJMAJ0dOA7pmA+k+gorpfNEl+tLkkPIAwCfSVLd KeUzSPKUAYL/SA/3n1LSS+Y= =8iQy -----END PGP SIGNATURE-----

2 1

Interchange for SUSE also requires non-threaded perl.
by Boyd Lynn Gerber 09 May '06

09 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to package and maintain interchange for SUSE LINUX. http://www.icdevgroup.org. It requires a non-threaded perl. The way I have been doing it is compiling a non-threaded perl and putting it in /usr/local/bin/. Installing from CPAN using /usr/local/bin/perl -MCPAN -e 'install Bundle::Interchange' Then creating the rpm for SUSE Linux. Interchange requires all these modules. I would like to use the build service to do this. I requested a build account in January of this year. Do you think this is something the community would like? Thanks, - -- Boyd Gerber <gerberb(a)zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEXzhBVtBjDid73eYRAjv6AJ9GFY9PDAz5VEBwScFU5f8TgzxX4ACfXZpp 8gzX572zf8hCYkENVHyKXDQ= =PsNa -----END PGP SIGNATURE-----

4 5

Questions on y2pmbuild
by Rauch Christian 09 May '06

09 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had a look at y2pmbuild and got it working by now, though there remain some questions to me: 1. When I build a few packages at once, which rely upon, the packages are written to the repository and createrepo/create_package_descr is called. (I can see this in the output). Though the next package fails, because it can't find the previously built package. When I take out the sources for the already built package and run y2pmbuild again, the next package builds and so on. Can this be solved? Is it a matter of config? 2. With SUSE 10.1, Repositories should be signed. How exactly can this be done and is it possible to automate this with y2pmbuild? 3. In general, is it possible to start a certain script after a build has been finished? 4. Is there any documentation available for y2pmbuild? Neither in the y2pmsh nor in y2pmsh-debuginfo in SUSE 10.0 is any documentation. The articles found on opensuse.org are helpfull, but they do not contain that much information. Regards, Rauch Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEYE1SayhvFxrDZlkRAuExAJ9cJ5HNcWTgn0JE/3j0GeEoQDaXdACfc5LB cLAkqwH42CHIe3jtKoQM7uU= =Wok6 -----END PGP SIGNATURE-----

3 8

y2pmbuild
by Martin Wilderoth 09 May '06

09 May '06

Hello I'm using the y2pmbuild tool to create a package. I'm compiling on an x86_64. Can i create i386 packages on the same plattform (64-bit) with the same tool ? Martin

2 1

Build service usage, osc
by Pascal Bleser 09 May '06

09 May '06

Hi folks Are there any guidelines on how to submit something into the Build Service ? I installed Peter's osc, which seems by far the most practical and comfortable way to use the Build Service (I mean, the web interface is "pretty" but useless IMO, at least to me - I want to script, automate, work on the shell, not click around in the browser). Now, when I "osc ls", I see various subdirs, like home:cihlarov playground_abauer Debian-etch AdriansPlayground qsvn Kopete packman SL10.0 Amarok_Devel etc... Those are all very different in structure and purpose. Is there any guideline on how to submit a project ? e.g. make it a toplevel (e.g. qsvn), have your own namespace (e.g. guru/amarok), ... ? Seems to me there isn't any as of now, which already causes chaos in the repository structure now, AFAICS ;) BTW, I'm already maintaining the latest amarok releases in my package repository. Let's pick that one as an example. How are we supposed to work together, to avoid duplicate efforts ? Or is it way too early to even consider it ? ;) cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels

2 1

denyhosts rpm
by Craig Millar 05 May '06

05 May '06

Hello all I've created an rpm for DenyHosts http://denyhosts.sourceforge.net/ which I find pretty useful. A brief synopsis first: Summary: DenyHosts is a utility to help sys admins thwart ssh hackers Description: DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins. I'm pretty inexperienced at rpm building, still learning really, and I was wondering if someone could take a look at the source rpm I've created and let me know if it's ok. You can find it here: http://www.craigmillar.org/DenyHosts-2.4b-5.src.rpm I'm attaching the spec file at the end of this message as well. My main concern with the spec file is that I'd like the main executable to be renamed denyhosts from denyhosts.py. I tried the following lines: ln -sf ../../usr/bin/denyhosts.py $RPM_BUILD_ROOT%_prefix/bin/denyhosts This works - but results in denyhosts and denyhosts.py in /usr/bin, so this is in the linked to version. mv ../../usr/bin/denyhosts.py $RPM_BUILD_ROOT%_prefix/bin/denyhosts This doesn't work at all, which baffles me somewhat, as it's referencing the same directory. Bah. Finally, if this package is considered useful, how do I go about submitting it for wider use? I can't promise to maintain it, but I think it's a pretty nifty tool that would be of benefit to others. Thanks for any responses Craig

1 0

Signing RPM packages in 10.1
by Marcel Hilzinger 02 May '06

02 May '06

Do 10.1 packages have to be signed by default? -- Mit freundlichen Grüßen, Marcel Hilzinger Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99

2 3

Dear "packager" of mozilla firefox
by Johan N. 02 May '06

02 May '06

I hope I found the right spot for this: I'd like to know who controls the version-numbering of mozilla Firefox inside SuSE as it's not quite compatible with what some banks demand despite the fact that there was an update via YOU lately :) I hope I can encourage whoever it is to follow the "official" Mozilla Firefox version-numbering because thats where others look. Novell/SuSE is not big enough to dictate that yet ;) Luckily you had a more reasonable version 1 and half months ago in the supplementary section of the ftp site but not the smartest way to have things done and for some to be able to do some online banking ;) A browser like Mozilla Firefox should be kept much more "current" than in the past. Keep up the good work (generally) at opensuse.org/suse Yours Johan

5 7