test April 2004

test@lists.fedoraproject.org

553 participants
1033 discussions

selinux, kickstart scripts and roles: I give up.
by Anthony Joseph Seward 30 Apr '04

30 Apr '04

As part of my kickstart %post script I run some commands as a normal user by using su. The shell environment in the %post script does not seem to have the permissions that I need to do this. I've tried 'setenforce 0', but that doesn't work. I tried to change the role too, but that didn't work. Does anyone have any ideas on how to get around this? TIA, ajs

1 0

how to install GPG keys for up2date?
by Rory Gleeson 30 Apr '04

30 Apr '04

I know this is going to seem like a dumb question to many, but how can I install GPG Keys for up2date, so I won't get GPG key prompts for each package, every time I update a batch? I'm a newbie to this GPG key thing - I haven't encountered when updating with other distros. Googling hasn't turned up any consistent info re: Fedora yet. Thanks, Rory

2 1

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

30 Apr '04

Fulko.Hew(a)sita.aero said: > > >> up2date and yum have different feature sets. > > As an end-user, I don't know that, and I don't see that, > unless I really dive into the documentation of both. Again, this applies to a number of things. That doesn't mean that one should go away. [snip] > I only have a single system image to update, therefore updating the > system is purely functional and could/should be devoid > of 'asthetic' flame wars. Never seen an apt/yum/up2date or deb/rpm/tgz flamewar, huh? [snip] > Whats wrong, is that for some reason (that I do not understand) > this morning I had the various apps reporting the following > various needs: > > package rhn up2date yum > ------------------------------------------------- > perl-XML-Twig need it need it need it > perl-Net-DNS need it need it > gaim need it > rpmdb-fedora need it > > I'd have to think that if they were all using the same info, > they'd be reporting the same thing. Wouldn't they? Are they using the same info? By default up2date will use a random mirror (possibly a different one each run). rhn-applet (which I assume is what you mean by rhn) I'm not sure, I will have to look. Yum uses download.fedora.redhat.com. > The fact that three different apps are reporting three different > 'apparent' states of my system is disconcerting. Please give us more info. How about the output of: yum check-update up2date -l rhn-applet-tui [snip] > My answers are... I don't know, I don't know, I don't.... > I installed whatever the 'system' told me to install. > If I needed something else, 'the system' should have either come > with it, or told me so, or the release notes.... It does come with the other GPG keys. > Otherwise, how am I to know? > I know this is a test release, but sorry... Exactly, which means as a tester the decision of what keys to trust falls on you. I definitely don't want up2date automatically importing beta or test keys on a production system. A better question to come out of this is why isn't yum doing gpg checks out of the box? > Because they are all intended to report the same information: > "what RPMs I should be updating" Just to take this reasoning to the extreme... apache and IIS should use the same configuration info because they both "serve HTTP"? The sooner you get past the idea that up2date and yum are different programs, even though they have some functional overlap, the better off you will be. [snip] >>It couldn't possibly be the fact that the mirrors (and main server) are >>being hammered by people downloading the new test release... > > Hammered, just means slow or no data... It should never mean 'incorrect > data'. Well, missing headers or packages on the mirror: no data Truncated package download: slow data followed by no data >>That is what testing is about, finding out if anything broke. If you >> want >>new features and no bugs (yeah, right) wait for the release. > > Sorry M$... no bugs should always take precedence over new features > especially since the bugs have been found and documented. Got a bug number from bugzilla yet? You are still running on the assumption that all your issues are the programs when it is more likely a mirror or rawhide tree issue. > Unless we test the software, report the problems, _and_ have the problems > fixed, there will be no point in waiting for the next release, because > the bugs will still be there in the new release. > (Just like the 'update/size' bug that hasn't been fixed since Core 1). Is a pretty cosmetic issue, but IIRC it only happens in 1 place now. The metadata hasn't changed so it still doesn't have the size information to put in before the packages are being downloaded. [snip] >>Whichever one you want. My point is that you don't run "both at the same >>time" you are running up2date, then running yum. Just like KDE and >> Gnome. > > OK, so noted. But on the other hand, if they are independent, and the > result is in the RPM database, I should be able to run both interchangably > but not simultaneously. Exactly. -- William Hooper

1 0

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

30 Apr '04

> up2date and yum have different feature sets. As an end-user, I don't know that, and I don't see that, unless I really dive into the documentation of both. The apparent, and implied use is that both tools can be used to update your system to the 'current' level. Perhaps both do more and different things above and beyond this basic function, but most people look to them to perform nothing else but 'updating to current'. > KDE and Gnome do the same thing (they are "Desktop Environments"). I guess you are correct. Where the functionality of KDE and GNOME overlap there should not be differences in configuration. But desktops _are_ different, they are visible, they are personal, so I give that a little more slack. I only have a single system image to update, therefore updating the system is purely functional and could/should be devoid of 'asthetic' flame wars. ... snip ... >>>> 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. >> >> Its more like neither _uses_ the other's headers... >> hence the duplication and inconsistency problems that result. >> (see the final comment). > >But vi not using emacs settings is OK? KDE not using Gnome settings is >OK? PostgreSQL and MySQL not using the same files? What is the >difference? Why is it so important that these two programs use the same >everything when there are so few examples of two programs that do? Whats wrong, is that for some reason (that I do not understand) this morning I had the various apps reporting the following various needs: package rhn up2date yum ------------------------------------------------- perl-XML-Twig need it need it need it perl-Net-DNS need it need it gaim need it rpmdb-fedora need it I'd have to think that if they were all using the same info, they'd be reporting the same thing. Wouldn't they? The fact that three different apps are reporting three different 'apparent' states of my system is disconcerting. Thats why I don't know who to believe. And yes, I know that rpm -q tells what I've got But this discussion thread revolves around: 'which of these packages _really_ need updating'? (Not a yum/up2date/apt-get/etc flame war.) >>>> 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... >> >> What are the correct keys? >> I installed test 3 from the release CDs and went through the >> upgrade process. Are there other manual, un-documented steps >> that need to be performed to get rid of these GPG errors? >> If so, please give me a link. > >Depends, what GPG keys did you install? You are running a test release, >did you install the test key? You are trying to get updates from rawhide, >did you install the rawhide key? My answers are... I don't know, I don't know, I don't.... I installed whatever the 'system' told me to install. If I needed something else, 'the system' should have either come with it, or told me so, or the release notes.... Otherwise, how am I to know? I know this is a test release, but sorry... people should not have to be fighting these types of issues past the first hour of a new release.. >http://fedora.redhat.com/about/security/ Ok, I will review that tonight, and see what it says. >> Because I don't know which tool I _should_ be using. :-( > >Which ever one you like. That is what choice is about. I would pick and only use one, but... Sorry, with three different tools telling me three different things make me believe that potentially none of them are right. >Again, why should two completely different programs use the same processes? Because they are all intended to report the same information: "what RPMs I should be updating" >> And both used to work for me too. Its just that as the days >> go by, and as we moved from test2 to test3, things are >> degenerating (here). > >It couldn't possibly be the fact that the mirrors (and main server) are >being hammered by people downloading the new test release... Hammered, just means slow or no data... It should never mean 'incorrect data'. >That is what testing is about, finding out if anything broke. If you want >new features and no bugs (yeah, right) wait for the release. Sorry M$... no bugs should always take precedence over new features especially since the bugs have been found and documented. Unless we test the software, report the problems, _and_ have the problems fixed, there will be no point in waiting for the next release, because the bugs will still be there in the new release. (Just like the 'update/size' bug that hasn't been fixed since Core 1). > (w.r.t. header files and RPM files on mirrors....) >You seem to be wanting to make a dependency there. On the contrary, _I_ don't want to make a dependency between hdrs and RPMs on repositories, but apparently there is one. And so, it should/must be dealt with in a professional manner. >Whichever one you want. My point is that you don't run "both at the same >time" you are running up2date, then running yum. Just like KDE and Gnome. OK, so noted. But on the other hand, if they are independent, and the result is in the RPM database, I should be able to run both interchangably but not simultaneously. >Again I ask why two separate programs should be expected to use the same >set of files. What if you have up2date checking an apt repo? or RHN? True, if two apps are using two different repositories, I would expect two different answers, but since they are not, they are using the same repositories, and the same mirrors, I expect them to report the same thing. >You are trying to jam up2date and yum into the same mold, and they won't >fit. They are two different programs with two different ways of doing >things. But the same basic end result: "... You have the following list of RPMs to install:"

3 2

FC2T3 problems with partition with BootIt NG
by Ken Roser 30 Apr '04

30 Apr '04

Are there any testers out there using BootIt NG? I installed test 3 and after some testing and some problems I decided to do another clean install. Using BootIt NG, I deleted the 3 logical volumes that were used by Fedora. These 3 logical volumes were in an extended partition that also included an NTFS volume. After deleting these volumes, BootIt NG didn't show that there was any free space in the extended partition. It did show the NTFS volume and its size was considerably less than the extended partition size so there should have been free space. Booting Win XP and using disk management I can see the free space. Also, another attempt to install Fedora does result in Fedora seeing the free space. It's only BootIT NG that doesn't see the free space. I'm currently working with the BootIT NG support person to try to resolve this, but I'm wondering if others here might have encountered the same problem. This wasn't a problem with test1 and test2; just test3. Is there anything going on with the disk partitioning that's different in test3? The computer is a Dell Dimension 8300 with 80 GB disk and 1 GB RAM.

1 0

smc2802wV1 Fedora Core1 Kernel 2.6.5
by linuxrh 30 Apr '04

30 Apr '04

I have kernel 2.6.5 working with fedora C1 but I can't get my smc2802w version1 working. I can't even get Fedora to see it. Any one have a step by step setup for this card and this O/S.... Scott....

3 2

Re: up2date choking on Perl:Twig
by t l 30 Apr '04

30 Apr '04

try "yum --exclude=perl-XML-Twig update" That should avoid the problem. This has already been bugzilla'ed: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122079 tom ------------------------------------------- From: "rgleeson" <rgleeson(a)childwelfare.ca> Subject: up2date choking on Perl:Twig To: fedora-test-list(a)redhat.com Message-ID: <20040430172221.M59667(a)childwelfare.ca> Content-Type: text/plain; charset=iso-8859-1 I've been having problems using up2date (and Yum and Apt, for that matter) with the latest round of updates on Test 3. Today I discovered it was was choking on Perl:Twig v.3.13-4. The error message is: "unresolvable chain of dependencies - requres Perl:XML XPath" I have a couple of question related to this: 1) I have everything installed from the Test 3 CDs. Why am I running in to a dependency issue like this on an basic update? I already have 3.09-3 installed. How can I resolve it? More long-term: 2) In the case of this conflict, would it not be a good idea to install everything possible and then note which packages couldn't be installed at the end, rather than choking the process at the beginning? 3) I keep getting GP Key (sp?) prompts for each package. Is there a way to bypass this? #2 and #3 speak to the fluidity of an update with up2date, being able to leave it do its business and not having to babysit it. 4) very minor cosmetic point: Why are there three periods on the bottom-left hand corner of the GUI for up2date? It makes it appear like it's still unfinished, which it may be, given it's a beta verion of Fedora. 5) I guess the refresh issue has been well-noted? The blanked out screens while retrieving info make it look as it up2date has stalled and needs to be re-started. Rory Toronto, Canada -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 2

up2date choking on Perl:Twig
by Rory Gleeson 30 Apr '04

30 Apr '04

I've been having problems using up2date (and Yum and Apt, for that matter) with the latest round of updates on Test 3. Today I discovered it was was choking on Perl:Twig v.3.13-4. The error message is: "unresolvable chain of dependencies - requres Perl:XML XPath" I have a couple of question related to this: 1) I have everything installed from the Test 3 CDs. Why am I running in to a dependency issue like this on an basic update? I already have 3.09-3 installed. How can I resolve it? More long-term: 2) In the case of this conflict, would it not be a good idea to install everything possible and then note which packages couldn't be installed at the end, rather than choking the process at the beginning? 3) I keep getting GP Key (sp?) prompts for each package. Is there a way to bypass this? #2 and #3 speak to the fluidity of an update with up2date, being able to leave it do its business and not having to babysit it. 4) very minor cosmetic point: Why are there three periods on the bottom-left hand corner of the GUI for up2date? It makes it appear like it's still unfinished, which it may be, given it's a beta verion of Fedora. 5) I guess the refresh issue has been well-noted? The blanked out screens while retrieving info make it look as it up2date has stalled and needs to be re-started. Rory Toronto, Canada

2 1

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

30 Apr '04

Fulko.Hew(a)sita.aero said: > > ... some context snipped for brevity... > >>> 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? > > If yum is not to replace up2date for updating, then why does it exist? > What itch is _it_ scratching that up2date > wouldn't/shouldn't/couldn't scratch? up2date and yum have different feature sets. >>> After all, they are both supposed to do the same thing. >> >>Again, KDE vs. Gnome, vi vs. emacs, etc. > > but KDE and Gnome do _not_ do the same thing, and they do not > use the same config files, and they are not infered to work together > (except for the rhn applet that does work on both task bars.) KDE and Gnome do the same thing (they are "Desktop Environments"). Because they are different programs they "and they do not use the same config files, and they are not infered to work together", just like yum and up2date. > As for vi vrs emacs, they both operate on the same kind text files, > and when your done editing your file with one, the file is still readable > and usable by the other editor, so thats not a valid analogy. up2date and yum operate on the same RPM files and when you are done the RPM database is usable by the other. What is not valid? >>> 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. > > Its more like neither _uses_ the other's headers... > hence the duplication and inconsistency problems that result. > (see the final comment). But vi not using emacs settings is OK? KDE not using Gnome settings is OK? PostgreSQL and MySQL not using the same files? What is the difference? Why is it so important that these two programs use the same everything when there are so few examples of two programs that do? >>> 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... > > What are the correct keys? > I installed test 3 from the release CDs and went through the > upgrade process. Are there other manual, un-documented steps > that need to be performed to get rid of these GPG errors? > If so, please give me a link. Depends, what GPG keys did you install? You are running a test release, did you install the test key? You are trying to get updates from rawhide, did you install the rawhide key? http://fedora.redhat.com/about/security/ >>> 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. > > Yes, 100% reproducible since yesterdays's daily RPM fetch. > ... while typing this message, I tried it again, and it no longer > hangs. :-( Maybe some of my earlier playing with the header > directories has resolved something... I don't know.... > But the 'there are 2 packages to fetch, but you can only select > one of them' issue still remains. Must have missed that thread. >>> 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? > > Because I don't know which tool I _should_ be using. :-( Which ever one you like. That is what choice is about. > I'd like to use the rhn_applet and up2date because: > a) thats what I used with RH7.x, 8.x, 9.x > b) it always _used_ to work > c) its on the desktop and its pretty, > d) and most of the time it works (or at least it did, > ignoring the 'size reporting' issue Already in bugzilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107048 > and the "GPG error' issues. See above. > But now that doesn't work so I have to use yum, > which gets me a 'little' further. > >>> So in the end you don't know what you've got, >>> who's wrong, whats wrong >>> or where and how to fix it. >> >>They all use the same rpm database. > > Sorry, I was talking about the various update notice facilities > and updating processes, not their end product. Again, why should two completely different programs use the same processes? >>> 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. > > And both used to work for me too. Its just that as the days > go by, and as we moved from test2 to test3, things are > degenerating (here). It couldn't possibly be the fact that the mirrors (and main server) are being hammered by people downloading the new test release... > ... snip ... > >>I'm sorry, if you are not interested in new features why are you running >> a >>test release? > > Because I want some of those new feature, but call me selfish... > I also don't want some of the old features broken. ;-) > Like up2date, or USB hotplug. That is what testing is about, finding out if anything broke. If you want new features and no bugs (yeah, right) wait for the release. >>>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? > > If there is a dependency and synchronization requirement on the > updating facility, then rsync is 'inappropriate' to use to maintain > mirrors in order to ensure 'system integrity'. You seem to be wanting to make a dependency there. >>>>Yes, I think you should pick one and throw the rest away. >>> >>> OK, which one? Which one works? ...Neither. >> >>In my experience both. > > That _used_ to be my experience, but since the virgin install of > test3, this no longer seems to be the case (and its not just me, > count at least 2 occurances here in Canada). > >> If you are trying to run up2date and yum at the same time you might have >> just answered your own question. > > Then I'm back to asking which one _should_ I be using? Whichever one you want. My point is that you don't run "both at the same time" you are running up2date, then running yum. Just like KDE and Gnome. > ... snip.... > >>> 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? > > The directories where current and ancient headers and rpms are saved: > > /var/spool/up2date > /var/cache/yum/development/headers Again I ask why two separate programs should be expected to use the same set of files. What if you have up2date checking an apt repo? or RHN? You are trying to jam up2date and yum into the same mold, and they won't fit. They are two different programs with two different ways of doing things. -- William Hooper

1 0

Re: alsa mute
by Law Horne 30 Apr '04

30 Apr '04

> > >/etc/asound.state is saved at shutdown, and running alsactl restore >immediately after login does restore the correct values for PCM and >other controls. So the problem seems to be that modprobe didn't run >alsactl restore at startup. > Would running "# rc-update add alsasound boot" Not fix that? This is kinda shot in a dark as this from another Linux distro alsa setup. But I have used this on slackware 9.1 and it worked despite this not being it's own setup guide. I haven't had a chance to try on fedora I got rid of my test3 installin favor of Fedora core 1. Law

2 1

← Newer
1
2
3
4
5
6
7
8
...
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