As an answer to a my ultimate question of life, the universe, and everything, Deep Thought suggested me to reach 42 stickers:

@prog-amateur I gave you the -1 "like" not because of your question, but because your imply, without knowing its purpose, that it "allows redirections to Canonical servers" coming to suspect a GDPR incompatibility and ending by asking what else (not if else)" is sent as a telemetry from OS/app to whatever company/organization". All after the initial sentence, resuming or reminding the Ubports sentence in the website about the care about freedom of choice and privacy, as it were a lie, and asking "clear answers" assuming the ubports foundation has ever in some way given unclear or ambiguous answers or/to hide the truth behind them or has reason to do so..

so that -1 is for the chosen style and the tone of the question that I personally perceive and didn't like, not for the question. about your question, because it is a good question, this was my answer: https://github.com/ubports/morph-browser/pull/250

ps: I'm not in any way endorsed by or affiliated with ubports and what I say may not be what ubports thinks

IMHO it's fundamental that the icon resemble the original one obviously avoiding any trademark infringing. I think we can use the original "3D-ish" icon as a base and colors (so to keeping similarity with the official one and make it discernable from the Unav one) and apply on it some of the UT official graphic guideline/style so to avoid trademark infringing.
for example something like:

and

they both are in origami style. in the first the geometry and the style of the paper airplane is different from the original/official logo (it'is another paper airplane ;)). the second is more similar in terms of geometry but the teleport effect make it whole new icon.

Hi guys,
as a way to spread UT/UBports I think could be also useful to make more famous our logos/mascot to the world.
One of our main communication channel is based on telegram that is the perfect platform for some of our marketing purpose for various reasons:

• it is used on smartphonens

• it is supported on UT (thank you guys!)

• it is used by people prone to try something different even if it is (still) less used than whatsapp

• it has stickers

I started to make a little collection of yumi images based on this guideline and using telegram guidelines
Our current sticker pack has "only" 13 images so I tried to expand it (actually I've 35) and substitute some of them with new one, :
eg

vs

A more completed pack is more probable being used in our and other telegram channels spreading the world Yumi mascot and UBports logo.

So now I've some questions for the UBports Foundation:

• Could this be useful for you?
• Am I infringing your trademark
  • do I need an official approval?
    • do I need only an official approval for the whole stickers pack or
    • do I need an official approval for each sticker?
• do exist already a sticker project/place where I can contribute?
  thank you!

because this is a more stable configuration than a circle
Jokes aside, when I made this symbol I was thinking of the third generation of Ubuntu DE (after gnome and unity7, our beloved unity8) and

• to the three elements of the project:
  • the foundation,
  • the community,
  • all the mainstream projects,
• and to the three levels of the system:
  • the device,
  • the OS,
  • the applications,
• or
  • the hardware,
  • the software ,
  • the user.

new two stickers are coming:

this is for the next UT code cleaning

and this is for the next features requests

@Flohack I don't have to motivate the people.

I don't think you can look in his eyes and say to him "no"

Pine64 choosed to ship pinephone with Plasma Mobile on Manjaro ARM base from this point on.
Q1 are you surprised?
Q2 What do you think is the motivation behind this decision?
Q3 Is manjaro/plasma seen as a more robust/mature project or as a more enjoyable experience or was only a problem of (missing) comunication about advancement in the development of ut for pinephone ?
I know we are very friend and bound togheder with the manjaro team ( I too LOVE their os) but a friendly competition could also be healthy...so maybe... Q4 are you thinking a B plan/strategy to compensate/answer to this situation?

@UBportsNews I have already contributed here and there but have done only little things. I'm studyng how to develop on UT but I'm only an hobbyist so I'm not a so good investment...
But, I found that there are at least two other italian UT users near me (less than 30km, and they are very active in the Italian UBports telegram group) and I'm already thinking of share with them my rpi4 to help each other in the develop and test process. Also in Mezzago (a town 7km from my home) there is a little but lively linux community that could be interested in the UT and its app development.
Last but not the least I directly know and I'm friend with many guys from informatics engineering (from the university Politecnico di Milano) with which I collaborate in the Openstreetmap project and wikimedia foundation and that could be interested in software development on more exotic platform like UT

Pine64 choosed to ship pinephone with Plasma Mobile on Manjaro ARM base from this point on.
Q1 are you surprised?
Q2 What do you think is the motivation behind this decision?
Q3 Is manjaro/plasma seen as a more robust/mature project or as a more enjoyable experience or was only a problem of (missing) comunication about advancement in the development of ut for pinephone ?
I know we are very friend and bound togheder with the manjaro team ( I too LOVE their os) but a friendly competition could also be healthy...so maybe... Q4 are you thinking a B plan/strategy to compensate/answer to this situation?

@kaizen Amazig work! goood job! I really like it

Can I suggest something from a non-technical POV?
At the top of the sketch you have inserted a truly explanatory schematization (we need to add the app layer). I suggest to keep the same order for the component listed in the first "about the project" section.
Also in the second "about the project" you have used new therms and this could be confusing for someone like me:

• where is the lomiri layer?
• what is this new midleware? is it the halium + core layer?

A better way to keep all more intuitive as possible (but i don't know if it is possible) is to make all the information hidden unless we touch on the desired section: if you touch the "lomiri" layer on the top scheme it opens in the bottom the "Lomiri project" of the first "about the project"
If you touch the "halium" layer on the top scheme it opens in the bottom the "halium project" of the first "about the project" with also the explanation you putted in the second "about the project" section
and so on...
also all element in the second "about the project" should be clickable (not the software ) with direct link to the doc or their github/lab page.

my2cents.

Aury

@alan_g
Oh! so I totally misunderstood that command...reading the documentation seemed to me git pull already encompass a git fetch and a git merge. also I tried the git pull after the make command and that confirmed the local branch was up-to-date. ok, i will try again after the fetch. thank you.

@jonius i tried again after the git pull but obtain the same error

during the QtMir build with make -j 6 all test I also had the fatal error described by @jonius :

[ 87%] Building CXX object tests/mirserver/ScreensModel/CMakeFiles/ScreensModelTest.dir/screensmodel_test.cpp.o
In file included from /home/aurelio/qtmir/src/modules/Unity/Application/mirsurface.h:35:0,
                 from /home/aurelio/qtmir/tests/modules/SurfaceManager/surface_manager_test.cpp:22:
/home/aurelio/qtmir/src/modules/Unity/Application/mirbuffersgtexture.h:20:30: fatal error: miroil/mirbuffer.h: Not existing file or directory 
compilation terminated.
tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/build.make:62:  instruction set  for the target "tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/surface_manager_test.cpp.o" failed
make[2]: *** [tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/surface_manager_test.cpp.o] Error 1
CMakeFiles/Makefile2:2146:  instruction set  for the target "tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/all" failed
make[1]: *** [tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/all] Error 2
make[1]: *** waiting incomplete process....

and after that

[ 95%] Built target applicationmanager_test
Makefile:138: instruction set  for the target  "all" failed
make: *** [all] Error 2

@flohack thank you! Now it is more clearer.
Now my only doubt is what is the scheme in an "open hardware" device like pinephone or librem5 and what closed source parts still have to be integrated in UT (preventing UT to be fully FSF compliant.)

PS: I don't find that very informative scheme in our doc...I think that could be usefull to understand what UT is and what is/must be touched by halium and the port process. why that is not in our documentation?

@flohack I already know-ish almost all of these things my doubt was about the "position" of this system.img/abstraction layer(I though halium was covering the bottom red and blue areas in a "kernel-land"and UT was over it)
I already know UT needs (as any other SO) these blobs to run on "android device".
Replicant does not seems to use these services/daemons and so their os is always missing something in any device.

@kugiigi I only copy-pasted what they wrote on their website

I don't think they are purer that other distros on pinephone or librem5 and I suspect they also know that but avoid to talk about this.

@fla I already wrote them for another reason (make microkernel an HPP) I was only waiting to understand what is the foundation and community will about all this (so also to gain some time between the two email)

but I fear UT is not listed in the HPP because, as said by Replicant:
" Many mobile operating systems are mostly free software (e.g. Android, Firefox OS, Ubuntu Touch, Tizen), as they use the Linux kernel, a free framework and ship with free base applications. However, the user-space hardware abstraction layers are for the most part proprietary (it varies from one device to another) and they also ship with proprietary loaded firmwares for various integrated circuits. Every piece of proprietary software running on the system is a risk for privacy/security as they can offer remote access back-doors and compromise the rest of the system."
And also
" None of these mostly-free systems have a clear policy to reject proprietary software and not advocate its use, except for Replicant. "

PS: are we using a user-space abstraction layer? I thought the abstraction layer was between the hardware and the kernel, so a kernel-space abstraction layer

I see few question for this Q&A so I'll do more questions... feel free not to answer them all

with the removal of Oxide in the OTA 16 you said in the past the system image size will be lightened.
Q1: how many megabytes will be saved?
Q2: are you going to fill (part of) the saved space with something else or for the moment are you simply aiming to distribute lighter system images.

With the upgrade from Qt 5.9 to 5.12 we are a step closer to the transition from 16.04 to a 20.04 base.
Q3: what remains to be done to make the switch?
Q4: is the switch from upstart to Systemd one of these steps?
Q5: will be there devices that will not support the newer kernel (and/or init system)? what will happen to them?

I've always been curious to understand what steps are required when porting an app to new libraries or a system from one kernel to another
Q6: can you please describe us how the transition from a base to the next takes place, or pointing us to an explicative documentation/howto?
Q7: is there anything a community of ordinary users (non-programmers) can do during this process to help?

ps: I wish you Merry Christmas and Happy New Year

@libremax seems to me canonical has complied with the FSF terms years ago as said in the first paragraph. ubports is going to be also more and more independent from the canonical policies and trademarks;
this is not really a situation like us against PureOS so give to UT and endorsement from FSF don't prevent a FSF endorsement also to PureOS or viceversa.
Last but not the least your statement seems to contradict what ubports stated about ut: "Ubuntu Touch is 100% community driven and independent." so why UT should have a complicated relationship with FSF because of a past ( more than 5 years ago) complicated relationship between Canonical and FSF?

Have ubuports already tried to apply ? is it a your guess/fear or does already UT been refused by FSF?