file-not-utf8 complaints
by Jason L Tibbitts III
Normally we fix up non-utf8 documentation and such with a quick call
to iconv. It seems that this is problematic for some; see
https://bugzilla.redhat.com/show_bug.cgi?id=226079
Any comments on how much we actually care about this, especially in
the case that it might not actually be as easy as a call to iconv
(such as a changelog file with a pile of random encodings in it).
- J<
15 years, 11 months
eclipse plugin without feature.xml
by Sergio Pascual
Hello, I'm trying to package a eclipse plugin called veditor. I have
followed the guidelines in wiki/Packaging/EclipsePlugins
The zip with the source code contains a file plugin.xmll but doesn't
contain feature.xml. When building,
%{eclipse_base}/buildscripts/pdebuild -f net.sourceforge.veditor
fails, because feature.xml doesn't exist. How do I build with
plugin.xml but without feature.xml?
Regards, Sergio
15 years, 11 months
How to make SRPMs and RPMs?
by Michelle Konzack
Hello *,
I am "new" to Fedora since I was using long time ago DLD (Deutsche Linux
Distribution from Delix which was bougth by RedHat in 1999) and I need a
little bit help to start.
If this list is not the right one, please let me know.
I am Debian GNU/Linux Consultant in Strasbourg and now have to work with
RedHat and Fedora since my customers proprietary software does not work
on ANY Debian machines.
I need to package some software for my customer and like to know HOW to
package it. Curently I run only Debian Unstable/Stable and I am doubt
if I can create packages under Debian without installing a Xen Machine
for it since learning the whole RedHat/Fedora thing is currently a
little bit to much.
Now I have some questions:
1) Where can I find the "Packaging Tutorial"?
2) Where can I find the "Guidelines for Packaging"?
3) Where can I find infos about the FSH (File System Hierarchy)
since it is a little bit different from Debian?
4) What does I need to build my own private fedors mirror (RPMs and
SRPMs) with GPG signed packages?
5) If I create my own private fedora mirror on my server, is it
possibel under Fedora to have the mirror password protected?
x) What should I know more?
y) Is there a tutorial, "HOW TO INSTALL" a Fedora-Xen-DomU on a
Debian host system. My Development station is a AMD Phenom Quad
9800 with 8 GByte of memory and 74 GByte SCI/SCA drives (one per
guest OS).
Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
Fedora Newbie :-)
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
15 years, 12 months
shipping distribution-specific patches *separately*
by Thorsten Leemhuis
Hi!
Quoting a paragraph from:
http://lwn.net/Articles/283030/
> Debian's packaging policy resembles that of most other distributions.
> A Debian source package is supposed to contain a tarball of the
> upstream source distribution, without changes. Any
> distribution-specific patches are included separately and applied
> when the source package is prepared for building.
Do we have a policy that all patches we apply in our packages need to be
included *separately*? (I couldn't find anything like that in our
guidelines, but maybe I missed it) And if not: Do we want such a
statement in our guidelines?
Background: I wanted to use grub as provided by Fedora on a FAT
partition. That didn't work properly, as the Fedora grub includes this
patch:
http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.p...
The main part of it (¹):
- .string "/boot/grub/menu.lst"
+ .string "/boot/grub/grub.conf"
That of course creates trouble, as FAT due to its 8.3 filemane
limitations can't store a file called grub.conf. Thus I had to build a
special grub where this patch wasn't applied. That was no big deal and
at least for me a easy thing to do.
In F8 and later that's way harder, as there is one patch (created from
git afaics) where all the patches that in F-7 were applied separately
are now merged into one giant 1,6 MByte big patch:
http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?vi...
Building grub without that one patch of course is way harder now, as I
need to get my hands on that one patch and revert it after the giant
patch was applied. Not impossible, but way harder if one doesn't know
where to find that one small patch to revert it.
Do we care or do we want to ignore this (minor) issue?
CU
knurd
(¹) Side note: I think it's wrong to add such a patch, as differing from
upstream in things like config file naming just creates trouble and
confusion for everyone.
16 years
My absence at yesterdays FPC meeting
by Hans de Goede
Hi All,
Sorry for not being there yesterday (again), I'm currently in a bit of a
rough spot / time in my personal (well actually paid work) life. Its not
that I cannot be there, its more that I just have so much on my mind I
forgot.
Apologies.
Regards,
Hans
16 years
Using alternatives
by Dominik 'Rathann' Mierzejewski
Hi.
While reviewing a package, I stumbled across the use of alternatives
and found out it's not regulated in any way in Fedora. So far, I've
encountered three ways of handling the symlinks that are set up using
alternatives:
1. some packages have Provides: for them (like cups or postfix),
2. some don't own those files at all (like lam or scim),
3. some %ghost them.
All seem to work, but in case of 2. it's not possible to find out which
packages own/provide those files using rpm -qf, thus I consider it an
inferior solution.
Personally, I'm leaning towards 1., but I don't see any disadvantages
in 3., either. Comments?
Having said that, I'm going to write up a guideline to cover that. I expect
to have a presentable draft ready in a week or two.
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
16 years
[Fwd: [JPackage-discuss] Moving jpp# to Provides:]
by Jesse Keating
I sent this over to the jpackage discussion list after a lengthy talk on
IRC with a few Fedora and jpackage folks. So far there hasn't been any
response other than some clarification of the rpm level drawback of
using Provides. I thought I would toss it over here for some
consideration on our side of things.
-------- Forwarded Message --------
From: Jesse Keating <jkeating(a)redhat.com>
Reply-To: Discussion about JPackage project <jpackage-discuss(a)zarb.org>
To: Discussion about JPackage project <jpackage-discuss(a)zarb.org>
Subject: [JPackage-discuss] Moving jpp# to Provides:
Date: Mon, 19 May 2008 16:05:01 -0400
In trying to find a compromise for jpackage packages in Fedora, we asked
somebody from the jpackage side to provide a list of technical reasons
why 'jpp#' needed to continue to be in the Release: string of an rpm.
Deepak provided us with
http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP
In reviewing this and in the various arguments that have happened over
the past few years surrounding the jpp vendor tag, I think I've struck
upon something that just may work, at least work to the best of the
requirements that I know of.
If we simply move the 'jpp#' part of the release string to a Provides:
line in the spec file, here is what happens:
Exclusion of jpp* from a specific repo can still be done, since excludes
work upon Provides too. It can be even more precise since currently a
package with the name of foolalajpp4me would trigger the excludes and
cause problems.
Deploying an entire jpackage stack is still possible. This is actually
better accomplished at the yum repo level. yum --disablerepo=\*
--enablerepo=jpackage install \* <-- that will install everything from
jpackage, which I am understanding is the goal of this data point.
JPackage is still given credit as the package provides jpp, has the jpp
changelogs, can have # comments regarding the jpackage interaction,
summary, description, etc...
Grouping by jpp is still possible. yum --disablerepo=\* --provides jpp*
----
A current drawback to using jpp# is that the '#' can change, so using
rpm itself becomes more tricky as rpm doesn't accept globs. That said,
instead of doing jpp# you could just do 'jpp' and then rpm would be able
to do things like:
rpm -q --whatprovides jpp
and well, whatever you want to do with that output.
However if you wanted to keep the versioning information, and still
retain the ability to query on 'jpp', you could do:
Provides: jpp = #
or =< if that fills your needs. Since rpm does handle versioning in
Provides you can still do rpm -q --whatprovides jpp and that will work.
Anyway I'm drifting a bit here, but I did want to start a conversation
about the feasibility of using Provides to accomplish the listed goals
rather than added characters in the release string.
I should also note that for best results, this Provides should
be /added/ at both the jpackage and Fedora level. Removal of the jpp#
information from release string technically only needs to be done at the
Fedora level, it could remain at the jpackage level if so desired. The
existence of "jpp#" can easily be controlled by a %{_dist} like tag in
the release string. In jpackage build roots that value can expand to
'jpp#' and in Fedora buildroots that value would expand to '.fc#'.
Since the other version-release parts should be used for version
comparison it shouldn't much matter if jpp# is on the jpackage side
and .fc# is on the Fedora side.
_______________________________________________
JPackage-discuss mailing list
JPackage-discuss(a)zarb.org
https://www.zarb.org/mailman/listinfo/jpackage-discuss
--
Jesse Keating
Fedora -- Freedom² is a feature!
16 years
Broken dependency /bin/sh?
by Roland Wolters
Hi list,
I recently got error messages for all my (three) packages stating a broken
dependency:
ktorrent has broken dependencies in the development tree:
On ppc:
ktorrent-3.0.2-3.fc10.ppc64 requires /bin/sh
On ...
I'm not sure what the cause of this is, and what I should do about. Should I
add /bin/sh as a fixed dependency?
Roland
--
Typical Canadian wimpiness! That's why you have snowballs and we have the
H-bomb!
-- Simpsons
16 years
New packager question
by Gregory Hosler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
new packager here.
Apologies in advance for any ignorant questions.
:)
I'm the package maintainer/co-maintainer and I am now getting ready to do my first package
update (the original commit was done for me :).
I have been thru the PackageMaintainers/UpdatingPackageHowTo wiki.
I have setup my cvs stage area. That was straight forward.
I now am preparing to update the fedora package from upstream. The recent upstream package
updates (i.e. since the original commit to fedora) include not only a new source tarball,
but in addition, some spec file changes (to incorporate a division of sub-packages, as
well as re-arrange the directory structure of the package deployment layout, stuff like that).
As I walk thru the PackageMaintainers/UpdatingPackageHowTo, it instructs me how to setup
cvs (done), import my new tarball to the devel branch and then to do a make. But I am not
seeing how my new (changed) spec file is to be integrated into the structure.
First question: What is the procedure when there are changes to the spec file ?
Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I
see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand
that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm
lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8,
F-9}, and/or {common}
I am gathering that changes are done in devel first, and then after they build correctly,
those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7,
F-8, F-9}, one at a time. Is this correct ?
now, the pc I'm using for development is presently F-8, i386; How do I verify a package
for other platforms, other hardware ? I have heard of mock, koji, and have been to the
relevant wiki pages. I'm more needing some step-by-step guidance, as to what needs to be
done, and the order of things :)
I'm guessing that once I've been thru this once or twice, it'll become 2nd nature, so
please bear with me thru this introduction :)
Any help / suggestions / (and esp) clarifications regarding the above, are most welcome.
All the best,
- -Greg
- --
+---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler ghosler(a)redhat.com |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFIMNpw404fl/0CV/QRAklfAKC/+IMlDOsv9VgxtEHR0D8KGzKTdwCfTZS3
a5nTCfd6S0ETA1Xa8KR0CLs=
=toZE
-----END PGP SIGNATURE-----
16 years
jpp naming exception
by Tom Callaway
Hi FPC members,
I would like to propose that we eliminate the jpp naming exception.
I think that Bill Nottingham summarized the issue nicely:
<notting> ok, as far as I can see:
<notting> jpackage wants (the equivalent of) repotags
<notting> we do not support repotags in fedora
<notting> we have grandfathered in a %{release} hack for jpacakge for a
while
<notting> we'd like to get rid of that
<notting> if they're going to insist that anything done to get rid of
that is unacceptable because it's not a repotag... oh well
<notting> but yum-priorities is a 'better' solution for repotags than
Group-hackery :)
I would agree with this assessment, and accordingly, I would like us to
vote to eliminate the jpp naming exception during tomorrows meeting.
Bring your flame-retardant underwear, but I would like to put this to
bed.
A few points to keep in mind:
1. This is solely about the naming exception in Fedora, not in any other
repositories.
2. We do not permit repotags in any other scenario in Fedora.
3. Using the yum-priorities plugin permits weighting a third party
repository over Fedora for packages.
As usual, FESCo will have to ratify this.
Thanks in advance,
~spot
16 years
