This kind of guessing can not really work here and leads to failing
builds when using KVM. (eg. when using a preinstallimage)
Removing the code, since we have a now a way to allow the user to
specify building as user via su-wrapper config
If osc is invoked, for instance, via "osc -d rbl ... > log.txt 2>&1",
writes to stderr and stdout do not necessarily appear in program order
in the log.txt file. More precisely, it is possible that the buildlog
comes first and the http debug output is at the end of the
file.
During osc/python3 startup (with the redirection from above), the
following is done:
- make stdout line buffered (due to the code in osc-wrapper.py)
- make stderr buffered (but not line buffered) because stderr does
not refer to a tty (python3 startup)
Consequently, if osc has code like
print("foo")
print("bar", file=sys.stderr)
print("baz")
it is possible that the contents of the log.txt is
foo
baz
bar
because stderr is buffered (but not line buffered). In order to fix
this, make stderr line buffered, too.
Element.getchildren is deprecated and not available on python39
anymore. Instead, iterate over the element itself (which iterates
over the element's children).
Fixes: #903 ("AttributeError: 'xml.etree.ElementTree.Element' object
has no attribute 'getchildren'")
Most osc commands support slash notation for the specification of
a project package pair. That is, "osc <cmd> prj/pkg" has the same
semantics as "osc <cmd> prj pkg" (in most cases).
For consistency reasons, "osc creq" should also support the slash
notation for the action type's arguments. That is, for instance,
"osc creq -a submit src_prj/src_pkg dst_prj/dst_pkg" should have the
same effect as "osc creq -a submit src_prj src_pkg dst_prj dst_pkg".
Proposed-by: darix
Add --lastsucceeded/--last-succeeded option to "osc buildlog" (the latter
option is also added to "osc remotebuildlog").
Also take the --lastsucceeded option into account when computing the
file offset (for the corresponding *tail commands).
Moreover, improve the error message in case of an unknown build type (now,
it also includes flatpak* filenames).
Workaround/fix for pypi deployment via travis.
Note: I cannot really "review" this change because I have no clue about
travis. Since the current pypi deployment via travis does not seem to
work, merging it does not seem to be a problem.
Probably fixes: #884 ("osc pypi artifact is not up to date")
Deployment via Travis CI failed due an error during
cleanup (#884):
`Could not restore untracked files from stash entry`
Disabling the cleanup fixes this problem.
If there are existing requests that should be superseded, the old
code stores the Request instances in the myreqs list, which is
returned to the caller. However, the caller expects only request
ids instead of instances of class Request. Eventually, this results
in a type error - excerpt:
...
File "/usr/lib/python3.8/site-packages/osc/commandline.py", line 1892, in do_createrequest
change_request_state(apiurl, srid, 'superseded',
File "/usr/lib/python3.8/site-packages/osc/core.py", line 4322, in change_request_state
u = makeurl(apiurl,
File "/usr/lib/python3.8/site-packages/osc/core.py", line 3326, in makeurl
return urlunsplit((scheme, netloc, '/'.join([path] + list(l)), query, ''))
TypeError: sequence item 2: expected str instance, Request found
Hence, simply return the request ids instead of the Request instances.
Note: this changes the API of the Osc._submit_request method but
this is OK because it is not part of the public API.
When calling "osc creq -a prj1 foo prj2 bar -a submit prj1 bar prj2 bar",
the requests that could be superseded are calculated two times for the
prj2/bar package. Hence, they could end up two times in the "supersede"
list (see do_createrequest) In order to avoid duplicates, use a set
instead of a list.
Kudos to darix for pointing this out!
Note: it is a bit questionable if osc's current semantics makes sense
in the above example.
When creating a new request via the core.Request.create method, there is
no need to escape the data that is assigned to the "description" attribute
of a core.Request instance. Internally, core.Request.create ensures that
the data, which is POSTed to the api, is correctly escaped (the escaping
is implicitly done by ET (see core.Request.to_str)). Manually escaping the
description results in a double escaping (the escaped description is
escaped by ET again) - this is not the desired behavior.
Analogously, there is no need to escape the data that is passed to the
message parameter of the core.create_submit_request function because
core.create_submit_request takes care of escaping it.
Fixes: #869 ("Silly encoding of htmlencodable entities")
So far, core.get_prj_results only supports a substring based name
filtering mechanism. Now, a regex based name filtering mechanism
is used. That is, if the regex matches a package name, the package
is not filtered out.
This is an API incompatible change:
- 3rd party code which looks like this is going to break:
class Foo(str):
...
def __eq__(self, other):
return ...
... = core.get_prj_results(..., name_filter=Foo())
(My gut feeling says there are no such callers. However, if this
really breaks any serious code, we can fix it in a follow-up commit)
- "osc prjresults openSUSE:Leap:15.2:Update --name-filter zypper." will
now also show "zypper-docker" etc. because the dot (".") matches any
character (except a newline). Previously, only packages that contained
the str "zypper" followed by a dot (".") were shown. The old behavior
can be restored, if the dot is escaped: "osc prjresults
openSUSE:Leap:15.2:Update --name-filter 'zypper\.'".
Of course, this affects all other special characters, too.
Additionally, if an illegal regex is passed to the --name-filter option,
an exception is raised. The previous code did not fail.
This can break existing workflows and scripts. We could avoid this by
introducing a --name-filter-regex option but this would clutter the
UI (IMHO).
A regex based name filtering feature was requested by darix.
Using os.getcwd() in combination with a subsequent .encode() is error
prone:
marcus@linux:~> mkdir illegal_utf-8_encoding_$'\xff'_dir
marcus@linux:~> cd illegal_utf-8_encoding_$'\xff'_dir/
marcus@linux:~/illegal_utf-8_encoding_ÿ_dir> python3
Python 3.8.6 (default, Nov 09 2020, 12:09:06) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getcwd().encode()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 36: surrogates not allowed
>>>
Hence, use os.getcwdb(), which returns a bytes, instead of
os.getcwd().encode().
Fixes: commit 36f7b8ffe9 ("Fix a
potential TypeError in CpioRead.copyin and CpioRead.copyin_file")
If no dir is passed to util.ArFile.saveTo, dir is set to os.getcwd(),
which returns a str. Since self.name is a bytes, the subsequent
os.path.join(dir, self.name) results in a TypeError.
To fix this, use os.getcwdb(), which returns a bytes instead of a
str.
Support "osc build --vm-type=nspawn". Without this change build_root
is changed to "build_root/.mount", which results in an invalid name
for systemd-nspawn (see build-vm-nspawn in the obs-build codebase).
Now, --vm-type=nspawn behaves the same as --vm-type=lxc wrt. option
passing to the build script and package signature checking.
This allows to utilise support for systemd-nspawn backend in build engine.
Like LXC, systemd-nspawn creates isolated lightweight container.
Signed-off-by: Oleg Girko <ol@infoserver.lv>
If no "dest" argument is specified when calling CpioRead.copyin or
CpioRead.copyin_file, a TypeError occurs in CpioRead._copyin_file
because os.getcwd(), which returns a str, is used as dest and, hence,
the subsequent os.path.join(...) fails (because it tries to join a
str and a bytes).
In order to avoid this, encode the result of os.getcwd().
Note that the existing
archive.copyin_file(hdr.filename,
os.path.dirname(tmpfile),
os.path.basename(tmpfile))
was OK because CpioRead._copyin_file os.path.join()s "dest" and
"new_fn", which are both str. It is just changed to stress that
CpioRead is a bytes-only API.
Fixes: #865 ("Traceback in osc/util/cpio.py line 128: TypeError:
Can't mix strings and bytes in path components")
Currently, when trying to initialize a non existent (server-side)
project via "osc init <prj>", osc errors out (after creating the wc)
because it fails to retrieve the package list. However, there is no
need to retrieve the package list in the "osc init <prj>" case. Hence,
skip the package list retrieval. As a result, osc does not error out.
For the background, see the discussion in #858 ("osc fails to check
out an empty project as project") [1].
[1] https://github.com/openSUSE/osc/issues/858#issuecomment-722330024
