Does setting emails in your inbox folder to junk working automatically?
It seem it doesn't do it automatically and I have to keep selecting them
and manually marking them junk.
On a fresh install (such as this one), I do a restore from a backup file
as I always do, to include doiong the same thing in F16 (that worked
just fine) and the settings are there, and set as suppose to be. Also
evolution-bogofilter is installed as well. Just for some reason it's
not setting them to junk automatically.
"Best little town on Earth!"
# Fedora Quality Assurance Meeting
# Date: 2012-04-02
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
It's meeting time once more. As Beta slipped, we're still working on
blockers, so we'll be doing some review and RC3 planning. Also, we
didn't get to the 'QA as a sub-project' topic last week, so let's sign
off on it this week.
This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
The current proposed agenda is included below.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 17 Beta status / blocker review
3. 'Project' status
4. Test Day report
5. Upcoming QA events
6. AutoQA update
7. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
dd if=/dev/zero ~56MB/s CPU < 10%
dd if=/dev/urandom ~12MB/s CPU 99%
haveged ~54MB/s CPU < 25%
The dd relative values are consistent with kernels in Fedora 16. However these tests were done with 3.3.0-1. The questions are:
Is the urandom performance expected?
What is the quality of pseudo-random data produced by urandom vs haveged?
If the qualities are similar, or haveged's is better, is there anything that can be done to improve urandom's performance? It really takes quite a bit longer to prepare a disk/volume for encryption.
This affects the following:
Whose owners are CCd and which I'll handle rebuilding unless the
owners would rather.
in your fear, seek only peace
in your fear, seek only love
My problem is about possible ways to form the version-release fields for
a git post-release.. My example involves a version like 1.1.0 and a git
release like 20120329git1234567
Reading , all examples of post-release updates are on the form
foo-1.1.0-1.20120328git1234567.fc16. Obviously, this is one way to do it.
However, when I try to read the link carefully, I also see a possibility
to use a version-release like foo-126.96.36.19920328git1234567-1.fc16. My
reasoning based on the link:
- Version tags are either properly ordered or not.
- git tags like this are properly ordered (thanks to the date prefix).
- For properly ordered tags, the text explicitly says the tag can go
into the version field. However, there are no such examples.
Of course, another question is why. In short, I see some minor
advantages w r t robustness and consistency using this form. But for
now, this is not really the focus of this question.
So, my question: Reading , is a version-release like