Best posts made by jezek

Failed MMS redownload progress report:

This week only nuntium PR got updated.

There was a problem with redownload after nuntium got restarted. After nunium restarted (on crash, or phone reboot), the redownload button from messaging-app didn't work. This was because of the button sends the redownload request to nuntium through dbus. And after nuntium restart, there was no one listening on dbus for the redownload signal. I've fixed this by spawning listeners for messages on modem identification. So the redownload now works even after phone restart.

Also the nuntium-inject-pust testing tool got update. It can now autodetect the end-point flag from nuntium logs using grep & sed commands.

Failed MMS redownload progress report:

There are now 3 drafts on github:

• https://github.com/ubports/nuntium/pull/8
• https://github.com/ubports/telephony-service/pull/20
• https://github.com/ubports/messaging-app/pull/260

This is the first working version, where you can initiate re-download of failed MMS by clicking a button in messaging-app. This version is quirky and will be improved further.

What needs to be done?

• make it possible to report failed message using status, not an empty message.
• refactoring, tests, documentation, changelogs, etc...

Will report again on any noticable progress.

I the banner. Also kudos to everyone who participated and made this possible.

@krogoth I like @dobey 's answer. Cause it's not a simple 'no'. It is accompanied by some hints, how you can try to approach the problem, if you want to solve it. Keep going @dobey , excellent work.

Failed MMS redownload progress report:

Because of unsafe apt operations, which makes crossbuilder & ubports-qa unsafe too, I've redirected my attention to nuntium, resulting in some commits to https://github.com/ubports/nuntium/pull/8. (Note: I can easily deploy nuntuim to phone without apt)

What was done?

My operator (and other?) resends multimedia message notifications ever 10 minutes, if notification is not marked as received. This resulted in new error message (when download fails) and notification sound every time. These new commits prevents this behavior.

Every notification comes with transaction-id, which is stored on download error and if new notification comes with the same transaction-id and there was a download error again, the error message will not be sent to telepathy again.

The only caveat is, that if the second download fails on another error as the first, then the second error will not be communicated (however no error description is communicated now, this will be added in future). I'll see, if this will need attention later.

To test these changes easier, I've added an transaction-id flag to nuntium-inject-push testing tool.

That's all for this week, see ya next time.

Failed MMS re-download progress report:

The progress is slow, but steady. Two PR drafts got updated:

• https://github.com/ubports/telephony-service/pull/20
• https://github.com/ubports/messaging-app/pull/260

What was updated:

1. Some refactoring was done in telephony-service in redownloadMesage pathway (the function now needs 3 string parameters instead of a string map).
2. The redownload (in telephony-service) changes message status to pending before sending a redownload request to nuntium.
3. The redownload (in telephony-service) sends redownload request to nuntium only if message status is unknown (later it will be other status) to not request redownload more times than needed (if function is called more times)
4. Redownload buton gets disabled if message status is other than unknown (will be other status later), to indicate hat redowload is in progress.

Failed MMS re-download progress report:

Number of drafts on github is now 5:

• https://github.com/ubports/nuntium/pull/8 - saves info about failed download, adds error & delete-event parameters (if needed) into dbus message for thelepathy-ofono and incoming re-download request.
• https://github.com/ubports/telepathy-ofono/pull/20 - for received mms (from nuntium), parses additional parameters ("Error", "DeleteEvent") and sets Telepathy message headers accordingly ("x-ubports-error", "supersedes").
  The "supersedes" header indicates, that the current message replaces the one stored in the header and is currently handled by history-service without any change. (Note: during injection testing, history service fails to delete the supersedes message, if it is in another conversation)
  The "x-ubports-error" header should indicate an error message when message propagates through telepathy-qt to history-service. Maybe the error propagation could be done via "delivery-status", "delivery-error", "delivery-error-message" headers and no changes in history-service will be needed (theory needs testing).
• https://github.com/ubports/history-service/pull/35 - the code here does nothing new yet, just adds some logging. The idea is to change status if "x-ubports-error" is set. It's possible, that this PR will be unnecessary.
• https://github.com/ubports/telephony-service/pull/20 - adds methods to propagate re-download request to nuntium.
• https://github.com/ubports/messaging-app/pull/260 - adds re-download button to error message.

The redownload should work after these PRs. The new thing is, that after hitting redownload the old error message bubble should be deleted when the new message arrives (as successfully received message or new error message).

What needs to be done:

• improve error mms logic (currently: when delivered message is empty, without attachments). The idea is, that a delivered message is an error message when message is empty (historical reasons) or status is one of MessageStatusPermanentlyFailed, MessageStatusTemporaryFailed or MessageStatusPending. The message, which can be re-downloaded will have temporaryFailed status and will show the re-download button. Upon re-download clicked the state will be changed to pending (the re-download button is disabled). When re-download is not possible (expired, some other error) the status will be permanentlyFailed or empty message (current).
• set status in history-service (if needed)
• refactoring, tests, documentation, changelogs, etc...

I'm sorry, I'm so slow with progress, have only cca a hour a day for coding/testing. And building, deploying, phone restarting and log/code studying takes too much time. I hope it'll get faster.

@lduboeuf said in The MMS lost story:

How do you manage to propagate error or deferred status as Telepathy Message object to Telephony-service and History-service ?. By using the messageType , e.g: ChannelTextMessageTypeNotice ?

I'm afraid, that propagating via messageType (declaring new type) could break some other logic, which handles message type. So I decided to go with custom header "x-ubports-error". Or maybe using other headers (see above).

Questions, ideas or critics are welcome.

Edit: https://github.com/ubports/telepathy-ofono/pull/20 and https://github.com/ubports/history-service/pull/35 fail to pass checks. Does anyone know why?

@hummlbach Ok. I've decided. I'm ready to maintain the messaging app, if there isn't anybody else. I think I can read/write code, but I'm not familiar with the workflow of maintaining an app on UT. So what do I need to do/know for starters?

Hello there.

I made a pull request, to be able to build messaging-app with clickable tool. This can be usefull for develpoing and testing purposes. And who knows, maybe sometimes all apps come as clickable (snap, ...) packages and can be uninstalled to make UT more flexible.

I'm writing this, to bring a little bit of attention to the PR, to do some testing, if it can be accepted. Feel free to ask any questions.

and PF 2021

@dtarrant I played with clickable and webapps few weeks ago .... this is the result: memrise webapp

After looking to my history, these were my steps to init, build & deploy to phone:
on notebook with Ubuntu MATE 18.04

1. install & setup clickable & docker

   sudo add-apt-repository ppa:bhdouglass/clickable
   sudo apt update
   sudo apt install clickable docker
   

2. go to your project dir & create project via clickable (project folder will be created)

   cd ~/projects/ubports/webapps/
   clickable init
   

3. after app creation was successful, you should see an dir created in your current dir with the name of the project you typed in clickable initialization. Enter the project dir

4. try to run (I've figured out, you have to use sudo to run docker)

   sudo clickable -e
   

5. edit files, play, debug, etc ...

6. to deploy to phone, there is a .click package (like appname.developername_1.0.0_all.click) in build folder in your project dir. If not use step 4. or build with

   sudo clickable --output .
   

   this produces a .click package in current dir & tries to copy it to your phone via adb.

on the Ubuntu Touch phone
0) upload .click package to your phone somehow, if not uploaded yet

1. install uploaded .click package via Ubuntu Twaek (or some other way)
2. have fun

So I found out it is possible to select messages in thread fo mass operations. But not as expected. Instead long-hold anywhere on message line, you have to long-hold on left (or right) edge of screen, or somewhere between 2 adjacent message bubbles. It is not every time, but 1 out of 5 attempts is successful, and select mode is turned on.

It is only on my fp2, or are you experiencing the same behavior on your phones too?

@thrill_seeker Quick search on github.com/ubports found a folder for morph search engines implementation. The code in SearchEngines.qml scans through the dir for *.xml and uses them. So to add new search engine, add a new XML to the dir. You can look on the other to figure out how to write a new one. Good luck.

@Ghostrider said in Ubports with a jbl go speaker:

@advocatux I tried your suggestion, I've a terminal return : no space on /var/cache/apt/archives

This is normal for FP2, since last 2 or 3 OTAs. You can try to free some space using these commands extracted fom another post:

$ sudo mount -o rw,remount /
$ sudo rm -r /var/cache/apt
$ sudo tune2fs -m 0 /dev/loop0

If previous commands can't free enough space for /var/cache/apt/archives, you can temporary mount-bind the folder to somewhere else with more space, as described in this post:

$ sudo mkdir -p /userdata/system-data/var/cache/apt/archives
$ sudo mount -o bind /userdata/system-data/var/cache/apt/archives /var/cache/apt/archives/

After this you can try the @advocatux suggestion and it should work without free space problems. Maybe you will have more luck.

I tried the sudo ubports-qa install xenial_-_new-bluez, but it didn't finish and got stuck on bluetooth restarting. After rebooting, as I wrote in previous post, no improvement was observed. And because of the freezing on bluetooth restart, I couldn't revert things back with sudo ubports-qa remove xenial_-_new-bluez, so full image reinstall was needed. Has anyone more luck with this, as I had?

You can bind /var/cache/apt/archives temporary, using mount -o bind command.

# create dir in userdata space 
$ sudo mkdir -p /userdata/system-data/var/cache/apt/archives
# mount - bind
$ sudo mount -o bind /userdata/system-data/var/cache/apt/archives /var/cache/apt/archives/

Now your /var/cache/apt/archives has more space until reboot.

@advocatux said in Ubports with a jbl go speaker:

@Ghostrider there's a new bluetooth version for testing. If you know what you're doing and you are comfortable tinkering, you can give it a try. Run sudo ubports-qa install xenial_-_new-bluez. If after doing that your device gets stuck (because it's trying to restart bluetooth) you just need to reboot your device.

That new version works way better than the old one btw

I'm an FP2 & JBL GO user too and I can't use the speaker with Ubuntu Touch too. I've tried your advice and use new bluetooth version, but the outcome is the same. You connect to speaker, speaker beeps, that it is connected, but no music is allowed to play in music app, and you can't disconnect the speaker, or shut down bluetooth. You have to restart device.

However my other JBL Clip 2 speaker works with UT. And both, with the JBL GO speaker, are working with my Ubunu Mate 18.04 laptop.

@futurecn said in How to keep my python running in the container properly while the screen is locked?(N7 2013 flo):

I tried apt install screen on ubport and apt can't run.

You need to install screen into your libertine container.

$ libertine-container-manager install-package -p screen

Then you can run a screen session.

$ libertine-container-manager exec -c "screen"

NOTE: first time I got access permission error for /var/run/screen. You can fix this by logging into container and change permissions.

$ libertine-container-manager exec -c "/bin/bash"
root@ubuntu-phablet:/# chmod 777 /var/run/screen/
root@ubuntu-phablet:/# exit

After this, I was able to run a screen instance, deattach, bu no reattach success after libertine container was exited and run again.

# enter container, run screen and deattach
$ libertine-container-manager exec -c "/bin/bash"
root@ubuntu-phablet:/# screen -ls
No Sockets found in /var/run/screen/S-root.

root@ubuntu-phablet:/# screen -dmS worker
root@ubuntu-phablet:/# screen -ls
There is a screen on:
	30070.worker	(15.02.2019 17:57:40)	(Detached)
1 Socket in /var/run/screen/S-root.

# worker is in deattached state, reattach
root@ubuntu-phablet:/# screen -r worker

# Now I'm succesfully attaced to worker, using "ctrl-a d" to deatach again
[detached from 30530.worker]
root@ubuntu-phablet:/# screen -ls
There is a screen on:
	30530.worker	(15.02.2019 18:00:38)	(Detached)
1 Socket in /var/run/screen/S-root.

# exit container and reenter again
root@ubuntu-phablet:/# exit
 libertine-container-manager exec -c "/bin/bash"
root@ubuntu-phablet:/# screen -ls
There is a screen on:
	30530.worker	(15.02.2019 18:00:37)	(Detached)
1 Socket in /var/run/screen/S-root.
root@ubuntu-phablet:/# screen -r worker

Error: Cannot find master process to attach to!
root@ubuntu-phablet:/# 

Failed MMS redownload progress report:

Following PR's got some updates:

• https://github.com/ubports/telepathy-ofono/pull/20 - set delivery-status header to indicate error message
• https://github.com/ubports/history-service/pull/35 - set TemporarilyFailed status to error message. Before this, the status was default (unknown) and the error message was identified by empty message & attachment fields for incoming message. From now on, we can identify an error message by status and we can use the message & attachment fields to identify the error & other info (expire, ...) in future.
• https://github.com/ubports/messaging-app/pull/260 - The error message text & redownload button (visibility, enabled) depend on message status. The redownload button gets disabled right after click, for more responsible feeling.
• https://github.com/ubports/telephony-service/pull/20 - only redownload error messages with TemporarilyFailed status.

@lduboeuf Just made a PR, the code is in there.