Proposed and major updates policy
by Rahul Sundaram
Hi
Currently the usage of updates-testing repository for proposed updates
to a release is entirely based on the package maintainer and in many
cases seems to be arbitrary for the end users. Can we have a policy to
ensure to that all the updates have a week or so of testing period in
the updates-testing repository with the exception of security updates
which go through a shorter duration of testing?. It might also be better
to have some consistency in between providing updates for major
revisions of packages. KDE got a major update while GNOME and Firefox
didnt in Fedora Core 4 as an example of current status.
While the current amount of feedback that we receive from end users on
the packages in updates-testing repository is low to non existent, it
would be better to encourage usage of that and provide interested
testers a chance to send in feedback rather than releasing it
immediately to the updates repository leading to potential regressions
more rapidly.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
18 years, 2 months
Re: Fedora Core 5 Test 3 Slip
by Alan Cox
On Sat, Feb 04, 2006 at 11:57:16AM -0500, Philippe Rigault wrote:
> relevance of March 15 as the release date for FC5-final, which I see a the
> worst possible choice in March, given the following release dates:
> March 15 GNOME-2.14, koffice-1.5
> March 17 KDE-3.5.2
>
> These would make Fecora Core 5 labeled as both "obsolete" and "unstable" if it
It would need to be a large delay because moving to major new versions means
invalidating a lot of the testing work in T1/T2. If sliding test2 a bit to fit
these would have worked then maybe there would be a practical way to do it, but
test3 > final is about polishing critical final bugs.
Alan
--
"He's been overclocked. All that beer you see him drinking ? - Coolant."
- Adam Thornton
18 years, 2 months
Question about IT821x driver and DMA
by G.Wolfe Woodbury
I actually have an ITE8212 with two 400GiB drives in a RAID1
configuration.
It seems that I cannot set DMA with hdparm on this drive without driving
the system into a lockup.
>From what I could understand of the code, there are some significant DMA
problems with the device, but there are a lot of workarounds present.
The question is: am I doomed to PIO Mode on this device forever, or are
y'all working actively to make real DMA work?
The card locks the system hard when it fails, and it is prone to fail
most frequently when trying to DMA and serve the data via SMB or NFS to
other systems. I can practically guarantee that turning on DMA will
kill the system in less than 1 minute if I attempt to turn it on with an
active SMB session in progress.
--
G.Wolfe Woodbury `- -'
RHCT U
The Line Eater is a boojum!
18 years, 2 months
fc5 test2 haldaemon failed?
by Leo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Hal fail to start on system boot. Does anyone has similar experience?
I'm going to file a bug if anyone confirm. And gnome powermanager applet
failed too. It might have to do with hal.
Run `/etc/init.d/haldaemon restart' gives:
Stopping HAL daemon: [FAILED]
Starting HAL daemon: [FAILED]
- --
_.---. _
Happy _/ __ >99.
Dog (-. ,-.`(6666\
Year _ @| \@| )9999}
<_>' `' /66666\
2006 (^. {9999999)
`-`.___/ }666666}
) {9999999)
/,. \666666{
,%%%\ `99999)
,%%%%%; `'~'\
%%%%%%%} `-._
%%%%%,' `-.
;%%%; ; \-.
;;`%; / _)`\
_;| ; ,'_ .-''''/
((_j~_(,.,_;(((`._ /'''''/
(((___) ('''''(
`".''')
`.(
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD5c5DKDqgm5pnsV8RAvfhAKCXH9B/w8tfFD1xxsRPW5Yfde3j6QCeK3/K
Xbdm0ybSmsD0HAv5OEknc8U=
=7Ob9
-----END PGP SIGNATURE-----
18 years, 2 months
gcc 64-bit mode disapear on x86_64
by Kłoczko Tomasz
[kloczek@kloczek01 src]$ LANG= make CC="gcc -m64" passwd
if gcc -m64 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../libmisc
-DLOCALEDIR=\"/usr/share/locale\" -g -O2 -MT passwd.o -MD -MP -MF
".deps/passwd.Tpo" -c -o passwd.o passwd.c; \
then mv -f ".deps/passwd.Tpo" ".deps/passwd.Po"; else rm -f
".deps/passwd.Tpo"; exit 1; fi
passwd.c:1: sorry, unimplemented: 64-bit mode not compiled in
make: *** [passwd.o] Error 1
[kloczek@kloczek01 src]$ rpm -q gcc --qf
"%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"
gcc-4.1.0-0.20.x86_64
[kloczek@kloczek01 src]$ gcc -dumpspecs | grep 64
[kloczek@kloczek01 src]$
kloczek
18 years, 2 months
e1000 in rawhide kernel
by Michael J. Knox
Hi all,
I am looking at a problem with the e1000 driver in rawhide (will the
installed FC5t2 kernel).
I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its
statically asigned, I am ok.
lspic output:
03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet
Controller (Copper) (rev 0.3)
The e1000 kernel module is loaded, ifconfig shows that eth0 was brought
up.
dmesg shows:
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex.
Has anyone else seen this issue?
Thanks
Michael
18 years, 2 months
rawhide report: 20060206 changes
by Build System
Updated Packages:
NetworkManager-0.5.1-10.cvs20060205
-----------------------------------
* Sun Feb 05 2006 Dan Williams <dcbw(a)redhat.com> 0.5.1-10.cvs20060205
- Workarounds for madwifi/Atheros cards
- Do better with non-SSID-broadcasting access points
- Fix hangs when access points change settings
* Thu Feb 02 2006 Dan Williams <dcbw(a)redhat.com> 0.5.1-9.cvs20060202
- Own /var/run/NetworkManager, fix SELinux issues
bash-3.1-6
----------
* Sun Feb 05 2006 Tim Waugh <twaugh(a)redhat.com> 3.1-6
- Patchlevel 7.
* Wed Jan 18 2006 Tim Waugh <twaugh(a)redhat.com>
- Removed inaccuracies from %description (bug #178189).
epiphany-1.9.6-2
----------------
* Sun Feb 05 2006 Matthias Clasen <mclasen(a)redhat.com> 1.9.6-2
- Update requires
file-4.16-6
-----------
* Sat Feb 04 2006 Radek Vokál <rvokal(a)redhat.com> 4.16-6
- xen patch, recognizes Xen saved domain
* Fri Jan 13 2006 Radek Vokal <rvokal(a)redhat.com> 4.16-5
- fix for 64bit arrays
* Fri Dec 09 2005 Jesse Keating <jkeating(a)redhat.com>
- rebuilt
kdenetwork-7:3.5.1-1
--------------------
* Sun Feb 05 2006 Than Ngo <than(a)redhat.com> 7:3.5.1-1
- 3.5.1
kdesdk-3.5.1-1
--------------
* Sun Feb 05 2006 Than Ngo <than(a)redhat.com> 3.5.1-1
- 3.5.1
kdeutils-6:3.5.1-1
------------------
* Sun Feb 05 2006 Than Ngo <than(a)redhat.com> 6:3.5.1-1
- 3.5.1
kdevelop-9:3.3.1-1
------------------
* Sun Feb 05 2006 Than Ngo <than(a)redhat.com> 9:3.3.1-1
- 3.3.1
kdewebdev-6:3.5.1-1
-------------------
* Sun Feb 05 2006 Than Ngo <than(a)redhat.com> 6:3.5.1-1
- 3.5.1
mozilla-37:1.7.12-4
-------------------
* Sun Feb 05 2006 Christopher Aillon <caillon(a)redhat.com> 37:1.7.12-4
- Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296
openoffice.org-1:2.0.1.1-10.2
-----------------------------
* Thu Feb 02 2006 Caolan McNamara <caolanm(a)redhat.com> - 1:2.0.1.1-10
- reshuffle bridge patch
- reimplement lang from locale patch
redhat-artwork-0.237-1
----------------------
* Sun Feb 05 2006 Matthias Clasen <mclasen(a)redhat.com> 0.237-1
- Fix Bluecurve-inverse wait cursor
ruby-1.8.4-3
------------
* Mon Feb 06 2006 Akira TAGOH <tagoh(a)redhat.com> - 1.8.4-3
- ruby-1.8.4-no-eaccess.patch: backported from ruby CVS to avoid conflict
between newer glibc. (#179835)
sound-juicer-2.13.4-3
---------------------
* Sun Feb 05 2006 Christopher Aillon <caillon(a)redhat.com> 2.13.4-3
- Fix broken Requires
wpa_supplicant-0.5.1-1
----------------------
* Sun Feb 05 2006 Dan Williams <dcbw(a)redhat.com> 0.5.1-1
- Update to 0.5.1
- Add WE auth fallback to actually work with older drivers
xorg-x11-drv-ati-6.5.7.3-3
--------------------------
* Sun Feb 05 2006 Mike A. Harris <mharris(a)redhat.com> 6.5.7.3-3
- Updated radeon.xinf to be up to date with the xf86PciInfo.h from the Xorg
X server 1.0.1-1 source. This should account for all supported Radeon
models now modulo errors/omissions.
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5
GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5
GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp
GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5
cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5
cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5
cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp
cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5
dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5
dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5
dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp
dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5
gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5
gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5
gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp
gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5
Broken deps for ia64
----------------------------------------------------------
rgmanager - 1.9.31-3.ia64 requires ccs
Broken deps for ppc
----------------------------------------------------------
ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1
gulm - 1.0.4-2.FC5.1.ppc requires ccs
Broken deps for ppc64
----------------------------------------------------------
cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11
Broken deps for s390
----------------------------------------------------------
systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11
Broken deps for s390x
----------------------------------------------------------
libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit)
libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit)
systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5
GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5
cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5
cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5
dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5
dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5
gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5
gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5
18 years, 2 months
bad dependency with sound juicer
by Louis Garcia
when the dependency on gstreamer went from 0.8 to 0.10 the new requires
should have been gstreamer-plugins-base not gstreamer-plugins.
-Louis
18 years, 2 months
FC5 and firefox-trunk
by Takanori MATSUURA
Dear all,
Do you have any good idea?
Now I'm trying to build trunk version of firefox and there is a problem.
https://bugzilla.mozilla.org/show_bug.cgi?id=325716
https://bugzilla.mozilla.org/show_bug.cgi?id=325719
FC5 has cairo-1.0.2 and firefox-trunk has 1.1 from cairo-CVS.
1. If we run configure script with '--enable-system-cairo', firefox
cannot build because firefox-trunk source calls cairo-1.1-specific
functions.
2. If we run configure script with '--disable-system-cairo', firefox
cannot build because system cairo is detected by 'pkg-config
gtk+-2.0'.
MATSUURA Takanori
18 years, 2 months
Xorg 6.9 Update for FC4?
by Peter Gordon
Hi all.
With the recent release of the modular X.org X11R7, will Fedora Core 4 receive
an update to its monolithic counterpart X11R6.9?
The primary reason I inquire about this is for the updated drivers. Every so
often, OpenGL-intensive apps such as BZFlag and others will inevitably hardlock
my system, forcing a reboot to fix it. Some games such as gl-117 refuse to even
play without hardlocking. However, I upgraded a now-dead Gentoo install to one
of the later X.org release candidates and found that, unlike 6.8 (both on Gentoo
and Fedora), X11R7 seems to fix every issue that I have with the R200 driver.
(I use a Radeon 9200.)
While I'm aware that the shift to a modular, autotool build and distribution
system is a very fundamental change to the architecture of X.org, it did put out
a 6.9 release which is of the same codebase of 7.0, and thusly would (hopefully)
also fix this and other small issues I have with the radeon driver. It would
also provide better support for newer video cards (such as the i945 Intel GMA,
R300-series Radeon cards, et al.)
Also, I'm not aware of any difficulties that we would face in doing this. It
would only be a matter of version-bumping the various xorg-x11 packages and
building a new release, right?
Alternatively, would it be better for me to grab a 6.9 source RPM and rebuild it
for my FC4 system? If this is the preferred method by the Fedora X.org team,
would someone please point me to instructions to do this? (Would it be a simple
"rpm --rebuild xorg-x11*.src.rpm"?)
Thanks for your time!
--
Peter Gordon (codergeek42)
GnuPG Public Key: 0xDA3634D7
18 years, 2 months