Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
docs-Support-building-documentation-locally.patch | docs: Support building documentation locally Building the documentation locally without Internet access will fail, because sphinx will try to download the intersphinx inventory from http://docs.python.org/3/objects.inv. Support building the documentation locally without Internet access by searching for locally installed intersphinx inventory first. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian | 2021-11-17 | |
Make-the-Salt-Proxy-environment-aware.patch | Make the Salt Proxy environment aware The Salt proxy minion is looking for proxy minion modules in `salt://_proxy/`. It does so however only in the default `base` environment. On setups which do not use `base` or shall be executed in a different environment this breaks: /etc/salt/master: ``` ... file_roots: noc: - /srv/salt ... ``` ``` $ grep "proxyenabled" /srv/salt/_proxy/junos_manager.py __proxyenabled__ = ['junos_manager'] $ salt-proxy --proxyid=dev1 -l debug ... [DEBUG ] rest_sample proxy __virtual__() called... [INFO ] ssh_sample proxy __virtual__() called... [DEBUG ] Could not LazyLoad junos_manager.grains [DEBUG ] Could not LazyLoad junos_manager.init [ERROR ] Proxymodule junos_manager is missing an init() or a shutdown() or both. Check your proxymodule. Salt-proxy aborted. [WARNING ] Stopping the Salt Proxy Minion [ERROR ] -1 [INFO ] The proxy minion is shutting down.. [INFO ] The Salt ProxyMinion is shut down ``` This is because the loader only looks for _proxy modules in the `base` environment. This commit fixes this (but might possibly break other things, though I did not find side-effects). Initial pull request: https://github.com/saltstack/salt/pull/36704 |
Arno Toell <arno.toell@profitbricks.com> | yes | 2016-09-30 | ||
doc-Exclude-documentation_options.js-from-default-th.patch | doc: Exclude documentation_options.js from default theme `documentation_options.js` from the default theme sets the option `URL_ROOT` to: ``` document.getElementById("documentation_options").getAttribute('data-url_root') ``` This requires that the script element for `documentation_options.js` includes the tag `id="documentation_options"` and sets the `data-url_root` tag. Otherwise evaluating `URL_ROOT` will fail and building the documentation during the Debian package build will fail: ``` dh_sphinxdoc: error: DOCUMENTATION_OPTIONS does not define URL_ROOT ``` The variable `DOCUMENTATION_OPTIONS` is directly set `layout.html` and therefore `documentation_options.js` does not need to be included. So just exclude it. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-10-13 | ||
Support-sphinx-4.2.patch | Support sphinx 4.2 Add the sphinx documentation options provided by sphinx 4.2. Otherwise the search will produce URLs with `undefined` instead of `.html`: ``` ref/states/all/salt.states.fileundefined?highlight=file#module-salt.states.file ``` |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-10-13 | ||
remove-privacy-breach.patch | Remove privacy breach in docs | =?utf-8?b?T25kxZllaiBOb3bDvQ==?= <onovy@debian.org> | no | 2021-11-01 | ||
Make-default-pki-directory-configurable.patch | Make default pki directory configurable The files in `/etc/salt/pki` are not configuration files in the sense of the FHS ("local file used to control the operation of a program"). Debian wants to change the default location to `/var/lib/salt/pki` (to properly follow FHS and to allow setting StateDirectory in the salt master systemd configuration). Therefore introduce a `STATE_DIR` syspaths variable which defaults to `CONFIG_DIR`, but can be individually customized. fixes #3396 |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian | 2022-01-13 | |
run-salt-master-as-salt-user.patch | Run salt-master daemon as 'salt' user | Benjamin Drung <benjamin.drung@ionos.com> | no | 2021-11-17 | ||
remove-old-hg_piller-test.patch | remove old hg_piller test | Thomas Phipps <tphipps@vmware.com> | no | upstream, commit: 399835f672771db8a25ebc6efd71709984a9a11f | 2022-01-27 | |
doc-fix-logo-link.patch | doc: Fix logo link The link on the brand image was pointing to index.html which does not exist. The index file seems to be contents.html. |
Steffen Kockel <steffen.kockel@profitbricks.com> | no | 2019-04-23 | ||
Use-jquery.js-from-sphinx.patch | Use jquery.js from sphinx Sphinx uses libjs-jquery >= 1.11.1 which is newer than jquery-1.9.1.js shipped by salt. Therefore jquery.js from sphinx can be used again. |
Benjamin Drung <benjamin.drung@ionos.com> | no | 2021-10-12 | ||
ensure-searchtools.js-gets-included.patch | doc: Ensure searchtools.js gets included Searchtools did not get included with Debian > stretch and Sphinx > 1.6.7. Sphinx 3.4.0 also needs `language_data.js` to properly search. See https://github.com/readthedocs/sphinx_rtd_theme/pull/1021 `searchtools.js` and `language_data.js` are only needed by `search.html`. So maybe better just add `search.html` to the template. |
Steffen Kockel <steffen.kockel@profitbricks.com> | no | 2021-10-13 | ||
Fix-various-spelling-mistakes.patch | Fix various spelling mistakes | Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-01 | ||
Fix-various-spelling-mistakes-in-release-notes.patch | Fix various spelling mistakes in release notes There are various spelling mistakes in the git commit messages in the release notes. Fix those spelling mistakes. Since each commit is either referenced by the commit has or pull request, fixing those spelling mistakes has no negative effect on finding those commit. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-01 | ||
alternatives-Do-not-access-var-lib-dpkg-alternatives.patch | alternatives: Do not access /var/lib/dpkg/alternatives directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. So use something like: ``` update-alternatives --query $name ``` to query information about alternatives in a machine readable format. Also add tests cases for `alternatives.show_links` using real data from the distributions. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian upstream | 2021-10-12 | |
dpkg_lowpkg-Do-not-access-var-lib-dpkg-info-package-.patch | dpkg_lowpkg: Do not access /var/lib/dpkg/info/<package>.list directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. So use something like: ``` dpkg-query --showformat '${db-fsys:Last-Modified}\n' --show $pkg ``` to get the mtime from /var/lib/dpkg/info/<package>.list files. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian upstream | 2021-10-08 | |
dpkg_lowpkg-Drop-reading-var-lib-dpkg-available-dire.patch | dpkg_lowpkg: Drop reading /var/lib/dpkg/available directly salt contains modules, which directly access the dpkg internal database, instead of using one of the public interfaces provided by dpkg. This is a problem for several reasons, because even though the layout and format of the dpkg database is administrator friendly, and it is expected that those might need to mess with it, in case of emergency, this “interface” does not extend to other programs besides the dpkg suite of tools. The admindir can also be configured differently at dpkg build or run-time. And finally, the contents and its format, will be changing in the near future. `/var/lib/dpkg/available` should not be read directly. Instead `dpkg-query --print-avail` should be used. The `/var/lib/dpkg/available` file is only kept up-to-date when using dselect, but nowadays `apt` is used, and therefore this file does not provide much more information than `dpkg-query -W`. Users of APT-based frontends should use `apt show` or in our case the `pkg.show` salt module. `dpkg-query --print-avail` provides following keys (on Ubuntu 20.04): ``` $ dpkg-query --print-avail | sed 's/:.*$//' | sort | uniq Architecture Breaks Bugs Build-Essential Built-Using Cnf-Extra-Commands Cnf-Priority-Bonus Conflicts Depends Description Description-md5 Enhances Essential Filename Homepage Important Installed-Size Maintainer MD5sum Multi-Arch Origin Original-Maintainer Package Pre-Depends Priority Provides Recommends Replaces Section SHA1 SHA256 Size Source Suggests Supported Task Version ``` Following keys cannot be retrieved by `dpkg-query -W`: ``` Build-Essential Built-Using Cnf-Extra-Commands Cnf-Priority-Bonus Important Multi-Arch Original-Maintainer SHA1 SHA256 Supported ``` Please use `pkg.show` for those keys. Following additional keys could be retrieved if needed: ``` Breaks Enhances Essential Filename Pre-Depends Priority Suggests ``` Without calling `_get_pkg_ds_avail`, `info` just calls `_get_pkg_info` and converts it into a dict and add a license field. Since `_get_pkg_ds_avail` is used nowhere else, move it into `info`. Do not query Installed-Size, because it was stripped as "technical" key previously. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian upstream | 2021-10-08 | |
loader-Fix-loading-grains-with-annotations.patch | loader: Fix loading grains with annotations If custom grain modules use annotations, salt will fail to load them. Example grain: ``` from typing import Dict def example_grain() -> Dict[str, str]: return {"example": "42"} ``` `salt-call grains.items` will print this exception: ``` Failed to load grains defined in grain file ... in function <...>, error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/salt/loader.py", line 847, in grains parameters = salt.utils.args.get_function_argspec(funcs[key]).args File "/usr/lib/python3/dist-packages/salt/utils/args.py", line 271, in get_function_argspec aspec = _getargspec(func) File "/usr/lib/python3/dist-packages/salt/utils/args.py", line 40, in _getargspec "Function has keyword-only arguments or annotations" ``` Python recommends to use `inspect.signature` instead of `inspect.getfullargspec` (which is only needs to maintain compatibility with the Python 2 `inspect` module API). Since salt only supports Python 3, drop using the wrapper function `get_function_argspec` and use `inspect.signature` directly. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-09-17 | ||
Add-missing-job_name-to-schedule.job_status-example.patch | Add missing job_name to schedule.job_status example The module `schedule.job_status` requires a job name, but the example does not mention that. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-10-13 | ||
job_status-Convert-datetime-objects-into-formatted-s.patch | job_status: Convert datetime objects into formatted strings `salt-call schedule.job_status` will return empty values for the `datetime.datetime` objects. So convert the `datetime.datetime` objects into formatted strings. Then they will be shown correctly: ``` $ sudo salt-call schedule.job_status __mine_interval local: ---------- _last_run: 2021-11-01T12:36:57 _next_fire_time: 2021-11-01T13:36:57 _next_scheduled_fire_time: 2021-11-01T13:36:57 _run_on_start: False _seconds: 3600 _splay: None enabled: True function: mine.update jid_include: True maxrunning: 2 minutes: 60 name: __mine_interval return_job: False run: True run_on_start: True splay: None ``` |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-01 | ||
Mark-test_buildout_bootstrap-with-pytest.patch | Mark test_buildout_bootstrap with pytest Pytest runs `BuildoutOnlineTestCase.setUpClass` despite skipping all tests. Mark `test_buildout_bootstrap` with pytest to avoid running the `setUpClass`. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-10-27 | ||
Fix-test-cases-with-PermissionError-on-var-cache.patch | Fix test cases with PermissionError on /var/cache Some test cases fail when run without root permission, because they want to read/write to `/var/cache`: ``` python3 -m pytest -ra tests/pytests/unit/state/test_state_format_slots.py tests/unit/utils/test_parsers.py ``` `test_format_slots_parallel` fails with: ``` Process ParallelState(always-changes-and-succeeds): Traceback (most recent call last): File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap self.run() File "salt/utils/process.py", line 996, in wrapped_run_func return run_func() File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "salt/state.py", line 2023, in _call_parallel_target with salt.utils.files.fopen(tfile, "wb+") as fp_: File "salt/utils/files.py", line 385, in fopen f_handle = open(*args, **kwargs) # pylint: disable=resource-leakage ``` Similar for `tests/unit/utils/test_parsers.py`: ``` FAILED tests/unit/utils/test_parsers.py::SaltRunOptionParserTestCase::test_jid_option - salt.exceptions.SaltSystemExit: No permissions to access "/var/log/salt/master", are you running as the correct user? FAILED tests/unit/utils/test_parsers.py::SaltRunOptionParserTestCase::test_jid_option_invalid - salt.exceptions.SaltSystemExit: No permissions to access "/var/log/salt/master", are you running as the correct user? FAILED tests/unit/utils/test_parsers.py::SaltSSHOptionParserTestCase::test_jid_option - salt.exceptions.SaltSystemExit: No permissions to access "/var/log/salt/ssh", are you running as the correct user? FAILED tests/unit/utils/test_parsers.py::SaltSSHOptionParserTestCase::test_jid_option_invalid - salt.exceptions.SaltSystemExit: No permissions to access "/var/log/salt/ssh", are you running as the correct user? ``` fixes #61148 |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2022-01-12 | ||
Fix-test-cases-with-PermissionError-on-var-cache-sal.patch | Fix test cases with PermissionError on /var/cache/salt When running the test cases without root permission, some test cases fail: ``` $ python3 -m pytest -ra tests/pytests/unit/state/test_state_compiler.py tests/pytests/unit/test_minion.py [...] FAILED tests/pytests/unit/state/test_state_compiler.py::test_render_requisite_require_disabled - PermissionError: [Errno 13] Permission denied: '/var/cache/salt' FAILED tests/pytests/unit/state/test_state_compiler.py::test_render_requisite_require_in_disabled - PermissionError: [Errno 13] Permission denied: '/var/cache/salt' FAILED tests/pytests/unit/test_minion.py::test_minion_module_refresh - PermissionError: [Errno 13] Permission denied: '/var/cache/salt' FAILED tests/pytests/unit/test_minion.py::test_minion_module_refresh_beacons_refresh - PermissionError: [Errno 13] Permission denied: '/var/cache/salt' ``` Fix these test cases by using a temporary directory as cache directory. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-12-22 | ||
Fix-misspelled-import-of-M2Crypto-in-test_crypt.py.patch | Fix misspelled import of M2Crypto in test_crypt.py When running the tests from `tests/pytests/unit/utils/test_crypt.py`, `test_random` fails when `M2Crypto` is installed: ``` $ python3 -m pytest -ra tests/pytests/unit/utils/test_crypt.py [...] FAILED tests/pytests/unit/utils/test_crypt.py::test_random - ``` This is caused by `salt.utils.crypt` importing `M2Crypto`, but the test does not due to a spelling mistake. This was introduced in 74194770a8d50d3c8a2ccc2031de924435c4e495. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-02 | ||
Fix-test_ssh_kwargs-to-not-access-etc-salt-pki.patch | Fix test_ssh_kwargs to not access /etc/salt/pki Running the SSH unit tests without root permission fails: ``` $ python3 -m pytest tests/pytests/unit/client/ssh/test_ssh.py [...] Traceback (most recent call last): File "salt/client/ssh/__init__.py", line 264, in __init__ salt.client.ssh.shell.gen_key(priv) File "salt/client/ssh/shell.py", line 36, in gen_key os.makedirs(os.path.dirname(path)) File "/usr/lib/python3.9/os.py", line 215, in makedirs makedirs(head, exist_ok=exist_ok) File "/usr/lib/python3.9/os.py", line 215, in makedirs makedirs(head, exist_ok=exist_ok) File "/usr/lib/python3.9/os.py", line 225, in makedirs mkdir(name, mode) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "tests/pytests/unit/client/ssh/test_ssh.py", line 134, in test_ssh_kwargs ssh_obj = client._prep_ssh(**opts) File "salt/client/ssh/client.py", line 125, in _prep_ssh return salt.client.ssh.SSH(opts) File "salt/client/ssh/__init__.py", line 266, in __init__ raise salt.exceptions.SaltClientError( salt.exceptions.SaltClientError: salt-ssh could not be run because it could not generate keys. ``` Changing the accessed directories to temporary directories would be a solution: ```python client.opts["pki_dir"] = tmpdir.join("pki").strpath client.opts["cachedir"] = tmpdir.join("cache").strpath ``` But running the 38 tests takes 130 seconds on an Intel Core i7-8850H CPU @ 2.60GHz. So mock all functions and methods that try to write to the pki or cache directory. Then the tests will succeed in a few seconds. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-03 | ||
tests-Replace-os.getlogin-by-getpass.getuser.patch | tests: Replace os.getlogin by getpass.getuser The test `test_run_cwd_in_combination_with_runas` fails in some test environments (like Debian autopkgtest): ``` ====================================================================== [CPU:0.0%|MEM:6.5%] cmd.run executes command in the cwd directory |
Benjamin Drung <benjamin.drung@ionos.com> | no | 2021-04-28 | ||
Wrap-long-Python-lines.patch | Wrap long Python lines Some source file includes a line length that is well beyond the normally human made code line length. Wrap long strings (use 20 bytes per line for the binary data). Also blacken `salt/ext/vsan/vsanmgmtObjects.py` to make the code readable. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-11 | ||
Wrap-contributor-list-in-release-documentation.patch | Wrap contributor list in release documentation The release documentation files contain a list of contributors for the release. This list is written in one line and can become very long, which makes reading source file uneasy. So wrap the list of contributions in the release documentation files. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-11 | ||
Wrap-long-lines-in-release-documentation.patch | Wrap long lines in release documentation | Benjamin Drung <benjamin.drung@ionos.com> | yes | 2021-11-11 | ||
Do-not-require-contextvars-for-Python-3.7.patch | Do not require contextvars for Python >= 3.7 Python >= 3.7 comes with an `contextvars` module and therefore a separate `contextvars` package is not needed. Otherwise salt will needlessly fail: pkg_resources.DistributionNotFound: The 'contextvars' distribution was not found and is required by salt |
Benjamin Drung <benjamin.drung@ionos.com> | yes | debian | 2021-11-16 | |
Remove-faulty-dot-in-template-fixes-58195.patch | Remove faulty dot in template fixes #58195 | Antoine Amacher <antoine.amacher@infomaniak.com> | no | debian | upstream, https://github.com/saltstack/salt/pull/61095 | 2021-11-16 |
linux_sysctl.present-Fix-replacing-spaces-by-tabs.patch | linux_sysctl.present: Fix replacing spaces by tabs `salt/modules/linux_sysctl.py` tries to be smart in `persist()` and replaces spaces by tabs, which will be correct for keys like `net.ipv4.tcp_rmem` but not for `kernel.core_pattern`. So only sanitize the values for comparison, but not for persisting them in the configuration file. |
Benjamin Drung <benjamin.drung@ionos.com> | yes | upstream | 2022-01-13 | |
78525c985826ab813c14c21e20e880da7ff02187.patch | Fix test with py3.10 | krionbsd <krion@FreeBSD.org> | no | upstream, commit: 306aa6dd2948e8d149fa65f51e9959a2e464a930 | 2021-11-30 | |
Mock-ip_addrs-in-utils-minions.py-unit-test.patch | Mock ip_addrs() in utils/minions.py unit test Previously the test used `salt.utils.network.ip_addrs()' in the same way that the tested code did. This worked well as long as at least one IP address was returned by `salt.utils.network.ip_addrs()'. Since this is a unit test, it should not depend on the environment, it should just work™, even if there are no real IP addresses assigned to the system (or container) that runs the test. |
Alexander Graul <agraul@suse.com> | no | debian | https://github.com/saltstack/salt/pull/60324 | 2021-10-22 |
test_roots-Set-cachedir-to-writable-temporary-direct.patch | test_roots: Set cachedir to writable temporary directory Running `test_symlink_list` during Debian package build fails because the test case tries to write to `/var/cache`: ``` =================================== FAILURES =================================== ______________________________ test_symlink_list _______________________________ base_env_state_tree_root_dir = PosixPath('/tmp/stsuite/integration-files/state-tree/base') def test_symlink_list(base_env_state_tree_root_dir): with pytest.helpers.temp_file( "target", "data", base_env_state_tree_root_dir ) as target: link = base_env_state_tree_root_dir / "link" link.symlink_to(str(target)) > ret = roots.symlink_list({"saltenv": "base"}) tests/pytests/functional/fileserver/test_roots.py:25: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ load = {'saltenv': 'base'} def symlink_list(load): """ Return a dict of all symlinks based on a given path on the Master """ if "env" in load: # "env" is not supported; Use "saltenv". load.pop("env") ret = {} if ( load["saltenv"] not in __opts__["file_roots"] and "__env__" not in __opts__["file_roots"] ): return ret if "prefix" in load: prefix = load["prefix"].strip("/") else: prefix = "" symlinks = _file_lists(load, "links") > return {key: val for key, val in symlinks.items() if key.startswith(prefix)} E AttributeError: 'list' object has no attribute 'items' salt/fileserver/roots.py:467: AttributeError |
Benjamin Drung <benjamin.drung@ionos.com> | no | 2022-02-14 | ||
test_aptpkg-Skip-tests-if-etc-apt-sources.list-is-mi.patch | test_aptpkg: Skip tests if /etc/apt/sources.list is missing If `/etc/apt/sources.list` does not exist, three functional test cases fail with ``` ``` because they try to open this files: ``` ________________________________ test_get_repos ________________________________ def test_get_repos(): """ Test aptpkg.get_repos """ > test_repo, comps = get_current_repo() /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:109: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:64: in get_current_repo with salt.utils.files.fopen("/etc/apt/sources.list") as fp: ________________________ test_get_repos_multiple_comps _________________________ def test_get_repos_multiple_comps(): """ Test aptpkg.get_repos when multiple comps exist in repo. """ > test_repo, comps = get_current_repo(multiple_comps=True) /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:126: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:64: in get_current_repo with salt.utils.files.fopen("/etc/apt/sources.list") as fp: _____________________________ test_expand_repo_def _____________________________ def test_expand_repo_def(): """ Test aptpkg.expand_repo_def when the repo exists. """ > test_repo, comps = get_current_repo() /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:169: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /<<PKGBUILDDIR>>/tests/pytests/functional/modules/test_aptpkg.py:64: in get_current_repo with salt.utils.files.fopen("/etc/apt/sources.list") as fp: ``` Some Debian buildd do not have `/etc/apt/sources.list` and therefore these test cases fail: https://buildd.debian.org/status/fetch.php?pkg=salt&arch=all&ver=3004%2Bdfsg1-9&stamp=1644870337&raw=0 So just skip these test cases if `/etc/apt/sources.list` does not exist. |
Benjamin Drung <bdrung@debian.org> | yes | 2022-04-16 | ||
Mark-test_list_available_packages-requiring-network.patch | Mark test_list_available_packages requiring network `test_list_available_packages` calls pip which needs Internet access. Mark this test with `requires_network` to avoid breakage in case there is no Internet access. |
Benjamin Drung <bdrung@debian.org> | yes | 2022-04-16 | ||
Don-t-rely-on-importlib.metadata-it-s-still-not-ready-for.patch | Don't rely on importlib.metadata, it's still not ready for our usage ``` [root@36c42c7ecd24 code]# [ERROR ] 'PathDistribution' object has no attribute '_normalized_name' Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/salt/utils/parsers.py", line 210, in parse_args mixin_after_parsed_func(self) File "/usr/lib/python3.10/site-packages/salt/utils/parsers.py", line 887, in __setup_extended_logging log.setup_extended_logging(self.config) File "/usr/lib/python3.10/site-packages/salt/log/setup.py", line 414, in setup_extended_logging providers = salt.loader.log_handlers(opts) File "/usr/lib/python3.10/site-packages/salt/loader/__init__.py", line 686, in log_handlers _module_dirs( File "/usr/lib/python3.10/site-packages/salt/loader/__init__.py", line 148, in _module_dirs for entry_point in entrypoints.iter_entry_points("salt.loader"): File "/usr/lib/python3.10/site-packages/salt/utils/entrypoints.py", line 43, in _wrapped return f(*args, **kwargs) File "/usr/lib/python3.10/site-packages/salt/utils/entrypoints.py", line 55, in iter_entry_points entry_points = importlib.metadata.entry_points() File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 980, in entry_points return SelectableGroups.load(eps).select(**params) File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 429, in load ordered = sorted(eps, key=by_group) File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 977, in <genexpr> eps = itertools.chain.from_iterable( File "/usr/lib64/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen k = key(element) ``` |
piterpunk <piterpunk@slackware.com> | no | upstream, commit a273fffc857145198f25ba269f7e2493112e55fc and 8e008cfd1ebf124cac7ff3b8b01373827cf9f70f | 2021-10-15 | |
test_aptpkg.py-Fix-UnboundLocalError-local-variable-test_.patch | test_aptpkg.py: Fix UnboundLocalError: local variable 'test_repo' If `/etc/apt/sources.list` does not contain a line with `ubuntu.com` or `debian.org`, the test cases in `test_aptpkg.py` will fail with `UnboundLocalError`: ```python ________________________________ test_get_repos ________________________________ @pytest.mark.skipif( not os.path.isfile("/etc/apt/sources.list"), reason="Missing /etc/apt/sources.list" ) def test_get_repos(): """ Test aptpkg.get_repos """ > test_repo, comps = get_current_repo() tests/pytests/functional/modules/test_aptpkg.py:113: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ multiple_comps = False def get_current_repo(multiple_comps=False): """ Get a repo currently in sources.list multiple_comps: Search for a repo that contains multiple comps. For example: main, restricted """ with salt.utils.files.fopen("/etc/apt/sources.list") as fp: for line in fp: if line.startswith("#"): continue if "ubuntu.com" in line or "debian.org" in line: test_repo = line.strip() comps = test_repo.split()[3:] if multiple_comps: if len(comps) > 1: break else: break > return test_repo, comps E UnboundLocalError: local variable 'test_repo' referenced before assignment tests/pytests/functional/modules/test_aptpkg.py:77: UnboundLocalError ``` So set `test_repo` to `None` to ensure that the variables are defined. If `test_repo` is still `None` after reading `/etc/apt/sources.list` skip the test case. |
Benjamin Drung <bdrung@debian.org> | yes | debian | 2022-04-16 |