From: Ben Hutchings <ben@decadent.org.uk>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Masanari Iida <standby24x7@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lunar@debian.org
Subject: Re: make htmldocs on linux-next failed with warnings.
Date: Thu, 06 Aug 2015 23:39:58 +0100 [thread overview]
Message-ID: <1438900798.7315.53.camel@decadent.org.uk> (raw)
In-Reply-To: <20150806124331.10016ae7@lwn.net>
[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]
On Thu, 2015-08-06 at 12:43 -0600, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 08:31:59 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
> > On Thu, 16 Jul 2015 15:28:56 +0100
> > Ben Hutchings <ben@decadent.org.uk> wrote:
> >
> > > On Thu, 2015-07-16 at 23:22 +0900, Masanari Iida wrote:
> > > > make htmldocs on linux-next have some parser warnings.
> > > > Following commit cause the warning.
> > >
> > > Yes it has warnings but they should be non-fatal.
> >
> > Even so, we don't really want to be adding warnings to the build.
> > Hopefully it shouldn't be too hard to fix these...?
>
> So I've not heard any further on this.
Sorry about that. I didn't forget about it but didn't have a good idea
how to fix it.
> I think at this point I'm going
> to revert the patch in question; adding warnings for everybody is just
> not the right thing to do. The other patches in the series can stay.
OK.
> Having spent some time pondering on the issue, I've also concluded that
> this isn't quite the right solution to the problem. Better, I think, to
> have docproc filter out the duplicates directly, and to direct the output
> to a different file type (.fxml, say). Otherwise the .xml files can have
> two different things depending on which type of docs was built first,
> leading possibly to other formats being built with missing stuff.
>
> I may hack together a solution along these lines, just because I do think
> that the reproducible builds goal is an important one. But I've got a
> *bunch* of other stuff that I have to get done, so I'm not quite sure
> when I can get to it.
I've now thought of another approach, which is to keep the duplicates
during the build process and de-duplicate when installing. I've just
sent a patch along those lines.
Ben.
--
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
prev parent reply other threads:[~2015-08-06 22:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 14:22 make htmldocs on linux-next failed with warnings Masanari Iida
2015-07-16 14:28 ` Ben Hutchings
2015-07-16 14:31 ` Jonathan Corbet
2015-08-06 18:43 ` Jonathan Corbet
2015-08-06 22:39 ` Ben Hutchings [this message]
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=1438900798.7315.53.camel@decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lunar@debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox