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
-----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-----
-----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-----
[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
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
-----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-----
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
-----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-----