https://bugzilla.redhat.com/show_bug.cgi?id=1855464
Bug ID: 1855464
Summary: how to create and activate swapfiles post-install
Product: Fedora Documentation
Version: devel
Status: NEW
Component: docs-requests
Assignee: pbokoc(a)redhat.com
Reporter: bugzilla(a)colorremedies.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: nobody(a)fedoraproject.org, sparks(a)redhat.com,
zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
This feature means by default there will be no swap partition by default
https://fedoraproject.org/wiki/Changes/SwapOnZRAM
Some folks might want/need disk based swap.
swapfiles:
pros: easy to setup; no reboot required; supported on btrfs, ext4, xfs;
removable
cons: hibernation is sketchy. it should work on ext4, might work on xfs, does
not work on btrfs (it can but requires a tool to find an offset, due to the
lack of a standard interface across all file systems, for automatically finding
the offset)
https://lore.kernel.org/linux-btrfs/20200127192548.GA683123@vader/
partition:
pros: no limitations
cons: takes up space, isn't resizeable; more complicated/risky to create;
requires reboot.
Notes:
The installer's custom partitioning will continue to permit the creation of a
swap partition and will configure for hibernation.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1831542
Bug ID: 1831542
Summary: Documentation of PEERNTP variable
Product: Fedora Documentation
Version: devel
Status: NEW
Component: system-administrator's-guide
Assignee: pbokoc(a)redhat.com
Reporter: mlichvar(a)redhat.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: swadeley(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The PEERNTP variable, which can be set to "no" in /etc/sysconfig/network in
order to disable use of NTP servers provided by the DHCP server, is described
in the "Configuring NTP Using ntpd" section, but not in the "Configuring NTP
Using the chrony Suite".
Both ntp and chrony follow this setting. The documentation should make it clear
that NTP servers provided by DHCP are enabled by default.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1662306
Bug ID: 1662306
Summary: TigerVNC Configuration Page out of date
Product: Fedora Documentation
Version: devel
Hardware: x86_64
OS: Linux
Status: NEW
Component: system-administrator's-guide
Severity: medium
Assignee: pbokoc(a)redhat.com
Reporter: colin.henry(a)gmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: swadeley(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Documentation does not reflect current file configuration
Version-Release number of selected component (if applicable):
Fedora 29
How reproducible:
Try and follow the instructions on the configuration page, it tells you to
change settings that aren't there. For instance, users are told to edit the
and change:
ExecStart=/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
PIDFile=/home/USER/.vnc/%H%i.pid
Whereas the actual file contains:
ExecStart=/usr/bin/vncserver -autokill %i
PIDFile=/home/<USER>/.vnc/%H%i.pid
Steps to Reproduce:
1. Go to the documentation page:
https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide…
2. Install tigervnc-server
3. Look at the configuration file /lib/systemd/system/vncserver@.service
Actual results:
The files differ significantly, also following the instructions in the
configuration file fails to start vnc successfully, but I'll file a bug for
that separately.
Expected results:
Configuration documentation should match the files on the host
Additional info:
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1878577
Bug ID: 1878577
Summary: Grammar Mistake
Product: Fedora Documentation
Version: devel
Status: NEW
Component: documentation-guide
Severity: low
Assignee: pbokoc(a)redhat.com
Reporter: ali.cruz(a)me.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com, pkovar(a)redhat.com,
sparks(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Group: fedora_contrib_private
Classification: Fedora
Created attachment 1714711
--> https://bugzilla.redhat.com/attachment.cgi?id=1714711&action=edit
Grammar mistake
Document URL: selinux-managing-confined-services-guide
Section Number and Name: LOGO
Describe the issue: DOUMENTACIÓN de Fedora
Suggestions for improvement:
Additional information: selinux-managing-confined-services-guide
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1790615
Bug ID: 1790615
Summary: AppStream (formerly AppData) packaging guidelines use
outdated terms and example code
Product: Fedora Documentation
Version: devel
Status: NEW
Component: packager-guide
Assignee: pbokoc(a)redhat.com
Reporter: andrew(a)tosk.in
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pkovar(a)redhat.com
Target Milestone: ---
Classification: Fedora
I'm referring to the docs at "Packaging Guidelines for AppData Files"
<https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/>
The AppStream project has made a number of changes since these Fedora
guidelines were written, and the conflicting information confused me at first,
as I looked up how to add AppStream metadata to a new package I'm working on...
* In the Fedora guidelines, the second sentence
("Installed .appdata.xml files MUST follow the AppData specification page.")
links to
<http://people.freedesktop.org/~hughsient/appdata/>
but this URL now redirects to
<https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#se…>
* As far as I can tell, the AppStream specification no longer
uses the filename to distinguish between applications and
addons, and all AppStream metadata files should now be named
.metainfo.xml. Files for GUI applications are no longer named
.appdata.xml.
See
<https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#se…>
* The example .appdata.xml file in the Fedora guidelines is
therefore also out of date. The current AppStream spec,
for example, states that the component type should be
"desktop-application" instead of just "desktop".
Unless I'm misunderstanding something, the Fedora guidelines here will need to
be rewritten somewhat.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1850288
Bug ID: 1850288
Summary: Page Missing - v22 - multiboot-guide - "6.3.2.2.
Reinstalling GRUB on BIOS systems."
Product: Fedora Documentation
Version: devel
Status: NEW
Component: multiboot-guide
Assignee: pbokoc(a)redhat.com
Reporter: sy(a)josiahluscher.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: me(a)petetravis.com
Target Milestone: ---
Classification: Fedora
Description of problem: Entire documentation section missing.
Version-Release number of selected component (if applicable): v22
How reproducible: Very Easy
Steps to Reproduce:
1. Open the following page with web browser:
https://docs.fedoraproject.org/en-US/Fedora/22/html/Multiboot_Guide/GRUB-re…
Actual results: Header is displayed with no content.
Expected results: Enlightenment(?)
Additional info: My server won't boot! Plasse HALP! [Sad Human] -- Thanks!
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1859811
Bug ID: 1859811
Summary: The appdata guidance is out of date
Product: Fedora Documentation
Version: devel
Status: NEW
Component: packager-guide
Assignee: pbokoc(a)redhat.com
Reporter: t0dd(a)protonmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pkovar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
If you go looking for guidance for how to package RPMs, there is really no
better guide than what Fedora produces. It is therefore that much more
important that Fedora keeps up with Freedesktop.org standards.
The problem is that the "Packaging Guidelines for AppData Files" is out of date
and wrong.
Version-Release number of selected component (if applicable):
https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/
As of July 23, 2020
Actual results: Let's just tick off the problems (just a few, it needs a
revamp)
- .metainfo.xml files are now preferred and .appdata.xml is deprecated
- example .xml file has wrong component type and id
"""
<component type="desktop">
<id>comical.desktop</id>
"""
...that should be...
"""
<component type="desktop-application">
<id>comical</id>
"""
...better yet, that should be...
"""
<component type="desktop-application">
<id>com.example.Comical</id>
"""
It's also missing the launchable tag
"""
<launchable type="desktop-id">com.example.Comical.desktop</lauchable>
"""
Expected results:
See above.
Additional info:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1815635
Bug ID: 1815635
Summary: Fedora 31 bluetooth stopped working
Product: Fedora Documentation
Version: devel
Hardware: x86_64
OS: Linux
Status: NEW
Component: technical-notes
Severity: high
Assignee: pbokoc(a)redhat.com
Reporter: super250(a)g.uky.edu
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: wb8rcr(a)arrl.net, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem: bluetooth stopped working
Version-Release number of selected component (if applicable): 31
How reproducible:
Steps to Reproduce:
1.\<edit\> /usr/lib/systemd/system/bluetooth.service
\<add '-d' to ExecStart line as option to bluetoothd\>
2. systemctl daemon-reload
3. systemctl restart bluetooth
(Capture the logs to put in bugzilla report) journalctl -r -u bluetooth >
/tmp/bluetoothd.out
Actual results:
bluetooth.service: Service has
no ExecStart=, ExecStop=, or SuccessAction=. Refusing
Expected results:
bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
Active: active (running) since Wed 2017-10-04 16:07:40 EDT; 1 day 22h ago
Docs: man:bluetoothd(8)
Main PID: 27427 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4915)
CGroup: /system.slice/bluetooth.service
└─27427 /usr/libexec/bluetooth/bluetoothd
Additional info:
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1831872
Bug ID: 1831872
Summary: Legacy DNF enable repo documentation from gnome-wiki
Product: Fedora Documentation
Version: devel
Status: NEW
Component: documentation-guide
Assignee: pbokoc(a)redhat.com
Reporter: csiterallat(a)gmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com, pkovar(a)redhat.com,
sparks(a)redhat.com, stickster(a)gmail.com,
zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Document URL: https://fedoraproject.org/wiki/StackTraces#gdb
Section Number and Name: nstalling debuginfo RPMs using DNF
Describe the issue:
This command is doesn't work, it's Legacy!
dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo install
<pkg-spec>-debuginfo
Suggestions for improvement:
TRUE ENABLE REPO COMMAND ON FEDORA 32:
sudo dnf config-manager --set-enabled fedora-debuginfo updates-debuginfo
Additional information:
This link is come frome gnome-wiki
(https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Dist…)
I try to install debuginfo packages for totem, but this documentation is not so
helpful :(
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1889931
Bug ID: 1889931
Summary: feature request: release notes document status of
systemd-homed for install and upgrade to fedora33
Product: Fedora Documentation
Version: devel
OS: Linux
Status: NEW
Component: release-notes
Severity: medium
Assignee: pbokoc(a)redhat.com
Reporter: william.garber(a)att.net
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: relnotes(a)fedoraproject.org, wb8rcr(a)arrl.net,
zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
would like some easy to find documentation on status of systemd-homed setup
for install and/or upgrade to fedora33.
i.e. what happens to standard home directory on upgrade.
Version-Release number of selected component (if applicable):
fedora 32 upgrade to fedora 33
How reproducible:
would like to know how this works before installing.
Additional info:
was not so easy to find on web.
should be more easy to find on fedora website.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1901486
Bug ID: 1901486
Summary: Release notes should mention fixes for older systems
impacted by security tightening in F33
Product: Fedora Documentation
Version: devel
Status: NEW
Component: release-notes
Assignee: pbokoc(a)redhat.com
Reporter: russ+bugzilla-redhat(a)gloomytrousers.co.uk
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: relnotes(a)fedoraproject.org, wb8rcr(a)arrl.net,
zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
On booting my system after upgrade from F31 to F33, neither httpd nor dovecot
would start. This system is quite an old one that's been upgraded through many
versions of Fedora. This appears to be a result of "Strong Crypto Settings -
Phase 2" mentioned on
https://docs.fedoraproject.org/en-US/fedora/f33/release-notes/sysadmin/Secu…
The relevant errors were:
* Apache (/var/log/httpd/error_log):
[Mon Nov 23 11:44:11.517501 2020] [ssl:emerg] [pid 13680:tid 13680] AH02562:
Failed to configure certificate gigalith.gloomytrousers.co.uk:443:0 (with
chain), check /etc/pki/tls/certs/localhost.crt
[Mon Nov 23 11:44:11.517525 2020] [ssl:emerg] [pid 13680:tid 13680] SSL Library
Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
This cert was 1024 bit, first generated in 2010. The fix was to remove
/etc/pki/tls/certs/localhost.crt and /etc/pki/tls/private/localhost.key then
run /usr/libexec/httpd-ssl-gencerts.
* Dovecot (journal):
Nov 23 12:35:27 gigalith.gloomytrousers.co.uk dovecot[31160]: config: Warning:
please set ssl_dh=</etc/dovecot/dh.pem
Nov 23 12:35:27 gigalith.gloomytrousers.co.uk dovecot[31160]: config: Warning:
You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1
skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem
/etc/dovecot/dh.pem was present, dating from from 2013. The recommended fix did
NOT work (I recall having run this in the past) - it just generated an
identical file. The actual fix (stumbled across in bug 1882939) was to
regenerate the DH params with `openssl dhparam -out /etc/dovecot/dh.pem 4096`
(this took 32 mins on my machine!)
I suspect Exim might also have similar problems for some people, although I
didn't have a problem (my cert was 2048 bit from 2010, although I think I
generated this in a non-default way at the time). The fix in this case would be
to remove /etc/pki/tls/certs/exim.pem and /etc/pki/tls/private/exim.pem then
run /usr/libexec/exim-gen-cert.
I suggest these workarounds which might be required for older systems be
documented on
https://docs.fedoraproject.org/en-US/fedora/f33/release-notes/sysadmin/Secu…
- along with anything else that might suffer from similar issues.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1951400
Bug ID: 1951400
Summary: feature request: dnf-system-upgrade website
instructions for upgrade from previous to beta then to
final release
Product: Fedora Documentation
Version: devel
OS: Linux
Status: NEW
Component: install-guide
Severity: low
Assignee: pbokoc(a)redhat.com
Reporter: william.garber(a)att.net
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pbokoc(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
feature request
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
would like to see edit to above web page of yours:
instructions for how to upgrade
first from fedora 33 to 34 beta
next from fedora 34 beta to 34.
Additional info:
the instructions were found on the below website
and are copied below:
https://fedoramagazine.org/announcing-fedora-34-beta/
the name is simply 34.
And, it’s enough that you upgrade your system just once.
F34 Beta will evolve into F34 on (?)April 27–
all you should do is a regular update of packages
while no rebasing of the system is necessary.
sudo dnf upgrade –refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download –refresh –releasever=34
sudo dnf system-upgrade reboot
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1956227
Bug ID: 1956227
Summary: DNF System Upgrade page links to non-existent
component=dnf-plugin-system-upgrade
Product: Fedora Documentation
Version: devel
OS: Linux
Status: NEW
Component: install-guide
Severity: high
Assignee: pbokoc(a)redhat.com
Reporter: info(a)skierpage.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pbokoc(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
(there's no Fedora Documentation component for Upgrading to a new release, or
Quick Docs)
Description of problem:
I followed https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/,
it went smoothly, well done!
But under "Frequently Asked Questions - How do I report issues with the
upgrade?", the step
Search Bugzilla for an existing bug report.
is a link to
https://bugzilla.redhat.com/buglist.cgi?component=dnf-plugin-system-upgrade…
The bug list currently has one open bug 1767781 for the component
dnf-plugin-system-upgrade, but this doesn't seem to be a valid component any
more; it's not in the pop-up list when you enter a new bug. I'm not sure what
the correct component is for dnf system-upgrade bugs: some bugs are filed
against dnf, and others against dnf-plugins-extras.
Version-Release number of selected component (if applicable):
Not applicable.
How reproducible:
Every time.
Steps to Reproduce:
1. Read https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
2. Follow the link in "Search _Bugzilla for an existing bug report_."3
3. Try to file a bug.
Actual results:
Only one open bug for dnf-plugin-system-upgrade, and you can't choose this
Fedora component to enter a new bug.
Expected results:
Link should show a list of bugs with current system-update.
Additional info:
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1952656
Bug ID: 1952656
Summary: F33+ "DNF System Upgrade" needs changes.
Product: Fedora Documentation
Version: devel
Hardware: x86_64
OS: Linux
Status: NEW
Component: install-guide
Severity: medium
Assignee: pbokoc(a)redhat.com
Reporter: mattison.computer(a)yahoo.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pbokoc(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
The F33 (and newer) "DNF System Upgrade" instructions document has a couple of
minor issues, and one more serious problem.
Version-Release number of selected component (if applicable):
Fedora-33, and probably newer.
How reproducible:
not applicable.
Steps to Reproduce:
1. not applicable.
2. not applicable.
3. not applicable.
Actual results:
not applicable.
Expected results:
not applicable.
Additional info:
I. The "Clean-Up Old Packages" Section (2 minor issues).
In the "Clean-Up Old Packages" section, the instructions first say to do "sudo
dnf repoquery --unsatisfied", and then to do "sudo dnf repoquery --duplicates".
After that, there is a "NOTE" box saying to first do "sudo dnf update". After
the "NOTE" box, the instructions say to do "sudo dnf list extras", and so on.
A. Assuming that the "NOTE" box is saying to do the "sudo dnf update" before
doing the "sudo dnf repoquery --unsatisfied" and the "sudo dnf repoquery
--duplicates", the box should be moved to between
* the "Clean-Up Old Packages" section title, and
* the instruction to do "sudo dnf repoquery --unsatisfied".
So it should be:
1. The section title "Clean_Up Old Packages";
2. The "NOTE" box for sudo dnf update";
3. instruction to run "sudo dnf repoquery --unsatisfied";
4. instruction to run "sudo dnf repoquery --duplicates"; and
5. instructions to run "sudo dnf list extras", and so on.
B. According to the dnf man page, the "update" command is deprecated. It is now
"upgrade". So the dnf command in the "NOTE" box discussed above should be
"sudo dnf upgrade", not "sudo dnf update".
II. The "Clean-Up Old Symlinks" Section (more serious problem).
In the Fedora users list, in the thread "invisible application after upgrade",
one member said that the "sudo symlinks -r -d /usr"
step isn't necessarily a good idea. He provided an example. There was a
little more discussion in the Fedora users list thread "dangling symlinks and
upgrades (was "invisible application after upgrade").". This section needs to
be either redone or deleted. I do not have the expertise to be more specific.
I am a home user with no training as a sys.admin. I have a stand-alone home
work station. I do my own systems administration. So I rely on the Fedora
"DNF System Upgrade" document to guide me through semi-annual upgrades. I ask
that this section be researched and either improved or deleted as appropriate.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1957968
Bug ID: 1957968
Summary: WIFI connection with WPS-PBC not working
Product: Fedora Documentation
Version: devel
Hardware: x86_64
OS: Linux
Status: NEW
Component: wireless-guide
Assignee: pbokoc(a)redhat.com
Reporter: hk(a)hsyn.de
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: sradvan(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
WiFi Connection can't be established with the Fedora 34 via WPS-PBC.
Version-Release number of selected component (if applicable):
OS: Fedora 34 live USB stick.
Rooter: Fritz!Box 7590 v7.27
Notebook: ThinkPad w520
How reproducible:
Start Fedora 34 from USB stick. Try to connect to a WPA&WPA2 Secured WiFi.
Steps to Reproduce:
1.
2.
3.
Actual results:
Connection can't established.
Expected results:
Authentication without manual key enter
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1979552
Bug ID: 1979552
Summary: Typo in python api example
Product: Fedora Documentation
Version: devel
Status: NEW
Component: rpm-guide
Assignee: pbokoc(a)redhat.com
Reporter: laurence.rochfort(a)oracle.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: bcotton(a)redhat.com, pkovar(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
There is a typo in the code example in the following section:
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-si…
The example states:
To turn off all checks, you can pass –1 to setVSFlags:
ts.setVSFlasgs(-1)
The example code should be:
ts.setVSFlags(-1)
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1010477
--- Comment #5 from Marek Suchánek <msuchane(a)redhat.com> ---
We are now working on this documentation for RHEL. The plan is to publish it
with the RHEL 8.5 release.
See the cloned RHEL bug: BZ#1912408
--
You are receiving this mail because:
You are the QA Contact for the bug.