release tag question.
by Michael J. Knox
Hi..
Just looking at the cvsup package, as I need to use it at work. Anywho..
Just curious the rationale for the release tag. The actual version of
the package is 16.1h, but its packaged as 16.1 and the "h" is pushed out
into the release tag. Like:
cvsup-16.1-9h
Why? Would this not work:
cvsup-16.1h-9
My first guess is that version comparisons would be messed up if the h
was in the version tag, but then would it not mess up the release
comparison also?
Michael
17 years, 10 months
Mono conversations
by Paul F. Johnson
Hi,
After the release of monodoc-1.1.13-12, there was some discussion on the
FE list about the packaging of it, and in particular the AC_CANON bits
that had been suggested. Due to this, it was suggested to move monodoc
back to review - I managed to persuade the original reviewer not to do
this as the suggestions made had been from IRC discussion and packaging
discussions.
The discussion thread can be found here
https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00835.html
Would anyone care to comment on the discussion?
I've not altered monodoc yet and haven't played with the other 2 in the
AC_CANON triple due to a requirement to sleep!
While we're on the subject, could someone else please report the noarch
rpm bug? I kept getting it closed as not a bug.
TTFN
Paul
--
"99 Jahre Krieg ließen Keinen Platz für Sieger - Kriegesminister gibt's
nicht mehr - und auch keine Düsenflieger - heute ziehe ich meine Runden
- sehe die Welt in Trümmern liegen - hab' nen Luftballon gefunden - denk
an dich und laß ihn fliegen" - Nena, 99 luft balons
17 years, 10 months
libexecdir, rpmlint, and Packaging Guidelines
by Toshio Kuratomi
I would like to have clarification of whether using libexec is in
accordance with the Fedora Guidelines or if packages using it should be
changed.
The usage of libexecdir for binary programs (not libraries) which are
not intended to be invoked by users, just other programs (gnome panel
applets are an example) is currently part of Fedora Core, the *BSDs, and
the GNU Coding Standards. The FHS had libexecdir in a draft at one
point but apparently dropped it after a poll (The FHS mailing list
archives are currently inaccessible so I can't verify this) Debian has
been vehement in its following the letter of the FHS so they set
libexecdir to /usr/lib/pkgname through configure. If we decide libexec
is not allowed we should consider doing the same with our %configure
macro.
There have been several email threads related to libexecdir vs the FHS
on the fedora lists. The last one I recall is here:
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/
The thread brings up an issue which similar discussions on Debian
mailing lists fail to mention (because Debian is not multilib): On
multilib, you want one version of a helper program that matches the
wordsize of the main program, not one for 32 bits in /usr/lib and
another for 64 bits in /usr/lib64. Thus /usr/libexec to match /usr/bin.
There have been several people who have said they intended to bring the
libexec lack to the attention of the FHS but with their mailing list
inaccessible I'm unable to check whether any discussion reached the FHS.
-Toshio
17 years, 10 months
Re: [Bug 192912] Review Request: paps
by Ralf Corsepius
> ------- Additional Comments From jko(a)redhat.com 2006-06-15 02:45 EST -------
> ------- Additional Comments From jkeating(a)redhat.com 2006-06-11 11:04 EST -------
> NEEDSWORK
> - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built.
Why? I thought, RH was going to use the *same* conventions as Fedora?
Apparently not ...
Ralf
17 years, 10 months
Mono Packaging Issues
by Tom Callaway
As I look into lifting the hold on Mono packages in Fedora Extras (aka,
blessing the mono packaging guidelines found here:
http://fedoraproject.org/wiki/Packaging/Mono), I'd like to state my
opinions on the following blocker issues:
1. Redefining libdir for mono packages:
If mono and its tools cannot find a library on a 64bit architecture when
it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken
on that architecture, and needs to be fixed. This is a serious flaw, and
I will not have us doing ugly hacks in spec files to work around mono's
ineptitude. Every other core component is able to handle this, this bug
should be filed and fixed.
2. Putting DLLs in %{_datadir} vs %{_libdir}:
The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture
Independent Data". These DLL files do not seem to qualify as
"Architecture Independent Data". I think that having them live in the:
%{_libdir}/mono/ hierarchy seems to be the most appropriate for them at
this point in time. Obviously, this can be revisited if upstream changes
the default location. The gacutil command should be putting these DLL
files in the right place.
3. Forcing local copies of DLL libraries instead of using system
installed DLLs.
This concept is documented upstream here:
http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstabl...
IMHO, this is a really stupid and braindead idea. In fact, I've yet to
talk to anyone who actually thinks this is a good idea. This is the same
thing as static linking a private copy of a library instead of using the
system shared lib. We do NOT permit this sort of behavior in Fedora, and
mono is no exception.
I've copied alexl on this email, since he is the mono owner in Fedora
Core, and likely has an opinion or two. ;)
~spot
--
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
17 years, 10 months
Mono packaging guidelines
by Paul F. Johnson
Hi,
This is what has come to pass so far...
1. If the application just uses mcs and doesn't call gcc anywhere, then
it should be BuildArch: noarch - if it is mixed, stick with a buildarch
[*]
2. Because %configure isn't playing ball with noarch, you must define a
target - don't worry what the target is, it'll be ignored
3. Due to a bug in rpmbuild with noarch (BZ 195487), the libdir hack is
still required to ensure packages are built on 64 bit architecture
4. Lots of the errors thrown up by rpmlint can be ignored as mono apps
are not ELF
5. Stick with putting things in /usr/lib rather than %{_datadir} - this
is inline with upstream and other distros
[*] The exceptions here are anything built using nant (such as boo) -
you can't specify the architecture (from what I can see)
Can I have some comments back so that this can move forward to the
packager committee on high?
TTFN
Paul
--
"99 Jahre Krieg ließen Keinen Platz für Sieger - Kriegesminister gibt's
nicht mehr - und auch keine Düsenflieger - heute ziehe ich meine Runden
- sehe die Welt in Trümmern liegen - hab' nen Luftballon gefunden - denk
an dich und laß ihn fliegen" - Nena, 99 luft balons
17 years, 10 months
Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras
by Nicolas Mailhot
Le vendredi 16 juin 2006 à 13:38 -0400, buildsys(a)fedoraproject.org a
écrit :
> Job failed on arch noarch
>
>
> Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/11111-de...
Well either something strange is happening, or the buildsys does not
like my alphatag.
If the buildsys does not like ~, what separator could I use ?
I need to construct an alphatag out of svn number, svn date, svn string
For obvious reasons :
- svn number and svn date must be separated,
- the separator must be part of the base latin block
- - is taken as rpm field separator
- . is taken as in-field separator
- : is taken as epoch separator
- _ is ugly, and besides CVS flattens . in _ when making up tags, so it
would collide with .
~ was nice and even defined as separator character in the Gnome
character map, but it seems it's a no-go too
Any ideas ?
Regards,
--
Nicolas Mailhot
17 years, 10 months
Proposal: Standardized License tags
by Stephen John Smoogen
As of this morning, the Fedora Core and Extras repositories have 2884
src.rpm packages in them. Going through them, there are 191 different
licenses listed.. many of them variants of the same name (and
sometimes a mis-spelling). Some of the names are useful, and others
are odd:
libselinux -- License: Public domain (uncopyrighted)
or
cmucl -- License: Public Domain/MIT
needs an explanation on the mailling lists every now and then. [Like
can you license public domain stuff?
Some license tags give the version of the license.. others also add in
where the person can get a definitive copy of the license. I would
like to start a discussion on having a list of licenses names to be
put in these tags to make it easier for people to keep track of what
is installed on a system.
Something like
GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2]
GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2]
GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2]
Mozilla Public License (MPL) version 2.0 [see
/usr/share/fedora-licenses/MPL_2.0]
etc.
in the cases of BSD-like/BSD-ish/etc you would refer to the packages
license.. but would use the same syntax.
it would also help to have something more clear on the packages listed
as Distributable (all ~100 of them).. having to figure out the
restrictions on each one is a pain.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
17 years, 10 months
