@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

Also note it works a little differently now in the updated script. It will create an $HOME/UBports directory on the host which it will mount as the $HOME in the container. It also symlinks any ssh keys you might have on the host and copies over the .gitconfig. This way it keeps the container home seperate from host but can easily be accessed on the host. If you want to change the directory used for the container you can do

export UBPORTS_HOME=$HOME/Custom/Path
./ubports-sdk-setup -d

@fulvio Hi there. So first you don't really want to change the target especially 17.10 as the sdk is uninstallable on that release. (as per this thread) It default's to 16.04 which runs the sdk fine and is what we will be targeting in the near future for our devices so it makes sense to just leave that as is. I added the target option in case someone wanted to use an older 15.04 cloud-image. So i would suggest to leave it as is and just run ./ubports-sdk-setup -d

I see the bug in check_uid_gid you can just remove the exit 1 from the if block.

I've just fixed that and pushed to github, so if you pull the latest and try again and see how it goes.

It would appear not https://open.uappexplorer.com/?sort=relevance&search=slack

@jimmiejohnsson84 githubs free for public projects. You only have to pay for private projects

For the folks that like living a little on the wild side you could try this . It uses a xenial lxc container to run the sdk but it uses qtcreator directly from upstream qt as it's the only one that worked ok from inside the container. Feel free to swap that out in the script though.

For the most part it works ok, there isn't USB pass through so you would still need to use clickable on the host. and for sound you need to enable networking for local servers in paprefs. It simply allows you develop build and run UT apps on your desktop if your not on 16.04 already.

I still need to add better documentation but there should be enough to get you going. Or ping me if you hit any issues.

@gnu-mobile said in Wanted? Email-chat compliant Dekko. Messaging with UBports and beyond?:

I made a mockup from the screenshots, now. Thought of a new button or virtual folder that lists the current chats in the left pane (the screenshot happens to be from delta chat's long-press-on-chat feature (for archiving or deleting). The right pane shows the opened chat with the messages and text input line.

If both re-implementing all the things in Dekko as well as switching backends is too much work, maybe it is easiest to just embed deltachat within Dekko.

I'm not sure what you mean by "embed deltachat"? It's not really possible to just embed an android app like it's an iframe or something.

This layout isn't possible with dekko's plugin architecture. Where you have placed the delta chat icon in the left side action bar is used to determine which plugin is displayed. So there is a mail plugin which loads the mail views in the reamining window area to the right. It will be the same for calendar, contacts etc when they are complete.

The two options i can see from this are

1. Keep the delta chat icon in it;s current location and create a new view (well it will actually be a plugin) that will contain the chats list and chat view but won't have the folder list on the left side. as it's really not needed in this context.

2. Create a "Chats" virtual folder in the left navigation panel. Possibly below "All inboxes" which when selected would open the chats list and chat view like in your mockup. This approach though would mean adding additional complexity to the views that might cause some bother.

Personally i'm more in favour of option 1 as it could then be included/installed as an optional plugin. In the future there will be an extensions store but until then it could be shipped with dekko and just need to be enabled by the user.

@flohack Advising users to add a thumb-up reaction to an issue they would like to see priotitized, is a possible way voting could work. Then you can filter by reaction https://github.com/ubports/ubuntu-touch/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@gnu-mobile Firstly, thanks for trying to gather some interest around your idea.

If this was to be implemented in Dekko it wouldn't use the deltachat-core library, as that would be a really intrusive change that will take alot of effort for a library that only supports a subset of what Dekko currently provides. I would rather implement the delta chat specification in Dekko's current libraries as it wouldn't be a massive amount of work to add. Autocrypt seems very promising and i'm considering adding that as the first pgp implementation for Dekko, I really like this idea of "opportunistic encryption" that gets out the way of the user. Really nice!

I think the big issue would be how to separate a chat view from the standard mailbox views. Dekko supports adding filter plugins which process messages before adding them to the mailstore. So we could possibly filter for chat messages and apply flags so they appear in a virtual "Chats" folder. The chat messages would be left in the Inbox folder so they can still be accessed from a standard MUA, and filtered out of Dekko's Inbox views to try and make a clear separation of standard email vs chat threads.

I'd be interested to see some mockups of how you (or anyone else) think this should look in Dekko.

Regards

Dan

I have a pull request for this ready here. Hopefully we are not too late to get it in for OTA-3