This file is indexed.

/usr/lib/lv2/eg-amp.lv2/manifest.ttl is in lv2-examples 1.14.0~dfsg1-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
# ==== Bundles ====
#
# LV2 plugins are installed in ``bundles'', a directory with a particular
# format.  Inside the bundle, the entry point is a file called `manifest.ttl`.
# The manifest lists the plugins (or other resources) that are in this bundle,
# and the files that contain further information.
#
# Hosts typically read the `manifest.ttl` of every bundle when starting up to
# discover what LV2 plugins and other resources are present.  Accordingly,
# manifest files should be as small as possible for performance reasons.
#
#
# ==== Namespace Prefixes ====
#
# Turtle files contain many URIs.  To make this more readable, prefixes can be
# defined.  For example, with the `lv2:` prefix below, instead of
# <http://lv2plug.in/ns/lv2core#Plugin> the shorter form `lv2:Plugin` can be
# used.  This is just a shorthand for URIs within one file, the prefixes are
# not significant otherwise.

@prefix lv2:  <http://lv2plug.in/ns/lv2core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

# ==== A Plugin Entry ====

<http://lv2plug.in/plugins/eg-amp>
	a lv2:Plugin ;
	lv2:binary <amp.so>  ;
	rdfs:seeAlso <amp.ttl> .

# The token `.so` above is replaced by the build system with the
# appropriate extension for the current platform (e.g. .so, .dylib, .dll).
# This file is called called `manifest.ttl.in` rather than `manifest.ttl`
# to indicate that it is not the final file to be installed.
# This is not necessary, but is a good idea for portable plugins.
# For reability, the following text will assume `.so` is the extension used.
#
# In short, this declares that the resource with URI
# `http://lv2plug.in/plugins/eg-amp` is an LV2 plugin, with executable code in
# the file `amp.so` and a full description in `amp.ttl`.  These paths are
# relative to the bundle directory.
#
# There are 3 statements in this description:
# [options="header"]
# |================================================================
# | Subject                             | Predicate    | Object
# | <http://lv2plug.in/plugins/eg-amp>  | a            | lv2:Plugin
# | <http://lv2plug.in/plugins/eg-amp>  | lv2:binary   | <amp.so>
# | <http://lv2plug.in/plugins/eg-amp>  | rdfs:seeAlso | <amp.ttl>
# |================================================================
#
# The semicolon is used to continue the previous subject; an equivalent
# but more verbose syntax for the same data is:

<http://lv2plug.in/plugins/eg-amp> a lv2:Plugin .
<http://lv2plug.in/plugins/eg-amp> lv2:binary <amp.so> .
<http://lv2plug.in/plugins/eg-amp> rdfs:seeAlso <amp.ttl> .

# (Since this data is equivalent, it is safe, if pointless, to list it twice)
#
# The documentation for a URI can often be found by visiting that URI in a web
# browser, e.g. the documentation for lv2:binary can be found at
# <http://lv2plug.in/ns/lv2core#binary>.  All standard LV2 classes and
# properties are documented in this way, so if you encounter a URI in some data
# which you do not understand, try this first.
#
# The URI of a plugin does not need to be a resolvable web address, it just
# serves as a global identifier.  However, it is a good idea to use an actual
# web address if possible for easy access documentation, downloads, and so on,
# even if no documents are currently hosted there.  There are compatibility
# rules about when the URI of a plugin must be changed, see the
# http://lv2plug.in/ns/lv2core[LV2 specification] for details.  Note that this
# does not require authors to control a top-level domain; for example, URIs in
# project directories at shared hosting sites are fine.  It is not required to
# use HTTP URIs, but use of other schemes is strongly discouraged.
#
# AUTHORS MUST NOT CREATE URIS AT DOMAINS THEY DO NOT CONTROL WITHOUT
# PERMISSION, AND *ESPECIALLY* MUST NOT CREATE INVALID URIS, E.G. WHERE THE
# PORTION FOLLOWING ``http://'' IS NOT A DOMAIN NAME.  If you need an example
# URI, the domain http://example.org/ is reserved for this purpose.
#
# A detailed explanation of each statement follows.

<http://lv2plug.in/plugins/eg-amp> a lv2:Plugin .

# The `a`, as in ``is a'', is a Turtle shortcut for `rdf:type`.
# `lv2:Plugin` expands to <http://lv2plug.in/ns/lv2core#Plugin> (using the
# `lv2:` prefix above) which is the type of all LV2 plugins.
# This statement means ``<http://lv2plug.in/plugins/eg-amp> is an LV2 plugin''.

<http://lv2plug.in/plugins/eg-amp> lv2:binary <amp.so> .

# This says ```eg-amp` has executable code in the file `amp.so`''.
# Relative URIs in manifest files are relative to the bundle directory, so this
# refers to the file amp.so in the same directory as this manifest.ttl file.

<http://lv2plug.in/plugins/eg-amp> rdfs:seeAlso <amp.ttl> .

# This says ``there is more information about `eg-amp` in the file `amp.ttl`''.
# The host will look at all such files when it needs to actually use or
# investigate the plugin.