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=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=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=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=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=1802159
Bug ID: 1802159
Summary: Default login for Fedora core os either undocumented
or missing
Product: Fedora Documentation
Version: devel
Status: NEW
Component: install-guide
Assignee: pbokoc(a)redhat.com
Reporter: hadmut(a)danisch.de
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pbokoc(a)redhat.com, zach(a)oglesby.co
Target Milestone: ---
Classification: Fedora
Description of problem:
I was just giving Fedora Core OS a first try and installed it from the ISO
image to the bare metal following the instructions at
https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/
Since I didn't have an ignition file yet, I just ran
sudo coreos-installer install /dev/sda
with out the ignition file, and this worked.
After rebooting, the system came up, but I could not login on the console. The
Docs do not contain a hint about what username and what password to use. When i
mounted the file system on a different linux machine I saw that there is a core
use with no password set. Since I'm not familiar with ostree, I wasn't sure
whether I was breaking anything if I just changed the password in the
/etc/shadow on that disk, and this is probably not the intended way to use the
system.
You end up with having a system that's of no use since you can't login.
Either the docs should tell how to login after plain install, or
coreos-installer should prevent from installing a system with no use and no
login.
regards
--
You are receiving this mail because:
You are the QA Contact for the bug.