docs-qa November 2020

docs-qa@lists.fedoraproject.org

1 participants
15 discussions

[Bug 1790615] New: AppStream (formerly AppData) packaging guidelines use outdated terms and example code
by bugzilla＠redhat.com 21 May '24

21 May '24

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.

1 1

[Bug 1893428] New: netinstall image requirement for using kickstart could be made clearer
by bugzilla＠redhat.com 21 Jun '21

21 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1893428 Bug ID: 1893428 Summary: netinstall image requirement for using kickstart could be made clearer Product: Fedora Documentation Version: devel Status: NEW Component: install-guide Severity: low Assignee: pbokoc(a)redhat.com Reporter: glaebhoerl(a)gmail.com QA Contact: docs-qa(a)lists.fedoraproject.org CC: pbokoc(a)redhat.com, zach(a)oglesby.co Target Milestone: --- Classification: Fedora Based on the https://docs.fedoraproject.org/en-US/fedora/f33/install-guide/advanced/Kick… page, I attempted to add an inst.ks= boot option to my Fedora Workstation installation image (after copying its contents to a FAT32 filesystem). This resulted, when beginning the installation, in the message: "Kickstart is not supported on live installs. This installation will continue interactively." Googling for this message found single-digit hits, almost all of which were for the several-years-old commit which originally added the message. It was very unclear to me what I should have been doing instead, and spent most of a day fruitlessly googling to try to find out. Every page only ever said that I needed to add a boot option to the kernel command line of the installer (which is what I believed myself to be doing), and went from there. The root of the issue is that it was not apparent to me what the alternative to a "live install" was, or how to activate it. (Maybe I needed to pass different boot options so that it would boot directly into the installer?? I spent a while trying different ways to achieve this.) "Kickstart is not supported on live installs" may have been sufficient information back in the day when live and non-live installation images were provided side by side, but these days, at least for the Workstation version, live is the only download option prominently visible, and it is not even called out as being such. Finally, after trying the twentieth combination of search terms, I found that the page https://docs.fedoraproject.org/en-US/fedora/f33/install-guide/install/Prepa… mentions that "Kickstart installation requires the netinstall media type, or a direct installation booting method such as PXE; kickstarts are not supported with live images". I admit that if I had read all of the instructions linearly from beginning to end, then I would probably not have had this problem. Nonetheless, I humbly suggest that if the "Automating the Installation with Kickstart" page also made some mention of this requirement, it would be a helpful thing. In addition, it might be helpful to extend the "kickstart is not supported on live installs" error message with some mention of the suggested alternatives as well. Thank you for your work and attention. -- You are receiving this mail because: You are the QA Contact for the bug.

1 8

[Bug 1899912] anaconda generates an undocumented timesource option in kickstart file
by bugzilla＠redhat.com 23 Nov '20

23 Nov '20

1 0

[Bug 977051] Yum section should document using a proxy
by bugzilla＠redhat.com 04 Nov '20

04 Nov '20

https://bugzilla.redhat.com/show_bug.cgi?id=977051 --- Comment #1 from Ryan <im_dracula(a)hotmail.com> --- This should be included in the DNF section now, but most things use the system proxy config or $http_proxy and $https_proxy env vars so it may not be as necessary as it was back in Fedora 2x days...still, adding proxy=http://proxy:8080 to your dnf.conf file is still a possible solution -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1615208] /var diskspace is under specified
by bugzilla＠redhat.com 02 Nov '20

02 Nov '20

https://bugzilla.redhat.com/show_bug.cgi?id=1615208 --- Comment #2 from Leslie Satenstein <lsatenstein(a)yahoo.com> --- Has this issue been resolved? I am now using btrfs (One full partition) and if the issue is not resolved, the /var will gradually eat up all the partition space. -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

docs-qa November 2020