[Bug 450331] New: lack of documentation on restoring from bare-metal (UUID problem)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=450331
Summary: lack of documentation on restoring from bare-metal (UUID
problem)
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: docs-requests
AssignedTo: kwade(a)redhat.com
ReportedBy: czar(a)acm.org
QAContact: stickster(a)gmail.com
CC: fedora-docs-list(a)redhat.com
Description of problem:
ref: https://bugzilla.redhat.com/show_bug.cgi?id=449299
There is a lack of documentation on restoring a system from bare metal. I have
found (see reference) that restore the root ("/") is not as simple as as just
executing the restore command when running in rescue mode.
With the current emphasis being place on use of UUIDs in both Fedora and RHEL,
the whole business of UUIDs need to be better documented.
Version-Release number of selected component (if applicable):
Fedora 9
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
11 years, 1 month
[Bug 479470] New: cobbler kssendmac and breed suse
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: cobbler kssendmac and breed suse
https://bugzilla.redhat.com/show_bug.cgi?id=479470
Summary: cobbler kssendmac and breed suse
Product: Fedora Hosted Projects
Version: unspecified
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: Deployment_Guide
AssignedTo: mhideo(a)redhat.com
ReportedBy: quenzler(a)us.ibm.com
QAContact: rlerch(a)redhat.com
CC: fedora-docs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
breed = suse
/boot/grub/menu.lst contains kssendmac
Version-Release number of selected component (if applicable):
cobbler-1.2.9-1.fc9.noarch
How reproducible:
Install a SuSE client
Actual results:
kssendmac exists as a boot parameter on a SuSE client
Expected results:
No kssendmac boot parameter
Additional info:
Find a way to avoid adding kssendmac to the kernel_options string if it's not
applicable to the breed.
Hack (since I'm only installing SuSE clients):
# diff utils.py utils.py.ori
478,479c478,479
< # if len(kernel_txt) < 244:
< # results["kernel_options"]["kssendmac"] = None
---
> if len(kernel_txt) < 244:
> results["kernel_options"]["kssendmac"] = None
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 9 months
Proposal for Implementing a Docbook Editor
by satya komaragiri
Hello,
I am a final year undergraduate student from India and I plan to apply
for Google Summer of Code. I would like to implement a Docbook editor.
I discussed this idea with Mr. Yaakov Nemoy (cc'ed in this mail) who
has agreed and is guiding me through the process.
The Docbook editor will make it easy to write documentation through a
wysiwyg interface. Since Docbook has a great collection of XSLs[1] it
will be easy to convert it to HTML and write a web based editor.
My research has pointed me to Beacon[2], which is a similar editor for
GuideXML (Gentoo's documentation format). It uses an XSLT engine to
transform XML to HTML and vice versa. I contacted the developer of
this project and it seems like this project has been in hibernation
for couple of months or so. But the codebase is quite developed and
should be easy to work with. The developers were also making it a
generic plug-able framework for easy integration of other doc types.
Since it is a web-based editor, we can integrate this into the Fedora
documentation site for easy editing and creation.
It would be very nice if the Docs team could provide some feedback on
what they feel about a web-based GUI editor which would eliminate the
need for knowing the Docbook XML format. If I am given a go ahead, I
would like to put this up as a Feature.
Regards,
Satya Komaragiri
[1] Existing XSL for Docbook:
http://wiki.docbook.org/topic/DocBookXslStylesheets
[2] Beacon: http://beacon.kix.in/
14 years, 11 months
[Fedora Release Notes] #29: Remove whitespace trigger ugly PDF formatting
by fedora-badges
#29: Remove whitespace trigger ugly PDF formatting
---------------------+------------------------------------------------------
Reporter: quaid | Owner: quaid
Type: task | Status: new
Priority: major | Milestone: RC-ready
Component: Content | Version: 10
Keywords: |
---------------------+------------------------------------------------------
Just in case we cannot get this fixed in the PDF toolchain, we need to
remove all the leading whitespace for tags that display CDATA or other
content verbatim.
This could be done as part of a general run of a tool such as docbook-lint
or xmlformat. Before doing that, we need to assess the risk of the tool
chaining line numbers and causing translation stats to go fuzzy.
--
Ticket URL: <https://fedorahosted.org/release-notes/ticket/29>
Fedora Release Notes <https://fedorahosted.org/release-notes/>
Fedora Release Notes
15 years
Wiki Freeze Tomorrow
by John J. McDonough
The wiki freeze is scheduled for tomorrow. If you plan to add some release
notes content to the wiki, time is getting short.
If there are items you think need more content, but you aren't comfortable
with the wordsmithing, leave some content in the wiki and the Docs folks
will be happy to clean up the prose.
Following the wiki freeze we still can make changes in the xml, so if
something comes up that should change the release notes, email myself or
Ryan Lerch and we will make the changes.
--McD
15 years
More Publican Pain
by John J. McDonough
Today I made the mistake of looking at the Publican produced release notes
with Internet Explorer. I can't believe it has taken me so long to make
this check, but it wasn't pleasant. They are pretty badly munged up. I
wonder if there are things we can do/set in Publican to straighten this out.
The first problem is that the first page stops with the logo image. This
eliminates the table of contents and first section. By changing the
chunking in Publican we can get the first section back, but I don't know how
to get the table of contents. And the little box where the logo belongs
looks trashy. I suspect I could modify the branding to use the png version.
I also did a different document with Publican, and all looked fine when I
looked at it on my local box, but when I moved it to a webserver off my LAN
(I believe it is RHEL), a bunch of XML shows up where the logo belongs when
viewed with FF. And it has the same issues with IE.
Second, every section number is followed by an A circumflex. I suspect this
is some sort of codepage issue, but I can't say I'm sure of that.
I checked the Fedora 10 release notes, which weren't produced with Publican,
and they are fine.
I know, why aren't I using Firerox/KonquerorOpera pick your favorite poison.
Fact is, Ryan put together the F11 RN's months ago, and amongst many
experiments, I've probably viewed them a hundred times, with Firefox, Opera,
SeaMonkey, Konqueror, Epiphany; I can't believe it has taken me this long to
look at them with IE. In spite of the inroads Firefox in particular has
made, Internet Explorer is still the big bear in the woods, and it doesn't
look good for Fedora if our documentation looks trashy.
--McD
15 years, 1 month
Publican Documentation Naming
by Eric Christensen
Earlier today the Fedora Packaging Committee (FPC) looked at two
"obstacles" to Publican-generated documentation. The first was the
naming convention[1] and the second was how Publican handles
the .desktop in the SPEC file[2]. Both passed the FPC.
The FPC did say that we (the Docs Project) need to create a review
process to ask "is this documentation really version specific? is there
value in having multiple releases in the same dist at once?". This is
an important test that we need to develop and handle in-house. This is
NOT a solution to allow all Publican documents but it is a solution for
allowing release-specific documents in Fedora.
Also discussed was the multiple SRPMs that are generated by having
multiple languages for each document. To simplify the process of
reviewing these it was suggested that we use subpackaging. Each SRPM
for each language would be wrapped into a single package.
I'm adding these three items to the agenda for this week's Docs
meeting[3].
[1] http://fedoraproject.org/wiki/PackagingDrafts/DocumentationNaming
[2] http://fedoraproject.org/wiki/PackagingDrafts/EmbeddedDesktopFiles
[3]
http://fedoraproject.org/wiki/Docs_Project_Steering_Committee_meetings
Thanks,
Eric
15 years, 1 month
