I apologize if this is a dumb question, but how does compatibility work when installing packages? I've been able to install packages on my new Pinebook Pro (Ubuntu MATE) using either apt or the .deb package manager. Every now and then, some of these installs fail. My question is what is required for an Ubuntu application to be able to run on the Pinebook Pro? Did someone have to specifically compile it for the right CPU architecture? And if that is the case, are we significantly limited then on what can run on the Pinebook Pro?

If there is a good reading material that explains this in detail, I'd appreciate a link or if you point me in the right direction.

Thank you!

This morning I found that both plastic spacers at the hinge corners had fractured. These are part of the physical design of the laptop and should be replaced.

I measured the spacers with digital calipers and found the height of each to generally be 1.3 mm, with the inner diameter of the hole to be about 2.2 mm. A request in the #pinebook IRC channel for the design dimensions did not get a response, so I am using the dimensions as measured.

I sourced two different sets of spacers from the local hardware store. Each set had these characteristics:

Material: black nylon
Height: 1.5 mm
I.D.: 3.4 mm

Material: fiber
Height: 1.4 mm
I.D.: 3.9 mm

I selected the black nylon spacers. Although slightly taller than the original, the inner diameter is slightly smaller which should result in slightly less stress to the magnesium case should the screws be slightly over tightened.

I installed them by applying silicone adhesive to one side of the spacers and attaching them to the metal hinge assembly, centering the opening over the screw holes.


UPDATE: 26 DEC 2019

The ethyl cyanoacrylate adhesive (think super glue) is definitely the better choice for mating the spacer to the metal surface of the hinge. The spacers are staying put.

UPDATE: 07 DEC 2019

The nylon spacers are working great. The silicone adhesive was not that effective, the spacers did not stick very long. I have cleaned them and the metal mating surface with isopropyl alcohol and am testing an ethyl cyanoacrylate adhesive now.

Started thinking about this when the IR Chat turned to distros just now. I am pretty much distro agnostic - hope my contribution to Braveheart will be to get it towards being a daily driver. At least for me!

My prejudices include:

• - despising big corporates (Apple, Alphabet, Microsoft, IBM ...)
  
• - a dislike for any kind of eye-candy that soaks the resources I cherish (memory, bandwidth, ...)
  

• - able to make/receive calls
  
• - able to send/receive SMS
  
• - a workable browser (ideally Firefox) to cover the few Android apps I actually use
  
• - able to send/receive Signal messages - calls would be a bonus.
  
• - able to tether the mobile broadband to other devices, ideally via the USB-C
  

I think it would be rather nice to get an indication on how many phones that has been preordered. Exact numbers is less important but ballpark figures to get a feel for how much demand there is for a device like this one.
Does anyone else care about numbers like that?
Would that be at all possible or is it corporate business secrets?

...the phone run down the clock.

There I was at 8pm, but it seems Braveheart is still in the dressing room.

I will keep looking and hope I won't miss out on the chance to order one.

Hi PineTime Community: Here's my new article to get us hacking the PineTime faster... I'm happy to take any questions since this is very familiar ground to me... nRF52 on Visual Studio Code 

Sneak Peek of PineTime Smart Watch… And why it’s perfect for teaching IoT

UPDATE: Pine64 has just sent me the Hynitron Touch Controller Reference Code. Very useful for coding the touch controller!

Other relevant articles:

My port of Mynewt OS and Rust to PineTime is based on an earlier nRF52 article...
Coding nRF52 with Rust and Apache Mynewt on Visual Studio Code

You can run Bluetooth Mesh on PineTime. The code should be similar to this article...
Bluetooth Mesh with nRF52 and Apache Mynewt

Is Visual Rust useful for PineTime? If you think so, I'll port it to PineTime...
Visual Embedded Rust Programming with Visual Studio Code

Check the rest of my articles on IoT, Embedded Rust, STM32 Blue Pill, Visual Studio Code, GD32 VF103 on RISC-V, ...
https://medium.com/@ly.lee

If the Medium paywall blocks you, use the free access links from my resume...
https://lupyuen.github.io/

No pinephone for us?
as I expected, a lot of people want what you produced.
I hope I can order one.

Hi Everyone.

I'm one of those insane people who dared compiling everything on PBP. It actually hasn't been too bad. I've built the Manjaro kernel and everything I need. The problems were pretty much the same as those other people experienced here. However, I'm not sure about these:

1. Linux kernel load time is pretty long. dmesg indicates a 1 minute delay prior to executing
"cryptd: max_cpu_qlen set to 1000".
2. WiFi issue is present, although I wasn't able to associate it with high CPU load. For now I'm using a USB Ethernet adapter.
3. Sound issue - present, but I haven't tried the recent DTS fix yet. What I tried was using a USB sound interface (a 10 years old iMic). It worked fine. No noises or anything.
4. The main issue: flickering widgets in XFCE (checkboxes, especially). I thought it was only relevant to GTK applications, but Firefox appears to be ok. I'll continue playing with it. Another thing: upon launching Libreoffice, xorg begins using 100% CPU (single core) and the app becomes very slow and pretty much unusable.
5. Another one: the clock gets reset on every reboot.
6. Not sure if hardware video acceleration works. Does anyone know how it works? Does Panfrost have it implemented?

My software is:
Kernel 5.4.0-rc6-MANJARO-ARM
Mesa-19.2.4 (I did specify VIDEO_CARDS="panfrost" in make.conf)
Xorg-server-1.20.5
xfce-4.14-r1
Libreoffice-6.3.3.2.

If anyone tried to do what I did, please share your experiences

Hi all,

We just received the trackpad / keyboard firmware. If it checks-out and we're happy with it I'll try to push it by end of the day on Monday.
I'll update this post in the event that something isn't right with the firmware.

[update Nov 15] Testing the firmware today. The compiling and flashing processes are rather involved, especially the latter, so this will need to be automated as much as possible.

[update Nov 16] We're still working on getting everything functional. As we're going though this process we're also figuring out how much this can be automated for end users. Its taking some time because the source code + documentation we're working with aren't exactly great.
Huge shout-out to @xalius for doing much of the leg-work on this; fixing and making stuff work.

Once we've got it all figured out on our end, I'll make sure to write up proper documentation for the process before pushing it to end-users, including steps to take if you mess something up.  

For end users the process will likely consist of running 3 scripts in a sequence. Out of the 3 stages the only really tricky one is number 2 as it requires you to identify the trackpad bus and device.

Here are the stages:

• Stage 1) puts the keyboard in a state that allows you to bypass it for trackpad flashing
  
• Stage 2) flashes new firmware to the trackpad
  
• Stage 3) flashes keyboard firmware so it is usable again