PS/2 mouse jumpy in FC6 test1
by Pasha R
After installing FC6 test1 and updating it to current development
packages, my PS/2 (microsoft) mouse became very jumpy. When I move a
mouse, after some moving forward, pointer suddenly jumps back. This
occurs in both XWindows and in console mode. I tried to plug same
mouse to USB port and it works ok this way. Never had such problems
before with previous Fedora releases.
17 years, 10 months
rawhide report: 20060731 changes
by Build System
Updated Packages:
devhelp-0.12-1
--------------
* Sat Jul 29 2006 Matthias Clasen <mclasen(a)redhat.com> - 0.12-1
- Update to 0.12
- Rebuild against firefox
epiphany-2.15.4-1
-----------------
* Sat Jul 29 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.15.4-1
- Update to 2.15.4
- Rebuild against firefox-devel
firefox-1.5.0.5-8
-----------------
* Sun Jul 30 2006 Matthias Clasen <mclasen(a)redhat.com> - 1.5.0.5-8
- Pass --libdir to configure
module-init-tools-3.3-0.pre1.4.6
--------------------------------
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.6
- Don't call depmod on removing a kernel.
- Warn rather than exit if we can't process weak-updates on new kernel
- Handle duplicate modules by picking the latter version of the two.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.4
- Don't call mkinitrd when removing a kernel.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 3.3-0.pre1.4.3
- New weak-modules with fixes
openoffice.org-1:2.0.3-7.7
--------------------------
* Wed Jul 26 2006 Caolan McNamara <caolanm(a)redhat.com> - 1:2.0.3-7.7
- rh#200207# -> openoffice.org-2.0.3.ooo67779.svx.toolbarcrash.patch
- rh#200194# -> openoffice.org-2.0.3.ooo67793.sw.stickymenu.patch
- rh#199056# -> openoffice.org-2.0.3.ooo67829.dtrans.64bitpaste.patch
- rh#200042# -> openoffice.org-2.0.3.ooo65081.sw.layout.patch
- rh#200193# -> openoffice.org-2.0.3.ooo67781.sc.reloadhiddenrows.patch
- rh#200369# help build glitch
- drop openoffice.org-2.0.3.oooXXXXX.all.ODR.anonymousmembers.patch
- drop openoffice.org-2.0.3.oooXXXXX.sal.importvisibilityasexported.patch
- require dejavu-lgc-fonts, Greek coverage problems begone
- rh#200512# South African translations
- move to firefox-devel instead of mozilla-devel, --with-firefox
+ add workspace.configure18.patch
pirut-1.1.8-1
-------------
* Sun Jul 30 2006 Jeremy Katz <katzj(a)redhat.com> - 1.1.8-1
- Fix traceback (clumens, #200515)
redhat-rpm-config-8.0.45-1
--------------------------
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 8.0.45-1
- Fix inverted kernel test.
* Sun Jul 30 2006 Jon Masters <jcm(a)redhat.com> - 8.0.44-1
- Add a better check for a kernel vs. kmod.
yelp-2.15.5-1
-------------
* Thu Jul 27 2006 Matthias Clasen <mclasen(a)redhat.com> - 2.15.5-1
- Update to 2.15.5
- Rebuild against firefox-devel
17 years, 10 months
Argh! Firefox has gone insane!
by Paul F. Johnson
Hi,
I updated (via yum) to the current rawhide firefox and fired it up after
the install was complete.
For some reason, all of the menus (file, edit etc) have gone as have
just about all of the icons (such as back, forward etc).
Can anyone suggest the reason for this behaviour?
Using rawhide, x86_64, gnome desktop.
TTFN
Paul
--
Wenn sie denken, dass die bildung teuer ist, versuchen sie ignoranz
17 years, 10 months
IPv6 in rawhide
by Jay Cliburn
Before I go much further in investigating this, I'd like to ask if
anyone has successfully used IPv6 under rawhide?
I can ssh over IPv6 between FC5 and Centos 4.3 boxes, but any attempt to
ssh using v6 to or from a rawhide machine doesn't work. I haven't
gotten any details yet, other than an odd packet in an ethereal capture
that I executed on an FC4 machine while trying to connect IPv6 from a
rawhide machine to the FC4 machine. The frames shown below represent
the TCP 3-way handshake for the session, but the last frame seems to
indicate that the ssh client is ACKing a frame it hasn't yet seen. wtf?
No. Time Source Destination Protocol
Info
4 6.335103 fec0::250:8dff:feef:9069 fec0::250:8dff:fed3:7b0d
TCP 4
5702 > ssh [SYN] Seq=0 Len=0 MSS=1440 TSV=770378 TSER=0 WS=7
Frame 4 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: AbitComp_ef:90:69 (00:50:8d:ef:90:69), Dst:
AbitComp_d3:7b:0d
(00:50:8d:d3:7b:0d)
Internet Protocol Version 6
Transmission Control Protocol, Src Port: 45702 (45702), Dst Port: ssh
(22), Seq:
0, Len: 0
Source port: 45702 (45702)
Destination port: ssh (22)
Sequence number: 0 (relative sequence number)
Header length: 40 bytes
Flags: 0x0002 (SYN)
Window size: 737280 (scaled)
Checksum: 0x3ece [correct]
Options: (20 bytes)
========================================================================
========================================================================
No. Time Source Destination Protocol
Info
5 6.335131 fec0::250:8dff:fed3:7b0d fec0::250:8dff:feef:9069
TCP s
sh > 45702 [SYN, ACK] Seq=0 Ack=1 Win=22848 Len=0 MSS=1440 TSV=136555
TSER=77037
8 WS=2
Frame 5 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: AbitComp_d3:7b:0d (00:50:8d:d3:7b:0d), Dst:
AbitComp_ef:90:69
(00:50:8d:ef:90:69)
Internet Protocol Version 6
Transmission Control Protocol, Src Port: ssh (22), Dst Port: 45702
(45702), Seq:
0, Ack: 1, Len: 0
Source port: ssh (22)
Destination port: 45702 (45702)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 40 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 22848 (scaled)
Checksum: 0x3517 [correct]
Options: (20 bytes)
========================================================================
========================================================================
No. Time Source Destination Protocol
Info
6 9.330977 fec0::250:8dff:feef:9069 fec0::250:8dff:fed3:7b0d
TCP [
TCP ACKed lost segment] 45702 > ssh [SYN] Seq=0 Len=0 MSS=1440
TSV=771128 TSER=0
WS=7
Frame 6 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: AbitComp_ef:90:69 (00:50:8d:ef:90:69), Dst:
AbitComp_d3:7b:0d
(00:50:8d:d3:7b:0d)
Internet Protocol Version 6
Transmission Control Protocol, Src Port: 45702 (45702), Dst Port: ssh
(22), Seq:
0, Len: 0
Source port: 45702 (45702)
Destination port: ssh (22)
Sequence number: 0 (relative sequence number)
Header length: 40 bytes
Flags: 0x0002 (SYN)
Window size: 737280 (scaled)
Checksum: 0x3be0 [correct]
Options: (20 bytes)
SEQ/ACK analysis
TCP Analysis Flags
This frame ACKs a segment we have not seen (lost?)
17 years, 10 months
Re: FC4 glibc broken
by Stuart Anderson
> I added a comment to the new bug. I'm not clear as to whether the new glibc will make it into updates or not before the transition. Bugzilla does not make sense to me for some problem solutions. Fixed in rawhide should only be for those tracking development. If there is a fix that should make it to the release, it should be pushed to updates-testing. If the fix fixes the problem and does not break any other thing in updates-testing, it should be pushed to updates.
>
> So is FC4 and FC5 both broken regarding NIS? Maybe both should get a fix applied other than rawhide.
>
> Jim
The bug was reported against FC4 and there has been a fix (that works)
in FC4 updates-testing since May 9. The bugzilla was closed as a
duplicate of FC5 which was closed when a solution was in RAWHIDE.
Why has this fix languished in updates-testing for > 2 Months and
whom do I ask to get it pushed into updates?
Thanks.
--
Stuart Anderson anderson(a)ligo.caltech.edu
http://www.ligo.caltech.edu/~anderson
17 years, 10 months
Re: FC4 glibc broken
by Stuart Anderson
> On Sat, Jul 29, 2006 at 10:34:37PM -0400, Jim Cornette wrote:
> > So is FC4 and FC5 both broken regarding NIS? Maybe both should get a fix
> > applied other than rawhide.
>
> Looks like it's only NIS+, not regular NIS. In my experience, the older
> version is much more common.
Yes, our problem is with NIS+.
--
Stuart Anderson anderson(a)ligo.caltech.edu
http://www.ligo.caltech.edu/~anderson
17 years, 10 months
Re: FC4 glibc broken
by Stuart Anderson
> > Stuart Anderson wrote:
> >
> > The current FC4 glibc (glibc-2.3.6-3) was released on March 27 and has
> > a regression failure that prevents NIS+ clients from working. An updated
> > version (glibc-2.3.6-4) has been in updates-testing since May 9 that fixes
> > this problem. It is now July 28. When will FC4 updates be updated?
> >
> > Thanks.
> >
>
> You probably need to report the bug through bugzilla to let the developer know that the updates-testing works and the one in updates regular does not work. FC4 is in the last days of support and will be a Fedora legacy product shortly. Time is running out.
We opened this as,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188761
which was closed as a duplicate of the FC5 bug report,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186592
which is also closed with resoltuion "RAWHIDE".
My question is when will it move from RAWHIDE to an official FC4 update?
Is there some other problem with the test-update RPM preventing it from
being released?
Thanks.
--
Stuart Anderson anderson(a)ligo.caltech.edu
http://www.ligo.caltech.edu/~anderson
17 years, 10 months
Problems with FC6T1
by David Hagood
I've had the following problems on a fresh install of FC6T1:
1) The graphical installer barfs on my LVM/XFS root partition (manually
formatted via rescue mode before running the installer) - the volume is
300G, and the graphical installer insists that the volume is larger than
it is supposed to be at 256GiB. The partition *is* correctly sized,
and the text mode installer has no problems with this.
2) Trying to run an update is NEEDLESSLY PAINFUL - can we either a) make
YUM deal with conflicts in a more intelligent fashion that
"Conflict-DIE!", b) fix it so the damn repositories DON'T HAVE
CONFLICTS, or c) drop-kick YUM and use something better like APT for RPM?
3) After updating, when I reboot, the system fails to fsck my XFS
partitions, claiming there is a "permission denied" error running
fsck.xfs. However, when I am then dropped into the recovery shell, I can
execute this command without problems, and I see no differences between
/sbin/fsck.xfs and any of the other fsck.* programs (i.e. ls -laZ shows
no obvious differences). I worked around this by adding a "noxfs" to the
fsck parameters in rc.sysinit - and this might not be a bad idea anyway,
seeing as how fsck.xfs is a no-op anyway.
4) I don't know if this is a Wine error or a Fedora/SELinux error, but -
I pulled down the latest wine CVS (28 July 2006), and installed it to
/usr/bin/wine/* (e.g. the main executable is /usr/bin/wine/wine) (so
that when I want to wipe all the wine binaries for a new clean install I
can do so easily) (and I am not installing from RPM as a) I want the
latest Wine and b) I occasionally do a bit of Wine hacking). I relabled
all the /usr/bin/wine/* and /usr/lib/wine/*so files
(e.g. -rwxr-xr-x root root system_u:object_r:wine_exec_t
/usr/bin/wine/wine
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t
/usr/lib/wine/activeds.dll.so
) but I still get a "wine_main_preload_info not found" from wine when it
starts. The Wine source leads me to believe this is because Wine is not
able to load the wine-preloader. I've check to see if I have any audit
denies and I am not seeing any in the system logs.
17 years, 10 months
