openSUSE Packaging October 2005

packaging@lists.opensuse.org

31 participants
25 discussions

Packaging advice
by David Bolt 24 Nov '05

24 Nov '05

I've written spec files for a few packages that weren't available for SUSE, purely picked at random, just to see how well I can do at producing packages. The packages I've built successfully build on all SUSE versions from 9.0 to 10.0, although I don't foresee any problems building them on the 10.1 alphas/betas. What I'd like is for someone who's rather more experienced at packaging, which wouldn't take much really, to have a look at the spec files and see if there's anything that could be done to improve things[0]. At present I've copied the spec files and source RPMs to the free web-space provided by my ISP. Unfortunately, due to lack of space, I haven't been able to copy any of the pre-build packages. I would have hosted them on my home server, but that's on the end of a 256Kbps up-link that's presently pretty close to saturation (limited to ~80-90%) due to me keeping the 10.0, 10.0 delta[1] and 10.1alpha2 torrents running. The specs and source RPMs are presently located at: <URL:http://www.davjam.demon.co.uk/srpms/> Any suggestions, hints, tips, criticism, etc. (gratefully?) received. [0] I've already started using "install -D ..." in place of "mkdir -p" and "install ..." although, in some instances, it's failed to work in some instances so I've had to use "mkdir" and "install" [1] Not sure why I've still got the delta torrent still running as there doesn't seem to be many people either sharing or downloading the deltas. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ AMD1800 1Gb WinXP/SuSE 9.3 | AMD1300 512Mb SuSE 9.0 | AMD2400 256Mb SuSE 9.0 AMD2400 160Mb SuSE 10.0 | Falcon 14Mb TOS 4.02 | STE 4Mb TOS 1.62 RPC600 129Mb RISCOS 3.6 | A3010 4Mb RISCOS 3.11 | A4000 4Mb RISCOS 3.11

5 5

Packager communication + teamwork (was: mplayerplug-in)
by Pascal Bleser 07 Nov '05

07 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Ogley wrote: >> in the moment, Rainer Lay hasn't much time, so i'll try to "fix" missing rpms >> for 10.0. mplayerplug-in is now online on packman. ;) > > Cool, I've removed my packages now. > Teamwork - it's a beautiful thing :) Well, as I said/wrote again and again, it definately shows that we've been lacking a common communication media. Duplicate packages, recurring issues, maybe discussing over common style/guidelines for spec files, etc... At least that's the kind of things I hope we'll be able to talk about in some time (or maybe right now). We definately need to work much closer together. Most specifically, having duplicate packages is a big issue: 1) often they're not compatible and/or conflict: different package name, different subpackaging, ... 2) issues for end-user who have several repositories in their inst sources That's certainly the worst issue of them all, as we all want to give end-users a good experience and easy of use, without what we wouldn't do all this packaging stuff ;) 3) duplicated work Partly wasted time and effort for us packagers - and time sure is a valuable resource for all of us. This also means that we should keep this list clear from any support question ("yast gives me an error when I try to do a netinstall"-alikes). Package-related bug reports.. hmm... why not. Someone from SUSE mentioned that we could also use the openSUSE bugzilla to report issues about our "community-made" packages. I don't remember who it was... Adrian, AJ, Christoph... ? I would have a proposal: every time one of us makes a new package (not a new release, but start packaging a project you didn't do before), send a mail on this list. Like that, if someone else already packages/maintains it, we/they can discuss who maintains it, in order to avoid duplication. What do you guys think ? Feasible ? Too much overhead ? Also, when we find out about cool RPM/spec tricks, gotchas, bugs, tools, scripts, whatever, publicize it here. This list can also be used to extend our know-how. If some information is considered interesting or important enough to be "sticky", we can write it on the opensuse wiki. If noone is against it, I'll start doing so right now. What about everyone maintaining a public repository introducing himself here ? - - shortly - - what repository do you maintain (suser-guru, usr-local-bin, packman, suser-gbv, ...) - - what kind of software in your repo (anything, multimedia, server stuff, ...) - - what SUSE versions do you build for - - repo URLs/formats - - email address, jabber ID, ... Or maybe a page on the opensuse wiki ? 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDX05Sr3NMWliFcXcRAo0VAJ42bRQvrIjNfl+gxh3UEDBBouuJ0ACfZCr6 SUDyfdtnlZwyXvHPUBcUHxM= =YAFG -----END PGP SIGNATURE-----

13 15

New package: k9copy
by Detlef Reichelt 31 Oct '05

31 Oct '05

http://packman.links2linux.de/?action=687 Detlef

1 0

dot desktop files: run as root (KDE/GNOME)
by Pascal Bleser 29 Oct '05

29 Oct '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi This time I have a question ;) I quite often package up apps that have to run as root (e.g. smart, aptitude, ...), including console applications. I almost always add a .desktop file to have it appear in the users' menu (even though it's a console app). Now, my question... For KDE I found out somehow (it's not documented *anywhere*) that when you add the following two lines to your .desktop file, it will prompt the user to enter the root password (using kdesu) and then run as root: X-KDE-SubstituteUID=true X-KDE-Username=root Is this the right way to do it ? And what about GNOME ? Given the X-KDE- prefix, it only applies to KDE. What tags do I have to add to a .desktop file to force an "su" (gnomesu, whatever) to the root user? James, you should know that .. ? ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDY4iFr3NMWliFcXcRAkN+AJ91/jw49gcxYvc2AGFir5RSxrenAwCgl8bI U7Y5n0wI2JcGnzGTNEf1wNU= =NoUf -----END PGP SIGNATURE-----

2 1

Package naming & versioning (release 2 :-)
by R Hannes Beinert 29 Oct '05

29 Oct '05

[Apologies for my previous truncated email :-] Hello! I was curious if there is any standard (ad hoc, or otherwise) for package naming, and the spec file version/release information which includes provisions for (1) tagging the provenance of an rpm to a particular packager/repo, and (2) still allows for rpm-based installers to understand the proper package relationships. Specifically, my understanding of existing packging conventions (in part derived from practice, and in part derived from the SuSE Package Conventions document) a package consists of: <packagename>-<version>-<release>.<arch>.rpm where, <version> ::= <major version>.<minor version>{.<other stuff>} <release> ::= <release number>[.<release version>] and, it seems by convention, <major version> ::= Usually a number <minor version> ::= Usually a number <release number> ::= Always a number, set to zero on version update <release version> ::= Always a number, set to zero on release update However, within the spec file, if the release-tag has additional information regarding the rpm provenance, such as Pascal's convention of using "package-v.v-r.guru.distro.arch.rpm" where the release-tag is, for example, "1.guru.suse90" -- can rpm installers still typically track package sequences? The SuSE Package Conventions document implies a stricter standard for the release-tag. If a more informative release-tag is used, would it then be advisable to use the serial-tag? Or is that tag now deprecated, or ignored by rpm installation software? On a related matter, what are the most portable conventions for package naming and specifying version/release information? Thanks! Hannes. __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

1 0

Package naming & versioning
by R Hannes Beinert 29 Oct '05

29 Oct '05

Hello! I was curious if there is any standard (ad hoc, or otherwise) for package naming, and the spec file version/release information which includes provisions for (1) tagging the provenance of an rpm to a particular packager/repo, and (2) still allows for rpm-based installers to understand the proper package relationships. Specifically, my understanding of existing packging conventions (in part derived from practice, and in part derived from the SuSE Package Conventions document) a package consists of: <packagename>-<version>-<release>.<arch>.rpm where, <version> ::= <major version>.<minor version>{.<other stuff>} <release> ::= <release number>[.<release version>] and, it seems by convention, <major version> <minor version> <release number> <release version> are numbers. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

Common naming scheme for KDE styles, windecos, ...
by Pascal Bleser 28 Oct '05

28 Oct '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Something I've been running into again and again... Could we discuss having a common naming scheme for KDE styles and windeco packages ? e.g. kde3-style-..., kde3-windeco-... IMHO it's better to prefix the package name like that instead of just using the project name alone. e.g. "kde3-style-kurses" instead of just "kurses" Comments, please ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDYWZMr3NMWliFcXcRAg6vAKCO8vzSCrwPkq3JkMYRqDlFR1gNvgCdF1Iu c9rP4P+lMc98cEdv3ajUDSg= =lap7 -----END PGP SIGNATURE-----

3 2

Re: [opensuse] rpmbuild screws up install path with mythtv]
by Guðlaugur Jóhannesson 28 Oct '05

28 Oct '05

Originally posted on opensuse but I thought packagers might better be able to help me. Sorry for multi posting. Anders Johansson wrote: > The Makefile for mythtv is highly screwy. For one thing, it doesn't respect > DESTDIR or anything like that, you'll need to change it to make it work with > rpmbuild I agree with that and I am changing it now. The problem, however, is that calling qmake (qt3 version) from rpmbuild results in weird behavior with both the prefix and some include paths. It seems that qmake changes some instances of the /usr directory to ../../../../../../ when called from rpmbuild. It does not do that with the qt4 version or when manually calling the qt3 version. Could this be a bug with qmake from qt3? -- Guðlaugur Jóhannesson http://www.hi.is/~gudlaugu Tel: 849 8405 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-help(a)opensuse.org -- Guðlaugur Jóhannesson http://www.hi.is/~gudlaugu Tel: 849 8405

2 2

New package: konzept
by Herbert Graeber 27 Oct '05

27 Oct '05

I start building konzept for packman (x86_64 und i586). herbert

2 1

suser-guru: new packages
by Pascal Bleser 27 Oct '05

27 Oct '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, eating my own dogfood ;) - - amarok 1.3.5: not a new package but a new release.. just in case, is anyone else packaging that ? - - kurses 0.1: a minimalistic KDE3 widget style - - stellarium 0.7.1: new package, had several requests for that one - - metamonitor 0.2: /var/log/messages monitor systray, very early stages - - kasound 0.5_0.2: configuration frontend for alsa/.asoundrc If anyone else packages one of those, please shout. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDX/ujr3NMWliFcXcRArm2AKCckIFQUvXXhNZFW5hHHp6EFmAgRQCgpA4O vHKu8Jlf8+3IRbn+O1LVM2U= =ZVmk -----END PGP SIGNATURE-----

3 4

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging October 2005