| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
generate_wheels uses $WHEELHOUSE to generate and store the wheels for
requirements.pip and requirements-testing.pip (if it exists).
pip_install_requirements.sh installs requirements.pip from them if
possible (if not, then it fetches them from pypi) or, if passed the
--testing flag, it installs requirements-testing.pip.
Related: #7327
|
|
|
|
|
|
to workaround the incompatibility problem with Qt libs found in ubuntu
|
|
there are a couple of manual steps needed
|
|
linux only, at the moment, but it's a good start :)
|
|
|
|
- update pip
- install base reqs
|
|
Is useful for new providers to be able to use the stable Bitmask
version with this flag to be able to use custom certificates.
- Resolves: #7250
|
|
|
|
|
|
this is part of a process to make the setup of the development mode less
troublesome. from now on, setting up a virtualenv in pure development
mode will be as easy as telling pip to just install the external
dependencies::
pip install -r pkg/requirements.pip
and traversing all the leap repos for the needed leap dependencies doing::
python setup.py develop
- Related: #7288
|
|
|
|
otherwise the module cannot be imported (in the pseudo-pkg produced by
the sumo tarball)
- Releases: 0.9.0
|
|
- Releases: 0.9.0
|
|
Also, do not raise assertionerror, log warning instead.
|
|
otherwise, events are not correctly registered
- Resolves: #7149
|
|
Fix:
If the logbook controller is not started the stop call will fail.
Trying to start it twice fails.
|
|
lemur/buildbot is intentionally off
|
|
- Resolves: #7284
|
|
|
|
|
|
|
|
Prevent locks caused by the zmq log handler reaching the zmq's HWM (High
water mark / buffer limit) and causing some components to block until
the buffer is empty (running the zmq handler for instance).
We run the zmq handler in the background all the time to prevent this.
- Resolves: #7222
|
|
some general notes about the QA process
|
|
s/self/sync
|
|
Due to #7139 (the logbook log centralizer) logs from 3rd party libs are
included in the centralized logs with lots of debug information and we
don't want that.
We use the existing silencer to exclude logs that are not from leap
modules.
- Resolves: #7185
|
|
The logger is the first thing to be created and on a first run the
config path won't exist. This way we make sure the path always exists.
|
|
if the lsb_release utility is present on system, log part of its output
so we can have more information about the platform bitmask is running
on.
- Resolves: #7162
- Releases: 0.9.0
|
|
- Related: #7139
- Related: #7140
- Related: #7141
- Related: #7142
- Related: #7143
- Related: #7144
- Related: #7180
- Related: #7184
|
|
Rotate bitmask.log file on each start.
|
|
Forward Twisted logs to logging and use logbook to handle logging logs.
Store the bitmask logs on the config folder.
|
|
API to get the children has changed on latest psutil, this takes care
of it.
|
|
Replace logging.getLogger with custom get_logger.
Remove some unneeded dependencies and reorder other.
|
|
- Add a new handler for a zmq/thread-safe log send between components.
- Update the log window to use this new handler.
- Remove old custom handler
We have implemented a new handler that uses logbook, so this one is no
longer needed.
- Adapt log silencer to new handler
- Use log file always as default
- Related: #6733
|
|
We don't need to run the event server on the backend if we are running
from the standalone bundle since the launcher takes care of that.
- Related: #7126
|
|
This dependency was previously installed through soledad, but it
doesn't use that lib anymore.
|
|
due to remaining bits that had not been changed after a refactor.
- Resolves: #7093
|
|
Polkit was being launched and detected correctly, but Bitmask didn't
propagate this result to upper layers, so mainwindow thought the
platform wasn't initialized and then quitted without explanation.
Tested on debian testing, on June 5th 2015, using i3 window manager.
- Resolves: #6652
|
|
The backend was unsetting the soledad proxied object before actually calling
the soledad close() method and this was causing the application to hang when
exitting.
As the local soledad component's cancel_bootstrap() method is called before
the close() method, we'd better not unset the proxied object there, and let
only the close method do it. This commit fixes this by just removing the line
that unsets the proxied object in the wrong place.
|
|
If the events server is initialized in a different process than the backend,
the txzmq socket raises an "zmq.error.ZMQError: Interrupted system call"
exception during the events server initialization. Despite that, communication
seems to work flawlessly after the initialization.
Moving the events server initialization to the same process as the backend
causes the exception to not be raised during events server intialization.
|
|
- Related: #6359
|
|
* Instead of checking if soledad is still syncing for the timeuot cancel
the delayed call.
* Count retries properly.
* Now soledad sync only returns SoledadError (#6981).
|
