devel March 2004

devel@lists.stg.fedoraproject.org

238 participants
275 discussions

rawhide report: 20040330 changes
by Build System 31 Mar '04

31 Mar '04

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"

3 2

gaim depends on tcl
by Pete Zaitcev 31 Mar '04

31 Mar '04

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?

5 5

USB sound card.
by Naoki 31 Mar '04

31 Mar '04

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?

1 0

missing battery on acpi with Linux 2.6.4
by Rui Miguel Silva Seabra 31 Mar '04

31 Mar '04

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

1 0

Re: Please fix longstanding problem with authconfig/pam_ldap config
by "Nils O. Selåsdal" 31 Mar '04

31 Mar '04

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

1 0

Re: Fedora Tracker: Part Deux
by Matt Hansen 30 Mar '04

30 Mar '04

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

2 1

openoffice-1.1.1
by Florin Andrei 30 Mar '04

30 Mar '04

Any plans to include OpenOffice-1.1.1 in the final release? -- Florin Andrei http://florin.myip.org/

2 1

Flac in rythmbox.
by Konstantin Ryabitsev 30 Mar '04

30 Mar '04

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

5 8

FC2 Test 2 and Kernel
by Lorenzo Luconi Trombacchi 30 Mar '04

30 Mar '04

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

3 3

Re: Fedora Tracker: Part Deux
by Jef Spaleta 30 Mar '04

30 Mar '04

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2004