openSUSE Packaging June 2008

packaging@lists.opensuse.org

31 participants
22 discussions

by Stephan Kulow

Hi, Yesterday I learned something new and I think, so will you now: most of us (including me) did package renames the wrong way and the documentation in the wiki on it is unfortunately not very clear. So let me get this straight and I hope everyone will use it correctly from now on: oldpac.spec: Name: oldpac Version: 1.0 baselibs.conf: oldpac You want to rename it to newpac on update, what do you have to do? newpac.spec: Name: newpac Version: 1.1 Provides: oldpac <= 1.0 Obsoletes: oldpac <= 1.0 baselibs.conf: newpac obsoletes "oldpac-<targettype> <= 1.0" provides "oldpac-<targettype> <= 1.0" That's it - please always use <= with the latest version oldpac had, everything else is most likely wrong. And don't forget about the baselibs. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 9 months

[opensuse-packaging] Factory: rpmlint fallout

by Dirk Mueller

Hi, there is some fallout from the rpmlint 0.83 (new upstream release) upgrade in Factory, where a broken change caused a bootstrap issue and consequently all packges failed, and even a fixed package didn't build anymore. Please ignore rpmlint related failures today, everything should be back to normal tomorrow. Greetings, Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

[opensuse-packaging] python 2.6 and python3 in openSUSE 11.1 and beyond

by Jan Matějek

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello everyone, both Python 2.6 and Python 3.0 final releases are scheduled on Sep 04 [1], and they are both going into openSUSE 11.1 During this week i'm going to submit Python 2.6 to BETA (and probably mirror it to BuildService as well), and prepare a Python 3.0 package in BuildService, called "python3". Then i will be away for two weeks, and when i return, i'll start moving things to STABLE/Factory Gentle introduction - --- Python 2.6 is planned to be the last release of 2.x series. It should be mostly backwards compatible to 2.5, and also forward compatible to 3.0. Python 3.0, dubbed Py3k, will be massively *backwards incompatible*, and most of existing python code will not work in it. To ease the transition, there are two things: - - "2to3" converter script [2], which can translate existing 2.x compatible code to 3.0. The script is part of Python 2.6 release. - - Python 2.6's __future__ imports and Py3k warnings mode, which, simply put, turn 2.6 interpreter into 3.0-compatible transition device. Quoting PEP-361 ([1]): >> Python 2.6 is not only the next advancement in the Python 2 >> series, it is also a transitional release, helping developers >> begin to prepare their code for Python 3.0. As such, many >> features are being backported from Python 3.0 to 2.6. Thus, it >> makes sense to release both versions in at the same time. The >> precedence for this was set with the Python 1.6 and 2.0 release. Python 2.x series is slowly going to be deprecated in favor of 3.x series - but it seems now that it's a matter of years, not months. Inclusion proposal - --- 1. Python 2.6: Nothing much to say here, that should be a simple version increase. No major changes like 2.5's Py_ssize_t mayhem are planned. /usr/bin/python will be a symlink to /usr/bin/python2.6, and in addition /usr/bin/python2 will also be a symlink to python2.6. 2. Python 3.0: This is basically a "new product" which is going to be installed alongside and not colliding with regular 2.x python. Its binary will be /usr/bin/python3.0, and a symlink /usr/bin/python3. No packages depending on python 2.x should be harmed by having py3k present. Also, there probably won't be any packages depending on py3k yet. regards, m. [1] http://www.python.org/dev/peps/pep-0361/ [2] http://svn.python.org/view/sandbox/trunk/2to3/ - -- (if you have any comments, please CC me in the reply, otherwise my replies will break threads. that is a bug in my way of using the mailinglist, which is not yet fixed) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhilvoACgkQjBrWA+AvBr9TOwCfVZuYUlMYHn4Zkg0rarka/5O7 Z40An0Peh/qXFldNFxkJurqYP3UU5xoC =deZV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

[opensuse-packaging] libldap-2_4-2 branched off openldap2-client

by Ralf Haferkamp

Hi, as already mentioned yesterday, I reorganized the openldap2 packages according the the shared library policy. For that I just submitted new packages to autobuild. The openldap client libraries (libldap and liblber) have been moved to the libldap-2_4-2 Package. The openldap2-client package now only contains the command line tools (ldapsearch and so on) and the related manpages. Normally you should not notice anything of the change as the dependencies on the libraries are generated automatically and the name of the development package (openldap2-devel) that should be used in BuildRequires has not been changed. If you are maintaining a package that has a direct dependency on openldap2-client you should probably check that package if that dependency is really needed. -- regards, Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

[opensuse-packaging] Java program installations

by Dirk Stöcker

Hello, I do not know how to package java classes. Programms are stored in /usr/share/java, but where do I store classes used by these (in .jar format) and what about support libraries. Especially I talk about the packages "BT747" and "rxtx-java" in Application:Geo project of BuildService. I have a working solution, but I'm pretty sure the current solution is not correct. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

[opensuse-packaging] Shared library packaging policy

by Ralf Haferkamp

Hi, I am currently trying to split one of my packages (openldap2) according to the shared library packaging policy and I am wondering what the correct package name would be. The SONAME of the main library is: "libldap-2.4.so.2". According to the policy that would make a package name of: "libldap-2.4-2". But AFAIK we have some rule that dots in the package name are not allowed, is that correct? If yes, what would be the correct package name? BTW, to keep the required changes in other packages as minimal as possible I will not rename the main development package. That will still be called openldap2-devel. Renaming that would require changes in tons of other packages' Buildrequires. -- regards, Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

Re: [opensuse-packaging] is use of /srv/www in packages good practice?

by Herbert Graeber

On Tuesday 17 June 2008 16:27:35 Ludwig Nussel wrote: > While moving my files to a new workstation I stumbled across > /srv/www. The directory contains a mix of self written stuff and > distro packages. So I needed to take care to only copy my own files. > I'd assume that someone who actually uses /srv/www in production and > cared about the content would have a similar problem when creating > backups. The apache packages allows other packages to simply > drop a config file into /etc/apache2/conf.d and install e.g. a > custom directory alias this way. So files that need to be accessible > via http://somehost/foo do not actually need to be stored at > /srv/www/htdocs/foo but can reside in e.g. /usr/share/foo. So I > wonder what's best practice for packages. Dump stuff into /srv/www > or use aliases in the web server config? FHS is quite unspecific wrt > use of /srv [1]. I have also thought about this when creating my trac packages. I have decided not to put the trac files below /srv/www/htdocs and instead to provide a conf file. But I am in doubt if this is the right thing. For my ldap-account- manager packages on Packman (which should be moved into the BS), I have decided to install below /srv/www/htdocs without being sure to do the right thing, too. I had a look on other packages. The medaiwiki packages for example are installed below /srv/www/htdocs. One thing I discovered that might infer with an out of /srv/www/htdocs installation is apparmor. It seems that it expects that all web pages are installed below /srv/www/htdocs. For packages installed elsewhere it's rules must be modified. Cheers herbert --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 10 months

[opensuse-packaging] is use of /srv/www in packages good practice?

by Ludwig Nussel

Hi, While moving my files to a new workstation I stumbled across /srv/www. The directory contains a mix of self written stuff and distro packages. So I needed to take care to only copy my own files. I'd assume that someone who actually uses /srv/www in production and cared about the content would have a similar problem when creating backups. The apache packages allows other packages to simply drop a config file into /etc/apache2/conf.d and install e.g. a custom directory alias this way. So files that need to be accessible via http://somehost/foo do not actually need to be stored at /srv/www/htdocs/foo but can reside in e.g. /usr/share/foo. So I wonder what's best practice for packages. Dump stuff into /srv/www or use aliases in the web server config? FHS is quite unspecific wrt use of /srv [1]. cu Ludwig [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSY… -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 11 months

[opensuse-packaging] Security update of Opera (9.5)

by Rafał Miłecki

SGksCgpSZWNlbnRseSBPcGVyYSA5LjUwIHdhcyByZWxlYXNlZCB3aXRoIHNvbWUgc2VjdXJpdHkgZml4ZXMuIFlvdSBjYW4KZmluZCBjaGFuZ2Vsb2cgaGVyZToKaHR0cDovL3d3dy5vcGVyYS5jb20vZG9jcy9jaGFuZ2Vsb2dzL2xpbnV4Lzk1MC8KCkNhbiB3ZSBjcmVhdGUgT3BlcmEgOS41MCBwYWNrYWdlcyBhbmQgcHV0IGl0IGludG8gdXBkYXRlIGZvciBvcGVuU1VTRT8KSSBiZWxpdmUgaXQncyBxdWl0ZSBpbXBvcnRhbnQgYXMgOS41MCBmaXhlcyB0aGVyZSBzZWN1cml0eSBidWdzLgoKCi0tIApSYWZhxYIgTWnFgmVja2kK---------------------------------------------------------------------To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.orgFor additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 11 months

[opensuse-packaging] maven - package

by Denny Beyer

Hello again, i need maven to build a project i would like to package. the maven package seems to be kind of abandoned. There seem to be no official package available, when checking with packages search. Which package does work? Anyone taking care of this still? Are there any other options building maven packages? Cheers, Denny --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years, 11 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging June 2008