Do not fail with a traceback if the config file parsing fails.
Hence, catch the configparser.Error exception and print its
"message" attribute to the user.
Fixes: #985 ("Type error on any osc call")
Since a recent backend change, a bdep has a hdrmd5 by default. That
is, osc always downloads these bdeps from the API (unless they are
cached) instead of a mirror. This is not intended.
Using a mirror is no problem because the hdrmd5s are verified in
the build module.
Note: If this causes a problem, one could also use "osc build
--download-api-only" to mimic the old behavior.
If the oscrc is a symlink, follow the symlink when writing the
configuration file. The old code replaced the symlink with a
regular file (see #390 ("symlinked $HOME/.oscrc gets replaced
with a ordinary file")).
Implementation note: if the directory, which contains the resolved
config file, has a <config file>.new file, the file is overwritten.
When a user creates a symlink pointing from ~/.config/osc/oscrc
to a different location, don't overwrite the symlink but follow
it when writing configuration on disk.
Without escaping the % character, the download URL could be subject
to string formatting (depending on the subsequent characters). For
instance, if the url attribute's value of a buildinfo's path element
contains the substring "c_c%2B%2B", the "%2B" is interpreted as a
format string (see issue #965), which is wrong ("B" is not a valid
format character at all). In order to avoid this, escape all
% characters in the download urls.
Note: escaping the % characters in the download url itself is OK
because we only intend to "format" the path.
Note: we do not escape the % characters for urls from the config
file (implicit assumption: the user already correctly escaped the
urls (whether this assumption is sensible or not is debatable, of
course)).
Fixes: #965 ("unsupported format character 'B' (0x42) at index 66")
The old code passes try_again=False to the recursive postoptparse
call when calling it from one of the exception handlers. This is
wrong because it can result in an incomplete conf.config dict (for
instance, if two apiurl sections have no user and no password and
no credentials_mgr_class option - see #761 ("Traceback config with
two backends and no username")).
Hence, Osc.postoptparse should only return if the conf.get_config
call succeeds. For this, unconditionally call Osc.postoptparse from
within the exception handlers. Note: this could potentially (although
quite unlikely) result in an endless recursion but in each recursive
call "user" interaction is required (that is, the user could simply
press CTRL+c) - so this should not be a problem.
Implementation note: this change breaks the API. Rationale: the
semantics of Osc.postoptparse changed. Hence, "pretending" to
honor the try_again parameter could result in unexpected behavior
(from the API consumer's POV). Hence, a traceback might be more
sensible.
Fixes: #761 ("Traceback config with two backends and no username")
Support a zst compressed control.tar in debquery.DebQuery. A zst compressed
control tar is used, for instance, in Ubuntu 21.10.
Note: this requires the 3rd-party python-zstandard module.
Only change the mode of a config file if it is different from 0o600 (instead
of unconditionally calling os.chmod). The advantage of the new behavior is
that it also works with a read-only filesystem. Additionally, if the mode
is not 0o600 and the config file resides on a read-only filesystem, we
print a warning and continue (actually, this change is debatable but it is
also not too bad because the config file does not necessarily have to
contain the passwords anymore... (let's keep our fingers crossed that no
3rd party application relied on the "implicit" os.chmod API, though)).
Only verify the hdrmd5 for containers and rpms. Currently, the other formats
(deb and arch) lack a hdrmd5 implementation. For now, we skip the hdrmd5
verification for these formats. The downside is that the build could be
carried out with a "wrong" package (this could happen, for instance, if
a package is replaced with a different package and both packages have the
_same_ canonname).
The old code would abort the build if the buildinfo contains an arch/a deb
bdep with a hdrmd5 attribute - this is also not desirable from a user's
POV...
Eventually, we will implement the hdrmd5 computations for these formats,
too.
Current OBS is delivering hdrmd5 in buildinfo. It turns out
that osc has already code for validating cached files, but it
invalidates all local files atm with python 3.x
Fix rpm magic check in PackageQuery.queryhdrmd5 (str vs bytes).
Note: if a buildinfo's bdep element contains a hdrmd5, osc will refuse
the build in a non-rpm case.
Current OBS is delivering hdrmd5 in buildinfo. It turns out
that osc has already code for validating cached files, but it
invalidates all local files atm with python 3.x
Do not create an MR for the entire project if "osc mr" is invoked in
a package wc (only create an MR for the specific package instead).
Strictly speaking, the "breaks" the existing UI - but this rather seems
to be a "fix" than a "break";)
Some of our repositories have specific download urls. osc is ignoring
this so far and just tries to use the generic downloadurl
This code prefers definitions for individual path elements if they exist.
We could IMHO remove the old code, since old OBS instances would still
work via the api download fallback.
Real life examples for repo specific configs are on openSUSE all
repositories outside of the /repositories/ directory. eg.
<path project="openSUSE:Tumbleweed" repository="dod" url="http://download.opensuse.org/tumbleweed/repo/oss/"/>
Co-Author: Marcus Hüwe <suse-tux@gmx.de>
The old code does not print any information about the host, for
which the access failed, in case of an URLError. In order to fix
this, add information about the host (and port) to the URLError
instance in core.http_request and use this information in the
babysitter to print out a more detailed error message (which includes
the host (and port)).
For now, we simply add a "private" "_osc_host_port" attribute to
the URLError instance (this way we avoid potential name clashes (due
to the "_osc" prefix) and could come up with a different/more clever
way in the future (due to its privateness)).
Fixes: #954 ("Better diagnostic for domain name issues")
Fix/Workaround for "osc detachbranch" in case of a missing link target
(in this case, the _link file is removed; an alternative would be to
fall back to the last working rev). Also improve the Linkinfo.is_link
check.
os.sysconf is not available on all platforms (like Windows) but it
is used to retrieve the number of online processors. If missing,
assume one processor (building on such a platform will most likely
not work, though).
Fixes: #948 ("Windows compatibility") (at least it improves the
Windows support a bit)
A workflow token can be created via "osc token --create --operation
workflow --scm-token <SCM_TOKEN>".
Triggering a workflow token via osc is probably unlikely - that's
why it is not yet implemented (it would also make the UI a bit
awkward because one has to specify a concrete http header).
Fixes: #943 ("implement osc token --operation=workflow")
The use of makeurl makes the code more readable/maintainable (IMHO)
and it also does proper percentage encoding of the query string (not
that the osc codebase cares much about it, though:/).
Newer rexml Ruby gem used on OBS server side uses stricter XPath parsing.
This change fixes incorrect XPath that was accepted by older rexml,
but not accepted by newer one.
Signed-off-by: Oleg Girko <ol@infoserver.lv>
Offer a force ("f") choice if, for instance, "osc meta prj foobar -e"
fails due to a HTTPError in metafile.edit. If the force choice is
selected, a new url is constructed by invoking the metafile._URLFactory
instance with a "force='1'" argument (this adds a "force=1" to the
original url's query string (*)) and the corresponding file is PUTed
to the new url. If this PUT fails again and now the "y" choice is
selected, the file is PUTed to the original url (*).
(*): Stricly speaking, from metafile.edit's POV, the concrete url
depends on the passed in metafile._URLFactory instance, though.
Note: the metafile._URLFactory class and its is_force_supported method
is a gross hack. That's why this class is marked as private (that is,
we can remove it at any point in time again without breaking the
API/3rd party applications). An alternative to the metafile._URLFactory
approach would be manual URL parsing and manual URL construction
(adding "force=1" to the query string)... but this is also pretty
awkward (if done properly).
Fixes: #916 ("for osc meta edit change y/n to y/n/f")
Fixes: #942 ("Offer -f when prjmeta change leads to repo_dependency")
The order is now:
- ~/.osc_cookiejar, if it exists
- $XDG_STATE_HOME/osc/cookiejar if XDG_STATE_HOME neither null nor empty
- ~/.local/state/osc/cookiejar
Do not try to run source services when building in a non package wc. This
is the behavior we had prior commit c39c3b8cae
("Cleanup the source services execution code in do_build").
There is no "sane" way to execute the source services in case of a
non package wc build because we cannot export the OBS_SERVICE_PACKAGE
env variable with a meaningful value.
Fixes: #936 ("'osc build --local-package ...' fails with 'not an osc
package working copy'")
Be a bit more compliant to the XDG base directory spec: "If
$XDG_CONFIG_HOME is either not set or empty, a default equal to
$HOME/.config should be used." [1].
Now, if the $XDG_CONFIG_HOME env variable is empty, we use the
default.
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
When building a package from a directory that is not a checked-out
OBS working, the error message:
"Error: "<directory>" is not an osc package working copy."
is generated.
This occurs when build.main() attempts to run source services which
is probably not a good idea as these are part of the core.Package
infrastructure which cannot be initialized for such packages.
It is probably best to disable the source services in this case.
See Issue#936.
Suggested-by: Marcus Huewe <suse-tux@gmx.de>
Signed-off-by: Egbert Eich <eich@suse.com>