Also needed is the update to the networkmanager API version patch.
https://codereview.qt-project.org/#/c/96332/
That patch is now targeted for 5.4, but it is needed for the
networkmanager bearer plugin to work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Forgot to mention, all these patches will go into upstream 5.4, but will
also cleanly apply to 5.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
QNetworkAccessManager doesn't support
I now have a mako to test on.
As far as I can tell, those patches did not fix this. At leastnow the
bearer backend is mostly working.
Tested with the soundcloud scope tutorial app :) and one I made testing
QNAM/QNetworkConfiguration and friends.
I think the problem is the bearer backend does
QNAM uses QtBearer, which means those are handled by the NetworkManager
backend, which I am currently trying to fix up.
There are two ways of diserning online status with QtNetwork.
1) QNetworkConfigurationManager has isOnline() method, this can be done
on the defaultConfiguration().
2)
Is the generic bearer plugin also being installed? What happens when
that is removed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
QNetworkAccessManager doesn't support roaming on
I forgot to mention I noticed this weekend the NetworkManager plugin is not
exactly working well. There is a MR fixing this
https://codereview.qt-project.org/#/c/96332/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Looked into the code, it appears that when they were porting the NM
backend to qt5, they never hooked up anything to the StateChanged
signal. ;/ (I originally wrote the NM backend, but was not on the team
that ported it.)
--
You received this bug notification because you are a member of Ubuntu
I have no way to test this currently, but this change may also help.
The NM backend was missing some mobile connection functionality.
https://codereview.qt-project.org/#/c/96501/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This might be similar to this bug
https://bugreports.qt-project.org/browse/QTBUG-39905
which has this fix patch
https://codereview.qt-project.org/#/c/88823/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The dummy sensor plugin is useless by design, and emulates what an
accelerometer would be like in a desktop computer.
Noted from source code:
// Your average desktop computer doesn't move :)
It could probably be changed to provide some easy sine wave data, but I
am not sure it's worth it.
So there are two things that effect this bug.
1) NetworkManager backend is not working with current NetworkManager on
any platform.
The previously mentioned patches fix this. Mostly API changes in
NetworkManager from when I last worked on this bearer plugin.
2) Having the generic backend
Just pushed another revision to the first upstream change review. This
fixes the plugin on a desktop using ethernet and/or wifi connections.
As for #2. I can make QtNetwork ignore the generic plugin when others are
present and usable. It is a one line fix.
See
In my experience, a working sim toolkit is a requirement of some
operators.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1323837
Title:
Sim toolkit is not available on UT
To manage notifications
After initial testing, it looks like something like this needs to get used:
url.setPath(path,QUrl::DecodedMode);
As the default mode, QUrl::TolerantMode as well as QUrl::StrictMode
result in the '%3D' getting mangled.
--
You received this bug notification because you are a member of Ubuntu
This patch https://codereview.qt-project.org/#/c/98115/
and bug bugreports.qt-project.org/browse/QTBUG-40234
will probably effect/fix this bug as well as those other previous fixes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I get his log when running it with Qt 5.3:
type=AVC msg=audit(1414555047.145:83): apparmor=DENIED operation=create
profile=com.ubuntu.developer.jdstrand.permy_permy_0.7 pid=3682
comm=qmlscene family=netlink sock_type=raw protocol=0
type=AVC msg=audit(1414555047.155:84): apparmor=DENIED
QNAM does indeed block at startup. Unfortunately, the QtBearer backend
needs to perform synchronously in order for QNAM to perform correctly.
Under heavy cpu load, I have seen dbus get quite sluggish.
There is room for optimization in the NetworkManager backend so it uses
property cache with one
Unfortunately, QtBearer cannot be totally asynchronous, as QNAM is a
synchronous API.
It does need optimization in regards to amount of blocking calls it
does.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here'a yet another one. Hopefully only small bug fixes are needed after this.
https://codereview.qt-project.org/#/c/98547/
This one makes mobile data detection really works and uses property
cache instead of making blocking calls for every property call.
The 3 other reviews do not need to be
I found this which might be the problem:
QUrl AalMediaPlayerControl::unescape(const QMediaContent media) const
{
if (media.isNull())
return QUrl();
return QUrl::fromPercentEncoding(media.canonicalUrl().toString().toUtf8());
}
I tested this with a small commandline thing, and
Public bug reported:
Currently, the networkmanager plugin assumes one modem.
It needs to support dual sim properly.
** Affects: qtbase-opensource-src (Ubuntu)
Importance: Undecided
Assignee: Lorn Potter (lorn-potter)
Status: New
** Changed in: qtbase-opensource-src (Ubuntu
https://codereview.qt-project.org/98774
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1389084
Title:
networkmanager QtBearer backend does not support dual sim
To manage notifications about this
The public API between 5.3 and 5.4 has not changed, so using the 5.4 backend
code in 5.3 will work. It's how I am testing/developing it.
Sorry if this is a mess, the nm backend code was basically never totally
finished and untouched for a long time, except for the port to qt5 (which I had
This is really odd.
Digging into this, it appears that something in the system other than QtBearer
backend is causing this.
Attached is a dbus-monitor log. The connection never gets fully activated,
which goes along with the log:
Nov 7 16:45:37 ubuntu-phablet NetworkManager[1333]: warn DNS:
From that syslog:
Nov 7 16:02:32 ubuntu-phablet NetworkManager[1371]: info Activation (/ril_0)
starting connection '/310410528924256/context1'
Nov 7 16:02:32 ubuntu-phablet NetworkManager[1371]: info (/ril_0): device
state change: disconnected - prepare (reason 'none') [30 40 0]
Nov 7
Attached ofonod log when this happens, from just before disconnect through the
reconnect.
I think the new bearer backend is exposing a bug elsewhere, as this
happens even when there no QNetworkSession opened (which calls to
activate whatever configuration).
Whether it is in NetworkManager,
Using only the generic plugin: rmnet_usb0 seems to be having issues.
(repeated ad-infinitum)
(NetworkConfig::configurationChanged:202) - default config
(NetworkConfig::configurationChanged:183) - Unknown 312537797 rmnet_usb0
UnknownPurpose Defined BearerUnknown InternetAccessPoint
@kgunn72 I think we certainly have moved on to a different bug.
Originally, QNAM was not considering mobile data connection at all,
because the QtBearer was only using generic plug (which does not know
the difference between mobile data and other network interfaces and is
not really usable
This fix for this bug is part of the patch for
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-
src/+bug/1357321
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1389084
Title:
syslog with networkmanager debug.
Starts with being connected. double spaced when it reached disconnection, and
ends with reconnection.
** Attachment added: nm debug syslog
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1357321/+attachment/4258799/+files/syslog.log
--
As for the original comment. If I delete the cache and reboot,
icons/images do not show up like normal if I start up with 3g
connection.
Looking at the syslog, I noticed the disconnection always starts with
the line:
NetworkManager[1439]: debug [1415764765.680476] [nm-modem.c:533]
weird. I just downloaded/installed the package again, and I can no
longer see that disconnect/reconnect loop.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER]
Well, I did delete the contents of ~/.cache and reboot. But now I do not
have the apps grid.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't
According to dbus-monitor, the mode interface keeps failing:
signal sender=:1.8 - dest=(null destination) serial=1635
path=/org/freedesktop/NetworkManager/Devices/1;
interface=org.freedesktop.NetworkManager.Device; member=StateChanged
uint32 120
uint32 40
uint32 0
signal sender=:1.8 -
modem interface...
Is there anyway to edit comments?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu
To manage
When I use dbus-monitor on NetworkManager, I get this:
signal sender=:1.8 - dest=(null destination) serial=2845
path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager;
member=StateChanged
uint32 20
signal sender=:1.8 - dest=(null destination) serial=2852
Ok, I think I see the light now. This is an odd one.
There seems to be two connection settings (within networkmanager) for
the same connection context (even in mako), one being the nm settings
configuration that is actually connected (settings/2), and the other
that is not flagged as active
This fixes that last reconnection issue. There might be a better way,
but with this, the connection is stable again.
https://codereview.qt-project.org/#/c/99818/
But the question remains why NetworkManager has more than one
configuration for a context
--
You received this bug notification
When I run that test on the phone, it does not crash and passes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu
Updated upstream. https://codereview.qt-project.org/#/c/99818/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu
To
Here's a patch to skip some of the tests that are failing due to no
valid configurations on the test machines.
** Patch added: skip failing network tests
Has that network-manager fix hit ubuntu-rtm/devel yet? Because without
these qtbearer/qnam patches, I'm still seeing images loading issues.
The problem is not manually disabling the AP, but when moving (roaming)
from one to another, i.e. moving from wlan coverage to 3g coverage, or
from 3g to
I did more testing of the generic plugin, and it's not as bad as I
thought, in that it does signal when interfaces become the default
route.
But my comment still stands that without these patches (in the least,
the patch to QNAM itself is especially needed) the defaultConfiguration
internal to
Start InternetCheckercmd with wifi enabled, with the known wifi router
unpowered or out of range, while connected to mobile data. (will not
work like this when manually enabling/disabling wifi)
It will return something like this:
phablet@ubuntu-phablet:~$ InternetCheckercmd/InternetCheckercmd
Looks like an app armour thing.
Debug-helper Executing /usr/bin/qmlscene['/usr/bin/qmlscene', '$@',
'share/qml/nmsessiontest/nmsessiontest.qml']
process 7885: arguments to dbus_message_new_method_call() were incorrect,
assertion _dbus_check_is_valid_path (path) failed in file
[05:34:57] lpotter QDBusConnection: error: could not send message to service
org.freedesktop.NetworkManager path interface
org.freedesktop.DBus.Introspectable member Introspect:
[05:35:01] lpotter hmm
[05:35:24] mzanetti oh, you're still working. I hope it's not just for this
[05:35:34]
Added some error reporting:
QNetworkManagerInterface::QNetworkManagerInterface(QObject*) propsReply
An AppArmor policy prevents this sender from sending this message to
this recipient, 0 matched rules; type=method_call, sender=:1.136
(uid=32011 pid=5705
Briefly looked into this, and something odd is going on in the
networkmanager QtBearer backend.
The wifi connection is first reported in the Defined state, and then gets
Undefined for some reason when it should be updated to Active state.
Need to dig further.
--
You received this bug
I updated yesterday and this bug effects me (lenovo x1 carbon 1st gen).
I have no bluetooth now.
dmesg:
[ 73.111498] usb 1-1.4: new full-speed USB device number 7 using ehci-pci
[ 73.207595] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6
[ 73.207604] usb 1-1.4: New USB
Could you try to restart NetworkManager? Does that have the same effect
as restarting smartscopeproxy?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1413269
Title:
Qt network being unreliable
Patch attached that fixes wonky configuration state and also fixes isOnline for
me.
I will test and upstream this more tomorrow.
** Patch added: fix-ubuntu-bearer.diff
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1413269/+attachment/4305295/+files/fix-ubuntu-bearer.diff
QNetworkSession is part of Qt. Making isOpen use connectivity-api will
not work, because the QNetworkSession state isn't necessarily a one to
one relationship to the connectivity state.
QNetworkAccessManager and friends use QtBearer and the network manager
backends it provides for network
As for NetworkAccessibility bug:
https://codereview.qt-project.org/#/c/113478/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
QNetworkAccessManager hangs when in flight mode
To
additional patch:
https://codereview.qt-project.org/#/c/122382/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
QNetworkAccessManager hangs when in flight mode
To manage
Moving this to upstream bug, so I can do the work there.
https://bugreports.qt.io/browse/QTBUG-47482
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
QNetworkAccessManager hangs when
You do realize this means QNetworkAccessManager most likely will not
work as well.
Any network request, GET, etc... done with Qt runs though
QNetworkConfiguration, which uses the same backend plugin for accessing
network-manager. In which case Qt should probably be configured with the
hmm. might take yet another.. momentarily
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
QNetworkAccessManager hangs when in flight mode
To manage notifications about this bug go to:
I updated this patch today.
https://codereview.qt-project.org/#/c/121724/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
QNetworkAccessManager hangs when in flight mode
To manage
QtBearer just runs on top of the system networking, so if the platform
specifies it doesn't allow start/stop of interfaces, like the generic
bearer plugin, it is allowed to return an error of 'not allowed' or
somesuch.
It's the current network-manager bearer plugin that does not take into
account
Might try using bearer plugin based on connectivity-api
https://codereview.qt-project.org/#/c/140752/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1404188
Title:
QNetworkSession::isOpen() always
Might try using bearer plugin based on connectivity-api
https://codereview.qt-project.org/#/c/140752/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508945
Title:
"Couldn't load weather data,
You might be running into those dbus blocking calls in the network-manager
bearer backend.
The networkmanager bearer plugin currently is using a few blocking dbus calls
to get properties and such.
see this abandoned change here:
https://codereview.qt-project.org/#/c/98090/
This change was
That's right, any time QNAM is used it uses the Qt Bearer backend
(unless Qt is configure without bearer). In the case of the network-
manager backend, it calls the blocking dbus calls to get list of
services, and then for every service to get that services properties.
Even for local file://
Not sure that QtBearer is being understood.
http://doc.qt.io/qt-5/bearer-management.html
QNetworkAccessManager and friends (QNetworkRequest, etc) use bearer
management for starting and stopping connections when needed and if
allowed by the system.
QtNetwork / Bearer Management cannot be made to
hmmm... I just noticed/remembered that upstream Qt networkmanager plugin
has been updated, which should perform a bit better as it has had some
refactoring/rewriting done. It is slightly more sane.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
The generic bearer plugin is brain dead, especially when it comes to
knowing when it's actually connected or not.
Although connectivity-api also suffers from blocking dbus calls, I feel
the connectivity-api backend is the right way to go for bearer & QNAM
right now. In the least, it will lessen
Actually, the only time Qt's QNetworkManagerInterfaceAccessPoint does a
GetAll is in the QNetworkManagerInterfaceAccessPoint c'tor. But that is
in the upstream version.
And the current ubuntu version (at least the one I am seeing) does not
do GetAll at all.
--
You received this bug notification
I've done some work on QNAM recently in regards to accessibility
property in QNAM, and see that the patch that (which was upstreamed to
qt 5.6) makes this property follow the online state like it should, is
missing from ubuntu's repo.
I will try to do some testing on phone and see if this can
Looks like that test assumes it's always going to be either Accessible
or NotAccessible, and does not account for UnknownAccessibility.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1470700
Title:
FAIL! : tst_QXmlInputSource::waitForReadyIODevice() 'reply->error() ==
QNetworkReply::NoError' returned FALSE. ()
Loc: [tst_qxmlinputsource.cpp(150)]
This test is http client/server test. I have tested this here and it
hangs on previous version (5.4.2) as well. The request never gets the
quick patch to fix this.
** Patch added: "nmbearer-system-settings-fix.diff"
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1523975/+attachment/4531606/+files/nmbearer-system-settings-fix.diff
--
You received this bug notification because you are a member of Ubuntu
patch #6 fixes crash in system-settings (#1523975) and removes wifi
scanning updates, which could potentially drain the battery (#1524133)
** Patch added: "net-bearer-nm-disconnect-ap-signals6.patch"
I don't agree that it makes sense to disable one input method if another
is available. Make it a user configurable option to use one or the
other, but do not disable using both.
I have a touchscreen desktop with second screen. I want both mouse and
touchscreen available. I use both at the same
There are still a few API changes coming. I will make sure it compiles
with 5.4 as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1525879
Title:
Integrate InputInfo patch from upstream
To
@Tony
1) requestUpdate() should be left in, as the backend needs to tell other parts
when the update request has been completed. I have tested this, so it does
compile. In further testing, it does not look like any clients are requesting
updates, so the increased power consumption is coming
fyi: requestUpdate is called by the qnetworkconfigurationmanager, when
updateConfigurations() gets called.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480877
Title:
Access points'
just a note, some of the missing values in deviceinfo can be gotten from
hybris properties, such as in ubuntu-system-settings
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1197542
Title:
System
In that case, yes I agree.
If it means I can only use one or the other then no.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1525979
Title:
Touchscreen interactions should take priority over
Public bug reported:
Using Nexus 4, Ubuntu 15.04 (r330) (rc-proposed)
The bearer plugin that uses connectivity-api used to work (ubuntu touch) back
in November :
https://codereview.qt-project.org/#/c/140752/
It still compiles, but now I get:
2016-01-06T13:28:29 (unknown:0) - QObject::connect:
Just tried the qml example found here:
https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.Connectivity.NetworkingStatus/
Main.qml:27:5: QML Connections: Cannot assign to non-existent property
"onStatusChanged"
shows "Not online" when I am connected.
--
You received this bug
For at least the c++ example, it seems the example code connect call
should be at least:
QObject::connect(ns.data(),
::statusChanged,
[=](NetworkingStatus::Status value)
--
You received this bug notification because you are a member of Ubuntu
Bugs,
calling something like this:
QObject::connect(ns.data(),
::statusChanged,
this, ::networkStatusChanged);
still does not work.
In networking-status.h, the signal should be declared as:
void statusChanged(NetworkingStatus::Status value);
I looked at
I tested landing-032 and system-settings at least does not hang at
'checking for updates' when on mobile data (it now checks and when it
completes says 'connect to the internet to check for updates')
landing-032 contains needed fixes in QtNetworkAccessManager (including this
bug), and would be
This seems to be working now as expected (usinglanding-032) without the
'connect to the internet to check for updates'
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1528886
Title:
Checking for
Seems this did not totally fix this, it will still hang at 'checking' if
I switch off wifi and then quickly check for updates, but will work if I
press back and then check again.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ok. I thought it was fixed, but as I have investigated it further in
qnetworkaccessmanager, I was somehow fooled and that landing does not
fix this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Is there any reason to keep both connections active at the same time?
Obviously it needs to be able to connect to mobile data when wifi is
connected for HERE/agps, but I think it just needs to download satellite
data once (I could be wrong it might need to keep downloading this data)
--
You
I hate to say it, but this sounds like a bug in qnam/qtbearer I have
been chasing where the default configuration does not get switched back
from wifi to an already/still connected mobile data connection.
Perhaps
https://bugreports.qt.io/browse/QTBUG-49760
or
@Tony, currently I am on stable/ubuntu-developer. Previously I was
testing on stable/ubuntu. I was on rc-proposed for quite a while, but it
seemed to have only a few scopes, and not the twitter scope which I
wanted to try out.
My updated patch removes actions on device added and removed calls.
I can confirm on ubuntu touch that FaceUp and FaceDown are not being
handled or signaled when they should be (qtubuntu-sensors orientation
does not even handle it)
As well, there is no implementation for AmbientLight in qtubuntu-
sensors.
--
You received this bug notification because you are a
I changed my phones image channel, tested (with a few specific test apps
I have for QNAM & friends) that new patch and didn't see any thing too
wrong.
Although I am seeing heaps of GetAll calls that do not need to happen
(even for non nm managed interfaces - rmnet). Attached patch
@Tony I suppose that if statement in
QNetworkManagerEngine::requestUpdate() could also be removed, leaving
the last line only, since we do not do anything with uknown AP's
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This patch fixes duplicate entries of access points. Which contributes
to but may not totally fix this bug.
** Patch added: "nmbearer-fix-duplicates.diff"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1480877/+attachment/4521638/+files/nmbearer-fix-duplicates.diff
--
You
nmRegistered will only get called from the connection signal/slot when
networkmanager daemon if and when gets registered on the dbus. If it is
already registered, it will get called from that invokeMethod.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
You are correct in that GetAll gets called twice for each accesspoint.
I can see that by adding qDebug's and disable/enable wifi
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1480877
Title:
Access
Sorry, thought I'd include more.
2nd patch that obsoletes my previous patch includes disconnecting from
system dbus when objects get deleted.
** Patch added: "nmbearer-fix-duplicates2.diff"
Since it takes quite a bit of time to get a satellite fix, but it does
get one eventually (nexus 4 here), we can probably assume that it is
agps that is not working.
In the location log, I can getting errors such as:
E1123 16:30:46.685298 1232 android_hardware_abstraction_layer.cpp:157] Error
There is a manual test app included with qtsysteminfo called sysinfo-
tester. You have to manually build this.
I can go though this on the phone, see what is missing, wrong, etc. and
fix it up.
It tries a variety of ways to determine different values..
--
You received this bug notification
I agree, since nothing controls the connections through QtBearer (and
the platform doesn't want that), and AP lists are not allowed in
contained apps, it makes sense to simply remove them.
I've fixed up that patch in regards to d'tor disconnects, removed some
redundant code.
And since it was a
@Tony
I noticed this on touch.
The problem was that the ConnectionActive was returning true for mobile data
ipv6 default route when wifi had the actual default route, so it would never
get updated when wifi became default.
--
You received this bug notification because you are a member of
1 - 100 of 245 matches
Mail list logo
