Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failed to load external entity "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" #1

Open
GoogleCodeExporter opened this issue Mar 31, 2016 · 0 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?

downloaded GIT 1.7.9
./configure
make prefix=/usr all doc info


What is the expected output? What do you see instead?

No idea what the expected output is supposed to be. I saw the below message and 
re-ran "make doc" with the same result.

I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
(etc)
warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"

I checked the URL and can see it on my browser.

My various queries on the net reveal all sorts of "fixes" and none particularly 
current or germane to my OS.


What version of the product are you using? On what operating system?

Linux (my workstation's name) 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:12 EDT 2008 
i686 i686 i386 GNU/Linux

git 1.7.9
asciidoc 8.6.6



Please provide any additional information below.


Original issue reported on code.google.com by elaineri...@gmail.com on 1 Feb 2012 at 8:02

GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
When ac49f5c (rerere "remaining", 2011-02-16) split out a new
helper function check_one_conflict() out of find_conflict()
function, so that the latter will use the returned value from the
new helper to update the loop control variable that is an index into
active_cache[], the new variable incremented the index by one too
many when it found a path with only stage #1 entry at the very end
of active_cache[].

This "strange" return value does not have any effect on the loop
control of two callers of this function, as they all notice that
active_nr+2 is larger than active_nr just like active_nr+1 is, but
nevertheless it puzzles the readers when they are trying to figure
out what the function is trying to do.

In fact, there is no need to do an early return.  The code that
follows after skipping the stage #1 entry is fully prepared to
handle a case where the entry is at the very end of active_cache[].

Help future readers from unnecessary confusion by dropping an early
return.  We skip the stage #1 entry, and if there are stage #2 and
stage #3 entries for the same path, we diagnose the path as
THREE_STAGED (otherwise we say PUNTED), and then we skip all entries
for the same path.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
A conflicted index can have multiple stage #1 entries when dealing
with a criss-cross merge and using the "resolve" merge strategy.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
A conflicted index can have multiple stage #1 entries when dealing
with a criss-cross merge and using the "resolve" merge strategy.

Plug the leak by reading only the first one of the same stage
entries.

Strictly speaking, this fix does change the semantics, in that we
used to use the last stage #1 entry as the common ancestor when
doing the plain-vanilla three-way merge, but with the leak fix, we
will use the first stage #1 entry.  But it is not a grave backward
compatibility breakage.  Either way, we are arbitrarily picking one
of multiple stage #1 entries and using it, ignoring others, and
there is no meaning in the ordering of these stage #1 entries.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
GoogleCodeExporter pushed a commit that referenced this issue Mar 31, 2016
Code clean-up and minor fixes (so far).

* jc/rerere: (21 commits)
  rerere: un-nest merge() further
  rerere: use "struct rerere_id" instead of "char *" for conflict ID
  rerere: call conflict-ids IDs
  rerere: further clarify do_rerere_one_path()
  rerere: further de-dent do_plain_rerere()
  rerere: refactor "replay" part of do_plain_rerere()
  rerere: explain the remainder
  rerere: explain "rerere forget" codepath
  rerere: explain the primary codepath
  rerere: explain MERGE_RR management helpers
  rerere: fix benign off-by-one non-bug and clarify code
  rerere: explain the rerere I/O abstraction
  rerere: do not leak mmfile[] for a path with multiple stage #1 entries
  rerere: stop looping unnecessarily
  rerere: drop want_sp parameter from is_cmarker()
  rerere: report autoupdated paths only after actually updating them
  rerere: write out each record of MERGE_RR in one go
  rerere: lift PATH_MAX limitation
  rerere: plug conflict ID leaks
  rerere: handle conflicts with multiple stage #1 entries
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant