rawhide report: 20040330 changes
by Build System
Updated Packages:
aumix-2.8-8
-----------
* Mon Mar 29 2004 Mike A. Harris <mharris(a)redhat.com> 2.8-8
- Added ghosted config files for SElinux file_context (#119130)
- Quote CFLAGS export
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com> 2.8-7.EL
- rebuilt
* Sun Aug 31 2003 Mike A. Harris <mharris(a)redhat.com> 2.8-6.EL
- Rebuilt 2.8-6 as 2.8-6.EL for Red Hat Enterprise Linux, to pick up the
ppc64 inclusion
gstreamer-0.8.0-3
-----------------
* Mon Mar 22 2004 Colin Walters <walters(a)redhat.com> 0.8.0-3
- Add BuildRequires on flex
- Add patch to avoid calling opendir() on files
hwdata-0.114-1
--------------
* Mon Mar 29 2004 Bill Nottingham <notting(a)redhat.com> 0.114-1
- fix entries pointing to Banshee (#119388)
kernel-2.6.4-1.298
------------------
* Mon Mar 29 2004 Arjan van de Ven <arjanv(a)redhat.com>
- 2.6.5-rc2-bk8
* Mon Mar 29 2004 Dave Jones <davej(a)redhat.com>
- Include latest agpgart fixes.
kernel-utils-2.4-9.1.126
------------------------
* Tue Mar 30 2004 Karsten Hopp <karsten(a)redhat.de> 2.4-9.1
- fix permissions of config files and man pages (#116243)
libdv-0.102-1
-------------
* Mon Mar 29 2004 Warren Togami <wtogami(a)redhat.com> 0:0.102-1
- update to 0.102
rhythmbox-0.7.1-2
-----------------
* Mon Mar 29 2004 Colin Walters <walters(a)redhat.com> - 0.7.1-2
- Remove BuildRequires on autoconf and libvorbis-devel
* Mon Mar 29 2004 Colin Walters <walters(a)redhat.com> - 0.7.1-1
- New major version - I know we are past major version slush, but
this should have been done two weeks ago along with the GNOME 2.6
upload. As upstream author as well, I believe this version is
good enough for FC2.
- Remove --disable-mp3
- Remove id3, flac variables
- Remove GStreamer major version patch
- Fix typo in description
rpmdb-fedora-1.91-0.20040330
----------------------------
xinitrc-3.38-1
--------------
* Mon Mar 29 2004 Mike A. Harris <mharris(a)redhat.com> 3.38-1
- xinput fixes:
- Fix missing ']' on elif test on line 25 (FC2 BLOCKER #119284)
- Change test for /etc/profile.d/lang.sh to test with -r instead of -f
- Change all non-null string tests to use -n instead of != ""
- Change broken test logic in KDE block to use -o instead of ||
- Fixes for iiimf getting turned on even for European languages where it
is not useful. (Jens Petersen, FC2 BLOCKER #119241)
- Xsession cleanups:
- Update Xsession for new switchdesk (Than Ngo, FC2 BLOCKER #116164)
- Change all file existance tests using -f, to -r since we care if it is
readable rather than if it exists or not.
- Use new style $() command substitution rather than ``
- Updated the copyright messages of all script files, and added missing
GPLv2 notices where appropriate. Updated License: tag of spec file to be
"GPLv2, MIT/X11"
19 years, 6 months
gaim depends on tcl
by Pete Zaitcev
Hi, Christopher & others:
the gaim-0.75-1.3.0 requires tk & tcl, which I do not have installed,
so I went to investigate. The spec does not mention tcl anywhere.
So, obviously, during the build process, configuration picks
an installed libtcl/libtk, then somehow informs rpm that these
libraries are required. How does it actually happen?
I saw specs which have small sections like so
%{expand:%%define buildforrh7 %(A=$(awk '{print $5}' /etc/redhat-release); if [ "$A" = 7.2 -o "$A" = 7.3 ]; then echo 1; else echo 0; fi)}
......
%if %buildforrh7
BuildRequires: nautilus2-devel
%endif
I could understand if gaim spec had a scriptlet which parsed the output
of ./configure and set something like %wehavetcl, then added a Requires
like the above. But this is not what is happening. Can you enlighten me
about the magic workings in the case of gaim?
Thank you,
-- Pete
P.S. Aside from the spec magic, why would a modern application require tcl?
19 years, 6 months
USB sound card.
by Naoki
Ok, so my USB sound card disappeared in the recent updates and new 2.6.4
kernel.
Anybody else see this problem and have a quick solution before I begin
to dig?
19 years, 6 months
missing battery on acpi with Linux 2.6.4
by Rui Miguel Silva Seabra
Hi,
I upgraded Linux from 2.6.3-2.1.248 to 2.6.4-1.298 and now ACPI
doesn't seem to detect the battery.
Follows in attachment dmesg from both Linux's, it might be useful,
meanwhile I'll get back to 2.6.3-2.1.248.
I almost forgot, the only difference in my 2.6.3 from stock FC
development is swsusp activated (although it didn't work).
I have had battery present with previous 2.6 and 2.4 Linux's from FC.
Hugs, Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
19 years, 6 months
Re: Please fix longstanding problem with authconfig/pam_ldap config
by "Nils O. Selåsdal"
On Tue, 2004-03-30 at 16:30, Charles Lopes wrote:
> I'd like to attract attention to a problem described in bugs #55193,
> #63631, #77575, #86606, #103461 and #118239.
Defintly +1 from me on these.
--
Nils Olav Selåsdal
System Engineer
w w w . u t e l s y s t e m s . c o m
19 years, 6 months
Re: Fedora Tracker: Part Deux
by Matt Hansen
On Wed, 2004-03-30 at 10:37:12 -0500, Jef Spaleta wrote:
>
> ______________________________________________________________________
> Brad Smith wrote:
> > This assumes that Tracker is going to be integrated into
> > Fedora.org. As nice an ego-stroke as that would be for me, the very
> > reasons you point out would seem to make keeping it as separate an
> > entity as possible a good idea.
>
> I think perhaps you misinterpreted what I was trying to say. Or perhaps
> the fever I had yesterday affected my ability to communicate.
> Looking back today at what Matt H. wrote, its pretty clear my feverish
> state was affecting my comprehension. Matt H. was actually talking about
> turning the tracker into a subproject of Fedora, to give it a homebase
> for its development effort not necessarily incorporating it into the
> main site's functionality, which is how i originally read it yesterday.
> My main point being, as things stand, the potential usefulness of an
> implementation of the tracker is anti-correlated to its potential
> integration into official fedoraium functionality.
Yes, this anti-correlation is a shame for such a useful, needed
functionality. You are correct with your interpretation of my post; I
indeed would like to see a http://fedora.redhat.com/projects/tracker
page for this project.
> Once fedora extras opens up for contributors to use, i don't see any
> obvious problem with trying to use whatever hosting services Red Hat
> eventually provides for contributors who have new community initiated
> fedora related projects. We'll have to wait and see how things develop
> on that front. There's nothing inherently problematic with the tracker
> codebase really, the problems are very much associated with building the
> repo index. While the codebase itself might fit into an expanded idea
> of a community development model, any really useful implementation of
> this out in the wild has to be totally independent. Though, there could
> be some people like .edu's who might want to use something like the
> tracker in their intranet. If the fedora project does host web pages
> aimed at development of the tracker your still going to run into trouble
> trying to provide links from those development pages to a fully indexed
> demo.
Now, what ways can these legalities be dealt with to keep in line with
The Fedora Project's objectives? The underlying infrastructure is fine
as you mentioned, the issue is the with the content this infrastructure
interacts. I may be totally off-track here, but hosting a development
platform surely is different than hosting an implementation? Could this
not be the case for The Fedora Tracker Project? If we control what is
indexed, then development could continue as part of a Fedora
sub-project. i.e. fedora.redhat.com could implement a
DMCA/Fedora-compliant implementation (albeit limited), while Brad's full
version could be hosted elsewhere. This probably defeats the purpose of
Brad's goals for the Tracker however and wouldn't be very practical..
> > On the other, this opens up a whole set of issues, not just of
> > determining an appropriate policy, but of enforcing said policy without
> > making it prohibitively difficult to be indexed. As much as I support
> > the standardization of QA practices etc between repos, Tracker's job is
> > to help bridge the gaps between repos, not throw up barriers to
> > inclusion.
This statement, unfortunately, proves that my idea above is more of a
pipe dream. :( Even if a DMCA/Fedora-compliant implementation were
possible, it could never be as functional as it should be; - "bridge the
gaps, not throw up barriers"..
Regards,
-Matt
--
Registered Linux User #348963 / counter.li.org
GnuPG KeyID: 0xCE9F8922 / gnupg.org
19 years, 6 months
Flac in rythmbox.
by Konstantin Ryabitsev
Hello, all:
I may be missing something obvious, but I've not yet found a way to make
rythmbox play flacs. Can someone point me in the right direction?
Regards,
--
Konstantin ("Icon") Ryabitsev
Duke Physics Systems Admin, RHCE
I am looking for a job in Canada!
http://linux.duke.edu/~icon/cajob.ptml
19 years, 6 months
FC2 Test 2 and Kernel
by Lorenzo Luconi Trombacchi
The Fedora Core 2 Test 2 is out, but what about the bug id 118002 (or
118128)
and the Kernel 2.6.4-2.275 that fix the problems of this bug?
Thanks,
Lorenzo
19 years, 6 months
Re: Fedora Tracker: Part Deux
by Jef Spaleta
Brad Smith wrote:
> This assumes that Tracker is going to be integrated into
> Fedora.org. As nice an ego-stroke as that would be for me, the very
> reasons you point out would seem to make keeping it as separate an
> entity as possible a good idea.
I think perhaps you misinterpreted what I was trying to say. Or perhaps
the fever I had yesterday affected my ability to communicate.
Looking back today at what Matt H. wrote, its pretty clear my feverish
state was affecting my comprehension. Matt H. was actually talking about
turning the tracker into a subproject of Fedora, to give it a homebase
for its development effort not necessarily incorporating it into the
main site's functionality, which is how i originally read it yesterday.
My main point being, as things stand, the potential usefulness of an
implementation of the tracker is anti-correlated to its potential
integration into official fedoraium functionality.
Once fedora extras opens up for contributors to use, i don't see any
obvious problem with trying to use whatever hosting services Red Hat
eventually provides for contributors who have new community initiated
fedora related projects. We'll have to wait and see how things develop
on that front. There's nothing inherently problematic with the tracker
codebase really, the problems are very much associated with building the
repo index. While the codebase itself might fit into an expanded idea
of a community development model, any really useful implementation of
this out in the wild has to be totally independent. Though, there could
be some people like .edu's who might want to use something like the
tracker in their intranet. If the fedora project does host web pages
aimed at development of the tracker your still going to run into trouble
trying to provide links from those development pages to a fully indexed
demo.
> On the other, this opens up a whole set of issues, not just of
> determining an appropriate policy, but of enforcing said policy without
> making it prohibitively difficult to be indexed. As much as I support
> the standardization of QA practices etc between repos, Tracker's job is
> to help bridge the gaps between repos, not throw up barriers to
> inclusion.
Personally i think yer going to find that job description is going to
become rather cumbersome if the number of repositories you index grows
to 100+ repos. I think you will find that, for a tracker to stay useful
as its popularity increases, there is going to have to be continual
human effort,editorial effort, to evaluate the worth of the listing of
individual repositories in the index. I think anyone managing a popular
implementation of the tracker, is going to have to develop some policy
with regard to what is and what is not indexed, if the point is to
provide users with a useful tool. Do you really want to list all the
possible repos? Even if that means 100 different repositories that
provide binary kernels with different modules turned off or on or
compiled in? Shall we index all the 4 package people.redhat.com
micro-repositories?
-jef"how much fun would it be if all the projects building RPMs in the
st.net ftp trees decided to build individual yum repo and wanted to be
listed with the index..1000 or so indexed repositories would
be...interesting"spaleta
19 years, 6 months
