Some Good News!!! Just wanted to let everyone know my interest is coming back (Canonical just landing us in the (some expletive here) really put me off for a while) .

Anyway I'm going to start working on getting the latest Dekko into the openstore for the legacy devices. It's going to take a few weeks at least to get there and it will most likely only have a subset of the current features as it is going to require a bit of a rework of the code. But you will be able to do all the basic mail management tasks.

Does anyone here have any objection to it being an unconfined app?

Once i've got some of the details ironed out I will set up a better location for discussing Dekko's features and plans going forward. As I will need as much input/ideas as possible. I don't think spamming the ubports forum is the right place for this.

In the recent restructuring of the project a new website has arisen, which you can find here. You will find links to the issue tracker, forum etc... so if you have any ideas, feature requests or want to get involved then head on over.

Ok so here my 2c...

I fully support the move to GitLab, but not for any real reason to do with Microsoft acquiring GitHub (although i do get others concerns). For me it's more about the project management aspect of UBports.

GitLab supports groups and subgroups so it's easier to organise our 300+ repositories, making it easier for everyone to find their way round, and also visualise the different parts of the project/platform and how they fit together. There could be groups for Unity8, System Apps, Core Apps, Packaging, Infra, Documentation, Tooling, Working Groups, Experimental... the possibilities are endless but each group is easy to digest and only contains repos specific to each groups goals. On GitHub you just get a giant list of all repos and you almost have to remember repo names as paginating through the list is just painful if you can't.

GitLab supports issues, milestones and kanban boards at both group and project level. This makes it really easy to organise per project as well as at the group level and get a higher level view of what's going on. You can also move issue between projects which is handy!.

GitLab CI would also be a great thing to have at the project level. Each project could define it's own pipeline for merge requests, doc generation, building and publishing clicks to open-store etc... and not have to use an external tool like TravisCI. Jenkins is probably still the right tool for the building ubports repo and could continue to build debs on changes to master, xenial, bionic branches. But allowing a project to define it's own pipeline, even attach their own hardware via a dedicated gitlab runner in my opinion is quite a powerful thing. Members of the community could even offer up spare hardware and create a pool of runners for UBports

GitLab releases new features nearly every month, so things can only get better.

GitHub is serving it's purpose right and doing the job ok, so it definitely doesn't need to be rushed if a decision is made to move.

Please note Dekko in the openstore is not ready for daily use, is still very much experimental and still very much geared towards being used on desktops. So please don't expect too much from it right now

p.s POP3 will be coming in the next update

@zubozrout something like this should work

$ docker run -it -v $PATH_TO_CLICK_DIR:/clickdir clickable/ubuntu-sdk:16.04-amd64 bash
$ apt install click-reviewers-tools
$ cd /clickdir
$ click-review my.click

@Phil-UK Dekko never stopped being developed or supported. Just the old code base was deprecated.

@aury88 No you can either create a Gitlab account or use an existing google, twitter, github or bitbucket account to sign-up/register

Rather than go forking Dekko, if someone sends me a patch that get's click support back in shape. We can see about doing a release. Just because I'm personally no longer supporting click, doesn't mean someone else can't jump in and take the baton on that side and keep up the support. Patches are always welcomed!

If you are just wanting to flash devices and not develop for them, then you should be fine using the UBports Installer on Debian. It is packaged as an AppImage

I'm not really sure what you are trying to achieve with this topic? Would you mind expanding on it a little more please?

Is your intention to document application development for unity8 / Ubuntu Touch?

Some notes:

Ubuntu "snaps" support any programming language as it's just a packaging format, and are not limited to what you have documented above. Also yaml and soap are not programming languages... one is a data serialization format for configuration files and the other is a protocol specification for structured data.

The HTML5 sdk hasn't been maintained for a couple of years now and shouldn't be considered an option unless somone wishes to bring it up to spec with the QML UI toolkit.

There is the Ubuntu React Native framework that web devs could use to bring there apps to Ubuntu https://github.com/CanonicalLtd/react-native/

@hoh61 That's not correct. Applications are run exactly the same now as they were in the original ubuntu image. Just confined processes using apparmor. As you noted though there is an minimal android container which is the only usage of lxc (unless you install anbox).

@aury88 No you can either create a Gitlab account or use an existing google, twitter, github or bitbucket account to sign-up/register

Ok so here my 2c...

I fully support the move to GitLab, but not for any real reason to do with Microsoft acquiring GitHub (although i do get others concerns). For me it's more about the project management aspect of UBports.

GitLab supports groups and subgroups so it's easier to organise our 300+ repositories, making it easier for everyone to find their way round, and also visualise the different parts of the project/platform and how they fit together. There could be groups for Unity8, System Apps, Core Apps, Packaging, Infra, Documentation, Tooling, Working Groups, Experimental... the possibilities are endless but each group is easy to digest and only contains repos specific to each groups goals. On GitHub you just get a giant list of all repos and you almost have to remember repo names as paginating through the list is just painful if you can't.

GitLab supports issues, milestones and kanban boards at both group and project level. This makes it really easy to organise per project as well as at the group level and get a higher level view of what's going on. You can also move issue between projects which is handy!.

GitLab CI would also be a great thing to have at the project level. Each project could define it's own pipeline for merge requests, doc generation, building and publishing clicks to open-store etc... and not have to use an external tool like TravisCI. Jenkins is probably still the right tool for the building ubports repo and could continue to build debs on changes to master, xenial, bionic branches. But allowing a project to define it's own pipeline, even attach their own hardware via a dedicated gitlab runner in my opinion is quite a powerful thing. Members of the community could even offer up spare hardware and create a pool of runners for UBports

GitLab releases new features nearly every month, so things can only get better.

GitHub is serving it's purpose right and doing the job ok, so it definitely doesn't need to be rushed if a decision is made to move.

You would need ~/.cache/dekko2.dekkoproject and ~/.local/share/dekko2.dekkoproject

@zubozrout ahh i wonder if click-review was updated in the ubports archive to allow the new framework. Try dropping the framework to a 15.04 one and run click-review to see what the real errors are and then bump it back up before pushing to the store as the framework most likely isn't the issue.

@zubozrout something like this should work

$ docker run -it -v $PATH_TO_CLICK_DIR:/clickdir clickable/ubuntu-sdk:16.04-amd64 bash
$ apt install click-reviewers-tools
$ cd /clickdir
$ click-review my.click

@jardenblack26 First step would be to check for any errors in ~/.cache/upstart/dekkod-notify.log

Also for apps using pyotherside you no longer need to include pyotherside and libpython3.4m in your click package. These are now available in the rootfs, so make sure to remove them from your click before building for xenial.

@pavejon have you enabled the "less secure apps" option in your google settings? https://support.google.com/accounts/answer/6010255?hl=en or if you use two factor authentication you can get an app specific password instead and use that to authenticate.

@ukphil No there's no issue. just gmail is a special cupcake and uses a different (and still to be standardised) SASL mechanism than what is normally used by email servers. There are pros & cons to using it but it will be implemented in Dekko again at some point. Just not high up my priority list right now. Patches welcome though