Hello community, here is the log from the commit of package xorg-x11-doc for openSUSE:Factory checked in at Mon Nov 15 16:04:15 CET 2010. -------- --- xorg-x11-doc/xorg-x11-doc.changes 2010-04-07 12:13:54.000000000 +0200 +++ /mounts/work_src_done/STABLE/xorg-x11-doc/xorg-x11-doc.changes 2010-11-12 13:51:26.000000000 +0100 @@ -1,0 +2,18 @@ +Fri Nov 12 12:08:40 UTC 2010 - sndirsch@novell.com + +- xorg-docs 1.5.99.901 (1.6 RC1) + * This package provides the X Window System documentation that + doesn't belong in a more specific package. It used to provide + a lot of docs that did belong in more specific packages, but + that has largely been corrected in this release: + git diff --shortstat xorg-docs-1.5..xorg-docs-1.5.99.901 + 155 files changed, 27570 insertions(+), 112431 deletions(-) + The protocol specifications have mostly moved to the matching + proto modules. The library API references have mostly moved + to the matching lib modules. The server internals docs have + mostly moved to the xorg-server module. + What's left has mostly (but not yet completely) been converted + to Docbook XML, from troff, SGML, and other formats. +- adjusted xorg-x11-doc.diff + +------------------------------------------------------------------- calling whatdependson for head-i586 Old: ---- xorg-docs-1.5.tar.bz2 New: ---- xorg-docs-1.5.99.901.tar.bz2 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xorg-x11-doc.spec ++++++ --- /var/tmp/diff_new_pack.pTVpNQ/_old 2010-11-15 16:03:58.000000000 +0100 +++ /var/tmp/diff_new_pack.pTVpNQ/_new 2010-11-15 16:03:58.000000000 +0100 @@ -1,5 +1,5 @@ # -# spec file for package xorg-x11-doc (Version 7.5) +# spec file for package xorg-x11-doc (Version 7.5.99.901) # # Copyright (c) 2010 SUSE LINUX Products GmbH, Nuernberg, Germany. # @@ -21,14 +21,14 @@ Name: xorg-x11-doc BuildRequires: docbook-utils pkgconfig xorg-x11-util-devel Url: http://xorg.freedesktop.org/ -Version: 7.5 -Release: 2 +Version: 7.5.99.901 +Release: 1 License: MIT BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-build Group: Documentation/Other Summary: X.Org documentation -Source: xorg-docs-1.5.tar.bz2 +Source: xorg-docs-1.5.99.901.tar.bz2 Patch: xorg-x11-doc.diff %description @@ -65,6 +65,6 @@ %files %defattr(-,root,root) %doc %{_mandir}/man7/* -%doc %{_datadir}/X11/ +%doc /usr/share/doc/xorg-docs/ %changelog ++++++ xorg-docs-1.5.tar.bz2 -> xorg-docs-1.5.99.901.tar.bz2 ++++++ ++++ 160502 lines of diff (skipped) ++++++ xorg-x11-doc.diff ++++++ --- /var/tmp/diff_new_pack.pTVpNQ/_old 2010-11-15 16:03:59.000000000 +0100 +++ /var/tmp/diff_new_pack.pTVpNQ/_new 2010-11-15 16:03:59.000000000 +0100 @@ -1,133 +1,12 @@ ---- man/general/Makefile.am.orig 2007-07-03 20:22:14.069593776 +0200 -+++ man/general/Makefile.am 2007-07-03 20:22:39.763091872 +0200 +--- man/Makefile.am.orig 2010-09-14 01:25:46.000000000 +0200 ++++ man/Makefile.am 2010-11-12 13:18:40.000000000 +0100 @@ -24,9 +24,7 @@ - miscman_PRE = \ - Consortium.man \ -- Xsecurity.man \ - Standards.man \ -- X.man \ - XOrgFoundation.man \ + miscman_PRE = \ + Consortium.man \ +- Xsecurity.man \ + Standards.man \ +- X.man \ + XOrgFoundation.man \ XProjectTeam.man - ---- ../xorg-docs-1.5.old//sgml/core/Xserver-spec.sgml 2010-04-04 12:34:52.000000000 +0000 -+++ sgml/core/Xserver-spec.sgml 2010-04-04 12:41:49.000000000 +0000 -@@ -4996,7 +4996,7 @@ mi and fb implementations.</para> - <listitem><para>none not implemented in sample implementation</para></listitem> - </itemizedlist> - </para> -- <table frame="all" id="routines-1"> -+ <table frame="box" id="routines-1"> - <title>Server Routines (Page 1)</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -5063,7 +5063,7 @@ mi and fb implementations.</para> - </tgroup> - </table> -- <table frame="all" id="routines-2"> -+ <table frame="box" id="routines-2"> - <title>Server Routines (Page 2)</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -5130,7 +5130,7 @@ mi and fb implementations.</para> - </tgroup> - </table> - -- <table frame="all" id="routines-3"> -+ <table frame="box" id="routines-3"> - <title>Server Routines (Page 3)</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> ---- ../xorg-docs-1.5.old//sgml/security/XACE-Spec.sgml 2010-04-04 12:34:52.000000000 +0000 -+++ sgml/security/XACE-Spec.sgml 2010-04-04 12:44:29.000000000 +0000 -@@ -188,7 +188,7 @@ - <section> - <title>Hooks</title> - <para>The currently defined set of XACE hooks is shown in <xref linkend="hooks_tab"/>. As discussed in <xref linkend="future_hooks"/>, the set of hooks is likely to change in the future as XACE is adopted and further security analysis of the X server is performed.</para> -- <table frame="all" id="hooks_tab"> -+ <table frame="box" id="hooks_tab"> - <title>XACE security hooks.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -330,7 +330,7 @@ - <para>The <structfield>parent</structfield> field is the parent resource itself or NULL if not set. The parent resource is set only when two conditions are met: The resource in question is being created at the time of the call (in which case the <structfield>access_mode</structfield> will include <literal>DixCreateAccess</literal>) and the resource in question has a defined parent object. <xref linkend="resource_access_parents" /> lists the resources that support parent objects. The purpose of these two fields is to provide generic support for "parent" resources.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are defined in <filename>include/dixaccess.h</filename>. The meaning of the bits depends on the specific resource type. Tables for some common types can be found in <xref linkend="resource_access_modes"/>. Note that the <literal>DixCreateAccess</literal> access mode has special meaning: it signifies that the resource object is in the process of being created. This provides an opportunity for the security extension to initialize its security label information in the structure devPrivates or otherwise. If the status field is set to an error code in this case, the resource creation will fail and no entry will be made under the specified resource ID.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the resource lookup will fail and an error (usually, but not always, the status value) will be returned to the client.</para> -- <table frame="all" id="resource_access_modes"> -+ <table frame="box" id="resource_access_modes"> - <title>Resource access hook access modes.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -455,7 +455,7 @@ - </tgroup> - </table> - -- <table frame="all" id="resource_access_parents"> -+ <table frame="box" id="resource_access_parents"> - <title>Resource access hook parent objects.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -497,7 +497,7 @@ - <para>The <structfield>dev</structfield> field refers to the input device being accessed.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the device operation will fail and an error (usually, but not always, the status value) will be returned to the client.</para> -- <table frame="all" id="device_access_modes"> -+ <table frame="box" id="device_access_modes"> - <title>Device access hook access modes.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -621,7 +621,7 @@ - <para>The <structfield>ppProp</structfield> field is a double-indirect pointer to the PropertyRec structure being accessed. The extra level of indirection supports property polyinstantiation; see below. If your extension does not use the polyinstantiation feature, simply dereference the pointer to obtain a <type>PropertyPtr</type> for the property</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the property request will not be processed further and the error code will be returned to the client. However, the <literal>BadMatch</literal> code has special meaning; see below.</para> -- <table frame="all" id="property_access_modes"> -+ <table frame="box" id="property_access_modes"> - <title>Property access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -728,7 +728,7 @@ - <para>The <structfield>target</structfield> field refers to the client being manipulated.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the request will fail and an error (usually, but not always, the status value) will be returned to the client.</para> -- <table frame="all" id="client_access_modes"> -+ <table frame="box" id="client_access_modes"> - <title>Client access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -787,7 +787,7 @@ - <para>The <structfield>client</structfield> field refers to the client making the request.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the request will fail and an error (usually, but not always, the status value) will be returned to the client.</para> -- <table frame="all" id="server_access_modes"> -+ <table frame="box" id="server_access_modes"> - <title>Server access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -844,7 +844,7 @@ - <para>The <structfield>ppSel</structfield> field is a double-indirect pointer to the Selection structure being accessed. The extra level of indirection supports selection polyinstantiation; see below. If your extension does not use the polyinstantiation feature, simply dereference the pointer to obtain a <type>SelectionRec *</type> for the selection.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the property request will not be processed further and the error code will be returned to the client. However, the <literal>BadMatch</literal> code has special meaning; see below.</para> -- <table frame="all" id="selection_access_modes"> -+ <table frame="box" id="selection_access_modes"> - <title>Selection access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -899,7 +899,7 @@ - <para>The <structfield>screen</structfield> field refers to the screen object being referenced.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the request will not be processed further and the error code will be returned to the client.</para> -- <table frame="all" id="screen_access_modes"> -+ <table frame="box" id="screen_access_modes"> - <title>Screen access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> -@@ -946,7 +946,7 @@ - <para>The <structfield>screen</structfield> field refers to the screen object being referenced.</para> - <para>The <structfield>access_mode</structfield> field encodes the type of action being performed. The valid mode bits are described in the table below.</para> - <para>The <structfield>status</structfield> field may be set to a nonzero X protocol error code. In this event, the request will not be processed further and the error code will be returned to the client.</para> -- <table frame="all" id="screensaver_access_modes"> -+ <table frame="box" id="screensaver_access_modes"> - <title>Screen saver access hook mode bits.</title> - <tgroup cols='3' align='left' colsep='1' rowsep='1'> - <thead> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Remember to have fun... -- To unsubscribe, e-mail: opensuse-commit+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-commit+help@opensuse.org