[Bug 1008194] New: Enlightenment
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1008194
Bug ID: 1008194
Summary: Enlightenment
Product: Fedora Documentation
Version: devel
Component: release-notes
Keywords: Tracking
Assignee: relnotes(a)fedoraproject.org
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jreznik(a)redhat.com, metherid(a)gmail.com,
relnotes(a)fedoraproject.org, wb8rcr(a)arrl.net,
zach(a)oglesby.co
Depends On: 954132 (Enlightenment-Tracker), 998517
+++ This bug was initially created as a clone of Bug #998517 +++
This is a tracking bug for Change: Enlightenment
For more details, see: http://fedoraproject.org//wiki/Changes/Enlightenment
Enlightenment 0.17 a new stable release has been released after 12 years or so
of development. As many desktops are being landed on Fedora, Integrating
Enlightenment in Fedora can not only enlarge the number of available desktops
in Fedora, but also improve user experiences and give users another choice of
Desktop Environment.
------------------------
Discussion at
https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001210...
Please document this Change in the Release Notes.
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 5 months
[Bug 1008196] New: GLIBC 2.18
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1008196
Bug ID: 1008196
Summary: GLIBC 2.18
Product: Fedora Documentation
Version: devel
Component: docs-requests
Assignee: nobody(a)fedoraproject.org
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: codonell(a)redhat.com, jreznik(a)redhat.com,
nobody(a)fedoraproject.org, sparks(a)redhat.com,
stickster(a)gmail.com, zach(a)oglesby.co
Depends On: 999952
+++ This bug was initially created as a clone of Bug #999952 +++
This is a tracking bug for Change: GLIBC 2.18
For more details, see: http://fedoraproject.org//wiki/Changes/GLIBC218
Switch GLIBC in Fedora 20 to GLIBC version 2.18
--------------------------------------------------------
Discussion at
https://lists.fedoraproject.org/pipermail/devel/2013-July/184937.html
Please assess existing documentation for the impact of this Change.
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 5 months
[Bug 987710] New: section "Guest CPU models" needs updating
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=987710
Bug ID: 987710
Summary: section "Guest CPU models" needs updating
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
The section "Guest CPU models" should be updated, comments below:
Background:
- http://wiki.qemu.org/Features/CPUModels has the QEMU roadmap for relevant
features
- rawhide/F20 is currently shipping qemu-1.5.1
- F19 is currently shipping qemu-1.4.2
- F18 is currently shipping qemu-1.2.2
- Fedora ships qemu-kvm as /usr/bin/qemu-kvm not /usr/libexec/qemu-kvm
The first part of the section states CPU configurations are defined in XML
files rather than hardcoded; per the roadmap, they are again hardcoded to allow
compatibility code and more unified processor definitions. There's no
indication of backwards compatibility from qemu, although virsh and friends may
still accept .conf definitions and Know What To Do when talking to qemu.
In F18 and F19, `qemu-kvm -cpu ?cpuid` and `qemu-kvm -cpu ?dump` do not
function.
In F18, `qemu-kvm -cpu ?` gives a terse list of definitions.
in F19, `qemu-kvm -cpu ?` gives a more descriptive list, and also includes a
comprehensive list of recognized CPU flags. This could possibly replace
`?cpuid`
In both, `qemu-kvm -cpu <name>,enforce` functions as expected; this content is
commented out.
Looking further into comparing guest CPU features, I find `virsh capabilities`
will generate xml representing the host. It also appears to represent other
architectures that the host could emulate - if the appropriate packages (ie
qemu-arm ) are installed, and I correctly understand what they do.
There's also `virsh cpu-baseline` to generate a cpu definition that would allow
migration between file-defined hosts, and `virsh cpu-compare` to compare a
defined host with the local host. Both of these rely on [deprecated] xml .conf
cpu definition files. I haven't been able to find a more elegant way to compare
cpu configurations than scripting together the above virsh commands, presuming
`virsh capabilities` works the way I suspect.
The qemu roadmap cites `-cpu best` as a way to get the best CPU definition when
creating a guest - but it doesn't work here, and I'm not sure how it would make
a determination if it did.
A lot of the information I've discovered deals directly with qemu, not libvirt.
With qemu moving back to hard coded cpu definitions, I think it would be good
to get some insight on if libvirt tools are affected and how they are handling
the change. In general, I think it would be better to present libvirt commands
rather than commands executing qemu directly.
I'm not submitting a patch for this one because I'm not sure where to go with
it. It *seems* like libvirt should have a simple way to compare the
capabilities of heterogeneous hosts and aid in creating the best definitions
for guests.
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 5 months
[Bug 987664] New: Guide intro references documnetnation that is not available for Fedora
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=987664
Bug ID: 987664
Summary: Guide intro references documnetnation that is not
available for Fedora
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
Created attachment 777453
--> https://bugzilla.redhat.com/attachment.cgi?id=777453&action=edit
Patch commenting out unavailable guides.
The introduction to the Virtualization Deployment and Administration Guide
references related documentation that has been developed for RHEL/RHEV but is
not maintained for Fedora. The attached patch comments out those sections so
that only guides that are currently maintained for Fedora will be referenced.
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 5 months
[Bug 831619] New: Inaccuracy in Fedora 17 “Power Management Guide”
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=831619
Bug ID: 831619
QA Contact: docs-qa(a)lists.fedoraproject.org
Severity: low
Version: devel
Priority: unspecified
CC: ddomingo(a)redhat.com, oglesbyzm(a)gmail.com
Assignee: r.landmann(a)redhat.com
Summary: Inaccuracy in Fedora 17 “Power Management Guide”
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: vaskodd(a)yahoo.com
Type: Bug
Documentation: ---
Hardware: x86_64
Mount Type: ---
Status: NEW
Component: power-management-guide
Product: Fedora Documentation
Created attachment 591487
--> https://bugzilla.redhat.com/attachment.cgi?id=591487&action=edit
The problem description in .pdf format - easy to follow
Hi,
First I want to notice I am a Linux newbie and my English is not that good.
Now straight to the point! (The same description is available in the attached
pdf file and is more easy to follow)
I've noticed some inaccuracy in Fedora 17 “Power Management Guide” (Fedora
Documentation), particularly in section “2.5. Tuned and ktune” including
“2.5.1. The tuned.conf file” and “2.5.2 Tuned-adm”.
In section “2.5. Tuned and ktune” right bellow the “yum install tuned”
command it's written:
“Installing the tuned package also sets up a sample configuration file at
/etc/tuned.conf and activates the default profile.”
There is no such file in /etc. I found a /etc/tuned/active_profile file
containing the following: “/usr/lib/tuned/balanced/tuned.conf”. I'm not sure
this file (/etc/tuned.conf) is missing only on my system or it has a new
location by default for each profile - /usr/lib/tuned/profileX/tuned.conf.
Bellow in this section and in “2.5.1. The tuned.conf file” it is pointed again
that the default location for the tuned.conf file is /etc/tuned.conf.
In section “2.5.2 Tuned-adm” in the first paragraph it is written “Fedora 17
includes a number of predefined profiles for typical use cases...”. Just to be
precise it is good to be mentioned that these profiles are not installed by
default with “yum install tuned” command (tuned-2.0.1-1.fc17 package), but can
be found in tuned-profile-compat-2.0.1-1.fc17 package (I found it in Gnome
Package Manager).
Another thing in this section is in the last third of the page where it is
written:
“All the profiles are stored in separate subdirectories under
/etc/tune-profiles. So /etc/tune-profiles/desktop-powersave contains all the
necessary files and settings for that profile. Each of these directories
contains up to four files:”
There /etc/tune-profiles directory does not exist. Instead I found the profiles
stored in /run/lib/tuned.
Each directory for the corresponding profile typically contains only 2 files -
script.sh and tuned.conf. The presence of script.sh is not mentioned in the
directories contains description – it is mentioned ktune.sh insetad.
That's all. I hope this is helpful.
Best regards
Vasil Draganov
Fedora 17 3.4.0-1.fc17.x86_64
P.S. “Power Management Guide” is great. It's really useful. The moment i run
tuned service i noticed how quieter my laptop became (less heat – less fan
needed :) ). The first thing I noticed about new Fedora installation was that
the laptop was noisier in comparison to Win7 (I dual-boot with Win7). Tuned
just fixed that :)
Many thanks to the creators of Fedora Documentation!!!
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 6 months
[Bug 1011418] New: alias bondN bonding not required for bonding configuration
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1011418
Bug ID: 1011418
Summary: alias bondN bonding not required for bonding
configuration
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Assignee: swadeley(a)redhat.com
Reporter: john.haxby(a)oracle.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: swadeley(a)redhat.com
Description of problem:
In the F18 System Administrators Guide (and shouldn't that have an apostrophe
after the 's'?), §8.2.3 it says:
-----------------------
For a channel bonding interface to be valid, the kernel module must be loaded.
To ensure that the module is loaded when the channel bonding interface is
brought up, create a new file as root named bonding.conf in the
/etc/modprobe.d/ directory. Note that you can name this file anything you like
as long as it ends with a .conf extension. Insert the following line in this
new file:
alias bondN bonding
Replace N with the interface number, such as 0. For each configured channel
bonding interface, there must be a corresponding entry in your new
/etc/modprobe.d/bonding.conf file.
------------------------
This is not true. The network scripts in /etc/sysconfig/network-scripts
define the function install_bonding_driver which is called whenever a bonding
slave or master is detected.
Version-Release number of selected component (if applicable): F18
How reproducible: Always
Steps to Reproduce:
1. Configure a bond
2. Miss out the step that adds "alias bondN bonding" to a modprobe conf file
3. Notice that bonding actually works (NetworkManager notwithstanding)
Actual results: works as expected when ignoring the documentation
Expected results: works as expected when not ignoring the documentation
Additional info:
The install_bonding_driver has been around for a while, but the final piece of
code to make it reliable comes from, I think,
* Mon Aug 15 2011 Petr Lautrbach <plautrba(a)redhat.com> 9.03.24-1
...
- make sure the bond exists when we bring up the slaves. (#694501)
(commit id 3de0e06afda2e572d0952941498446fdda7f3f42)
--
You are receiving this mail because:
You are the QA Contact for the bug.
10 years, 6 months