{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.bAFs7IKT/b1/tango_10.1.0+dfsg1-1~exp1_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.bAFs7IKT/b2/tango_10.1.0+dfsg1-1~exp1_amd64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,10 +1,10 @@\n \n 855bd274f9be58f3987fb23e04bceaa1 224548 libdevel optional libtango-dev_10.1.0+dfsg1-1~exp1_amd64.deb\n- 60eb3b3170caad23e92bd6d7165cb6ce 51693120 doc optional libtango-doc_10.1.0+dfsg1-1~exp1_all.deb\n+ 5ca4b1e48b8064c77f3a11edefe01a98 51693244 doc optional libtango-doc_10.1.0+dfsg1-1~exp1_all.deb\n 1cb9cb9499fc6a8ee13f86048a4f6ee8 417500 debug optional libtango-tools-dbgsym_10.1.0+dfsg1-1~exp1_amd64.deb\n 807b7b7f00f65be34ddf776484f2c191 43604 net optional libtango-tools_10.1.0+dfsg1-1~exp1_amd64.deb\n 9d4adb62b3b2ed1d4fd47ea0d708f270 34056104 debug optional libtango10-dbgsym_10.1.0+dfsg1-1~exp1_amd64.deb\n a2c9f6cdddb6ba1816b26d21406375e6 2292780 libs optional libtango10_10.1.0+dfsg1-1~exp1_amd64.deb\n f7609a3893ec61fbbf404dc1d9b888b8 1281120 debug optional tango-accesscontrol-dbgsym_10.1.0+dfsg1-1~exp1_amd64.deb\n d3a71da056871c45f9cce1414dc74c93 74684 net optional tango-accesscontrol_10.1.0+dfsg1-1~exp1_amd64.deb\n 009fd55285b68e621b7137d92ad4bb00 8648 net optional tango-common_10.1.0+dfsg1-1~exp1_all.deb\n"}, {"source1": "libtango-doc_10.1.0+dfsg1-1~exp1_all.deb", "source2": "libtango-doc_10.1.0+dfsg1-1~exp1_all.deb", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -1,3 +1,3 @@\n -rw-r--r-- 0 0 0 4 2025-09-05 17:22:14.000000 debian-binary\n--rw-r--r-- 0 0 0 18656 2025-09-05 17:22:14.000000 control.tar.xz\n--rw-r--r-- 0 0 0 51674272 2025-09-05 17:22:14.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 18640 2025-09-05 17:22:14.000000 control.tar.xz\n+-rw-r--r-- 0 0 0 51674412 2025-09-05 17:22:14.000000 data.tar.xz\n"}, {"source1": "control.tar.xz", "source2": "control.tar.xz", "unified_diff": null, "details": [{"source1": "control.tar", "source2": "control.tar", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "comments": ["Files differ"], "unified_diff": null}]}]}]}, {"source1": "data.tar.xz", "source2": "data.tar.xz", "unified_diff": null, "details": [{"source1": "data.tar", "source2": "data.tar", "unified_diff": null, "details": [{"source1": "./usr/share/doc/tango/html/_sources/Reference/glossary.md", "source2": "./usr/share/doc/tango/html/_sources/Reference/glossary.md", "comments": ["Ordering differences only"], "unified_diff": "@@ -47,84 +47,21 @@\n \n tangorc\n Tango configuration file holding various settings in the format `key=value`. This can be created globally in\n `/etc/tangorc` for unix-like OSes and in `${TANGO_ROOT}/tangorc` for Windows. Or for the current user only\n in `~/.tangorc` for unix-like OSes (not available for Windows). Environment variables with the same name\n override the entries from the files and the per-user file overrides the gobal one.\n \n-device pattern\n-\tProvides programmers with a framework on which they can develop new control objects.\n- For more details please see the {doc}`device-server-writing <../Tutorials/device-server-writing>` section.\n-\n-AtkPanel\n-\tAtkPanel is a generic control panel application. It can be used to control any\n-\tTango device. It supports most of Tango features and data types.\n-\tUsing AtkPanel you can view and set attribute values, execute commands, test\n-\tthe device and access diagnostic data.\n- For more details please see the {doc}`atkpanel <../Tutorials/atkpanel/atkpanel>` section.\n-\n-pipe\n-\tA pipe allows to read and/or write structured data from and/or to a {term}`device`. The data consists of one or more basic Tango data types. The structure of the data is defined by a {term}`device class` but is not static. It can be changed at runtime by the {term}`device` itself or modified upon request by a {term}`client` according to the `set_pipe_config` operation provided by pipe. The list of available pipes in a {term}`device` is defined by the {term}`device's ` {term}`device class`.\n- For more details please see the {doc}`pipe <../Explanation/pipe>` section.\n-\n-Attribute\n-\tAn attribute represents a process value (or values) in the system. It may have different formats or dimensions like scalar(0D), spectrum(1D) or image(2D). The attribute allows to read and/or write these values depending on programmer-defined access. The values may have different data types. In addition, an attribute provides some metadata like {term}`attribute quality`, timestamp or configuration properties. For a complete list please refer to the manual. A list of attributes available for a certain device is defined by its {term}`device class`.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Dynamic Attribute\n-\tA {term}`device` can create {term}`Attribute`s that have their configuration determined during device initialization or even later when the Device is already running. This kind of Attribute is called *Dynamic Attribute*.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Attribute quality factor\n-\tA value returned by an {term}`Attribute` has a runtime quality factor which is an enumeration describing the state of the read value (one of VALID, INVALID, ALARM, CHANGING, WARNING).\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Attribute quality\n-\tAnother name for {term}`Attribute quality factor`.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Enumerated Attribute\n-\tAttributes with a scalar data format can be enumerated allowing a set of defined label+value pairs.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Memorized Attribute\n-\tThe last written value for this type of attribute will automatically be stored in the database so that on startup this value is fetched and written to the attribute.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Forwarded Attribute\n-\tA forwarded attribute is one that gets its configuration from another attribute, which is known as the *root attribute*. It will forward requests, configuration changes, event subscriptions and locking behaviour to the root attribute.\n- For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n-\n-Tango Controls\n-\tTango Controls is an object-oriented, distributed control system framework which defines a communication protocol, an Application Programmers Interface (API) and provides a set of tools and libraries to build software for control systems, especially {term}`SCADA`.\n- For more details please see the {doc}`overview <../Explanation/overview>` section.\n-\n-Tango Resource Locator\n-\tSchema used to identify tango objects, similiar to [URLs](https://en.wikipedia.org/wiki/URL). The Tango Resource Locator is defined in [Tango's RFC 16](https://tango-controls.readthedocs.io/projects/rfc/en/latest/16/TangoResourceLocator.html)\n- For more details please see the {doc}`naming <../Explanation/naming>` section.\n-\n-command\n-\tA command is an operation a user may invoke on a device (eg. `SwitchOn`, `SwitchOff`). It also relates to a specific method in OOP (Object-Oriented Programming). Tango Controls allows a command to get input argument (argin) and to return a value (argout). List of available commands for a certain device is defined by its {term}`device class`. See the [command section](<#tango-command-model>) of this documentation for more details.\n- For more details please see the {doc}`command <../Explanation/command>` section.\n-\n-device\n-\tA device is a key concept of Tango Controls. It is an object providing access to its {term}`attributes `, {term}`pipes ` and {term}`commands `. The list of attributes, pipes and commands available for a certain device is defined by its {term}`class `. The device may be related to a hardware device it interfaces with or it may be a kind of a logical device providing some functionalities not directly related to hardware.\n- For more details please see the {doc}`device <../Explanation/device>` section.\n-\n-device class\n-\tA Device Class is an abstraction of a device's interface. It defines {term}`attributes `, {term}`pipes `, {term}`commands ` and {term}`properties ` which a device of the class provides to users and to other components of a Tango system. A device class ofter relates to a specific kind of equipment it allows to interface with like a `SerialLine` class defines interface to communicate with serial line equipment.\n- For more details please see the {doc}`device <../Explanation/device>` section.\n-\n-device server\n-\tA Device Server is a program (executable) which is able to create {term}`devices ` of certain classes. A Device Server may implement one or multiple classes and instantiate one or more devices. A running device server is called a {term}`device server instance`.\n- For more details please see the {doc}`device <../Explanation/device>` section.\n+Pogo\n+\tJava tool for generating boiler plate code for C++/Java Tango Device servers.\n+ For more details please see the {doc}`pogo <../tools/pogo>` section.\n \n-device server instance\n-\tA running device server is called a device server instance. So it means, it is a process. Every device server instance has an unique name in Tango Controls by which it can be referenced. The name is built as *\\{DeviceServerName}*/*\\{instanceName}*. For each running device server the system creates a special device of `DServer` {term}`device class`: *dserver/\\{DeviceServerName}/\\{instanceName}*. This device provides a management facility for the corresponding device server instance (see [DServer class device commands ](#dserver-class-device-commands)).\n- For more details please see the {doc}`device <../Explanation/device>` section.\n+tango_admin\n+\tCommand line utility for administrative tasks related to the {term}`TangoDB`\n+ For more details please see the {doc}`tango-admin <../tools/tango-admin>` section.\n \n Tango Database\n \tA combination of the Tango device server *Databaseds* and a MariaDB backend. It provides static and runtime configuration information about Tango Controls components in a Tango Controls system. It is used by the *Databaseds* device server and constitutes the {term}`Tango Host`.\n For more details please see the {doc}`tangodb <../Explanation/tangodb>` section.\n \n TANGO_HOST\n \tAn environment variable that specifies on which host and port a Databaseds device server is running. The host part and port are separated by a colon `:`. Commonly this is also referred to as the {term}`TangoDB`. See also [how to user multiple database servers](#multiple-db-hosts).\n@@ -160,38 +97,101 @@\n \tIn Tango a client is either a {term}`DeviceProxy` or an {term}`AttributeProxy` instance created by a program.\n For more details please see the {doc}`device-server-model <../Explanation/device-server-model>` section.\n \n property\n \tA configuration parameter stored in the {term}`Tango Database`. Properties can be assigned to a {term}`device class`, {term}`device` or elements of device interface ({term}`attributes `, {term}`commands `, {term}`pipes `). Properties can be also not related to {term}`device` - such properties are called `free properties`. Property values are often used by elements of {term}`Tango Controls` system during its startup. These usually provides information required to configure things like connections to hardware or to adjust to user preferences.\n For more details please see the {doc}`property <../Explanation/property>` section.\n \n+device\n+\tA device is a key concept of Tango Controls. It is an object providing access to its {term}`attributes `, {term}`pipes ` and {term}`commands `. The list of attributes, pipes and commands available for a certain device is defined by its {term}`class `. The device may be related to a hardware device it interfaces with or it may be a kind of a logical device providing some functionalities not directly related to hardware.\n+ For more details please see the {doc}`device <../Explanation/device>` section.\n+\n+device class\n+\tA Device Class is an abstraction of a device's interface. It defines {term}`attributes `, {term}`pipes `, {term}`commands ` and {term}`properties ` which a device of the class provides to users and to other components of a Tango system. A device class ofter relates to a specific kind of equipment it allows to interface with like a `SerialLine` class defines interface to communicate with serial line equipment.\n+ For more details please see the {doc}`device <../Explanation/device>` section.\n+\n+device server\n+\tA Device Server is a program (executable) which is able to create {term}`devices ` of certain classes. A Device Server may implement one or multiple classes and instantiate one or more devices. A running device server is called a {term}`device server instance`.\n+ For more details please see the {doc}`device <../Explanation/device>` section.\n+\n+device server instance\n+\tA running device server is called a device server instance. So it means, it is a process. Every device server instance has an unique name in Tango Controls by which it can be referenced. The name is built as *\\{DeviceServerName}*/*\\{instanceName}*. For each running device server the system creates a special device of `DServer` {term}`device class`: *dserver/\\{DeviceServerName}/\\{instanceName}*. This device provides a management facility for the corresponding device server instance (see [DServer class device commands ](#dserver-class-device-commands)).\n+ For more details please see the {doc}`device <../Explanation/device>` section.\n+\n+Tango Resource Locator\n+\tSchema used to identify tango objects, similiar to [URLs](https://en.wikipedia.org/wiki/URL). The Tango Resource Locator is defined in [Tango's RFC 16](https://tango-controls.readthedocs.io/projects/rfc/en/latest/16/TangoResourceLocator.html)\n+ For more details please see the {doc}`naming <../Explanation/naming>` section.\n+\n+command\n+\tA command is an operation a user may invoke on a device (eg. `SwitchOn`, `SwitchOff`). It also relates to a specific method in OOP (Object-Oriented Programming). Tango Controls allows a command to get input argument (argin) and to return a value (argout). List of available commands for a certain device is defined by its {term}`device class`. See the [command section](<#tango-command-model>) of this documentation for more details.\n+ For more details please see the {doc}`command <../Explanation/command>` section.\n+\n+Tango Controls\n+\tTango Controls is an object-oriented, distributed control system framework which defines a communication protocol, an Application Programmers Interface (API) and provides a set of tools and libraries to build software for control systems, especially {term}`SCADA`.\n+ For more details please see the {doc}`overview <../Explanation/overview>` section.\n+\n+pipe\n+\tA pipe allows to read and/or write structured data from and/or to a {term}`device`. The data consists of one or more basic Tango data types. The structure of the data is defined by a {term}`device class` but is not static. It can be changed at runtime by the {term}`device` itself or modified upon request by a {term}`client` according to the `set_pipe_config` operation provided by pipe. The list of available pipes in a {term}`device` is defined by the {term}`device's ` {term}`device class`.\n+ For more details please see the {doc}`pipe <../Explanation/pipe>` section.\n+\n+Attribute\n+\tAn attribute represents a process value (or values) in the system. It may have different formats or dimensions like scalar(0D), spectrum(1D) or image(2D). The attribute allows to read and/or write these values depending on programmer-defined access. The values may have different data types. In addition, an attribute provides some metadata like {term}`attribute quality`, timestamp or configuration properties. For a complete list please refer to the manual. A list of attributes available for a certain device is defined by its {term}`device class`.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Dynamic Attribute\n+\tA {term}`device` can create {term}`Attribute`s that have their configuration determined during device initialization or even later when the Device is already running. This kind of Attribute is called *Dynamic Attribute*.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Attribute quality factor\n+\tA value returned by an {term}`Attribute` has a runtime quality factor which is an enumeration describing the state of the read value (one of VALID, INVALID, ALARM, CHANGING, WARNING).\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Attribute quality\n+\tAnother name for {term}`Attribute quality factor`.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Enumerated Attribute\n+\tAttributes with a scalar data format can be enumerated allowing a set of defined label+value pairs.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Memorized Attribute\n+\tThe last written value for this type of attribute will automatically be stored in the database so that on startup this value is fetched and written to the attribute.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n+Forwarded Attribute\n+\tA forwarded attribute is one that gets its configuration from another attribute, which is known as the *root attribute*. It will forward requests, configuration changes, event subscriptions and locking behaviour to the root attribute.\n+ For more details please see the {doc}`attribute <../Explanation/attribute>` section.\n+\n Archiving\n \tIn Tango archiving refers to storing {term}`Attribute`s in a Database. See {term}`HDB++`.\n For more details please see the {doc}`archiving <../Explanation/archiving/index>` section.\n \n HDB++\n \tHistorical Database++ (HDB++) is the successor of HDB, Tango's {term}`Attribute` ariving solution.\n For more details please see the {doc}`archiving <../Explanation/archiving/index>` section.\n \n+device pattern\n+\tProvides programmers with a framework on which they can develop new control objects.\n+ For more details please see the {doc}`device-server-writing <../Tutorials/device-server-writing>` section.\n+\n+AtkPanel\n+\tAtkPanel is a generic control panel application. It can be used to control any\n+\tTango device. It supports most of Tango features and data types.\n+\tUsing AtkPanel you can view and set attribute values, execute commands, test\n+\tthe device and access diagnostic data.\n+ For more details please see the {doc}`atkpanel <../Tutorials/atkpanel/atkpanel>` section.\n+\n File Database\n \t The File Database is a lightweight, file-based alternative for the {term}`Tango Database` for testing\n \t purposes and single device server setups.\n For more details please see the {doc}`filedatabase <../How-To/deployment/filedatabase>` section.\n \n Tango Access Control\n \tA device server that manages user's rights to perform read/write requests\n \ton a particular device.\n For more details please see the {doc}`access-control <../How-To/deployment/access-control>` section.\n \n Property files\n \t Text format to store device classes and device servers including their properties.\n For more details please see the {doc}`property-file <../How-To/deployment/property-file>` section.\n \n-Pogo\n-\tJava tool for generating boiler plate code for C++/Java Tango Device servers.\n- For more details please see the {doc}`pogo <../tools/pogo>` section.\n-\n-tango_admin\n-\tCommand line utility for administrative tasks related to the {term}`TangoDB`\n- For more details please see the {doc}`tango-admin <../tools/tango-admin>` section.\n-\n ```\n"}]}]}]}]}