Debian packaging for V0.16.2 #84
Comments
|
Hi @rolandmas, thanks for the feedback! I suspect that this I think that we should begin by fixing this part of the issue: Apparently, this is caused by the fact that the |
|
BTW, the "cdl\tests\features\tour_unit_test.py" test is not the first test of the DataLab test suite. Otherwise, I will need to be able to reproduce the build to debug, like we did on the PlotPy Issue. |
|
I'm ready to rename the module into |
|
However, the impact of the renaming is quite significant (for consistency, a lot of modules would be renamed as well), so if you would help me diagnose the problem, it would be great. |
|
Thanks for the XDG_RUNTIME_DIR idea, I'll investigate it before any other and keep you informed. |
|
Ok, thanks @rolandmas . BTW, I think that the "signal" module that should be renamed just for testing purpose is this one: "cdl/tests/features/signal". |
|
My previous comment may still be relevant. However, in the meantime, I though about one thing that might be the cause. To check if
If what you see is described in point 2., then you should try to add the folder name after the |
|
FYI, I've renamed the submodule 'signal' to 'signals' in DataLab V0.16.2, so that this specific error will no longer occur (even though I suspect that it's not the real problem here). |
|
I haven't seen the "signal" problem yet (build is still running), but now I get the following error: |
|
This may (again) be a working directory issue, because some modules are not meant to be executed from some directory (it's sometimes difficult to cover all the conflict import combinations). So, without any execution context, I can't tell you more about this. |
|
In other words, a copy/paste of the original log would certainly help. |
|
I'm in the verge of releasing a new bugfix version (V0.16.2). |
|
Are you on IRC or Matrix by any chance? |
|
Current build (in progress): |
|
(Note the lack of "QStandardPaths: error creating runtime directory", which went away with XDG_RUNTIME_DIR=$HOME) |
|
I've read that the |
|
By the way, I see that you do not run tests using the official test suite which is based on |
|
It could be interesting that you take a look at the test script for Ubuntu's GitHub build action... for inspiration? |
|
All the issues above were fixed thanks to further discussions in a private chat room. Here is the final version of the command line executing tests in the context of the Debian package build process: set -e
for v in $(py3versions -vs); do
HOME=$(mktemp -d)
trap "rm -rf $HOME" EXIT
BUILD_DIR=/build/datalab-0.16.2/.pybuild/cpython3_${v}_datalab/build
cd $BUILD_DIR
unset SESSION_MANAGER
PYTHONPATH=$BUILD_DIR
XDG_RUNTIME_DIR=$HOME
xvfb-run
python$v -m pytest
rm -r $HOME
doneWith those modifications, only one test was still failing: cdl/tests/features/common/reorder_app_test.py: In V0.16.2, a workaround was implemented so that this test is now OK: instead of checking the absolute number of groups after removing one ( Here is the associated patch: --- a/cdl/tests/features/common/reorder_app_test.py
+++ b/cdl/tests/features/common/reorder_app_test.py
@@ -65,8 +65,9 @@ def test_reorder():
group = model.get_object_or_group(group.uuid)
assert group.number == 2
# Remove group
+ n_groups = len(model.get_groups())
model.remove_group(group)
- assert len(model.get_groups()) == 2
+ assert len(model.get_groups()) == n_groups - 1
if __name__ == "__main__": |
PierreRaybaut
changed the title
signal name conflict, ...
|
At first, writing the previous comment seemed inessential... but apparently it was a good idea to do so because it made me realized what was the real issue regarding the |
PierreRaybaut
changed the title
signal name conflict, ...
Describe the bug
The "signal" symbol seems to be conflicting with the standard library's "signal" module.
To Reproduce
Running the testsuite in a clean Debian unstable chroot, as part of building the .deb package.
Expected behavior
Testsuite proceeds and succeeds :-)
Screenshots
Here's the part where the package build runs the testsuite:
Installation information
Building from the 0.16.1 release, no patches.
Additional context
I suspect that the "signal" module that "multiprocessing" tries to use is actually one provided by Datalab rather than the one in the Python standard library. So either something's not tight enough when isolating the scope of the imports, or maybe it would be better to rename the "signal" submodules in Datalab.
The text was updated successfully, but these errors were encountered: