RPM submission script
by Eric S. Raymond
The next point release of Bugzilla will include and support a script
called bug-bugzilla, written by Christian Reis and myself, that allows
posting of bugs without going through a Web interface. You supply an
RFC822-like message on input instead.
Some may recall my urging that submission of RPMs for Fedora needs to
be scriptable. I followed through by working with the Bugzilla crew
to build and document this tool. The bug-bugzilla script is the
essential piece of infrastructure for scriptable RPM submissions to
happen. It abstracts away the details of interacting with Bugzilla CGIs.
I therefore propose the following:
1. A bug-bugzilla RPM should become part of Fedora core.
2. I will write a fedora-submit script, which will call bug-bugzilla.
3. fedora-submit should become part of the Fedora RPM tools RPM, with
a dependency on bug-bugzilla.
Later, if Fedora's submission channel for RPMs changes, fedora-submit
can be changed to suit. The important thing, in my opinion, is to get
a fedora-submit mechanism in place in order to encourage contributions
from people like me who run lots of projects and need scriptable RPM
submission to support that.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
-- Daniel Webster
20 years, 7 months
Re: ReiserFS in Anaconda?
by Michael Davies
> Jesse Keating wrote:
>
> Why does people want XFS? Any _special_ feature?
XFS was developed by SGI a while ago and has been in Irix for a longer
_time_ than any of ext2/3 and reiserfs (not sure on jfs. ext2 probably
has had more instances ever run, but I digress). This speaks for XFS's
rock solid stability.
As also mentioned here, terabyte filesystems and proper ACLs are included.
Important stuff. I'd be installing XFS be default if anaconda had it.
--
Michael Davies Linux.Conf.Au Adelaide Jan 12-17 2004
michael at msdavies dot net Australia's Premier Linux Conference
http://lca2004.linux.org.au
20 years, 7 months
Distags in rpm sort order (yes, versioning again ;)
by Axel Thimm
Bringing up this topic again, since it was left unresolved.
I won't go into details again, about *why* a disttag is needed and why
it has to adhear to rpm internal sort algorithms. Please check the
following threads in doubt (and discuss the reasons there please, help
keeping this thread constructive this time ;):
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551....
http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263....
The bottom line is that distags are needed if one wants to create
packages for the same upstream sources but built for different
distributions. Disttags can then be embedded in the release tag to
ensure proper upgradability.
==================== Disttag schemes: pick one!
Here are the discussed schemes (some others exist with small
variations, e.g. fc instead of fdr, or no fdr tag at all, the
discussion is the same). Default versioning is (no cvs/beta, kernel
modules and special cases, leave that for another thread):
<name>-<upstream version>-<releasenumber><disttag><non sort relevant suffixes, e.g. repoid>
e.g. simply
foo-1.2.3-4.<disttag>.johnsmith
disttag can be:
A B C
Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3
Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0
Red Hat Linux 9 fdr0.9 rh9 rh9
Fedora Core 1 fdr1 rh9.1 1fdr
Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr
A) + consistent distid
+ future tagging will be self-explanatory
+ fits nicer into a general nameing scheme (e.g. not only RHL and
FDR, but RHEL and non-RH could use, or allready do use the
<disttag>:=<distid><distversion> idiom)
- obfuscates RHL <= 9 rpm versioning
- requires rebuilding of existing 3rd party repos for the sake of
versioning.
o requires a statement from redhat to allow calling RH 7.3 as FDR
0.7.3 for instance, e.g. the "old" RHL product is officially
conamed Fedora 0.something
B) + current practice for many repos offering rpms build form the same
upstream sources for more than one distribution.
+ keeps current 3rd party repos from rebuilding all the old rpms
just for reversioning (and users from redownloading the same rpms
with a new name)
- does not pertain the strict separation RHL <-> FDR, and may cause
confusion.
o A) is preferable, but B) may be a nice transition solution for
existing installations.
C) + visually pertains separation of rh and fdr releases
- is a kludgy workaround using rpm semantics present only after
RHL9, thus breaking upgrading from RH8.0 and less (note that rpm
errata for fixing this rpm bug and others are still not
officially available)
- number prefixing breaks when the preceding expression is numeric
separated with dots or underscores, e.g.
foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr
(the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1")
Using decimal release tags needs to be separately considered, but
the fact is that they are being used often.
- reverses order of distid and distversion
- Variant "1fdr<version>" keeps order of distid and distversion,
but breaks in all other ways above, as well as introducing an
obfuscating decimal in the release tag.
I hope RH agrees to using A) or a variant thereof. In any case it
would be beneficial if an "official" solution could be blessed, so
that 3rd party repos don't have to reinvent their own
versioning.
Certainly many repos will start offering their packages (officially)
after FC1 is (officially) released, so there are only a few days left
...
In order to not molest users with forced downloads for reversioning
rpms for older RHL releases, I would suggest to use B) in a transition
phase for large rpms that do not need updating other than the
reversioning. After some time B) will have been phased out.
C) is not really an option. It will break more than it is intended to
salvage.
Also it would be nice to have rawhide versioning, e.g. immediately
after a release update fedora-release to the next test release
version or something below to indicate rawhide builds.
Thank you for your time.
--
Axel.Thimm(a)physik.fu-berlin.de
20 years, 7 months
Warren's Package Naming Proposal - Revision 1
by Warren Togami
http://www.fedora.us/wiki/PackageNamingGuidelines
The following is based upon current fedora.us package naming guidelines,
quickly edited and dramatically simplified because fedora.redhat.com no
longer needs many of fedora.us special considerations.
The below proposal is ALMOST EXACTLY THE SAME as fedora.us current
scheme except with the leading "0.fdr." removed from all %{release}
tags. I would assert that fedora.us package naming scheme has
demonstrated to be a great success, thus it should continued in
fedora.redhat.com. The below scheme is also in-line with the common
practices used by most of Red Hat's existing packages.
This proposal is missing considerations for 3rd party repositories.
Theoretically 3rd party repositories should no longer have a reason to
publish the same %{name} of any packages that exist in FC or FE because
changes should be incorporated upstream. There are however some cases
like kde-redhat where this is not possible, so we really need to discuss
possible solutions to this. Earlier we had discussed the possibility of
simply adding a %{reptag} to the far right of %{release}.
Fedora Package Naming Guidelines
Warren's Proposal for fedora.redhat.com
Revision 1
================================
i. Introduction
Goals for package naming guidelines
ii. Terminology
A. Package Name
B. Version
C. Release Tag
1. Release Prefix
2. Vepoch
3. Non-Numeric Version to Release
4. Dist tag
5. Special: Kernel modules
6. Special: Plugin, theme etc packages
7. Special: Minor Number
i. Introduction
===============
Goals for the Fedora Package Naming Guidelines
* Easily understandable package naming policy
* Indication of the original source version (end-user convenience)
* Allow for a smooth upgrade path between multiple levels of testing
branches and future distribution upgrades. This means E-V-R must never
be exactly identical between distribution versions.
* Minimize the chance of package conflicts for future Fedora
distribution upgrades.
ii. Terminology
==============
name
This is the "Name" field of RPM .spec files.
version
This is the "Version" field of RPM .spec files.
release tag
This is the "Release" field of RPM .spec files.
dist tag
This is a distribution tag indicating which RHL/FC distribution this
package is intended for. This only occurs in cases where packages from
different distributions are built from the same SRPM and patchlevel.
vepoch
This is our term for "version specific epoch", used in all packages as a
simple means of ensuring upgrades by simple incrementing the leading
number within the release tag. vepoch is otherwise known as "release
number" or "patchlevel". Read C-2 for more information.
E-V-R
Abbreviation for epoch, version, and release. This is often referred to
when talking about potential package upgrading problems.
A. Package Name
===============
Package name should preferably match the upstream tarball or project
name from which this software came. In some cases this naming choice is
more complicated. If this package has been packaged by other
distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS,
etc.) in the past, then we should try to match their name for
consistency. In any case, try to use your best judgement, and other
developers will help in the final decision.
Ultimately it is up to QA to decide upon the proper %{name} before
publication.
B. Version
==========
If the version is only numbers, then these numbers can be put into the
"version" field of the RPM .spec unchanged. If the version contains
non-numeric characters, this creates several problems for RPM version
comparison and a broken upgrade path.
Example:
foobar-1.2.3beta1.tar.gz
foobar-1.2.3.tar.gz
While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM
version comparison thinks the former is newer.
Example:
foobar-1.0a
foobar-1.0b
The "1.0b" version is higher than "1.0a", but all versions of RPM prior
to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever
package is first in the comparison "wins", thus this becomes a two way
upgrade problem. This a < b comparison works properly only in RH9 and
higher.
For simplicity, Fedora treats both pre-release and post-release
non-numeric version cases the same, making the version purely numeric
and moving the alphabetic part to the release tag. Take the numeric
portion of the source version and make that the package version tag.
Read C-3 for more details.
C. Release Tag
==============
The release tag of Fedora packages more complicated, so this is split
into several parts.
C-1. Release Prefix
-------------------
No longer needed in fedora.redhat.com.
C-2. Vepoch
-----------
The leftmost leading number within the release tag is the "version
specific epoch" or vepoch in Fedora. This number is incremented with
every package update. The vepoch is otherwise known as the "release
number" or "patchlevel".
The key difference between the concept of "vepoch" and "patch level" is
that everything to the right of the vepoch is PURELY INFORMATIONAL. The
only time where it matters is to guarantee a different %{release} tag
between two distribution versions.
The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy
as canonical. Package updates in any repository should always check all
other official repositories to be sure that the vepoch is always
incremented and never matching an existing package.
With most normal packages, vepoch is a single number starting at "1".
Under the (C-3) non-numeric version case it is two numbers starting at
"0.1" with the second number being the number to increment.
Normal Package Example:
foobar-1.2.3-1.src.rpm compiles to
foobar-1.2.3-1.i386.rpm
If this package is patched:
foobar-1.2.3-2.i386.rpm
foobar-1.2.3-3.i386.rpm
C-3. Non-Numeric Version to Release
-----------------------------------
As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
versioned packages can be problematic so they must be treated with care.
These are cases where the upstream version has letters rather than
simple numbers in their version. Often they have tags like alpha, beta,
rc, or letters like a and b denoting that it is a version before or
after the number. Read section B to understand why we cannot simply put
these letters into the version tag.
Release Tag for Pre-Release Packages:
0.%{X}.%{alphatag}
Release Tag for Non-Numeric Post-Release Packages:
%{X}.%{alphatag}
Where %{X} is the vepoch increment, and %{alphatag} is the string that
came from the version.
Example (pre-release):
mozilla-1.4a.tar.gz from usptream is lower than
mozilla-1.4.tar.gz the later "final" version thus
mozilla-1.4-0.1.a Fedora package name
Example (pre-release):
alsa-lib-0.9.2beta1.tar.gz becomes
alsa-lib-0.9.2-0.1.beta1
Example (post-release):
gkrellm-2.1.7.tar.gz
gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7
gkrellm-2.1.7-1.a
Upgrade Path Example (mozilla):
mozilla-1.4-0.1.a
Patched
mozilla-1.4-0.2.a
Patched again
mozilla-1.4-0.3.a
Move to 1.4b
mozilla-1.4-0.4.b
Patched
mozilla-1.4-0.5.b
Move to 1.4 "final" version
Notice that this becomes a normal C-2 case
mozilla-1.4-1
Patched
mozilla-1.4-2
Upgrade Path Example (alsa-lib):
alsa-lib-0.9.2-0.1.beta1
Patched
alsa-lib-0.9.2-0.2.beta1
Move to beta2
alsa-lib-0.9.2-0.3.beta2
Move to beta3 and simultaneously patch
alsa-lib-0.9.2-0.4.beta3
Patched again
alsa-lib-0.9.2-0.5.beta3
Move to rc1
alsa-lib-0.9.2-0.6.rc1
Move to rc2
alsa-lib-0.9.2-0.7.rc2
Move to "final"
alsa-lib-0.9.2-1
Patched
alsa-lib-0.9.2-2
C-4. Dist tag
-------------
In cases where the same SRPM and patchlevel is used between two or more
distributions supported by Fedora, a dist tag is appended to the end of
the release tag defined in C-2 and C-3. The dist tags with the
following examples appear to be only cosmetic, however the a different
E-V-R is needed between distributions to ensure dist upgrading works
fully in all corner cases.
Dist Tag for Normal Packages:
%{X}.%{disttag}
Where %{X} is the vepoch and %{disttag} is a distribution tag from this
table:
0.7.3 Red Hat Linux 7.3
0.8 Red Hat Linux 8
0.9 Red Hat Linux 9
1 Fedora Core 1
1.93 Fedora Core 1.93 beta
1.94 Fedora Core 1.94 beta
2 Fedora Core 2 beta
Example:
foobar-1.2.3-1_0.7.3.i386.rpm
foobar-1.2.3-1_0.8.i386.rpm
foobar-1.2.3-1_0.9.i386.rpm
foobar-1.2.3-1_1.94.i386.rpm
foobar-1.2.3-1_2.i386.rpm
Upgrade Path Example (FC1 only shown):
foobar-1.2.3-1_1.i386.rpm
foobar-1.2.3-2_1.i386.rpm
foobar-1.2.3-3_1.i386.rpm
Dist Tag for Pre-Release Packages:
%{X}.%{alphatag}.%{disttag}
Where %{X} is the vepoch, %{alphatag} is the pre-release tag described
in C-3, %{disttag} is a distribution tag described above.
Example:
alsa-lib-0.9.2-0.1.beta1_0.8.i386.rpm
alsa-lib for RH 8.0
alsa-lib-0.9.2-0.1.beta1_1.i386.rpm
alsa-lib for FC1
Upgrade Path Example (RH 7.3 only shown):
alsa-lib-0.9.2-0.1.beta1_0.7.3
alsa-lib-0.9.2-0.2.beta1_0.7.3
alsa-lib-0.9.2-0.3.beta2_0.7.3
alsa-lib-0.9.2-0.4.beta3_0.7.3
alsa-lib-0.9.2-0.5.beta3_0.7.3
alsa-lib-0.9.2-0.6.rc1_0.7.3
alsa-lib-0.9.2-0.7.rc2_0.7.3
alsa-lib-0.9.2-1_0.7.3
alsa-lib-0.9.2-2_0.7.3
C-5. Special Case: Kernel modules
---------------------------------
This section needs its own discussion due to changed provides within
FC1's kernel, and the fact that older distributions are different.
C-6. Plugin, theme etc packages
-------------------------------
Packages that are plugins, themes or the like, ie. enhance other
packages must be named <package-to-enhance>-<enhancement>. If the
resulting name differs significantly from upstream naming, a
Provides: <upstream-name> = %{epoch}:%{version}-%{release}
must be added. For example:
Upstream package name: modplug-xmms
Fedora package name: xmms-modplug
Provides: modplug-xmms = %{epoch}:%{version}-%{release}
C-7. Minor Number
-----------------------
Probably no longer needed at fedora.redhat.com.
20 years, 7 months
Trademarked Name? --redhar-config-*
by David T Farning
I have been working or the past several weeks on a visual gui front end
for yum I am considering bring that knowledge with me to work on the
fedora project.
But, Frankly, I am concerned about contributing to a program with a
trademarked name. I am interested in giving back to the entire
gnu/linux community not just the redhat community.
If someone likes my product, I would like them to be able to freely
use my work irregardless of their distro/flavor.
With this in mind what are your suggestions?
a. Go ahead and work on redhat-config-*
b. Seek renaming of redhat-config-* to something vendor neutral
c. Put my work in an up stream project and let it trickle down.
Thanks
Dave Farning
20 years, 7 months
ftwall build broke FC1 tcp.h (glibc-kernheaders)
by Warren Togami
Hi, I could really use assistance with the ftwall package. It fails
build on FC1 due to glibc-kernheaders tcp.h while it builds successfully
on RH9. Any suggestions for this problem?
Thanks,
Warren Togami
warren(a)togami.com
http://bugzilla.fedora.us/show_bug.cgi?id=941
http://videl.ics.hawaii.edu/~warren/fedora/ftwall-1.07-1.src.rpm
http://videl.ics.hawaii.edu/~warren/fedora/md5sums.asc
ftwall is a program for linux firewalls that allows the control of network traffic
from "Fast Track" peer-to-peer clients like "Kazaa" and it's derivatives.
It is designed to block network traffic from Fast track client applications
running in the "home" (or "green") network from making access to any peers
on the public internet. It is ideal for use in networks where the security
paradigm is "open access" for outbound connections and "tightly limited"
access for inbound ones. Ftwall can be used in such a network to prevent
outbound Fast Track access, hence preventing illegal file downloads and uploads.
Known Problems:
* Makefile doesn't use proper CFLAGS. Suggestions please.
* Due to the below change in glibc-kerneheaders /usr/include/linux/tcp.h in FC1,
compiler fails with this message:
In file included from /usr/include/linux/tcp.h:21,
from ftwall.c:51:
/usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header;
include <endian.h> instead!
In file included from ftwall.c:51:
/usr/include/linux/tcp.h:105: error: enumerator value for `TCP_FLAG_CWR' not
integer constant
/usr/include/linux/tcp.h:106: error: enumerator value for `TCP_FLAG_ECE' not
integer constant
/usr/include/linux/tcp.h:107: error: enumerator value for `TCP_FLAG_URG' not
integer constant
/usr/include/linux/tcp.h:108: error: enumerator value for `TCP_FLAG_ACK' not
integer constant
/usr/include/linux/tcp.h:109: error: enumerator value for `TCP_FLAG_PSH' not
integer constant
/usr/include/linux/tcp.h:110: error: enumerator value for `TCP_FLAG_RST' not
integer constant
/usr/include/linux/tcp.h:111: error: enumerator value for `TCP_FLAG_SYN' not
integer constant
/usr/include/linux/tcp.h:112: error: enumerator value for `TCP_FLAG_FIN' not
integer constant
/usr/include/linux/tcp.h:113: error: enumerator value for `TCP_RESERVED_BITS'
not integer constant
/usr/include/linux/tcp.h:115: error: enumerator value for `TCP_DATA_OFFSET' not
integer constant
ftwall.c:938: warning: conflicting types for built-in function `log'
make: *** [ftwall.o] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.86753 (%build)
* SOURCES includes entire iptables tarball because ftwall requires libipq.h
which is usually provided by iptables-devel in other distributions, but is not
included in Red Hat. Instead ftwall appears to static link to libipq from the
iptables tarball build.
This is the change in tcp.h that causes the build failure in FC1:
--- tcp.h-rh9 2003-11-06 21:45:40.000000000 -1000
+++ tcp.h-fc1 2003-11-06 21:46:08.000000000 -1000
@@ -102,16 +102,16 @@
#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3])
enum {
- TCP_FLAG_CWR = __constant_htonl(0x00800000),
- TCP_FLAG_ECE = __constant_htonl(0x00400000),
- TCP_FLAG_URG = __constant_htonl(0x00200000),
- TCP_FLAG_ACK = __constant_htonl(0x00100000),
- TCP_FLAG_PSH = __constant_htonl(0x00080000),
- TCP_FLAG_RST = __constant_htonl(0x00040000),
- TCP_FLAG_SYN = __constant_htonl(0x00020000),
- TCP_FLAG_FIN = __constant_htonl(0x00010000),
- TCP_RESERVED_BITS = __constant_htonl(0x0FC00000),
- TCP_DATA_OFFSET = __constant_htonl(0xF0000000)
+ TCP_FLAG_CWR = htonl(0x00800000),
+ TCP_FLAG_ECE = htonl(0x00400000),
+ TCP_FLAG_URG = htonl(0x00200000),
+ TCP_FLAG_ACK = htonl(0x00100000),
+ TCP_FLAG_PSH = htonl(0x00080000),
+ TCP_FLAG_RST = htonl(0x00040000),
+ TCP_FLAG_SYN = htonl(0x00020000),
+ TCP_FLAG_FIN = htonl(0x00010000),
+ TCP_RESERVED_BITS = htonl(0x0FC00000),
+ TCP_DATA_OFFSET = htonl(0xF0000000)
};
/* TCP socket options */
20 years, 7 months
RE: ReiserFS in Anaconda?
by Ro
Well I speak from inexperience, ergo, the reason I am questioning you all.
So, my wrap up of this entire thread: I currently have RH 9.0 production
Servers and since the Errata will end 'soon' for RH 9.0, I was wondering if
moving to Fedora Core 1 would be a smart move. And should I continue with
ext3 or perhaps explore other venues.... JFS perhaps. Your input is GREATLY
appreciated.
Cheers,
Ro
>>On Friday 07 November 2003 20:22, Ro wrote:
>> Well, we all know that ReiserFS is FAR from being in development...
>>it's BEEN out... So I was wondering if someone could objectively
>>answer this questions. I am really not trying to make anyone
>>uncomfortable, just curious. :-)
>Actually we don't know that. A lot of work is being done on Reiser4,
>and
>little on 3, and the author has stated that he's more concerned with
>feature sets than stability. Not exactly what I want to hear from my fs
>developer. Our company gave reiserfs a try a year or 2 back, given it's
>merits then, and everybody was saying it was stable, blah blah. It led to
>a lot of our customers losing their data when reiser would puke. We're
>re-evaulating our file system offerings, and at this point, JFS seems to
>be in the lead.
20 years, 7 months
Re: Re: esound.spec has a description thats\\\' out-of-date
by jigorou3＠mail.goo.ne.jp
sopwith(a)redhat.com wrote:
> On 8 Nov 2003 jigorou3(a)mail.goo.ne.jp wrote:
>
> > Recent version of Red Hat Linux (and Fedora Core) doesn't have
> > /usr/lib/rpm/redhat
> > , and esound's build fails in default setting.
>
> Make sure to install the redhat-rpm-config package.
Sorry, I haven't installed that one...
And after install, build succeed without problem.
Thanks
20 years, 7 months
Re: FC2 release
by Jef Spaleta
seth vidal wrote:
> Gotta make sure gnucash is working though. ;)
crap...I hate you...you've totally made it impossible for me to get work
done today. I have a mounting FC2 todo list in my head now because of
you. It's worse than when i had rico suave stuck in my head for a week.
One thing i REALLY want to see as early as possible is to get the people
with accessibility concerns talking ASAP about a priority list of
concerns they want to see addressed in the next distro. Being blindsided
late in the last beta about lilo vs grub accessibility was totally
uncool.
And I'm not saying the next release is going to a magical silver bullet
to solve accessibility problems...its a hard problem..and its one very
prone for communication disconnects, even though technical/development
people recognize it is important. I think a roadmap to on "focused"
accessibility cleanup longterm is something worth working on. Just
trying to have every package maintainer try to deal with accessibility
issues as they come up..is going to suck for everyone. But if there were
some priorities so people who understand accessibility issues could
start somewhere and work with a few developers at a time...and march
through the distro so that 3 or 4 releases from now not only is
accessibility a lot cleaner but there will be a real human development
process in place to keep accessibility from being something each
maintainer has to try to remember to deal with.
I want to see an accessibility focus/support group to be there in the
community to help developers deal with issues. And i want that
focus/support group to have a long term vision and a master plan to get
from here to there.
-jef"i also want my own jet pack"spaleta
20 years, 7 months
