Post-release tags
by Fernando Nasser
Hi all,
We have for quite some time figured out what to do with pre-release
tags: 0.#.<tag>.#%{?dist}
But what to do with _post_-release tags?
Here is an example:
These upstream software releases its software from pre-release to final
like that:
1_1_0_BETA
1_1_0_BETA1
1_1_0_BETA2
1_1_0_CR1
1_1_0_CR2
1_1_0_GA
So far so good, we use pre-release tags for all but the last, which we
call just '1.1.0'.
After the final release (GA- General Availability), the process goes on.
After some fixes are added, they release:
1_1_0_CP1
1_1_0_CP2
1_1_0_CP3
So I thought we could just add one decimal point: .1, .2 and .3 for the
above.
Eventually, they have a wider distribution one with a different naming:
1_1_0_SP1 (SP = Service Pack)
And there goes my extra decimal point scheme.
I think CPs after that would go like:
1_1_0_SP1_CP1
as I've also seen then use
1_1_0_GA_CP1 instead of just 1_1_0_CP1
I've also seem ugly things like
1_1_0_PATCH1
What should we do in these cases?
Add non-numerics in the version field and have:
1.1.0.GA
1.1.0.GA.CP1 or 1.1.0.GA_CP1
Or should we create a "post-release" convention, with a numeric field
(non-zero, to distinguish from pre-release tags) followed by the
alphanumeric from upstream, like "GA", "GA_CP1" etc?
Please, think a little bit about this, they have quite a few packages.
Regards to all,
Fernando
P.S.: We don't need the leading '0.' in this case as there won't be a
following pure digit version, like it happens for pre-release tags.
17 years, 1 month
[review: xorg-x11-server-Xgl] How you prefer start Xgl?
by alcapcom
Hi list,
Few months ago I have add a review for Xgl, without success at this
time. Considering that fglrx driver still not support AIGLX, this
package is useful for most of the fedora Desktop users.
The specfile follow the packaging guide line, and seem to be clean. The
only blocker that stay is "howto start Xgl".
The goal of this mail, is to know which of the two solutions you
preferred and why.
Have try to sum the (+/-) of each solution, if there is other
coolstuff/limitation/problem of one of them, it should be useful to know
too.
In advance, Thanks.
Alphonse
Start Xgl from GDM (session menu)
---------------------------------
(+) The login time is shorter (last Xorg improvement)
(+) Can choice a X type before login
(-) Traditionally X is started on the display :0, but that is not
possible if we
start Xgl from GDM (dislay :0 should already used by GDM)
(-) There are 3 log files for X (Xorg.0.log, Xorg.1.log and Xorg.93.log) that
should appear strange for the end user.
(-) For each WM available available on fedora, we needs a .desktop file (GDM session menu
can quickly look too long)
(-) two X are loaded at boot time + 1 if rgbd is used (graphical boot).
Try it : http://files.damaestro.us/xgl/Xgl-settings-0.1-3.fc6.noarch.rpm
Start GDM with Xgl
------------------
(+) do not have any of (-) thing of the first solution.
(-) The only thing that I see is that the login take more time between
the username input and the password input.
Try it:
http://download.tuxfamily.org/fedoraxgl/6/i386/system-config-xselector-0....
---
REVIEW BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192436
SPEC:
http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec
SRPM:
http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.4.2...
17 years, 1 month
cmake rpm macro(s):
by Rex Dieter
Appended is a first try at rpm macro'izing the the call to cmake per:
http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the
PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
-- Rex
#################################
## /etc/rpm/macros.cmake:
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix}
%_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON
%_cmake_lib_suffix64 -DLIB_SUFFIX=64
%cmake \
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
%{_bindir}/cmake \\\
%{?_cmake_install_prefix} \\\
%{?_cmake_build_shared_libs} \\\
%if "%{?_lib}" == "lib64" \
%{?_cmake_lib_suffix64} \\\
%endif \
###############################3#
17 years, 1 month
Repotag in EPEL
by Thorsten Leemhuis
Hi,
I'd like to ask the Packaging Committee (which afaics is responsible for
the Packaging standards used in Fedora projects, which includes EPEL)
for advice and a formal decision about using a repotag in EPEL. There
are a lot of people strongly urging to use one -- see attached mails or
the threads in the online archive at
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html
I (and some other EPEL SIG members afaics) don't care much about using
one or not. But afaics the use of a repotag is unwanted in Fedora-land
up to now afaics.
If the answer from the PC is "yes, EPEL is free to use a repotag" then
please decide how to actually use it -- Add a "repotag" macro defined by
the buildsys or overload %{dist}, ...
We need a decision soon. Thanks for your support.
CU
thl
17 years, 1 month
How to deal with folders that need the user to change permissions on?
by Axel Thimm
Hi,
the default mediawiki install does not allow image uploads (on
puprose) and requires the user to adjust permissions
(#231542). Perhaps there is a better way to deal with this in
mediawiki, but the general issue came up:
Suppose a package requires the user/admin to change permissions on a
folder to enable some functionality. How do we deal with that? A
package upgrade resets the permissions and there is no way to tell rpm
that this folder is "%configdir".
A workaround would be to not own this folder which is very ugly,
violates guidelines, leaves orphaned folders behind, and is just not
The Right Solution. Which is The Right Solution?
(again in the context of "folder permission change really required by
a package", I hope mediawiki's issue may be worked around, so don't
stick to this example)
--
Axel.Thimm at ATrpms.net
17 years, 1 month
buildroot race condition
by Till Maas
Hello,
an OpenSUSE packager made me aware of a race condition problem with a lot of
fedora specs:
http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html
A lot of specs and the template specs from rpmdev-newspec use following:
%install
rm -rf $RPM_BUILD_ROOT
# racing time
mkdir -p $RPM_BUILD_ROOT/bla/foo
The solution is to make the following mandatory:
%install
rm -rf $RPM_BUILD_ROOT
mkdir $RPM_BUILD_ROOT # this fails when $RPM_BUILD_ROOT already exists
Regards,
Till
17 years, 1 month
legal guidelines for new fonts?
by Jens-Ulrik Petersen
Hi,
Would it be a good idea to add a page under Packaging describing basic
legal requirements for new fonts being added to Fedora? Typically it is
a good idea to contact the original authors and the maintainers of fonts
to ascertain the origin and ownership of the design as part of the
review process.
I think this is something that we should consider making mandatory for
all new fonts packages.
Jens
17 years, 1 month
perl-* build dependencies
by Ville Skyttä
Hello,
Whether the perl/perl-devel split in devel (#226276) is here to stay or not,
I'd like to make the attached change to the rpmdevtools perl spec template.
Using perl(ExtUtils::MakeMaker) as the "base" build dependency is correct in
the vast majority of cases, no matter in which package ExtUtils::MakeMaker is
included. Packages using Module::Build should change the dep to
perl(Module::Build) - that'll pull in ExtUtils::MakeMaker too in case it's
needed for Module::Build's non-compat mode.
Doing the build dep this way should work for all distro versions as-is without
the need to put ugly conditionals on whether to pull in perl-devel or not or
whatever other perl package reorganizations we might see in the future. I
see some packagers have already started to make those unnecessary specfile
complications/per-distro forks so it'd be good to have this in the spec
template as well as applicable Wiki pages as soon as possible.
Comments, objections?
17 years, 1 month
Temporarily removing a sub-package
by Orion Poplawski
I'm looking to remove the -mpi subpackage of paraview because it does
not build. I've poked upstream to no avail, and I haven't been able to
figure out the problem myself. If this gets fixed, I'd like to add it back.
In the meantime, what kind of Provides/Obsoletes makes sense?
Provides: paraview-mpi
Obsoletes: paraview-mpi < %{version}-%{release}
?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
17 years, 1 month