debian testing: 2014-10-08 (Jessie Snapshot)

Howdy!

I just pushed out another round of images for testing.

For wheezy, mostly fixes, most of which have just been pushed to the repo, so:

sudo apt-get update; sudo apt-get upgrade

bone101 works again ( http://beaglebone.local/Support/bone101/ )
Still one blocker with jekyll, so it's not the head version of the
bone101 repo yet

Now for Jessie...

With a big Warning, Jessie isn't frozeen yet...

https://release.debian.org/jessie/freeze_policy.html

So anything packaged could still be taken away.

Desktop: lxqt 0.7.96 + qt 5.3.2
Kernel: 3.14.19-ti-r28 + sgx modules
Init: systemd
Network: connman + cmst
Bugs: cloud9 doesn't like jessie's tmux, so the html terminal console
isn't working.
(yes flasher only, I was running late...)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-10-08

3.8 -> 3.14 transition:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14

Note, rsync is still running, so not all images have been pushed out
yet as of (10:44am central time)

Regards,

Now for Jessie...

Hooray!!!

With a big Warning, Jessie isn't frozeen yet...

Jessie Freeze Policy

So anything packaged could still be taken away.

Desktop: lxqt 0.7.96 + qt 5.3.2
Kernel: 3.14.19-ti-r28 + sgx modules

Is anything else required to get the sgx working?

These instructions seem quite a bit outdated:
http://elinux.org/BeagleBoardDebian#SGX_Drivers

IIRC there are some library blobs that cannot be redistributed? Or do
they just not comply with the DFSG?

Now for Jessie...

Hooray!!!

With a big Warning, Jessie isn't frozeen yet...

Jessie Freeze Policy

So anything packaged could still be taken away.

Desktop: lxqt 0.7.96 + qt 5.3.2
Kernel: 3.14.19-ti-r28 + sgx modules

Is anything else required to get the sgx working?

These instructions seem quite a bit outdated:
BeagleBoardDebian - eLinux.org

Thanks! THis is now fixed:

http://elinux.org/BeagleBoardDebian#SGX_BeagleBone.2FBeagleBone_Black

IIRC there are some library blobs that cannot be redistributed? Or do
they just not comply with the DFSG?

So it's the "imgtec" demo's that cause the license issue. Till TI
physically separates the two into a lib & example download package i
can't do nothing about packing..

Regards,

Thanks! THis is now fixed:

BeagleBoardDebian - eLinux.org

When following the directions exactly, it fails because the
sgx_create_package.sh script can't source the ".CC" file. It looks like
this is created by the scripts/gcc.sh when downloading the compiler, but
that doesn't happen unless you build the kernel first.

IIRC there are some library blobs that cannot be redistributed? Or do
they just not comply with the DFSG?

So it's the "imgtec" demo's that cause the license issue. Till TI
physically separates the two into a lib & example download package i
can't do nothing about packing..

Can't the required user-mode library code be distributed without the
examples once it's all compiled and linked? Or am I missing something?

It _has_ to be possible for someone to ship a device with the SGX
drivers enabled. Is it just not possible to make a working image
legally downloadable? It seems like that would cause issues with
commercial folks trying to do on-line firmware updates!?!

Thanks! THis is now fixed:

BeagleBoardDebian - eLinux.org

When following the directions exactly, it fails because the
sgx_create_package.sh script can't source the ".CC" file. It looks like
this is created by the scripts/gcc.sh when downloading the compiler, but
that doesn't happen unless you build the kernel first.

I tried to cheat by just running scripts/gcc.sh to download the
compiler, but when I ran ./sgx_create_package.sh again, I got:

charles@dozer:/home/maker/ti-linux-kernel-dev$ ./sgx_create_package.sh
Verifying: Graphics_SDK_setuplinux_hardfp_5_01_01_01.bin
md5sum match: 94acdbd20152c905939c2448d5e80a72
Graphics_SDK_setuplinux_5_01_01_01 is installed
Cloning into /home/maker/ti-linux-kernel-dev/ignore/ti-sdk-pvr...
remote: Counting objects: 1205, done.
remote: Total 1205 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1205/1205), 1.90 MiB | 1.29 MiB/s, done.
Resolving deltas: 100% (555/555), done.
Branch tmp-build set up to track remote branch 5.01.01.01-ti from origin.
Switched to a new branch 'tmp-build'
Starting: copying files from the SDK
Copying: es8.x to build dir

ERROR: Run: ./build_kernel.sh first

So it seems like you should just add ./build_kernel.sh to the directions
on the elinux page. :slight_smile:

This works. :wink:

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/dd1f919b37d76493e1cc33955b1b97c351dab8be

Regards,

This will still be true during the freeze: non-ley packages that
have Release Critical bugs or depend on packages with RC bugs will
be removed from jessie.

https://release.debian.org/jessie/freeze_policy.html#autoremovals

[shameless promotion]

on the other hand, if something you need has a RC bug you can help
fixing it, there is no need to be a Debian Developer or anything.

You can join a Bug Squashing Party, if there is one in your area,
or you can just work from the confort of your home by following
the BeginnersHOWTO tutorial (up to the "Upload patch" step)

https://wiki.debian.org/BSP/BeginnersHOWTO

https://wiki.debian.org/BSP

[/shameless promotion]

I went ahead and built the kernel first, which worked.

I did have to "sudo ./OGLES2ChameleonMan", but IT WORKS!!!

This is totally awesome, Robert, *THANKS* for all the work this has taken!

...now I need to see if I can get the 3.14-ti kernel working with Xenomai.