<?xml version="1.0" encoding="UTF-8"?>
<otherdata xmlns="http://linux.duke.edu/metadata/other" packages="12">
<package pkgid="1968795fae8a127e0913ea2a8773e31b219efd91ec88615fb2d3a120caffd1e3" name="SLES16-Migration" arch="src">
  <version epoch="0" ver="2.1.34" rel="17.1"/>
</package>
<package pkgid="b9b0f9190f855f61dc1a2469976c996cbbbf421e491e828d74869f7a7523c5fb" name="SLES16-Migration" arch="x86_64">
  <version epoch="0" ver="2.1.34" rel="17.1"/>
</package>
<package pkgid="9266356ef552fba5603c274d18d6d8f241bfe6ace1dda61802d952485f6df7d3" name="python3-migration" arch="noarch">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="41f35780de5c81e2c6d2f467e5174ad9eb1a15dee61858f2471034c60a3cb9dc" name="suse-migration" arch="noarch">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="a5b6bbaec1d24d042a540599a3abe1cef47fff7e40d8730bb48ce411b41dac81" name="suse-migration-pre-checks" arch="noarch">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="45d17a99afb23e922331abf2c082022d416879986c809494cada4c6a1b847352" name="suse-migration-scripts" arch="noarch">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="d99fabdaa5e22c680dfc837fa8ed584ecd6565f5c64e20b77886e66eeed6f504" name="suse-migration-services" arch="noarch">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="26d264a96de967c9ad64fe8b62c5497eb3678c8d99bf14c6426b725d5fa96a80" name="suse-migration-services" arch="src">
  <version epoch="0" ver="2.1.34" rel="150700.47.1"/>
  <changelog author="yu.daike@suse.com" date="1775649600">- XFSv4 precheck</changelog>
  <changelog author="yu.daike@suse.com" date="1775649601">- fix: ensure `logger.handlers` is empty in tests
  Loggers will only be initialized once; thus if the logger test is
  scheduled after other tests, loggers might already be initialized and
  the logger creation code path might not be taken, causing the logger
  test to fail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775649602">- Add time info to backup directory
  So far only the date information was part of the backup
  directory. However, if multiple migration attempts happens
  on the same day, this would overwrite the data.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736000">- Fix quoting</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775736001">- Fix validation of zypper migration result
  Up to now the assumption was that any situation in which zypper
  migration cannot migrate the system returns with an error, meaning
  exit code != 0. However, this assumption is wrong. There are
  condition in which zypper migration only indicates a problem
  with a message saying 'No migration available' and the call
  return with a successful error code = 0. This causes big trouble
  for the DMS in a way that it continues running its services
  which all assumes the migration to the next major release was
  performed. It misleads readers of the log file into the wrong
  direction and the worst it causes modifications to the host
  system when it was not migrated. This commit makes sure that
  the migration stops and treats the above message as an error
  condition.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822400">- Fix Zypper class command output handling
  The way zypper is called always redirects all output,
  stdout and stderr into the main log file. Because of that
  the variables self.output and self.error are always empty.
  This commit fixes the command call in a way that
  stdout and stderr are multiplexed such that the caller
  data can be captured by the python call and the data gets
  appended to the log file too. This commit also drops the
  unused and due to the redirection always empty self.error
  variable. For multiplexing the tee command gets used which
  impacts the returncode of the actual call. In order to
  get the correct exit code we use set -o pipefail.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822401">- Init tools/migrate with debug set to false</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822402">- Bump Migration changelog version: 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775822403">- Bump version: 2.1.33 → 2.1.34</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081600">- Fixed ci-coding-format
  exit with an error if coding format was not applied</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081601">- Add explicit SLES15 migration target check
  Instead of falling back to the default with a misleading
  warning message, make sure to check for this target explicitly
  beforehand</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776081602">- Add jira reference commit
  This tracks the submission for DMS v2.1.34
  For details see jira#PCT-1129</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1776772800">- Use download-in-advance mode for zypper migration
  This reduces the risk of download problems while inside
  of the upgrade process. This Fixes jira#PCT-1170</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1777291200">- Fixed log message for already mounted system
  The log message was out of context and belongs to the
  block checking if the system was already mounted.
  This Fixes #479</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777377600">- wicked2nm: explicitly remove sysconfig-netconfig (bsc#1258112)
  If sysconfig-netconfig is not removed, when dropping wicked,
  NetworkManager still use `netconfig`.
  But `netconfig` doesn't find its
  `/etc/sysconfig/network/scripts/netconfig.function` file, which
  lead to an error like:
  ```
  NetworkManager[926]: /usr/sbin/netconfig: line 574: log: command not found
  ```</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464000">- Add ResolvConf class for unified name resolver mgmt
  Implement a new ResolvConf class to provide a consistent approach for
  handling /etc/resolv.conf during migrations. The class introduces
  logic to:
  - Detect if /etc/resolv.conf is managed by netconfig or NetworkManager.
  - Verify user customizations using MD5 checksums (compatible with
  netconfig) and header analysis.
  - Preserve custom configurations by moving them to a static file
  and creating a symlink to prevent future overwrites by network tools.
  - Support resolver setup for both the target root and live systems.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1777464001">- Integrate ResolvConf class and reorder network setup services
  Refactor SetupNameResolver and WickedToNetworkManager to use the new
  ResolvConf class for unified resolver handling.
  Swap systemd service dependencies to ensure name resolver setup
  runs before host network setup.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778068800">- Workaround for bsc#1263889 -- preserve resolv.conf</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241600">- Mount /system-root/run as tmpfs
  Use tmpfs for /run, so we do not write temporal
  files during migration to disk.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1778241601">- Bind mount resolv.conf to /system-root/run/.../resolv.conf
  This makes the resolv.conf available in the chroot environment
  if a none custom symlink is used.</changelog>
</package>
<package pkgid="29a55ed72c42067afd4ea9d2feca51a6a1b213fb5a8bdb02aec1a3c77ac08148" name="suse-migration-sle16-activation" arch="src">
  <version epoch="0" ver="2.1.34" rel="150700.54.1"/>
  <changelog author="marcus.schaefer@suse.com" date="1740657600">- Fixed suse-migration-sle16-activation spec
  All packages for the DMS must build from the same source tarball</changelog>
  <changelog author="fcrozat@suse.com" date="1749816000">- ensure migration to SLES16 uses selinux, not apparmor</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1751025600">- Support product specifier in ISO name</changelog>
  <changelog author="yu.daike@suse.com" date="1753185600">- fix: set path according to current arch in grub.d/99_migration</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1754654400">- Fix product related requirement settings
  The activation as well as the migration live image packages
  set a specific product requirement for the product named
  product(SLES). However this is in conflict with all products
  SUSE creates that are based on SLES. One example here is
  SLES for SAP which defines its own product product(SLES_SAP).
  The activation of the migration should not be product specific.
  These packages just sets up a bootloader setup to boot the
  respective live image. Therefore this commit drops the
  product requirement from the activation packages. The live
  image however must be product specific and therefore this
  commit adds code that allows to identify the target
  product by the given image name and sets the respective
  product requirement to the package that wraps the image.
  This change also follows the new strategy to provide
  migration live images for specific SUSE products, beginning
  with SAP. This Fixes #349 and Fixes #354</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1754913600">- Make activation package require by provides tag
  With the introduction of product specific migrations packaged
  up in different package names we can no longer make the activation
  package require a specific package. Instead the activation requires
  a capability which can be provided by different packages</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1757505600">- Setup ExclusiveArch for activation packages
  For migrations of SLE12 to SLE15 the DMS was used in
  the cloud context only. grub based activation is supported
  there only on x86_64 and aarch64
  For migrations of SLE15 to SLE16 the DMS is used in a broader
  context across SUSE products and architectures. grub based
  activation is supported for all archs except s390. On s390
  we support the kexec (run_migration) based method for
  activation only.
  This commit sets the ExclusiveArch option respectively</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1757505601">- Add wicked2nm network migration</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1757678400">- Add missing pre snapshot setup to run_migration
  The suse-migration-sle16-activation-spec-template provides code
  in %pre which is not fully covered by the run_migration tool.
  As we support both activation+grub and kexec (run_migration)
  modes, the pre code should match in either case.
  This Fixes #370</changelog>
  <changelog author="yu.daike@suse.com" date="1758283200">- architecture check before allowing migration to be activated
  SLE16 will panic on CPUs older than x86_64_v1 (i.e. x86_64). To
  avoid panicing the system we check for the architecture before
  activating the migration.
  Co-authored-by: Marcus Schäfer &lt;marcus.schaefer@suse.com&gt;</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1758283201">- Activation packages can no longer be noarch
  As we have architectures that does not support the grub
  based activation and therefore an ExclusiveArch setup in
  the spec, the package can no longer be noarch</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1758888000">- Add changes for newest wicked2nm
  With the new wicked2nm version 1.3.0 hopefully wicked2nm-continue-migration is
  less necessary so this removes the default true in SLE16.
  Also there are some changes to the netconfig handling so it makes more sense to
  read the base netconfig dir instead of copying the files to
  '/var/cache/wicked_config'.
  I've also added an explanation to the pre-checks to explain how to apply the
  `--continue-migration` flag to the migration.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1759147200">- Create systemd.link files for virtual VMware/Hyper-V NICs
  The 75-persistent-net-generator.rules does not create udev-rules
  for virtual nics, matching the hwaddr "00:0c:29:*|00:50:56:*" (VMware)
  or "00:15:5d:*" (Hyper-V).
  When migrating to SLE16, predictable ifnames are enabled and it
  is very likely, that the nic will get a different name.
  To fix this, create 'systemd.link' files matching the DRIVER and
  PCI_ID to ensure the virtual NIC retains its  expected name.
  (bsc#1250076)</changelog>
  <changelog author="yu.daike@suse.com" date="1759233600">- check migration target before testing for architecture version
  The x86_64 architecture version check only applies to migrations to
  SLE16. Do not check for it if we are migrating to SLE15.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1760356800">- shellcheck heavily complained
  Fix shell coding in run_migration and %post scripts
  to match with standards reported by shellcheck</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1760616000">- Simplify interface naming by disabling predictable names at boot
  Currently our most difficult problem with regards to the network interface
  naming scheme is that when the migration image boots the interfaces get
  predictable names like 'enp1s0' which we then have to revert/write custom rules
  around. To simplify this we can install a file at
  /etc/systemd/network/99-default.link. This skips all naming schemes and the
  kernel names are used. Then we can remove this file again and copy over all the
  necessary udev rules and link files from the host and with udevadm trigger apply
  these. This should imitate the behavior of the final migrated system most
  closely.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1762344000">- Refactor mount_system service
  So far the mount_system unit run through all disk devices
  and uses the first one providing a system with an fstab file.
  This concept is weak and fails on machines with multiple
  linux OS disks attached. This commit refactors mount_system
  such that it reads the migration_target= variable from the
  kernel cmdline. The kernel cmdline gets this information
  added by either the grub.d/99_migration menuentry or via
  the run_migration kexec method. The migration_target=
  variable is expected to contain the rootfs UUID value
  of the host that should be migrated. This is a unique
  identifier and as such cannot be confused by other devices
  attached to the system.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1763726400">- Create lib file for common network-prereq tasks</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1764158400">- Move script package to the main migration provider
  In the effort to provide a common script code package, the
  package suse-migration-sle16-scripts was provided. During
  testing I found that not all places where script duplication
  exists was covered. This commit addresses the code that was
  missed and also suggests that we move the common script
  code as a sub package to the main suse-migration-services
  package. The reason here is that the common code is not
  only used in the activation package. In addition I also
  suggest that the package name changes to be more generic.
  The reason here is that this will go beyond sle16 and can
  also contain common script code for sle15 migrations as
  well as for past sle16 migrations as we are moving forward.
  As such my suggestion to also rename the package to just
  suse-migration-scripts.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775563200">- Fix md device detection
  Fix detection of device mapper layered rootfs. Software
  raid disks are not found by findmnt if the actual rootfs
  is one or more layers down. This commit fixes the detection
  if we need to pass along the rd.auto cmdline option to
  let the boot process activate them.</changelog>
</package>
<package pkgid="bdda210c608d84405e20cb98fd5264e23519dccf1bb31e0f47aa0c8be16e6c53" name="suse-migration-sle16-activation" arch="x86_64">
  <version epoch="0" ver="2.1.34" rel="150700.54.1"/>
  <changelog author="marcus.schaefer@suse.com" date="1740657600">- Fixed suse-migration-sle16-activation spec
  All packages for the DMS must build from the same source tarball</changelog>
  <changelog author="fcrozat@suse.com" date="1749816000">- ensure migration to SLES16 uses selinux, not apparmor</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1751025600">- Support product specifier in ISO name</changelog>
  <changelog author="yu.daike@suse.com" date="1753185600">- fix: set path according to current arch in grub.d/99_migration</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1754654400">- Fix product related requirement settings
  The activation as well as the migration live image packages
  set a specific product requirement for the product named
  product(SLES). However this is in conflict with all products
  SUSE creates that are based on SLES. One example here is
  SLES for SAP which defines its own product product(SLES_SAP).
  The activation of the migration should not be product specific.
  These packages just sets up a bootloader setup to boot the
  respective live image. Therefore this commit drops the
  product requirement from the activation packages. The live
  image however must be product specific and therefore this
  commit adds code that allows to identify the target
  product by the given image name and sets the respective
  product requirement to the package that wraps the image.
  This change also follows the new strategy to provide
  migration live images for specific SUSE products, beginning
  with SAP. This Fixes #349 and Fixes #354</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1754913600">- Make activation package require by provides tag
  With the introduction of product specific migrations packaged
  up in different package names we can no longer make the activation
  package require a specific package. Instead the activation requires
  a capability which can be provided by different packages</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1757505600">- Setup ExclusiveArch for activation packages
  For migrations of SLE12 to SLE15 the DMS was used in
  the cloud context only. grub based activation is supported
  there only on x86_64 and aarch64
  For migrations of SLE15 to SLE16 the DMS is used in a broader
  context across SUSE products and architectures. grub based
  activation is supported for all archs except s390. On s390
  we support the kexec (run_migration) based method for
  activation only.
  This commit sets the ExclusiveArch option respectively</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1757505601">- Add wicked2nm network migration</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1757678400">- Add missing pre snapshot setup to run_migration
  The suse-migration-sle16-activation-spec-template provides code
  in %pre which is not fully covered by the run_migration tool.
  As we support both activation+grub and kexec (run_migration)
  modes, the pre code should match in either case.
  This Fixes #370</changelog>
  <changelog author="yu.daike@suse.com" date="1758283200">- architecture check before allowing migration to be activated
  SLE16 will panic on CPUs older than x86_64_v1 (i.e. x86_64). To
  avoid panicing the system we check for the architecture before
  activating the migration.
  Co-authored-by: Marcus Schäfer &lt;marcus.schaefer@suse.com&gt;</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1758283201">- Activation packages can no longer be noarch
  As we have architectures that does not support the grub
  based activation and therefore an ExclusiveArch setup in
  the spec, the package can no longer be noarch</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1758888000">- Add changes for newest wicked2nm
  With the new wicked2nm version 1.3.0 hopefully wicked2nm-continue-migration is
  less necessary so this removes the default true in SLE16.
  Also there are some changes to the netconfig handling so it makes more sense to
  read the base netconfig dir instead of copying the files to
  '/var/cache/wicked_config'.
  I've also added an explanation to the pre-checks to explain how to apply the
  `--continue-migration` flag to the migration.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1759147200">- Create systemd.link files for virtual VMware/Hyper-V NICs
  The 75-persistent-net-generator.rules does not create udev-rules
  for virtual nics, matching the hwaddr "00:0c:29:*|00:50:56:*" (VMware)
  or "00:15:5d:*" (Hyper-V).
  When migrating to SLE16, predictable ifnames are enabled and it
  is very likely, that the nic will get a different name.
  To fix this, create 'systemd.link' files matching the DRIVER and
  PCI_ID to ensure the virtual NIC retains its  expected name.
  (bsc#1250076)</changelog>
  <changelog author="yu.daike@suse.com" date="1759233600">- check migration target before testing for architecture version
  The x86_64 architecture version check only applies to migrations to
  SLE16. Do not check for it if we are migrating to SLE15.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1760356800">- shellcheck heavily complained
  Fix shell coding in run_migration and %post scripts
  to match with standards reported by shellcheck</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1760616000">- Simplify interface naming by disabling predictable names at boot
  Currently our most difficult problem with regards to the network interface
  naming scheme is that when the migration image boots the interfaces get
  predictable names like 'enp1s0' which we then have to revert/write custom rules
  around. To simplify this we can install a file at
  /etc/systemd/network/99-default.link. This skips all naming schemes and the
  kernel names are used. Then we can remove this file again and copy over all the
  necessary udev rules and link files from the host and with udevadm trigger apply
  these. This should imitate the behavior of the final migrated system most
  closely.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1762344000">- Refactor mount_system service
  So far the mount_system unit run through all disk devices
  and uses the first one providing a system with an fstab file.
  This concept is weak and fails on machines with multiple
  linux OS disks attached. This commit refactors mount_system
  such that it reads the migration_target= variable from the
  kernel cmdline. The kernel cmdline gets this information
  added by either the grub.d/99_migration menuentry or via
  the run_migration kexec method. The migration_target=
  variable is expected to contain the rootfs UUID value
  of the host that should be migrated. This is a unique
  identifier and as such cannot be confused by other devices
  attached to the system.</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1763726400">- Create lib file for common network-prereq tasks</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1764158400">- Move script package to the main migration provider
  In the effort to provide a common script code package, the
  package suse-migration-sle16-scripts was provided. During
  testing I found that not all places where script duplication
  exists was covered. This commit addresses the code that was
  missed and also suggests that we move the common script
  code as a sub package to the main suse-migration-services
  package. The reason here is that the common code is not
  only used in the activation package. In addition I also
  suggest that the package name changes to be more generic.
  The reason here is that this will go beyond sle16 and can
  also contain common script code for sle15 migrations as
  well as for past sle16 migrations as we are moving forward.
  As such my suggestion to also rename the package to just
  suse-migration-scripts.</changelog>
  <changelog author="marcus.schaefer@suse.com" date="1775563200">- Fix md device detection
  Fix detection of device mapper layered rootfs. Software
  raid disks are not found by findmnt if the actual rootfs
  is one or more layers down. This commit fixes the detection
  if we need to pass along the rd.auto cmdline option to
  let the boot process activate them.</changelog>
</package>
<package pkgid="296d8ca2cc5ab7a88f1e456f25e1bcc13da22a594df84dc9f42524d06b1f5f1b" name="wicked2nm" arch="src">
  <version epoch="0" ver="1.5.1" rel="150700.10.1"/>
  <changelog author="jorik.cronenberg@suse.com" date="1744804800">- Initial packaging @ v1.0.0</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1749643200">- Update to v1.1.0
  * Use agama-network instead of agama-(lib|server)
  * Only activate connections marked with autostart
  * Give hint in error message how to ignore warnings
  * Update README.md with updated installation and usage infos
  * Add support for Leap 15
- Remove BuildRequires that are no longer necessary due to the
  agama-network switch.
- The agama-network switch also removes the vulnerable and
  unmaintained 'users' crate from the dependencies.
  [bsc#1244188]</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1753790400">- Update to v1.2.0
  * Fix netconfig handling with proper priority setting
  * Add ovs support</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1755518400">- Update to v1.2.1
  * bump slab from 0.4.10 to 0.4.11 to address CVE-2025-55159
    [bsc#1248010]</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1758888000">- Update to v1.3.0
  * Issue only a info when dhcp.update is non default
  * Add ipv4_static broadcast
  * Apply dhcp settings to mirror wicked client id
  * Fix test.sh, fail if migration succeed but expect fail
  * Fix sysctl handling
  * Avoid cloning in parsing of route
  * Fix continue migration to show all warnings beforehand
  * Improve warning messages - show interface, element names
  * Remove unwrap in route parsing</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1760097600">- Update to v1.4.0
  * Activate only connections if present in the current system
  * Improve error output, exit codes and add flag to disable user
    hints
  * Add support for autoip-fallback</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1770724800">- Update to v1.4.1
  * bump bytes from 1.10.1 to 1.11.1
  * Update time to 0.3.47 (CVE-2026-25727)
    [bsc#1257911]
- Disable `update` in cargo vendor service, as newer agama versions
  are incompatible for now.</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1778587200">- Update v1.5.0
  * Respect create-cid and client-id in interface xml
  * Require at least one file for migrate and show commands
  * Perform extra validation for correct xml file
  * Improve dhcp.update default and user info
  * Update dependencies
  * Allow DHCP+staticIP addresses
  * Fix DHCLIENT_SET_DEFAULT_ROUTE="no"
  * Handle 'STATIC_FALLBACK' and 'NetworkManager' in netconfig
  * Implement team to bond migration
  * Update agama-network to remove dependency on curl
- Reenable `update` in cargo vendor service</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1781611200">- Require minimum cargo version 1.78 for lockfile version 4 parsing</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1784030400">- Update v1.5.1
  * Update agama to fix default vlan flags.
    Previously the default vlan flags in NM was set to 0, which
    overrides default kernel behavior and thus differed from
    wicked. It is now set to 1.
    [bsc#1271079]
  * Tests: Sort wicked show-config output by interface name
  * Add leap16.1 to CI</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1785240000">- Build  from https://github.com/openSUSE/wicked2nm/pull/83</changelog>
</package>
<package pkgid="6de67070ba68391709ed7fb7f59f8df3d77d3ecc103d8d37376aedbc0171ff56" name="wicked2nm" arch="x86_64">
  <version epoch="0" ver="1.5.1" rel="150700.10.1"/>
  <changelog author="jorik.cronenberg@suse.com" date="1744804800">- Initial packaging @ v1.0.0</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1749643200">- Update to v1.1.0
  * Use agama-network instead of agama-(lib|server)
  * Only activate connections marked with autostart
  * Give hint in error message how to ignore warnings
  * Update README.md with updated installation and usage infos
  * Add support for Leap 15
- Remove BuildRequires that are no longer necessary due to the
  agama-network switch.
- The agama-network switch also removes the vulnerable and
  unmaintained 'users' crate from the dependencies.
  [bsc#1244188]</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1753790400">- Update to v1.2.0
  * Fix netconfig handling with proper priority setting
  * Add ovs support</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1755518400">- Update to v1.2.1
  * bump slab from 0.4.10 to 0.4.11 to address CVE-2025-55159
    [bsc#1248010]</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1758888000">- Update to v1.3.0
  * Issue only a info when dhcp.update is non default
  * Add ipv4_static broadcast
  * Apply dhcp settings to mirror wicked client id
  * Fix test.sh, fail if migration succeed but expect fail
  * Fix sysctl handling
  * Avoid cloning in parsing of route
  * Fix continue migration to show all warnings beforehand
  * Improve warning messages - show interface, element names
  * Remove unwrap in route parsing</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1760097600">- Update to v1.4.0
  * Activate only connections if present in the current system
  * Improve error output, exit codes and add flag to disable user
    hints
  * Add support for autoip-fallback</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1770724800">- Update to v1.4.1
  * bump bytes from 1.10.1 to 1.11.1
  * Update time to 0.3.47 (CVE-2026-25727)
    [bsc#1257911]
- Disable `update` in cargo vendor service, as newer agama versions
  are incompatible for now.</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1778587200">- Update v1.5.0
  * Respect create-cid and client-id in interface xml
  * Require at least one file for migrate and show commands
  * Perform extra validation for correct xml file
  * Improve dhcp.update default and user info
  * Update dependencies
  * Allow DHCP+staticIP addresses
  * Fix DHCLIENT_SET_DEFAULT_ROUTE="no"
  * Handle 'STATIC_FALLBACK' and 'NetworkManager' in netconfig
  * Implement team to bond migration
  * Update agama-network to remove dependency on curl
- Reenable `update` in cargo vendor service</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1781611200">- Require minimum cargo version 1.78 for lockfile version 4 parsing</changelog>
  <changelog author="jorik.cronenberg@suse.com" date="1784030400">- Update v1.5.1
  * Update agama to fix default vlan flags.
    Previously the default vlan flags in NM was set to 0, which
    overrides default kernel behavior and thus differed from
    wicked. It is now set to 1.
    [bsc#1271079]
  * Tests: Sort wicked show-config output by interface name
  * Add leap16.1 to CI</changelog>
  <changelog author="cfamullaconrad@suse.com" date="1785240000">- Build  from https://github.com/openSUSE/wicked2nm/pull/83</changelog>
</package>
</otherdata>