On Thu, Nov 11, 2004 at 09:31:38AM -0600, Paul Johnson wrote: Synaptic requires apt. Apt is also great, but doesn't support multiarch, which is required for the x86_64 Fedora Core. -- Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/>

Kim Lux said: [snip] It seems to have to be mentioned every time, but apt isn't a packaging system. Apt on Fedora uses RPM to install the packages. The issues with apt aren't dependencies, it is the lack of multi-arch support and the fact that yum is written in python (which is the Red Hat preferred language). -- William Hooper

On Thu, 2004-11-11 at 09:49 -0700, Kim Lux wrote: I understand it is not graphical (yet) but you do know that yum exists, right? yum install nameofpackage it will download and install all the dependencies you need, too. -sv

On Thu, 2004-11-11 at 10:00 -0700, Kim Lux wrote: the repos aren't pointing anywhere meaningful? Where did you get the yum package? The yum package (in combination with fedora-release) that comes with fc3 has working configuration files. -sv

On Thu, 2004-11-11 at 10:08 -0700, Kim Lux wrote: you need to make sure that you have the right fedora-release package. This sets up the repo's in /etc/yum.repos.d -- Douglas Furlong Systems Administrator Firebox.com T: 0870 420 4475 F: 0870 220 2178

On Thu, 2004-11-11 at 10:13 -0700, Kim Lux wrote: rpm -ql fedora-release -sv

Notice these files. those are the yum repo files. -sv

On Thu, 2004-11-11 at 10:36 -0700, Kim Lux wrote: repository entries are in them. if you removed these files then that is why yum isn't working for you. if you didn't remove these files then you have them. what's the problem? -sv

On Thu, 2004-11-11 at 10:44 -0700, Kim Lux wrote: Aha! I've got an idea: If you changed the /etc/yum.conf file when you had an older version of yum, the new version won't clobber your config file. Check if you have a file called /etc/yum.conf.rpmnew . If you do, move your old /etc/yum.conf somewhere else (say, yum.conf.old - you can of course just rm this file when you've got a new working config but keep it around for reference for now) and then mv /etc/yum.conf.rpmnew /etc/yum.conf Then it should start looking at the files in /etc/yum.repo.d/ and if you haven't changed those it will point to FC3 + updates. Good luck! Per -- Per Bjornsson <perbj(a)stanford.edu&gt; Ph.D. Candidate, Department of Applied Physics, Stanford University

Just a quick side note: It's quite likely that actually getting your computer back on the FC3 updates track will fix your CD troubles (without mucking around with ide-scsi or anything like that), apparently the version of udev in the release was a bit quirky with a bunch of CD- ROMs. The new version is also faster in my experience. /Per -- Per Bjornsson <perbj(a)stanford.edu&gt; Ph.D. Candidate, Department of Applied Physics, Stanford University

On Thu, 2004-11-11 at 11:39 -0700, Kim Lux wrote: Oops. That's the updated version. Seems like I was wrong, sorry. Listen to Alan Cox instead of me, he knows what he's talking about, apparently I didn't in this case. /Per -- Per Bjornsson <perbj(a)stanford.edu&gt; Ph.D. Candidate, Department of Applied Physics, Stanford University

On Thu, 11 Nov 2004 10:44:11 -0700, Kim Lux <lux(a)diesel-research.com&gt; wrote: a couple of things to look at because of the way you upgraded from release candidate. 1) /etc/yum.conf should not have ANY repository definitions in it by default please check to be sure that you are using the default /etc/yum.conf that comes with fc3, and not an older yum.conf. You might find that rpm installed the default configuration file as yum.conf.rpmnew and left your previous yum.conf alone. The default yum.conf in fc3 should only have global variable definitions and should not include a repository entry. 2) Please look over each repo file included on the system in the repo.d directory. only certain files in that directory should have active repository entries. The others will have commented out entries that you can choose to enable by removing the leading # comments. Please make sure the the fedora-release and fedora-updates repo entries exist and are enabled. Please make sure the development entry if there is one is commented out. -jef

On Thu, 2004-11-11 at 12:01 -0500, seth vidal wrote: Just a side note: yum wouldn't update fedora-release-3-rawhide to fedora-release-3-8 for me, I had to do this manually. Nils -- Nils Philippsen / Red Hat / nphilipp(a)redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

There was a release (candidate) 8 ? I thought we stopped at rc 5 ? I agree that yum wouldn't upgrade anymore; I had the same problem and didn't have time to stop and find out why. There was a communication problem between the testers and the team in the last week or so prior to releasing. On Thu, 2004-11-11 at 18:29 +0100, Nils Philippsen wrote: -- Kim Lux (Mr.) Diesel Research Inc

I didn't update from a test release. I updated from a release candidate. I was told there is a difference. On Thu, 2004-11-11 at 14:35 -0500, William Hooper wrote: -- Kim Lux (Mr.) Diesel Research Inc

On Thu, 2004-11-11 at 13:04 -0700, Kim Lux wrote: Regardless of whether or not there is a difference, they are definitely the same in one respect: upgrades from either test release or release candidates to official releases are not supported. It is therefore to your benefit to set your expectations accordingly. It can and will break, albeit with RCs likely a lot less than test releases. But as you can see in your case, it has (slightly) broken things. So the general rule of thumb is that it will probably work most of the time, but you will likely need to spend a little time patching things up. We already beat this to death on this list (or was it fedora-devel- list?) earlier. What is it being rehashed again?

Kim Lux said: You are the one trying to make a distiction between "test" and "release candidate". They are the same thing. Those are what get tested. Trying to see if one random group of testing packages will update to another group of testing packages doesn't have anything to do with upgrading from a known set of released packages to a known set of release packages. [snip] The issue in this thread is a direct result of you trying to upgrade. End of story. [snip] Look at the subject again. No one here is talking about sound. Files that are changed outside of the normal RPM process (a big example are config files) aren't always over written. Additionally, some testing packages might appear "newer" than release packages, so they aren't upgraded. Your issue is most likely that you still have the wrong fedora-release RPM. Of course I'm guess here, because you are more interesting in ranting on about upgrading than giving us the info to help you. -- William Hooper

On Thu, 2004-11-11 at 14:33 -0700, Kim Lux wrote: Who? Lemme at 'em. ;-) Seriously, though, you are the only I remember asserting this. And by the way, what do you mean 'OK'? Some people (including me) *might* have said that it *might* work, but I don't remember anyone saying that it was supported or was ever going to be supported. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets

On Thu, 2004-11-11 at 14:00 -0700, Kim Lux wrote: [snip] You seem insistent on asserting that there is a difference between test releases and release candidates, while I don't remember anyone from Red Hat indicating anything of the sort. At least with respect to upgrades from RCs to official releases, there is no difference. I haven't seen RCs even *defined*. If they are not defined, how can you expect *anything* to be any more guaranteed to work than test releases. So the stance has not changed at all. You've just insisted on a definition of test releases that I don't think whoever labels release candidates as such shares. If whoever decided on the label 'Release Candidate' cares to comment, then fine, we may be on a path to defining what a Release Candidate actually is. Until then, you can assume nothing. See above. It all has to do an assumption you are making: that test releases and RCs are different. [mostly valid complaint about sound snipped] I won't argue with you about sound, since that is a change of topic anyhow. The problem at hand was yum repo files which are considered *config* files which do not always get updated, especially if they have been changed by the user (as that would be consider *bad* by most admins). But for the sake of argument, lets look at the four scenarios you presented: 1) FC2 final-> FC3Test3 = no sound 2) Clean FC3rc3 = no sound 3) FC3rc3 -> rc5 via yum when I finally got the repository = no sound. 4) FC3final = no sound. 1 - should have worked -- did you bugzilla? 2 - should have worked -- did you bugzilla (or update your bugzilla entry? 3 - no guarantees whatsoever ... the repo problem is no surprise and if you expect that to be fixed, you will be expecting for a long time 4 - should have worked, but only if you upgraded from FC2 or it was a clean install -- bugzilla? Show me where anyone has argued differently. If they did, you have every right to complain. What I have explained has been the (re-iterated many times) policy for as long as Red Hat has had beta/test/RC releases. It has not changed and likely won't. And I'll end it with a perfect example of what could easily have happened during *this* testing cycle from FC2 to FC3: rpm file conflicts. Through almost all test releases *and release candidates* file conflicts in rpm was turned off. It wasn't noticed until, I believe RC5 when the release notes were updated to reflect it. The subsequent flurry of protests triggered the rollback of the change to turn file conflicts back on. So it is entirely possible that some time between FC3RC1 and FC3 official, there may have been a package in rawhide that *overwrote* some file in some other rpm, but you never would have known. Subsequently upgrading via yum/rpm would not have caught that problem even when upgrading to the officially released rpm-4.3.2-21 and the officially released rpms of the packages in question (the one that overwrote the file from another package, and the one who's file got overwritten). But upgrading from FC2 *or* cleanly installing FC3 would not have exhibited the problem at all. Should that have happened? No. Is it what happens in real life? Yes. But the fact is that here is a perfect example of what can happen during a testing cycle that can cause possibly seriously unpredictable results when upgrading *from* test releases (note that I include RCs in my definition of test release until such time as whoever chose that label pipes in with what he defines it as). -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets

Paul Iadonisi wrote: I got the impression that the release candidates were very unofficialy bundled by a very nice chap (sorry can't remember your name mate), and mirrored by another very nice chappy over at duke.edu. I got the impression that there were three things being "achieved" by the RC's. A) Some final trails of the kernel, I get the impression they were not compleately confident and really wanted it tested thouroughly. B) Test a new build/release system. C) Let us eager beavers see the new greatest and latest, with most bugs squashed. No comments were made on http://fedora.redhat.com/ about it, which to me makes it "unoficial". What I hate, is the apparent attitude of some that seems to "demand" things from a free, voluntear force. I use fedora at work, BUT I know what I am getting and the stability of it, I also made it 100% clear to the company that I work for, what they are getting and what support they can expect. Nothing is being hidden from us, and at no point have I ever seen that upgrading from any thing other then a "Final Release" would EVER be "supported". Doug

Kim Lux wrote: Kim, I've seen you post to this list for a while now, you've been helpfull to quite a few people, but honestly, the tone of a lot of your messages on a couple of recent threads seem very antagonistic, I think it may be a good idea to step back for a while and cool down? Please don't take this in a condecending manner, as it's not meant in that way. Who were you told by? who were you garenteed by? This is a compleately open and unmoderated forumn. Unfortunately if you are given duf information, then there is little recourse, other then try to be more aware in the future, and take every thing said with a pinch of salt. In situations like this, it sounds like you will have to find the person responsible for the package, and then mail them directly, some times they just don't notice the bugzilla, or some one is shouting at them for another problem, letting off steam on this list is more likely going to just ostrasize you from the community which is no help to any of us. I assume this isn't one of the quotes ;) Yes, those bugs ARE taken seriously (I beleive). Upgrades are always asked to be tested, and they are probably one area that is not tested enough (I never upgrade....) It is not possible to maintain upgrade paths from essentialy random rawhide packages, upgrade paths are unlikly to be EVER planned for rawhide, or from test release to test release. And to be honest, I don't see why they should. To me this guy is saying, that it will probably be too much effort to trouble shoot the problem, and as such a fresh install would be easier/quicker. If he was wrong, then so be it, politely tell him other wise, don't get angry, or frustrated. sorry, but too tired to comment on the rest, I wanna go to bed :) Nighty night all. Dougie

This is my last post on this subject. It appears as though some of us disagree. I'll leave it at that. Comments below. On Thu, 2004-11-11 at 18:43 -0500, Paul Iadonisi wrote: They are all the same basic complaint: people use the fact that someone UPGRADED as an excuse not to take bugs seriously. My sound example was just that, an example. The topic hasn't changed since my first post. To make it clear: I no longer have an issue with sound. I am only using it as an example of when a bug was thought to have been caused by an UPGRADE when in fact the upgrade had NOTHING to do with it. Yep. Yes it did. FC3T3 broke my sound. At that point we have a bug that needs to be investigated. IT IS NOT PRUDENT TO TELL SOMEONE TO REINSTALL FROM FRESH HERE. IT IS TIME TO FIX THE BUG, NOT REINSTALL. (I'm not shouting, just emphasizing... I don't have bold...) Wrong answer ! Every upgrade should work. If the bug was fixed in FC3RC3, it should have worked fine. It would have. Wrong answer again ! You shouldn't have to reinstall to see if a bug is fixed !!! THIS ISN'T WINDOWS ! (Emphasis, not shouting.) I actually did option number 2 and proved the bug wasn't fixed. As far as I am concerned, if upgrading doesn't fix the bug, then then neither will installing fresh. Thinking that installing fresh will fix a bug is ludicrous ! Either all the packages are the same on the install are they aren't. It doesn't matter if they came from upgrade or fresh. Yep, that is what I did. I don't give a darn if it is "supported" or not. It should work. Don't you dare tell me I should have installed FC3final from fresh ! I posted my fix on 2 other sites and 2 other people have emailed me with thanks for helping them. The sound problem had NOTHING to do with fresh or upgrade. I originally upgraded from a good FC2 to FC3T3 and it didn't work. I am not going to repeat that process to find if the bug is still there or if the blacklist fixes it. I left it as an open bug. The developer can check if a) snd-intel8x0m needs to be blacklisted b) if the blacklisting occurs properly during install. It should be pretty straight forward to fix from here on in. When packages are updated, they are updated. Whether the original package was version 0 or version 23 shouldn't matter. This business of saying that the upgrade process from certain versions won't fix bugs is ludicrous. I'll bet I could install FC3T1 and upgrade to FC3 final and have a perfectly working system If I had time I would do it just to prove the point. That doesn't behoove me AT ALL. I'd would have loved someone to tell me there was a simple fix for this in the first place. Did you notice that I posted to the list several times about this issue before I upgraded/reinstalled and also tested 2 installs before reporting it as a bug. I understand that first releases aren't going to be perfect and that it will take a while until people find and fix all the bugs. WHAT I DONT LIKE IS PEOPLE BLAMING BUGS ON THE UPGRADE. Read my lips: UPGRADES ARE NOT AN EXCUSE FOR BUGS. BUGS ARE NOT FIXED BY FRESH INSTALLS. It might get broken, but the next update to that package should fix it again. You and I seriously disagree on that point. What do you mean by that ? I did several upgrades and they all worked. NO ! THE SOUND BUG IS NOT FIXED YET, EVEN NOW. Someone gave me a work around, but the next person to install with the same hardware is going to have the same problem. ABSOLUTELY NOT ! My fresh install of FC3RC3 proved it was NOT an anaconda bug as in something didn't install right. UUGGGGHHHH.... I didn't have any problems with upgrades. Upgrades worked fine. -- Kim Lux (Mr.) Diesel Research Inc

On Thu, 2004-11-11 at 17:40 -0700, Kim Lux wrote: Well, there is a problem with just leaving it at disagreeing. Eventually you are going to piss off some developer and he will tell you to take a hike. It has happened, and I won't cite the case to avoid embarrassing the offender, but it was case of much too high expectations. You're on that path as well. I suggest you *change* your expectation that upgrading from test releases must work (and if you think it should be fixed when broken, that too), or stop testing altogether. Otherwise, you are setting yourself up to be blasted by those who toil to give you the fruits of their labor for nothing other than some cooperation in troubleshooting a problem ... clean installs and upgrades from OFFICIAL releases being two of those steps. I agree with what someone else posted that you are a great help to many on this list, but I suspect that if something doesn't change with your expectations by the next testing cycle, you are going to find your reports of problems taken even less seriously than you say they are now. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets

Seth Vidal Wrote: I have used both apt-get for RPM and yum, and I have used both yumi (aka CoBind Manager) and synaptic. From a professional's point of view, synaptic/apt is superior in a number of ways: 1.) Header downloads are faster. I have timed the difference, using the same machine/OS, between a fresh 'yum update' run and an 'apt-get update && apt-get dist-upgrade' run. The apt run consistently finishes in a subtantially shorter amount of time, set up to use the same mirrors as the yum run. The yum run got bogged down in the header downloads. The difference in time was not small; I included DAG's RHEL3 repo in this instance, and, from a scratch WBEL3 respin1 install in both cases, the apt run took nearly two HOURS less time than the yum run. Downloading the headers from DAG took an hour and a half for yum, and less than five minutes for apt. This is on a T1 with a normally low-latency connection to MAE-East; congestion on the local pipe, according to mrtg, was similar during both runs. The machine on which this was running is a Dell PowerEdge 1750 (2.8GHz Xeon, 1GB RAM, 3x36GB 10kRPM U320 drives on a PERC4 RAID controller; machine performance is not an issue). I have duplicated the results for the yum run from home, where I have a DSL connection. I have duplicated the time lag about four times at this point, and a WBEL3r1->fully updated, KDE-Redhatted and DAGified WBEL3 takes approximately three hours to complete. I did virtually the same thing with Scientific Linux and went for SL303->KDE-Redhatted and DAGified SL in about an hour (downloading all the packages is close to an hour on my DSL). So it wasn't just a glitch in DAG's bandwidth. 2.) apt-get install and apt-get upgrade both run from the cache; thus, multiple install runs don't need to refresh the cache each and every run. Yum, OTOH, requires the specific use of -C to do this. Otherwise, each and every yum operation has to go out to the mirrors, refresh the header info, and might have to pull down new headers. Apt seems much faster in this regard. However, you do need to remember to apt-get update when needed, which might be considered a bad thing. 3.)Synaptic is not just head and shoulders better (from a user's point of view) than yumi currently, it is head, shoulders, torso, and legs better. Synaptic allows real package management, including seeing where your space hogs are in a very easy manner (sorting by size). I found yumi to be usable, but just barely so. The system-config-packages isn't even in the same league, since there is little to no documentation or configurability in use of third-party repos and individual package management (at least the last time I used it this was the case, but that has admittedly been a while). If some of synaptic's features can be added to yumi, yumi might be competitive. But the startup lag is so long and slow in non-local repo cases, that synaptic is just simply more of a joy to use because it feels more responsive. Now, synaptic has its own startup lag, but it is typically not as long as yumi's. Synaptic's ability to see into the package dependencies and dependents allows the user to remove packages if necessary in an intelligent manner. Both systems have dependency issues, and a yum repository is easier to set up and maintain. However, apt's configurability allows arcane command line parameters to at least troubleshoot the why of the problems. Yum's configurability is less stellar. I understand yum is intended to be simple, and for keeping a system up-to-date is is an excellent tool, paritcularly with a local repository where the latency issues of setting up a http GET for each and every header doesn't come into as much play as when you are accessing repositories halfway around the world (where it doesn't matter how fast the pipe is: TCP's windowing protocol limits your throughput regardless, and setting up the three-way handshake consumes significant time). In high-latency situations (which, if you are using, say, Scientific Linux and pulling packages from the KDE-redhat project, DAG's RHEL3 repository (in .be-land), and SL's own repository, is significant) yum loses to apt by simple network protocol metrics; apt downloads its large files (which benefit from TCP's window size increase algorithm) more quickly than yum can download its smaller files. Even if there have been few changes in the repository, I have found that an 'apt-get update && apt-get upgrade' sequence will have asked the user's confirmation and started downloading packages before a 'yum update' gets to the point of asking the user's confirmation. That is my experience here over a significant period of time. I tend to use both tools; yum for automatic updates, and synaptic for installing packages, or just seeing what new packages are out there (yumi's interface for installing new packages is not as easy to use as synaptic's: with synaptic, I can right click the package, select properties, and see at a glance what sort of dependencies a package has, see a description, etc). YMMV. And Seth, YUM does work, and it works well for its designed purpose (an updater). I use yum here with a local repository for Aurora Tangerine (SPARCLinux for those not familiar with it) since I have a 20 node Ultra30 cluster (well, not exactly a cluster, but close) running Tangerine. It behooves me to have a local repo in this case, and yum loses less in that instance. Note that these U30's only have 248MHz CPU's, 128MB RAM, and 4GB drives. Yum is faster on these boxes with a local (on the LAN) repo than it is on the Dell 1750 with non-local repos, showing that it seems to be network-bound performance-wise. Or, if you have space for it, a local rsync'd repo is a BIG WIN for yum performance. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu

On Thu, 2004-11-11 at 14:30 -0500, William Hooper wrote: I have to concur: I've tried both current yum and current apt to upgrade FC2->FC3. My experience with both of them basically matches with Lamar's. In addition to that, a "special" experience was using yum on connections with overloaded ftp-servers ... AFAIU, apt downloads its files in "one rush", while yum iteratively downloads the package headers. With overloaded servers rejecting or refusing connections on the remote end, yum bombed out with all kind of errors. I'll continue to use apt. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de

On Thu, 2004-11-11 at 09:49 -0700, Kim Lux wrote: No one said it was, William (I believe) state that APT was a single arch system. You really need to learn to seporate, RPM, APT, YUM, YUMI, YUMY (or however they are spealt) and Synaptic, up2date, etc etc etc they are different things. -- Douglas Furlong Systems Administrator Firebox.com T: 0870 420 4475 F: 0870 220 2178

On Thu, 2004-11-11 at 11:11 -0500, Temlakos wrote: Believe it or not this HAS been discussed in the past, as stated in a reply to this post some where else, we are using yum due to the multiple arch ability. I believe the yum and possible apt group are looking (in the long term) to work together so that repositories are interchangeable between apt and yum. This would make things like porting synaptic much easier, I believe. So in short, I believe it is being worked on, may be an idea to go to the fedora dev list. -- Douglas Furlong Systems Administrator Firebox.com T: 0870 420 4475 F: 0870 220 2178