test April 2004

test@lists.fedoraproject.org

553 participants
1033 discussions

Mouse problems
by Boris Goldowsky 30 Apr '04

30 Apr '04

Anyone know if the necessary configurations for scroll-wheel mouses have changed with the new X version? I have a microsoft intellimouse optical which is usb with a ps/2 adapter. I used to use it as a PS/2 mouse in XFree86 with a setting like this: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "Buttons" "7" Option "ZAxisMapping" "6 7" EndSection And with that the scroll wheel and side buttons worked well. But with XOrg I have been unable to make that work - it does not see any mouse on /dev/psaux (or any other device that I can locate - I tried /dev/mouse, /dev/input/mice, etc). I can get basic mousing to work with it plugged in to a usb port, but that does not recognize the scrollwheel or extra buttons. Anyone have a mouse like this working, or can you give me any pointers? I did read README.mouse and look at the x.org site, but didn't find anything helpful there. Thanks - Boris

2 1

Re: X and Logitech optical mouse (OEM)
by Brian Bober 30 Apr '04

30 Apr '04

I know PS/2 disconnects/reconnects (i.e. from a KVM switch) can cause erratic mouse behavior on Intellimouse in X windows. Maybe its similiar. Check to see if your mouse is pushed in enough.

2 1

Re: Sil 3114 Support
by Si Jones 30 Apr '04

30 Apr '04

Tried to boot FC2 T3 and no sil3114 support is there? any ideas?

1 0

RE: header/RPM mismatch
by Fulko.Hew＠sita.aero 30 Apr '04

30 Apr '04

"-=Brian Truter=-" <brian(a)famvid.com>@redhat.com on 04/30/2004 10:10:01 AM commented: >> Yesterday I was complaining about missing RPMs and the fact >> that the update icon, and up2date were out of sync., so today >> I thought I'd look at it some more. >> >> Today, my icon still says there are 2 RPMs to upgrade, but >> up2date says that only one is available. But up2date hangs >> while trying to resolve dependencies. >> >> So I went back to using yum. >> >> Yum told me that there are two other RPMs (gaim and >> rpmdb-fedora) that needed updating, and that there were >> problems with perl-XML-Twig that needs XML::Path, which is not found. >> >> So again I told it to ignore perl-XML-Twig, and yum installed >> gaim and rpmdb-fedora. But alas the icon and up2date are >> still as confused as ever. >> >> Looking at the alert notification tool I see that it says: >> >> Package Version Installed Version Available >> perl-Net-DNS perl-Net-DNS-0.31.3.2 perl-Net-DNS-0.45-2 >> perl-XML-Twig perl-XML-Twig-3.09-3 perl-XML-Twig-3.13-4 >> >> OK, I need perl-XML-Twig-3.13-4. So I manually look at the mirror >> site: >> http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS >> and the only version of perl-XML-Twig it has is 3.09-3 and >> the same goes for perl-Net-DNS (only the old version). >> >> >> Now i look in the mirrors header directory, and they don't >> have the new version either. But at some time, my system did >> fetch that header and now it thinks that's what it needs. >> >> Did someone release new versions of the headers, without the >> RPMs, (that my machine sucked)... and then pulled back the >> new headers, (causing my machine to get into a mode)? >> >> >> 1/ If so, why? >> 2/ And how do I get my machine to forget about the headers >> that point to >> non-existant RPMs? > >I didn't see your post from yersterday, so sorry if this was stated before >but, > >Is your up2date using the same repository as yum? Both tools can be pointed >at completely different repos. Up2date has its configuration file in >/etc/sysconfig/rhn/sources, and yum has its in /etc/yum.conf. Yes, they are pointing at the same repository. I am also using yum and up2date (as-is, out of the box). I looked a little deeper for perl-Net-DNS yum list perl-Net-DNS Looking in Available Packages: Name Arch Version Repo --------------------------------------------- perl-Net-DNS i386 0.45-2 development Looking in Available Packages: Name Arch Version Repo --------------------------------------------- perl-Net-DNS noarch 0.31-3.2 db Now having seen this, and transcribed it, it sounds like another email from the last 24 hours. >If they are not using the same repository, you will get results like you are >explaining. Also, updates that come out from fedora.redhat.com arent picked >up by mirrors immediately. There is varying time periods before each mirror >will sync with the main repo. <RANT ON> But both tools should be using the same config file!!! and the master site and the mirror site should be consistent within themselves ie. I better have the RPM that my hdr file points at. Ie. copy header files last. Also I don't think, by design you should allow either system to 'get into a mode' where the various tables, databases and directories can 'get out of sync' like this. And while I'm at it... This business about three different updating tools that use three different techniques, and 3 different stores, is a piece of ... Pick one and throw the rest away. Its hard enough testing new distributions for real problems without having to go through this aggravation that manufactures its own problems. <\RANT OFF>

2 1

RE: header/RPM mismatch
by Fulko.Hew＠sita.aero 30 Apr '04

30 Apr '04

WARNING: Additional ranting ahead. "William Hooper" <whooperhsd3(a)earthlink.net>@redhat.com on 04/30/2004 11:08:31 AM added: >Fulko.Hew(a)sita.aero said: > >> <RANT ON> >> But both tools should be using the same config file!!! > >So yum should loose features and use up2date's config file (not very >portable to non-RH systems), or should up2date loose features (RHN, apt >support) so it can use yum's config file? If yum is supposed to replace up2date, then its config file, should be a superset of up2date. After all, they are both supposed to do the same thing. The bigger issues is that headers are saved in two different directories on your system, so its guaranteed to get out of sync. As a user, which tool am I supposed to use. The answer (right now is) is... a) we give you a pretty icon on your desktop, but sometimes it lies. b) when you click on the icon it runs up2date, but sometimes it lies And it now lies about the packages sizes too! c) If you decide to carry on with up2date, you now have to ignore all of the GPG errors, because of... (well I don't know). e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll work. d) If you get frustrated by the now broken up2date and the GPG issues you resort to using yum. But sometimes _it_ lies. So in the end you don't know what you've got, who's wrong, whats wrong or where and how to fix it. I don't mind having choices, but at least one of those choices should work, and if the others don't. Then they shouldn't be supplied. "A man with two clocks, never knows what time it is." Sorry, there just appears to be too much of the 'barely good enough engineering' going on here. Do one thing, make it work, then go on to the next. Not: "It powered up in the lab once, ship it, its a legacy product." Just because certain vendors do that, doesn't mean the Linux community should stoop to their levels. >> and the master site and the mirror site should be >> consistent within themselves ie. I better have the RPM that >> my hdr file points at. Ie. copy header files last. > >So set up multiple rsync jobs and have a human check that the first is done? No, set up one job that rsyncs the RPMs, and then rsyncs the headers. >> Also I don't think, by design you should allow either system to 'get into >> a mode' where the various tables, databases and directories can 'get out >> of sync' like this. >> >> And while I'm at it... This business about three different updating tools >> that >> use three different techniques, and 3 different stores, is a piece of ... >> Pick one and throw the rest away. > >Yes, I think you should pick one and throw the rest away. OK, which one? Which one works? ...Neither. > Fedora shouldn't because different people like different > packages. What's this business with multiple GUIs? But you only run one GUI at a time. > multiple editors? But if I had two different editors and one only handled upper case and the other only handled lower case, and both would randomly decide whether they would support punctiatoion, they'd both be pretty useless. > multiple browsers? And can you say 'built for IE' only? >For that matter, Fedora only ships two (up2date and yum) and both are >using the same format for backend repos by default. But neither of them use the same front end database and neither seem to work right... anymore.

3 2

Disk Druid hangs on install Test3
by Stefan Rystedt 30 Apr '04

30 Apr '04

Disk druid hangs when trying to install Test 3. When I install I first get a message that one of my two disks has inconsistent partition table which I chose to ignore. Then I chose new install, personal install and partitioning with disk druid. So far so good but if i then click a little with my mouse on the different partitions Disk Druid hangs. Note that I hav not used any of the buttons to create modify and so on I just changes the highlighted partition. I have not investigated it to much yet. I think it happens when I click on the graphics of the partitions rather then the text list. It works a couple of time but then it hangs. I have switched to the different console window to se if I could se any errors printed but I could not. So the only option is to reboot. I have not issue a bugzilla on it yet I thought I should ask if any other has the same problem. I have an ASUS A7V mother bord with two UDMA 100 hard drives. /ryz

2 3

RE: header/RPM mismatch
by William Hooper 30 Apr '04

30 Apr '04

Fulko.Hew(a)sita.aero said: > > > WARNING: Additional ranting ahead. > > "William Hooper" <whooperhsd3(a)earthlink.net>@redhat.com on 04/30/2004 > 11:08:31 AM added: > > >>Fulko.Hew(a)sita.aero said: >> >>> <RANT ON> >>> But both tools should be using the same config file!!! >> >>So yum should loose features and use up2date's config file (not very >>portable to non-RH systems), or should up2date loose features (RHN, apt >>support) so it can use yum's config file? > > If yum is supposed to replace up2date, then its config file, should be a > superset > of up2date. Who said yum is supposed to replace up2date? > After all, they are both supposed to do the same thing. Again, KDE vs. Gnome, vi vs. emacs, etc. > The bigger issues is that headers are saved in two different directories > on your system, so its guaranteed to get out of sync. Huh? Neither needs the others headers. > As a user, which tool am I supposed to use. > The answer (right now is) is... > > a) we give you a pretty icon on your desktop, but sometimes it lies. > b) when you click on the icon it runs up2date, but sometimes it lies > And it now lies about the packages sizes too! > c) If you decide to carry on with up2date, you now have to ignore all > of the GPG errors, because of... (well I don't know). Of install the correct GPG keys... > e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll > work. Have a reproducible situation? A bug number? I've been using up2date on FC1, FC2Test2, and FC2Test3 and I don't recall any hangs. > d) If you get frustrated by the now broken up2date and the GPG issues > you resort to using yum. But sometimes _it_ lies. So if "you resort to using yum" why do you think it should replace up2date? > So in the end you don't know what you've got, rpm -q > who's wrong, whats wrong > or where and how to fix it. They all use the same rpm database. > I don't mind having choices, but at least one of those choices should > work, and if the others don't. Then they shouldn't be supplied. Both work for me. YMMV. > "A man with two clocks, never knows what time it is." > > Sorry, there just appears to be too much of the > 'barely good enough engineering' going on here. > Do one thing, make it work, then go on to the next. Not: > "It powered up in the lab once, ship it, its a legacy product." I'm sorry, if you are not interested in new features why are you running a test release? [snip] >>So set up multiple rsync jobs and have a human check that the first is > done? > > > No, set up one job that rsyncs the RPMs, and then rsyncs the headers. And the case of headers being release on the main site after the first job is started is resolved how? [snip] >>> Pick one and throw the rest away. >> >>Yes, I think you should pick one and throw the rest away. > > OK, which one? Which one works? ...Neither. In my experience both. >> Fedora shouldn't because different people like different >> packages. What's this business with multiple GUIs? > > But you only run one GUI at a time. If you are trying to run up2date and yum at the same time you might have just answered your own question. >> multiple editors? > > But if I had two different editors and one only handled upper case > and the other only handled lower case, and both would randomly decide > whether they would support punctiatoion, they'd both be pretty useless. A analogy, but no link to the original subject. >> multiple browsers? > > And can you say 'built for IE' only? Fedora doesn't ship IE. >>For that matter, Fedora only ships two (up2date and yum) and both are >>using the same format for backend repos by default. > > But neither of them use the same front end database and neither > seem to work right... anymore. Both use a yum repo and both put transactions into the RPM database. What database are you talking about? -- William Hooper

1 0

kickstart under Fedora Core 2 Test 3
by Martin Robb 30 Apr '04

30 Apr '04

Mostly good news. Kickstart (both ks=cdrom and ks=floppy) is working better for me under FC2t3 than it was under FC2t2! Flaw 1: (major) though kickstart is still not quite working for me, I'm getting much farther than under t1 and t2 and I'm getting consistent behavior on several different platforms. In t1 and t2 I was being asked to load additional drivers by kickstart even though an interactive install using the same CD sailed right through. Under t3 I'm sailing right past that point and getting through most of the install. However, the install eventually dies with an "error installing at-3.1.8-52" dialog box. This happens consistently on different architectures and with different install CDs. The at rpm installs cleanly in an interactive install using the same install CDs. Flaw 2: (minor) The automatically built /root/anaconda-ks.cfg file is close but not quite there. It listed the following clearpart and part lines: #clearpart --linux #part / --fstype ext3 --onpart hda5 #part swap --noformat --onpart hda6 #part /sandbox --fstype ext3 --onpart hda7 Simply uncommenting these lines causes the install to fail with a "requested partition does not exist ... hda5" error. However, using the lines: clearpart --all --initlabel part / --fstype ext3 --size 4096 part /sandbox --fstype ext3 --size 1 --grow part swap --size 1024 everything partitions cleanly. As an aside, FC2t3 is installing cleanly (without kickstart) on the HP Proliant platform -- under t1 and t2 I was getting the dreaded "loading cciss drivers" hang. With kickstart it is at least giving me consistent behavior with my other platforms. Marty MartinRobb(a)ieee.org

1 0

RE: header/RPM mismatch
by William Hooper 30 Apr '04

30 Apr '04

Fulko.Hew(a)sita.aero said: > <RANT ON> > But both tools should be using the same config file!!! So yum should loose features and use up2date's config file (not very portable to non-RH systems), or should up2date loose features (RHN, apt support) so it can use yum's config file? > and the master site and the mirror site should be > consistent within themselves ie. I better have the RPM that > my hdr file points at. Ie. copy header files last. So set up multiple rsync jobs and have a human check that the first is done? > Also I don't think, by design you should allow either system to 'get into > a mode' where the various tables, databases and directories can 'get out > of sync' like this. > > And while I'm at it... This business about three different updating tools > that > use three different techniques, and 3 different stores, is a piece of ... > Pick one and throw the rest away. Yes, I think you should pick one and throw the rest away. Fedora shouldn't because different people like different packages. What's this business with multiple GUIs? multiple editors? multiple browsers? For that matter, Fedora only ships two (up2date and yum) and both are using the same format for backend repos by default. -- William Hooper

2 2

Re: images/bootdisk
by Mark Fonnemann 30 Apr '04

30 Apr '04

Hello- >>>http://download.fedora.redhat.com/pub/fedora/linux/core/test/1.92/i386/os/i… >>> >>> its in the t3 tree. >>> >>> -jef > On Fri, 30 Apr 2004 07:36:53 -0400, Gene C. <czar(a)czarc.net> wrote: > > > > I looked at > > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/im… > > > > and all I see is boot.iso and diskboot.img > > any chance that an image combining boot.iso and stage2.img into a single iso image? it'd be about 76MB or so but i'd rather have a complete installer... it'd be the perfect intermediate between the small boot.iso and the full download of 3 ISOs. i think its a good compromise for people with cable modems but what do i know? mark. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
104
Older →

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

test April 2004