Thank you for your reply. Comments are mixed in below. BTW, I may be reading the release notes already, but I'm not going to be one of the first adopters. The rest of you can blaze the trail and collect the arrows for me. ;) At 3:49 AM +0530 6/12/05, Rahul Sundaram wrote: >Tony Nelson wrote: >>Release notes are good. >> >>As Colin Adams says, the page looks odd unless I select UTF-8. >> >> > >This should be fixed soon. I rather expected that. ;) >>What is the difference between the release notes and the errata? The pages >>look about the same to me. >> >> >> >Yes. The errata is provided as a place for important updates after the >release has been made or corrections in it. Currently it does have some >differences if you read it carefully I didn't spot any, but I did check that my comments still seemed pertinent before posting them. >>Some things in the release notes are unclear. If they should be reported >>somewhere else, someone here will let me know. In any event, I'll learn >>something from the discussion (or flaming). >> >> > >The errata release notes provides this link http://tinyurl.com/al5g4 for >filing bug reports. If you would like to initiate a discussion or >provide feedback on the release notes or any other Fedora documentation, >fedora docs list (CC'ing this reply) is the best place now. We might >have a separate list for release notes in the near future but we havent >decided on that yet. I do read this list but this is a high traffic one >and not everyone working on the documentation is subscribed to this list >or following any discussions related to it here. ACK. This reply now, bug report in the future. >>1.1 Gnome is now 2.10. I read that wrong for a while, as 2.1.0, and was >>confused. If this is happening much, it might be worth spelling it out as >>well, "two point ten". >> >> >Potentially a good idea. Would have to careful not to overdo it Fer sure. Don't do it just for me; wait for someone else to complain as well so you know it's a real problem. >>5.2 When mediacheck says a disk is faulty, but says it is OK when one >>boots the installer with ide=nodma, should the installation be done with >>ide=nodma or without? >> >> >> >Installation can proceed without this option. Using this option would >probably slow down the installation. Using the sha1sum and burning on >slower speeds is pretty reliable Well, I just mention it as something unclear from both FC3 and FC4 release notes. It seems odd that mediacheck would need something to read the disk successfully, and yet the real install surely doesn't. >>How does one use sha1sum? From the installation process, or by booting an >>existing linux installation and running it there? (I.e., from where the >>CDs were burned.) >> >> > >same as md5sum. Run it on the ISO image and check this page >http://fedora.redhat.com/download after the release is made. Windows >users could use the following link which also contains the rationale for >switching over to sha1sum from previously used md5sum checks > >http://lists.gnupg.org/pipermail/gnupg-ru/2004-December/000158.html Given the extent of the discovered weakness and the likelyhood that people won't be installing this release more than a few years down the road, this seems to me to be an overreaction. Ah, well. Hopefully it is known that SHA1 is truely more secure than MD5, rather than just that there have been no alarming reports yet. >Note: I havent tried the Windows version. There might be better options >out there Well, the release notes would be a good place to put a (full) link to that sort of thing. Especially with the bug or whatever in mediacheck, there might be lots of people facing this roadblock when installing on a Windows machine, as I did, and I had enough trouble figuring out how to do the more mature MD5 checksum stuff. >>5.3 Re. third party package conflicts during upgrades, does the installer >>detect the problem and warn about it? If not, what is a good way to find >>them before installing, other than remembering every package installed and >>just knowing which ones have conflicts? >> >> >No. The installer overrides it if you have a conflicting package. >Solutions to this are pretty tricky. I would suggest relying on official >repositories whenever possible and check whether your packages are >working properly immediately after the installation. An rpm query on the >packager could potentially be used before or after the installation can >be used to find out which ones arent provided by Fedora. There are other >naming conventions which can be helpful too. As an example Rpmforge >repository using the "rf" tag and dag repository uses "dag" (duh!) for >easy identification. Then the release notes should say that, and that the installer won't even tell you about such problems, and that pre- and post-install rpm queries would be a good idea (give the proper command line). Just to be clear, since people do use other repos at times, good idea or no, and making the pre- list after installation will be hard. In the future, on upgrades, the installer might provide a list of original packages and which of them it replaced, and save it in some installation file somewhere. Unless it already does, in which case the release notes should mention it here. >>Re. Ximian Gnome (which I don't use), when the notes say "immediately" do >>they mean during the installations (when?) or during the first boot (from >>runlevel 3?)? >> >> >After the installation. Run level really doesnt matter. !! From the tone, I thought Gnome wouldn't work at all. >>6.1.2 Does one need to edit the kernel command line to include audit=1 in >>order for auditd to be "enabled by default"? Or is it already enabled, and >>"auditing within the kernel" is something else that can also be enabled? >> >> >As I understand it, the audit daemon is enabled by default but you need >to enable the kernel part of it explicitly (probably due to performance >hits) either during boot time (audit =1) or for the session (*auditctl >-e 1)* Hmm. So the audit daemon is running by default but not doing anything. >>6.1.4 Is alocate used by Actions -> Search for Files? (Apparantly yes.) Oops, slocate, meant to fix that. >I dont think gnome-search-tool using slocate. It is not a build >dependency. It doesnt seem to be linked to the binary (ldd). Its not >mentioned in the help file either I saw it in the FC3 Search for Files help Introduction section: "Search for Files uses the find, grep, and locate UNIX commands". Maybe that's not slocate, but man locate brought up the slocate man page. Don't know about FC4. >>It seems odd that it isn't enabled by default. I expect that there will be >>much confusion (as well as some disk savings) from this. Hopefully Search >>for Files will automatically inform users of the problem. I think the FC4 >>release notes should mention the dependency. >> >> >One of the reasons for disabling slocate cron (updatedb) by default is >that we are currently investigating more intelligent and efficient >methods to do this. See "Audit-layer based slocate replacement" in >Fedora bounties for a feasible alternative > >http://fedoraproject.org/wiki/FedoraBounties All that matters to me (and to most I think) is that Search for Files still works right out of the box. Improving it is good. >>6.2.2.3 Step 1: does up2date --get-source kernel work on FC4? It doesn't >>work for me on FC3, with a 404 Not Found error for some header.info page. >> >> >You are talking about >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141289. I am not >aware whether it has been fixed in FC4 or not OK. It might be good to mention the problem if it still isn't working. Otherwise people will think it's just them, as I did. >>Step 3: the command "cd/usr/src/redhat/BUILD/ikernel-<version> /usr/src/" >>seems odd to me, having two directories on it. >> >> >> >Good time for a release notes errata I guess ;-) > >regards >Rahul Thank you. ____________________________________________________________________ TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' <http://www.georgeanelson.com/>
