Self-Introduction: Liu Zixi
by jetsaman@tuta.io
Hi, my name is Liu Zi Xi, who is often living in Liaoning, China, but will also go back to Beijing in the holiday, my IRC name and FAS username are Jetsaman, although I am still exploring IRC, which cannot be used in China normally.
I learned about the huge community of Fedora through my friend "mengjuntezhandui" on the Internet. We are all users of Fedora for a long time (although I may be younger). I have always been very interested in the Fedora QA, but now I Decide to officially Join it.
I can't say that I am good at programming or system packaging, but as a long-time Fedora user (and have used test software or even Rawhide and reporting errors), I think I can use idle time to make the package for the package. QA test and feedback report.
I once worked as an editor in oschina (open source China in Chinese, a well-known open source community in China), contributing dozens of articles on the comparison, introduction or recommendation of different open source software;
I Also Maintain My Blog Independently, And Use My Spare Time To Upload Some Articles About Software Recommendation and Simple Technology Teaching;
In Addition, I have participated in some not very well - known projects, But it is not horns ioning hereFinally.
At last ,I must apologize to you, I hope you forgive me unskilled and strange English expression :-)
From Jetsaman
3 years, 2 months
Proposal to modify: Working Sound Beta Release Criterion
by Lukas Ruzicka
Hello friends of Fedora,
I have been thinking about a proposal to modify the %subj. I have tried
several version and I did not like any, so finally I am proposing this text:
*Working sound*
*The installed system must be able to play back and record audio.*
This is a very short and general version, but I believe it supports the
following:
1. Playback and recording must work (which we want)
2. You can test on any application you like (The recording test case
will recommend Audacity)
3. It does not say that all applications must work, so we should be fine
if *some do*
What do you think?
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
3 years, 2 months
newbie question
by David
At this present state of Fedora 34 and Rawhide,
I see almost the same exact packages getting the same bumps in version
numbers, with only
the suffix "fc34" and fc35" being the difference.
1 ) Does this just mean that the identical packages are stored on the
server in a different directory ?
2 ) Are there any notable differences in the two products at this point ?
I assume that since there is Fedora 34 beta-freeze approaching, that
Rawhide will in the coming week or weeks have differences that are more
noticeable. Right ? If so, which ones ? the kernel ?? git
versions of certain packages ?
On a personal note, I will likely use Fedora 34 as my only operating
system, and no longer use Rawhide, as
I feel my brain-capacity has been maxxed-out, with whatever I had hoped to
learn from the Rawhide experience. I will likely
have several Fedora 34 SSD's with different DE's.
That all being said, for the time being I am sadly away from my computer,
having to do things on my phone, and a Chromebook.
Cheers,
David
3 years, 2 months
Blocker bugs
by pmkellly@frontier.com
I'm sitting here thinking about F34 Beta being just two days away and
what I have observed in my testing. I must admit being more than a
little concerned.
I have watched the blocker bugs and my concern stems from the fact that
I don't see some troubling ones listed there. Also there doesn't seem to
have been any discussion about these. Even if these don't technically
qualify as blockers, if they are not fixed. they will certainly send a
message to those those installing F34 Beta.
https://bugzilla.redhat.com/show_bug.cgi?id=1924908
I know the white screen with the sad face at least appears to be
cosmetic, but do we really want that.
https://bugzilla.redhat.com/show_bug.cgi?id=1928565
This is apparently one of the alerts that if a user has installed
setroubleshoot, they get alerts about every 2 seconds. Even if
setroubleshoot was not installed my guess is that the SELinux violations
are still occurring.
GCC has had trouble for the last three drops. Excuse me, I still have to
download 0221 for testing.
Our beta's are usually pretty sound, but from what I see these may
change that impression.
If I have gotten something wrong or missed something please let me know
if I am worried for no good reason.
Have a Great Day!
Pat (tablepc)
3 years, 2 months
criterion proposal: prevent services timing out on system shutdown
by Kamil Paral
*Why*
The recent spice-vdagent update causes all virtual machines to take 90
seconds longer on every shutdown/reboot:
https://bugzilla.redhat.com/show_bug.cgi?id=1813667
The service hangs when systemd tries to stop it, and systemd then kills it
after a 90 second timeout expires.
This is a recurring pattern, I saw services blocking shutdown/reboot in the
past, and so far we haven't been able to do anything about it from a
blocker perspective. I think that for cases where the problem occurs very
frequently or every time, we should have a way to block the release until
it's fixed. I find it a very poor experience to wait 90+ seconds for
machine reboot/shutdown. Much poorer than, say, a crashing desktop
application (which we block on), because that application can be replaced
with a different one. System services mostly can't be replaced, and
certainly not by a general user.
*Proposal*
So I propose to amend the "System services" criterion [1]:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
```
with something like this:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
*All system services present after installation with one of the
release-blocking package sets must not time out frequently or regularly
when they are being stopped during system reboot/shutdown.*
```
The way it is written, the mentioned bug would be a conditional violation
of that criterion (applies only to VMs) and we'd need to use our judgement
to determine whether it's a blocker.
Thoughts?
[1]
https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#System_se...
3 years, 2 months