Including a DOCTYPE reference to a DTD in the Repo manifest XML causes it to silent fail initialisation

Bug #1724498 reported by Thomas A. F. Thorne
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
repo (Ubuntu)
New
Undecided
Unassigned

Bug Description

I have written a manifest XML file for repo (or git-repo depending on how you like to name it). To help check my syntax, I attempted to generate a Document Type Definition (DTD) file to go with it based on the repo Manifest Format text document. When I include a <!DOCTYPE manifest SYSTEM "manifest.dtd"> line in my manifest XML file, repo silently fails to pull in the repositories.

I am relatively confident that the XML and DTD syntax is correct as I can call xmllint on the file when the DOCTYPE line is present and see it validate the XML against the DTD. It caught a couple of typos when I first ran the lint cycle, which is exactly the kind of thing I would like to be able to do by having the DTD file defined.

Here is the DTD file in question:
<!ELEMENT manifest (notice?,
                    remote*,
                    default?,
                    manifest-server?,
                    remove-project*,
                    project*,
                    extend-project*,
                    repo-hooks?,
                    include*)>

<!ELEMENT notice (#PCDATA)>

<!ELEMENT remote EMPTY>
    <!ATTLIST remote name ID #REQUIRED>
    <!ATTLIST remote alias CDATA #IMPLIED>
    <!ATTLIST remote fetch CDATA #REQUIRED>
    <!ATTLIST remote pushurl CDATA #IMPLIED>
    <!ATTLIST remote review CDATA #IMPLIED>
    <!ATTLIST remote revision CDATA #IMPLIED>

<!ELEMENT default EMPTY>
    <!ATTLIST default remote IDREF #IMPLIED>
    <!ATTLIST default revision CDATA #IMPLIED>
    <!ATTLIST default dest-branch CDATA #IMPLIED>
    <!ATTLIST default sync-j CDATA #IMPLIED>
    <!ATTLIST default sync-c CDATA #IMPLIED>
    <!ATTLIST default sync-s CDATA #IMPLIED>

<!ELEMENT manifest-server EMPTY>
    <!ATTLIST manifest-server url CDATA #REQUIRED>

<!ELEMENT project (annotation*,
                   project*,
                   copyfile*,
                   linkfile*)>
    <!ATTLIST project name CDATA #REQUIRED>
    <!ATTLIST project path CDATA #IMPLIED>
    <!ATTLIST project remote IDREF #IMPLIED>
    <!ATTLIST project revision CDATA #IMPLIED>
    <!ATTLIST project dest-branch CDATA #IMPLIED>
    <!ATTLIST project groups CDATA #IMPLIED>
    <!ATTLIST project sync-c CDATA #IMPLIED>
    <!ATTLIST project sync-s CDATA #IMPLIED>
    <!ATTLIST project upstream CDATA #IMPLIED>
    <!ATTLIST project clone-depth CDATA #IMPLIED>
    <!ATTLIST project force-path CDATA #IMPLIED>

<!ELEMENT annotation EMPTY>
    <!ATTLIST annotation name CDATA #REQUIRED>
    <!ATTLIST annotation value CDATA #REQUIRED>
    <!ATTLIST annotation keep CDATA "true">

<!ELEMENT copyfile EMPTY>
    <!ATTLIST copyfile src CDATA #REQUIRED>
    <!ATTLIST copyfile dest CDATA #REQUIRED>

<!ELEMENT linkfile EMPTY>
    <!ATTLIST linkfile src CDATA #REQUIRED>
    <!ATTLIST linkfile dest CDATA #REQUIRED>

<!ELEMENT extend-project EMPTY>
    <!ATTLIST extend-project name CDATA #REQUIRED>
    <!ATTLIST extend-project path CDATA #IMPLIED>
    <!ATTLIST extend-project groups CDATA #IMPLIED>

<!ELEMENT remove-project EMPTY>
    <!ATTLIST remove-project name CDATA #REQUIRED>

<!ELEMENT repo-hooks EMPTY>
    <!ATTLIST repo-hooks in-project CDATA #REQUIRED>
    <!ATTLIST repo-hooks enabled-list CDATA #REQUIRED>

<!ELEMENT include EMPTY>
    <!ATTLIST include name CDATA #REQUIRED>

I am writing a manifest for a Yocto work area so a minimal demonstration manifest.xml file is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manifest SYSTEM "manifest.dtd">
<manifest>
  <remote name="yoctop" fetch="git://git.yoctoproject.org/"/>
  <remote name="oe" fetch="git://github.com/openembedded"/>
  <default sync-j="4" revision="krogoth"/>
  <project name="poky" remote="yoctop" path="./"/>
  <project name="meta-openembedded" remote="oe" path="meta-openembedded"/>
</manifest>

With the DOCTYPE line in place I find that repo version v1.12.37 fails silently in its initiation and subsequent syncs. Without the DOCTYPE line you get a basic Yocto work area setup.
(You seem to need to have the manifest committed to a Git repository for repo to be happy using it.)

I posted a question about this on stackoverflow: https://stackoverflow.com/questions/44525174/is-it-possible-to-include-a-doctype-reference-to-a-dtd-inside-a-repo-manifest-xm
I realised the issue after posting a on the Google Group for repo-discuss https://groups.google.com/forum/#!searchin/repo-discuss/DOCTYPE%7Csort:relevance/repo-discuss/Js8JkvngQ0w/o1VdKcBwAgAJ
I have looked in both Ubuntu Launchpad and Debian but cannot find an existing bug. I also tried to work out what the upstream issue trackers is but with the demise of Google Code it is not clear to me where the repo code is now gathered from.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: repo 1.12.32-2
ProcVersionSignature: Ubuntu 4.10.0-35.39~16.04.1-generic 4.10.17
Uname: Linux 4.10.0-35-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.10
Architecture: amd64
Date: Wed Oct 18 09:51:33 2017
InstallationDate: Installed on 2017-10-06 (11 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: repo
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Thomas A. F. Thorne (tafthorne) wrote :
Revision history for this message
Thomas A. F. Thorne (tafthorne) wrote :

I have now raised a bug with Google / Android tools at https://issuetracker.google.com/issues/68131667
The Debian package maintainers suggested this was the bug tracker I should probably be using http://lists.alioth.debian.org/pipermail/android-tools-devel/2017q4/002864.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.