All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Masanari Iida <standby24x7@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-doc <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-usb@vger.kernel.org
Subject: Re: make xmldocs failed with error after 4.17 merge period
Date: Fri, 6 Apr 2018 12:11:26 +0300	[thread overview]
Message-ID: <20180406091126.GC21589@kuha.fi.intel.com> (raw)
In-Reply-To: <20180406083010.GA20174@kroah.com>

On Fri, Apr 06, 2018 at 10:30:10AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > > After merge following patch during 4.17 merger period,
> > > > > make xmldocs start to fail with error.
> > > > > 
> > > > >  [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > > > usb: typec: API for controlling USB Type-C Multiplexers
> > > > > 
> > > > > Error messages.
> > > > > reST markup error:
> > > > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > > > (SEVERE/4) Unexpected section title or transition.
> > > > > 
> > > > > ------------------------
> > > > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > > > make[1]: *** [xmldocs] Error 1
> > > > > Makefile:1527: recipe for target 'xmldocs' failed
> > > > > make: *** [xmldocs] Error 2
> > > > > 
> > > > > $
> > > > > 
> > > > > An ascii graphic in typec.rst cause the error.
> > > > 
> > > > Thanks for the report. I'm going to propose that we fix this by
> > > > marking the ascii art as comment:
> > > > 
> > > > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > > > index feb31946490b..972c11bf4141 100644
> > > > --- a/Documentation/driver-api/usb/typec.rst
> > > > +++ b/Documentation/driver-api/usb/typec.rst
> > > > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> > > > 
> > > >  Illustration of the muxes behind a connector that supports an alternate mode:
> > > > 
> > > > -                     ------------------------
> > > > +..                   ------------------------
> > > >                       |       Connector      |
> > > >                       ------------------------
> > > >                              |         |
> > > > 
> > > > I hope that works.
> > > 
> > > Try it and see!  :)
> > 
> > It will fix this issue. I was just wondering if use of ascii art is
> > acceptable in general with the .rst files? But then again, why
> > wouldn't it be.
> 
> There are ways to do this, look at how the v4l2 and I think the drm
> subsystems handle ascii art such that "real" drawings end up being
> produced.

Thanks. I did not actually find anything else except use of tables and
code-blocks in v4l documentation. Is that what you were referring?

I was propsed to use something called "Literal Block" with ascii art.
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks

Unless you object, that's what I will use.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Masanari Iida <standby24x7@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-doc <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-usb@vger.kernel.org
Subject: make xmldocs failed with error after 4.17 merge period
Date: Fri, 6 Apr 2018 12:11:26 +0300	[thread overview]
Message-ID: <20180406091126.GC21589@kuha.fi.intel.com> (raw)

On Fri, Apr 06, 2018 at 10:30:10AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > > After merge following patch during 4.17 merger period,
> > > > > make xmldocs start to fail with error.
> > > > > 
> > > > >  [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > > > usb: typec: API for controlling USB Type-C Multiplexers
> > > > > 
> > > > > Error messages.
> > > > > reST markup error:
> > > > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > > > (SEVERE/4) Unexpected section title or transition.
> > > > > 
> > > > > ------------------------
> > > > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > > > make[1]: *** [xmldocs] Error 1
> > > > > Makefile:1527: recipe for target 'xmldocs' failed
> > > > > make: *** [xmldocs] Error 2
> > > > > 
> > > > > $
> > > > > 
> > > > > An ascii graphic in typec.rst cause the error.
> > > > 
> > > > Thanks for the report. I'm going to propose that we fix this by
> > > > marking the ascii art as comment:
> > > > 
> > > > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > > > index feb31946490b..972c11bf4141 100644
> > > > --- a/Documentation/driver-api/usb/typec.rst
> > > > +++ b/Documentation/driver-api/usb/typec.rst
> > > > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> > > > 
> > > >  Illustration of the muxes behind a connector that supports an alternate mode:
> > > > 
> > > > -                     ------------------------
> > > > +..                   ------------------------
> > > >                       |       Connector      |
> > > >                       ------------------------
> > > >                              |         |
> > > > 
> > > > I hope that works.
> > > 
> > > Try it and see!  :)
> > 
> > It will fix this issue. I was just wondering if use of ascii art is
> > acceptable in general with the .rst files? But then again, why
> > wouldn't it be.
> 
> There are ways to do this, look at how the v4l2 and I think the drm
> subsystems handle ascii art such that "real" drawings end up being
> produced.

Thanks. I did not actually find anything else except use of tables and
code-blocks in v4l documentation. Is that what you were referring?

I was propsed to use something called "Literal Block" with ascii art.
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks

Unless you object, that's what I will use.


Thanks,

WARNING: multiple messages have this Message-ID (diff)
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Masanari Iida <standby24x7@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-doc <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-usb@vger.kernel.org
Subject: Re: make xmldocs failed with error after 4.17 merge period
Date: Fri, 6 Apr 2018 12:11:26 +0300	[thread overview]
Message-ID: <20180406091126.GC21589@kuha.fi.intel.com> (raw)
In-Reply-To: <20180406083010.GA20174@kroah.com>

On Fri, Apr 06, 2018 at 10:30:10AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > > After merge following patch during 4.17 merger period,
> > > > > make xmldocs start to fail with error.
> > > > > 
> > > > >  [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > > > > usb: typec: API for controlling USB Type-C Multiplexers
> > > > > 
> > > > > Error messages.
> > > > > reST markup error:
> > > > > /home/iida/Repo/linux-2.6/Documentation/driver-api/usb/typec.rst:215:
> > > > > (SEVERE/4) Unexpected section title or transition.
> > > > > 
> > > > > ------------------------
> > > > > Documentation/Makefile:93: recipe for target 'xmldocs' failed
> > > > > make[1]: *** [xmldocs] Error 1
> > > > > Makefile:1527: recipe for target 'xmldocs' failed
> > > > > make: *** [xmldocs] Error 2
> > > > > 
> > > > > $
> > > > > 
> > > > > An ascii graphic in typec.rst cause the error.
> > > > 
> > > > Thanks for the report. I'm going to propose that we fix this by
> > > > marking the ascii art as comment:
> > > > 
> > > > diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst
> > > > index feb31946490b..972c11bf4141 100644
> > > > --- a/Documentation/driver-api/usb/typec.rst
> > > > +++ b/Documentation/driver-api/usb/typec.rst
> > > > @@ -212,7 +212,7 @@ port drivers can use USB Role Class API with those.
> > > > 
> > > >  Illustration of the muxes behind a connector that supports an alternate mode:
> > > > 
> > > > -                     ------------------------
> > > > +..                   ------------------------
> > > >                       |       Connector      |
> > > >                       ------------------------
> > > >                              |         |
> > > > 
> > > > I hope that works.
> > > 
> > > Try it and see!  :)
> > 
> > It will fix this issue. I was just wondering if use of ascii art is
> > acceptable in general with the .rst files? But then again, why
> > wouldn't it be.
> 
> There are ways to do this, look at how the v4l2 and I think the drm
> subsystems handle ascii art such that "real" drawings end up being
> produced.

Thanks. I did not actually find anything else except use of tables and
code-blocks in v4l documentation. Is that what you were referring?

I was propsed to use something called "Literal Block" with ascii art.
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks

Unless you object, that's what I will use.


Thanks,

-- 
heikki

  reply	other threads:[~2018-04-06  9:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06  3:38 make xmldocs failed with error after 4.17 merge period Masanari Iida
2018-04-06  3:38 ` Masanari Iida
2018-04-06  7:51 ` Heikki Krogerus
2018-04-06  7:51   ` Heikki Krogerus
2018-04-06  7:51   ` Heikki Krogerus
2018-04-06  7:57   ` Greg KH
2018-04-06  7:57     ` Greg KH
2018-04-06  7:57     ` Greg Kroah-Hartman
2018-04-06  8:15     ` Heikki Krogerus
2018-04-06  8:15       ` Heikki Krogerus
2018-04-06  8:15       ` Heikki Krogerus
2018-04-06  8:30       ` Greg KH
2018-04-06  8:30         ` Greg KH
2018-04-06  8:30         ` Greg Kroah-Hartman
2018-04-06  9:11         ` Heikki Krogerus [this message]
2018-04-06  9:11           ` Heikki Krogerus
2018-04-06  9:11           ` Heikki Krogerus
2018-04-06 10:03           ` Markus Heiser
2018-04-06 10:03             ` Markus Heiser
2018-04-06 10:03             ` Markus Heiser
2018-04-06 10:51             ` Heikki Krogerus
2018-04-06 10:51               ` Heikki Krogerus
2018-04-06 10:51               ` Heikki Krogerus
2018-04-06 11:38               ` Markus Heiser
2018-04-06 11:38                 ` Markus Heiser
2018-04-06 11:38                 ` Markus Heiser
2018-04-07 19:19                 ` Johannes Berg
2018-04-07 19:19                   ` Johannes Berg
2018-04-07 19:19                   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180406091126.GC21589@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=standby24x7@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.