This sound good, but first we need to detect why rpms database got corrupted.
----- Original Message ----
From: Sam Varshavchik <mrsam(a)courier-mta.com>
To: Development discussions related to Fedora Core <fedora-devel-list(a)redhat.com>
Sent: Sunday, November 19, 2006 11:50:09 PM
Subject: Re: SUG: RPM database verification / repair, nightly and in Anaconda
Tony Nelson writes:
> I propose that there should be a nightly cron task to check the RPM
I proposed this several years ago, and got poo-poohed.
I now just have a cron.daily script that just makes a copy of /var/lib/rpm
on a five day rotation.
fedora-devel-list mailing list
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
The RPM database should be verified more often than it is now.
With FC6 there has been a spate of RPM database corruption. It happened to
me: though there may have been incipient corruption in my FC5, after
--rebuilddb and upgrading successfully I found more corruption later. This
brings up that the RPM database is just assumed to work, but isn't being
checked until it falls over.
I propose that there should be a nightly cron task to check the RPM
database with --verifydb, which would also attempt automatic repair (if the
Packages file is OK). I am developing and testing a shell script to do
this. Currently it seems to work when run manually; we'll see what happens
tonight. It logs its actions in syslog via logger. I expect that logwatch
will inform root by email.
I propose that Anaconda should check the RPM database before starting an
upgrade to an existing installation. Checking takes under a minute on my
system, so it should not be objectionable. Anaconda should offer to repair
a damaged RPM database (if the Package file is OK) before proceeding with
I suggest that the --verifydb command should not be undocumented in RPM and
its manpage. This seems to be on purpose, but I think it is a mistake.
I would like some feedback about these proposals. If they are acceptable I
will file RFE bugs on them.
My knowlege of things RPM is superficial. It would be a good idea to have
the proposed verification and repair methods criticised by authentic RPM
developers, but I'm not sure where they hang out -- the Redhat Rpm-list
appears to be for RPM users.
TonyN.:' The Great Writ <mailto:firstname.lastname@example.org>
' is no more. <http://www.georgeanelson.com/>
I am curious if anyone else is seeing it's processor at 100% when the
machine is supposed to idling (I do not use fancy screensavers, just
go to a blank screen after 10 minutes).
I noticed because this is a laptop and the fan is triggered by cpu
As soon as I touch the mouse, the CPU stops processing, but I can see
it was at 100% in the system monitor applet.
I suspect this is the inteded behavior of something but, nonetheless,
I would like to know what actually is (and eventually kill it...)
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
> Hi Igor,
> The .pot file hasn't been prepared by the author.
> It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ?
Why hasn't it be done at the same time than developing desktop-effects ?
Why translation is always seen as second class interest by developers ?
Why most translators seem to accept this second class idea ?
Why bugzilla bug reports must be opened to force a developer to add
Question I don't have any answer for ... yet ?
> Igor Pires Soares 提到:
> > Hello Guys!
> > Today I was looking into my "Translate" directory and noticed that there
> > is a desktop-effects folder, but there is only one po file inside. I
> > would like to know how to make a po file for my language.
> > Thanks in advance,
> > Igor Pires Soares
Congratulations for FC6, great work! I've been a long time
RH/FC user ('95), so I'm pretty excited about this release.
That being said, it's been a very rough experience from the
POV of a desktop experience. In fact, rather frustrating
Before I list the problems, let me just list a few datapoints:
* I try to keep a clean install, as close as possible to standard
* I use my desktop for email, browsing, VOIP, and hacking.
* I don't need proprietary 3D drivers, no games.
This is a very typical and non-taxing usage. Like for many (most?)
people out there the email, browsing, CD burning, and VOIP accounts
for probably 98% of what I need the desktop for.
So, considering this quite typical use case, this is what I
get from the upgrade from FC5:
1. Sound stopped working on my Intel ICH5 AC'97 Audio Controller
This killed VOIP on my box.
2. Evolution hangs when sending email
This renders Evolution almost entirely useless,
making this a critical bug.
3. Evolution continued to not print email bodies
A long standing and crippling bug in a business
environment where you receive invoices via email
that you need to print.
4. CD burining in Nautilus is broken
When clinking on the "Burn to CD..." button nothing happens
for >30 of seconds, then dialog appears. Clicking on the
drive dropdown to select another drive results in the same
freeze lasting 20s or so. A non-technical user would have
had to reboot the box!
5. Firefox starts using 100% after some time.
No bug report here, as I haven't figure out what to report,
but this makes browsing a painful experience. Slow, sluggish,
with hangs that lasts 10s of seconds. Every time I close a
Firefox window GNOME asks me if I want to kill it since it's
not reporting, etc. Horrible.
Considering these bugs, what is left of my desktop? I can't
use email, no sound/VOIP, CD burning is boken, substandard browsing.
I am not complaining about 3D drivers, fancy features, or Windows games,
but absolutely basic desktop features.
My question is: Quo Vadis? Shouldn't these problem been caught by QA?
Aren't these issues considered show stoppers for a Desktop distribution?
Dimi Paun <dimi(a)lattica.com>
Hi, the GNU cpio (http://www.gnu.org/software/cpio/) in some case (when
the folder's property is not contained into package) not set the
folder's access conforme to umask setting.
% find /tmp/some-folder -type f -depth |cpio -pvdmu /var/tmp
the some-folder and your subfolders copy into var/tmp have the access
set to "rwx------" (700), not in compliance with umask's setting (as an
The tar in these cases behaves itself correctly, creating the folders
(not contained in the package) compliance with umask's setting.
Is this a feature or a little bugs?
I have migrate some SCO unix to Linux and this "feature" is annoying.
I have watched into fc6's cpio-2.6-19.src.rpm and I have see witch some
patch has been added to the original version. But unfortunately I am not
a 'C' programmer and I not able to setup a specific patch witch set the
folder's access to umask's setting ...
What I can do?
Is possible add another patch for resolve this problem?
I must fill a bug into Bugzilla?
Pleas, give me some suggest ....
Many thanks to all, and sorry for my bad English
Dario Lesca <d.lesca(a)solinos.it>
I use Fedora daily, and I have a vested interest in -actively- helping
Fedora (and in-turn RHEL) become a better product.
I don't have a dedicated Rawhide machine, I do play with it from time to
time using VMWare Server, but this is fairly light testing as I'm pretty
short on time. (Just to see what's new)
I -do- try to install (at least on a VM machine) every test release and
give it a day or two of testing - but even this is hardly enough.
FC6 was a good release, but certain managed to slip through... some of
them rather critical (i586 kernel springs to mind) which should have
been found by us. (Read: testers)
As I see it, there's not enough Rawhide users to reduce the release bug
count, mainly because:
A. In my experience, 1 out of 2 rawhide installs break due to missing
dependencies - and spending four hours (and ~1+GB of bandwidth) just to
watch Anaconda choke on missing pygtk package is very frustrating.
B. Rawhide tends to break, a-lot.
C. As much as I disagree with this notion, people view Fedora as RHEL's
Alpha and view Rawhide as "experimental Alpha".
More then anything FC6 proved that 3 test releases may not be enough to
get a bug free release, so let me suggest the following:
A. Create more mile-stone releases. Once the tree reaches build
integrity (no missing packages), spin a test release. (Fixes P1, P2)
B. Change the terms that are being used to describe each test release.
Whether we like it or not, people are used to the "Alpha", "Beta" and
"RC" terms, and tend to consider "Test release" as "Alpha release". I
understand that the term "Test" was used to differentiate the
ever-rolling Fedora from the release-based RHEL, but Fedora has aged
enough to be viewed as an entity by itself and we can drop the "Test"
Using "normal" terms should help combat the "RHEL Alpha" and 'RHEL Alpha
experimental" image problem (Fixes P3).
C. Once Fedora hits RC, only bug fixes go into the tree. No last minute
2.6.39 kernel that break Anaconda, SCSI, and USB two days before the
release. Nada. New features can always enter the tree as updates once
the release ISOs have been sent.
Here's a mock Fedora release schedule:
T-4 Months: Alpha1
T-X Months: AlphaX
T-1 Months: Beta
T-3 weeks: RC1 - Tree go into lock mode.
T-1.5 weeks: RC2
T+n weeks: unexpected RC3.
T: release. Part time.
Many packages drop config files for logrotate in /etc/logrotate.d. without requiring logrotate, which is the owner of
/etc/logrotate.d, thus potentially leading to an unowned /etc/logrotate.d for users who don't want logrotate and thus remove it.
I see 2 solutions for this:
1) Add "Requires: logrotate" to all packages which put files in /etc/logrotate.d. IMHO this is not good as the user should be able
to choose if he wants logrotate or not.
2) Add /etc/logrotate.d to the filesystem package, this is my preferred solution.
I would like to hear what others think, before filing a bug against filesystem requesting 2) .