Posts by inusasha

I see the SSD1306 is now using Adafruit_BBIO, which we are not support.

Leave 'radeonsi' in the list of GRAPHIC_DRIVERS and it is building, again.

Maybe a missing dependency, which is included in 'radeonsi'. Or an option, which is depending on the GRAPHIC_DRIVERS.

lrusak may know, more.

Sascha

Of course.

But will take same days. I has to test some other devices.

Sascha

I updated the DHT library to the newest version.

Can you try the new addon: virtual.adafruit-libraries-8.2.102.zip

Sascha

Hi Thomas,

good news first:

your code looks ok.

bad news:

this can be an problem in adafruit library itself. Is not the first library, with this kind of problem.

But i need more information, about your setup.

1. which LE version, you are running?

2. which RPi do you use?

3. output of `cat /proc/cpuinfo` from your RPi console

Bye,

Sascha

Know bug in debian build, too.

#891365 - make-dfsg: FTBFS with glibc 2.27: undefined reference to `__alloca' - Debian Bug report logs

do you use a SSD, too?

No a beautiful answer, but i accept it for now.

But i will remember you, when you hit such a problem

sorry for the late response. i am actual a bit out of time.

It is a normal problem, when you use static libraries.

This are copied into the binaries, you link against.

But in LE, we do not relink the binaries with new build static libraries.

The result is, the updated/fixed library, will never reach the final image.

(and we use much static libraries )

we do actual the same with the additional linux driver.

I found a dirty problem in our build system, while i word on the switched to mariadb-client.

Between two packages can exists hard dependencies.

This mean, a package had to rebuild, when a package needed package was rebuild.

I my case, the mariadb/mysql-client is embedded in the kodi.bin.

After a change at the mysql, it was rebuilded, but not the kodi package.

Result: the change never reached the final image...

I looked into the code, and found no solution, that is

• not a dirty hack
• run in other problems (infinite loops)

Solutions i had dropped:

• clean package, when hard dependency was rebuild
  => This can lead to infinite loop in same cases.
  eg on this dependency: x:host -> rebuild-package -> x:target
  when we clean at x:target, the x:host will build again...
• add same checks into the package.mk
  we will need this, every static library... too many packages for hacks
• always a clean build... NOOOOOOOOOO

My only left idea is: split up sources and build paths into different trees. And clean sources and build-paths independed.

So we can clean the target build, without forcing rebuild host build of a package.

But this will lead to bigger change. I do not know, if this is the right way.

Parts we will need:

• mark which dependency is hard
  maybe as a additional ":hard" suffix in the dependency list

Anyone same other ideas, opinions?

Sascha

Edit:

Possible new path-tree of build-path

build-xyz
+ sources 
|   + gcc
|   + binutils
|   + ...
+ init
|   + gcc
|   + ...
+ host
|   + gcc
|   + binutils
|   + ...
+ target
...

please, add me

package.mk description is a bit outdated

You need GitHub - adafruit/adafruit-beaglebone-io-python: Adafruit's BeagleBone IO Python Library, which is not part of adafruit-library addon.

Quote from tjost

import Adafruit_BBIO.GPIO

ImportError: No module named Adafruit_BBIO.GPIO

Which feature you are missing in our adafruit_gpio?

tjost

You had to replace the Adafruit_Python_GPIO from the adafruit-libraries addon?

We use already the "

GitHub - adafruit/Adafruit_Python_GPIO: Library to provide a cross-platform GPIO interface on the Raspberry Pi and Beaglebone Black using the RPi.GPIO and Adafruit_BBIO libraries." in adafriut-addon, only the last commit is missing (deprecate an old function).

tjost

Adafruit_GPIO.SPI is part of the adafruit-library package.

You have to set the PYTHONPATH to '/storage/.kodi/addons/virtual.rpi-tools/lib:/storage/.kodi/addons/virtual.adafruit-libraries/lib'

before the import lines:

import sys
sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib')
sys.path.append('/storage/.kodi/addons/virtual.adafruit-libraries/lib')

tjost: which LE version, you are running? 8.0, 8.2 or 9.0 (devel)

I had build 7.95.2 in a docker container with debian-stable (with linux 3.16).
And the image is working, so i can confirm the usage of host headers for key-table.

i resume short the problems we found:

• with linux >= 4.6 the KEY_RIGHT/LEFT_UP is already defined.
  breaks the function of the right and left button
  
• the lirc-devinput build uses the linux headers from the build-host
  
• in the first boot, the lircd services, does not start.
  so remote is working, only after a second boot.

Sascha
PS: i need a faster build system

sounds great.