Re: A new comps group: dogtag
by Kevin Wright
Hi Bill,
I was wondering if you had a chance to review the patch to comps-
f13.xml.in.
Thanks,
--Kevin
On Feb 10, 2010, at 7:47 PM, Kevin Wright wrote:
>
> On Feb 10, 2010, at 10:01 AM, Bill Nottingham wrote:
>
>> Parag N(पराग़) (panemade(a)gmail.com) said:
>>> Forwarding this mail on behalf of Kevin Wright as his mail to devel
>>> list didn't appeared yet.
>>
>> Seems reasonable. Do you have a patch?
>>
>> Bill
>> -- devel mailing list
>> devel(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>
>
> Bill,
>
> I had to re-subscribe to the list. Here's the patch:
>
> cvs diff -u comps-f13.xml.in
> Index: comps-f13.xml.in
> ===================================================================
> RCS file: /cvs/pkgs/comps/comps-f13.xml.in,v
> retrieving revision 1.161
> diff -u -r1.161 comps-f13.xml.in
> --- comps-f13.xml.in 10 Feb 2010 04:49:19 -0000 1.161
> +++ comps-f13.xml.in 11 Feb 2010 01:23:33 -0000
> @@ -1235,6 +1235,44 @@
> </packagelist>
> </group>
> <group>
> + <id>dogtag</id>
> + <_name>Dogtag Certificate System</_name>
> + <_description>Enterprise-class open source Certificate
> Authority</_description>
> + <default>false</default>
> + <uservisible>true</uservisible>
> + <packagelist>
> + <packagereq type="optional">dogtag-pki-ca-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-common-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-console-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-kra-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-ocsp-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-ra-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-tks-ui</packagereq>
> + <packagereq type="optional">dogtag-pki-tps-ui</packagereq>
> + <packagereq type="optional">osutil</packagereq>
> + <packagereq type="optional">pki-ca</packagereq>
> + <packagereq type="optional">pki-common-javadoc</packagereq>
> + <packagereq type="optional">pki-common</packagereq>
> + <packagereq type="optional">pki-console</packagereq>
> + <packagereq type="optional">pki-java-tools-javadoc</packagereq>
> + <packagereq type="optional">pki-java-tools</packagereq>
> + <packagereq type="optional">pki-kra</packagereq>
> + <packagereq type="optional">pki-native-tools</packagereq>
> + <packagereq type="optional">pki-ocsp</packagereq>
> + <packagereq type="optional">pki-ra</packagereq>
> + <packagereq type="optional">pki-selinux</packagereq>
> + <packagereq type="optional">pki-setup</packagereq>
> + <packagereq type="optional">pki-silent</packagereq>
> + <packagereq type="optional">pki-symkey</packagereq>
> + <packagereq type="optional">pki-tks</packagereq>
> + <packagereq type="optional">pki-tps</packagereq>
> + <packagereq type="optional">pki-util-javadoc</packagereq>
> + <packagereq type="optional">pki-util</packagereq>
> + <packagereq type="optional">tomcatjss</packagereq>
> + </packagelist>
> + </group>
> + <group>
> + <group>
> <id>dns-server</id>
> <_name>DNS Name Server</_name>
> <_description>This package group allows you to run a DNS name
> server (BIND) on the system.</_description>
>
> --Kevin
14 years, 2 months
Re: Fedora rawhide FTBFS status 2010-02-10 x86_64
by Jaroslav Skarvada
Following the steps from deltarpm example (http://fedoraproject.org/wiki/UnderstandingDSOLinkChange#Example_deltarpm) helps me to reproduce the DSO issue in local mock.
Jaroslav
----- Original Message -----
From: "Ralf Corsepius" <rc040203(a)freenet.de>
To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org>
Sent: Monday, February 15, 2010 8:55:03 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: Fedora rawhide FTBFS status 2010-02-10 x86_64
On 02/13/2010 04:50 PM, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for x86_64
> using rawhide from 2010-02-10
>
> This run includes the new default linker feature --no-add-needed.
> This is responsible for 446 failures noted below. See
> http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking for
> further details.
>
>
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
> SoQt-1.4.1-14.fc13 (build/make) corsepiu
I can't reproduce this issue in a local mock[1] using "released
rawhide". Scratch-building using Fedora's infrastructure, however
exposes this issue.
This renders investigating this issue quite difficult and imposes
problems in fixing it[2]
What is required to be able to locally reproduce Matt's results?
- Is "released rawhide" different from what Matt rsp. "Fedora" is using?
- Is "released rawhide" outdated/Do I happen to be using outdated
rawhide mirrors?
- Are there some special settings required to trigger these DSO issues?
Ralf
[1] Standard "fedora-rawhide-*" mock setup on FC12 without any modification.
[2] I meanwhile have a "hack" which lets this package build again, but
without being able to reproduce the issues in a local mock, I hardly can
verify my "hack"'s correctness (This breakdown could easily be a
side-effect of other bugs).
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
14 years, 2 months
Re: No lzma sdk in fedora
by Chen Lei
In fact libarchive doesn't require lzma-libs any more in F12 and F13.
For F11:
repoquery --whatrequires libarchive.so.2
PackageKit-glib-0:0.4.9-1.fc11.i586
libarchive-0:2.6.2-1.fc11.i586
kdeutils-6:4.2.2-4.fc11.i586
PackageKit-glib-0:0.4.6-8.fc11.i586
libarchive-devel-0:2.6.2-1.fc11.i586
Updating libarchive to the F12 only affects a few stuffs(soname unchanged).
在2010-02-13?01:02:56，"Milos?Jakubicek"?<xjakub(a)fi.muni.cz>?写道：
>Hi?Chen,
>
>On?12.2.2010?12:50,?Chen?Lei?wrote:
>>?I?realized?from?"http://tukaani.org/xz/"??the?core?of?the?xz?utils
>>?compression?code?is?based?on?LZMA?SDK?<http://7-zip.org/sdk.html>,?but
>>?it?has?been?modified?quite?a?lot?to?be?suitable?for?XZ?Utils.
>>?So?I?think?we?should?ship?lzma?sdk?for?fedora?in?parallel?with?xz?utils
>>?and?p7zip.?Since?xz?utils?are?the?successor?to?lzma?utils,?maybe?lzma
>>?utils?can?be?safely?retired?in?fedora.
>
>Retiring?lzma?(completely)?is?a?long-term?plan,?yes?(I'm?the?maintainer?
>of?it).?Not?sure?about?the?right?time?--?F14?
>
>I'll?talk?to?the?libarchive?maintainer?--?any?other?objections?against?
>the?plan?to?retire?lzma?for?F14?
>
>Milos
14 years, 2 months
Anyone using e2fsprogs static libs?
by Eric Sandeen
I've finally been sufficiently pestered to fix this ;)
Is anybody using any of these static libs from e2fsprogs?
-%{_libdir}/libe2p.a
-%{_libdir}/libext2fs.a
-%{_libdir}/libcom_err.a
-%{_libdir}/libss.a
I'm inclined to just remove them rather than making a -static
package, unless anyone needs them.
Michael Schwendt was kind enough to go look and found none,
but I guess consider this last call...
Thanks,
-Eric
14 years, 2 months
kplayer
by Frode Nicolaisen
Hi!
Using the KDE version of fedora 12 and notice that the kplayer doesnt play mp3s via samba/networkshares. It plays for some seconds and just crash!
Anyone know what to do to fix it!?
__________________________________________________
Bruker du Yahoo!?
Lei av spam? Yahoo! Mail har den beste spambeskyttelsen
http://no.mail.yahoo.com
14 years, 2 months
FTBFS script (?) issue
by Ville Skyttä
https://bugzilla.redhat.com/show_bug.cgi?id=562316
Why did this bug end up in the FTBFS list? I don't think rpmdevtools has
actually failed to build from source according to the logs available right
now, this bug has nothing directly to do with FTBFS (or at least nothing that
a script could possibly determine fixed/unfixed), and there have been no
rpmdevtools releases yet which fix that actual bug, but it was closed by FTBFS
nevertheless. What's up?
14 years, 2 months
stk soname change
by Thomas Moschny
Hi!
Just a small heads up that I'm going to update stk (Synthesis ToolKit
in C++) to version 4.4.2 and thereby change the soname from
"libstk.so.4" to "libstk.so.0". This will, as far as I can see, only
affect lmms, which I also maintain and take care of the rebuild
myself. The rebuild seems necessary anyway: lmms build against 4.3.1
crashes when run with 4.4.2, which is an indicator that the soname
should have been changed. Upstream unfortunately doesn't seem to have
a consistent scheme yet, maybe we should work something out together
with them.
The new soname also would bring us in-line with Debian who used major
.0 for some time now.
- Thomas
14 years, 2 months
Suggestion: An earlier freeze for soname bumps
by Bruno Wolff III
It is hard to do testing for spins when there is also some broken dependency
in rawhide. (The latest last minute breakage being gmime.) Doing soname
bumps right before the alpha freeze (I think under the new development rules
the updates would be blocked for beta and beyond) results in fire drills
with people scrambling to get packages rebuilt and makes spin testing
difficult.
Perhaps a separate freeze date for soname bumps (at least for those that are
dependencies for other packages) could be made. Or at least a string suggestion
that people not frivilously do these right before freezes since they block
or make extra work for people when there is a tight deadline for getting things
done.
14 years, 2 months
