| Age | Commit message (Collapse) | Author |
|---|
|
these methods were returning None, and therefore breaking soledad
password change (since it checks whether mail is enabled before changing
soledad pass after srp pass change).
- Resolves: #7470
|
|
Right after a complete sync we show the unread emails.
- Resolves: #7453
|
|
|
|
Refactor ivan's code (aa4b684d0682ff9faf1577653fa5ceabbc6e0f20) to remove the
time.sleep.
- Resolves: #7414
|
|
the second callback was actually broken, not being called when it was
supposed to be.
the reason is that IncomingMail.startService returns a deferred which
callback is called with the loopingCall instance only when the
loopingCall is stopped.
|
|
logout calls were not being authenticated, so we were receiving 401
return code.
|
|
we need the 'multi' feature all the same, so we'll be depending on
logbook >= 0.7.0.
|
|
there's an error in the import
|
|
for the version in ubuntu trusty, the call for the zeromq handler
initialization gets one less argument
|
|
- Resolves: #7415
|
|
Look for file defined in the `BITMASK_CREDENTIALS` env variable and load
`provider`, `username` and `password` data.
Trigger login if they were loaded correctly.
The credentials file should look like this:
[Credentials]
username = my-account@my-provider.com
password = secret
- Resolves: #7419
|
|
|
|
|
|
If the user wants to register a new account we check whether the
provider allows registration or not right after getting the
provider.json file and show an error msg on the wizard if not allowed.
Also, there is a new signal to handle the error raised by the server if
a registration attempt is made but is rejected with error 403.
- Resolves: #6594
|
|
Is valid for a provider not to provide locations for their gateways.
- Resolves: #7281
|
|
on the sumo tarball, the _version file for leap/bitmask submodule wasn't
being frozen, and hence BITMASK_VERSION was None. this was breaking the
provider tests w/o any clear error message.
- Related: #7322
|
|
Register to Soledad's sync (send and receive) events and display the
progress in the UI.
- Resolves: #7353
|
|
this is a bug in macholib, there's a missing letter in the plugins path, so
unless we fix this they cannot be loaded from the bundle.
See:
https://bitbucket.org/pydica/pyside-setup/commits/4b8be97e5a00b577fe30ce9aa7e5723ff2a66f94
Quoting from http://code.activestate.com/lists/pythonmac-sig/23278/:
"""
The problem might be this line:
@rpath/Contents/mageformats/libqtiff.dylib
The "i" from "imageformats" is missing!
This _might_ be related to the unusual case that "libqtiff" has no path
at all, or something else
is funny, and we end up with a name that will not be found at all.
Then the loader finds the plugin in the installed Qt, which causes it to
load everything
again from there.
"""
|
|
due to zmq, we are hitting the limit and getting app crashes.
- Resolves: #7319
|
|
|
|
|
|
|
|
|
|
The tests where using deferToThread to run without need, I remove it
and now it's easier to debug when one test fails.
- Resolves: #7343
|
|
The new pyinstaller method will rule out the launcher, we need the
updater working inside bitmask client.
- Closes: #7291
|
|
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
|
|
|
|
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.
|
|
- 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
|
|
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
|
|
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
|
|
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).
|
|
Before this commit, the backend used plain pyzmq bindings for communicating
with the frontend. This implements the txzmq twisted-powered bindings instead.
Closes: #6360
|
|
- Related: #6876
|
