With full steam into the new year!


holy cow, it's beautyfull!!!
and you allready have the packaging-shots/artwork for this black semi-glossy cardbox with the pyra-in-the-dark front shot on the upper side and the pyra-from-behind shot on the other one. :)
 
Thanks for those pictures Ed, The unit looks really sturdy. Is it?
Though I still want a cream/off white or dark colored unit, the clear case does look nice with all those colors shining through I have to admit
 
  • Like
Reactions: rSl
@hns:
Is systemd-shim [1] installed on your test system? It's been a while since I made these tests, but I believe that the lxsession popup should disappear if this package is installed.

[1] https://packages.debian.org/search?...&searchon=names&exact=1&suite=all&section=all

Ah, would be good! I have found several tips and tricks but they recommended to edit files or remove packages that don't even exist on our system...

This package is a little strange because apt-get install says that it can not be found in the standard Jessie repository.

And I have tried to install it manually (download + dpkg -i) which went fine, but did not remove the popup.
 
If you do end up making black (or dark grey) and clesr cases, would it be possible to order a Pyra in a custom color scheme if you buy a second case with it? I don't know if that would make the mass production too slow... a black Pyra with only the backside of the lid (and the battery cover?) in transparent would be cool. Sort-of like the infamous two-colored Pandora, just better.

Can you actually make out the outside LEDs' light from the screen's side in daylight? That'd be cool for notifications.
 
You could also easily modify your Pyra yourself, as the Case Design now is much easier than on the Pandora:
You can access the Display whitout opening the upper half, and you ditnt need to worry much about the Display Cable because it's lot tougher than the Pandora ones..
So buy a Pyra and some case parts..
 
Looks gorgeus. Really seems a production unit.

I can't wait to see videos of developers trying things in his Pyras.
 
I won't have the time to summarize everything about the meeting today (I've got plenty of work right now), but you can look at some pictures of one of the prototypes we built today.

OMG, I really, really want the transparent casing! Please!

Not only is it beautiful, but it is also a security measure: It is harder for third party to bug the device unnoticed.
 
This package is a little strange because apt-get install says that it can not be found in the standard Jessie repository.
This is most likely because you have systemd "blacklisted" via apt pinning by a file in /etc/apt/preferences.d/ that contains a record like this one:
Code:
Package: *systemd*
Pin: release *
Priority: -1
In that case no packages that have "systemd" in their name will ever be installed by apt.

But as I understand, your goal is not to get rid of Systemd altogether. You just don't want it to be your init system. In that case you don't have to be quite that strict. You can replace Systemd as an init system by SysVinit as described here [1].

And I have tried to install it manually (download + dpkg -i) which went fine, but did not remove the popup.
You're right. My memory was wrong. But it can still be done:

I set up a VM in which I installed a minimal Debian Jessie system (without Recommends or Suggests), removed Systemd altogether via apt pinning, installed a minimal x-server and lxde-core on top of that. I believe apart from the architecture (amd64 vs armhf) this should pretty closely match your test system.
The system showed the same popup. Then I installed systemd-shim but the popup remained the same. Then I installed systemd (which btw. does not automatically replace sysvinit as the init system) and the popup changed to something related to policykit. So I installed policykit-1 and the popup disappeared altogether.
The VM still uses SysVinit.


btw: I still believe you should do your testing with Stretch instead of Jessie. Stretch is already in soft freeze for some weeks and will enter hard freeze in less than two weeks [2]. So it's general behavior will not change much anymore. On the other hand it's still mostly identical to Sid, which means any changes you upstream (and eventually appear in Sid) should be applicable to Stretch.
Jessie is "well aged" by now and behaves differently in some ways. So any problems you solve there might need further work to be solved in the final PyraOS.


[1] https://wiki.debianforum.de/Debian_ohne_systemd
(Sorry it's in German, but I know hns will understand and my translation wouldn't improve it.)
[2] https://wiki.debian.org/DebianStretch
 
This is most likely because you have systemd "blacklisted" via apt pinning by a file in /etc/apt/preferences.d/ that contains a record like this one:
Code:
Package: *systemd*
Pin: release *
Priority: -1
In that case no packages that have "systemd" in their name will ever be installed by apt.
You are right! I simply did forget about this after setting up this Jessie image years ago when Jessie was fresh (btw. this work dates back to Etch...).
But as I understand, your goal is not to get rid of Systemd altogether. You just don't want it to be your init system. In that case you don't have to be quite that strict. You can replace Systemd as an init system by SysVinit as described here [1].

You're right. My memory was wrong. But it can still be done:

I set up a VM in which I installed a minimal Debian Jessie system (without Recommends or Suggests), removed Systemd altogether via apt pinning, installed a minimal x-server and lxde-core on top of that. I believe apart from the architecture (amd64 vs armhf) this should pretty closely match your test system.
The system showed the same popup. Then I installed systemd-shim but the popup remained the same. Then I installed systemd (which btw. does not automatically replace sysvinit as the init system) and the popup changed to something related to policykit. So I installed policykit-1 and the popup disappeared altogether.
The VM still uses SysVinit.
I tried a little but it still shows dependency problems. It complains about udev although it is already installed.
btw: I still believe you should do your testing with Stretch instead of Jessie. Stretch is already in soft freeze for some weeks and will enter hard freeze in less than two weeks [2].
Basically I am testing hardware and kernel and not rootfs features... This are things that others can do much better :)
Debian is here just the rig to trigger things in the kernel, because it is so easy to apt-get install user-space tools for every kernel interface.
And therefore it must neither be polished nor complete nor a basis for PyraOS (except for learning how kernel interfaces can work).
For example making GPS work needs a kernel driver to power on the wwan-module (we have it) which is controlled by rfkill (apt-get install rfkill). And then sending some specific AT commands to the module interface /dev/ttyACM1 so that the module starts sending NMEA on /dev/ttyACM3. We have a shell script that does demonstrate this procedure. Same for dialing a phone number, enabling WiFi, scanning Bluetooth, making the vibramotor rumble, turn on/off backlight, a daemon to combine the volume wheel with the twl6040 audio etc.
So any problems you solve there might need further work to be solved in the final PyraOS.
My main rule is: don't change working tools in the middle of a project (unless it is proven to solve a significant tool problem)
So I better postpone updating this test system to the time when Pyra is finished and Squeeze is official.
Then, there is time to switch to systemd and learn how to configure it for testing purposes (e.g. root ssh w/o password, ethernet gadget communication on USB, automounts etc.) for the next project.
 
I tried a little but it still shows dependency problems. It complains about udev although it is already installed.
I have a vague idea about a possible reason, but I don't want to jump to any conclusions without knowing more what's actually going on there.

I have a Cubieboard 2 running original Stretch. So if you could give me a link to download your test system or precise instructions on how to create it, I may be able to chroot into it and see what's wrong there.
I'm not an expert on systemd, udev or all the *kit stuff though. So it would probably just be trial and error, but at least it wouldn't be on your time.
 
I have a vague idea about a possible reason, but I don't want to jump to any conclusions without knowing more what's actually going on there.

I have a Cubieboard 2 running original Stretch. So if you could give me a link to download your test system or precise instructions on how to create it, I may be able to chroot into it and see what's wrong there.
I'm not an expert on systemd, udev or all the *kit stuff though. So it would probably just be trial and error, but at least it wouldn't be on your time.
Here it is:

http://download.goldelico.com/letux-debian-rootfs/

I usually use the 20170118-jessie-8.7-lxde.tbz

There is also a qemu-wheezy-vexpress machine which is used to debootstrap the newer images inside a chroot.
 
Would you rather have something rushed and not work right?

Patience, for most of us here this has already been a 3 year adventure.
I think it is more like 5 since the concept was being vetted with TI. Can't believe it has been that long but here we are. Just figured I'd post while the internet is still operating in the US.

Stellar work ED!
 
Would you rather have something rushed and not work right?

Patience, for most of us here this has already been a 3 year adventure.

Only 3 years? Many of us have been discussing a Pandora successor since before the first batch of Pandoras shipped.

This is a very compact and complex device with some pretty out there capabilities. It is quite an accomplishment to be in the final stages of hardware revisions.

Frankly, I think we all got VERY lucky that a community member had access to the simulation software. That alone probably shaved 3-4 additional iterations off of the CPU board development.
 
Back
Top