Differences between revisions 1 and 33 (spanning 32 versions)
Revision 1 as of 2013-03-13 13:55:09
Size: 1087
Comment: Dependencies Patchwork
Revision 33 as of 2017-12-20 00:09:52
Size: 11860
Comment: more dcmd
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:

<<TableOfContents>>

= Various packaging related things =

== debconf stuff ==

 *http://www.debian.org/doc/packaging-manuals/debconf_specification.html
 *http://www.fifi.org/doc/debconf-doc/tutorial.html
 *http://hezmatt.org/~mpalmer/talks/2002/debconf-use-and-abuse/view.pdf
 *http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbconfig-common-using.html

== Platform Specifics ==
=== Defines ===
As I always search for that while debugging KFreeBSD or Hurd build issues ...
{{{
gcc -dM -E -x c++ /dev/null # for C++
gcc -dM -E -x c /dev/null # for C
}}}
 *[[http://nadeausoftware.com/articles/2011/12/c_c_tip_how_list_compiler_predefined_macros | C/C++ tip: How to list compiler predefined macros]]
 *[[http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system | C/C++ tip: How to detect the operating system type using compiler predefined macros]]
 *[[http://nadeausoftware.com/articles/2012/02/c_c_tip_how_detect_processor_type_using_compiler_predefined_macros | C/C++ tip: How to detect the processor type using compiler predefined macros]]

=== Platform Endianness, Debian architectures and compiler host names ===
I can't remember mostly of the time what relationship between the Debian architecture names, Compiler specific host names and endianness exists ...

TODO: move this to ArchitectureSpecificsMemo

||'''Debian architecture'''||'''Compiler host name'''||'''Endianness'''||
||<-4> ''RC platform'' ||
||i386 ||i686-pc-linux-gnu ||LE ||
||amd64 ||x86_64-pc-linux-gnu ||LE ||
||armel ||arm-unknown-linux-gnueabi ||LE ||
||armhf ||arm-unknown-linux-gnueabihf ||LE ||
||arm64 ||aarch64-unknown-linux-gnu ||LE ||
||mips ||mips-unknown-linux-gnu ||BE ||
||mips64el ||mips64el-unknown-linux-gnuabi64 ||LE ||
||mipsel ||mipsel-unknown-linux-gnu ||LE ||
||ppc64el ||powerpc64le-unknown-linux-gnu ||LE ||
||s390x ||s390x-ibm-linux-gnu ||BE ||
||<-4> ''non RC platform'' ||
||alpha ||alpha-unknown-linux-gnu ||LE ||
||hppa ||hppa-unknown-linux-gnu ||BE ||
||hurd-386 ||i686-pc-gnu ||LE ||
||kfreebsd-i386 ||i686-pc-kfreebsd-gnu ||LE ||
||kfreebsd-amd64 ||x86_64-pc-kfreebsd-gnu ||LE ||
||m68k ||m68k-unknown-linux-gnu ||BE ||
||powerpc ||powerpc-unknown-linux-gnu ||BE ||
||powerpcspe ||powerpc-unknown-linux-gnuspe ||BE ||
||ppc64 ||powerpc64-unknown-linux-gnu ||BE ||
||sh4 ||sh4-unknown-linux-gnu ||LE ||
||sparc64 ||sparc64-unknown-linux-gnu ||BE ||
||x32 ||x86_64-pc-linux-gnux32 ||LE ||

== git-buildpackage ==
=== Setting up Hooks with git-buildpackage ===
Every time I new set up my PC I also can't remember that. :-)

Setting up some global Hooks.
{{{
sudo mkdir /etc/pbuilder/hooks
cd !$
sudo ln -s /usr/share/doc/pbuilder/examples/C11screen
sudo ln -s /usr/share/doc/pbuilder/examples/D80no-man-db-rebuild
}}}
And enable them in the pbuilderrc.
{{{
sudo echo "HOOKDIR=/etc/pbuilder/hooks" >> /etc/pbuilderrc
}}}

= Misc =
== Syncing source package and Debian files somethere ==
Instead of using `scp` with a complex call simply use `dcmd` (from devscripts package):
{{{
$ dcmd scp mypackage_99.2-1~exp1.dsc somehost.org:/foo/bar/mypackage-99.2
}}}

== Searching for $package in Build-Depends,Build-Depends-Arch,Build-Depends-Indep ==
For preparation of a mass bug filing or simply research about the whole archive (depending on the used entries in sources.list), needs a installed package DebPkg:dctrl-tools and DebPkg:devscripts
{{{
$ grep-dctrl -FBuild-Depends,Build-Depends-Arch,Build-Depends-Indep $package /var/lib/apt/lists/*.debian.org_debian_dists_*Sources | dd-list --dctrl
}}}

== make git-archive more useful ==
Sometimes I need to make a orig.tar.xz tarball from a upstream repo.
{{{
$ git config tar.tar.xz.command "xz -c"
git archive --format=tar.xz --output=../mypackage_99.2.orig.tar.xz mypackage-0.99.2 # use a tag or ID
}}}

-----

= ARM based boards =
TODO: move this to InstallingDebianOn
The following stuff should finally go into the Installing Debian On X sites in the end. If someone wants to do so feel free, otherwise it's best to sort out some more things first.

== Libre Computer Board AML-S905X-CC - Le Potato ==
The Le Potato is a ARM64 based Raspberry Pi-Like Single-Board Computer. It's created by [[https://libre.computer/products/boards/aml-s905x-cc/ | Libre Computer]] and based on the Amlogic S905 processor, a 64-bit Quad Core ARM Cortex A53 SoC, with 2GB RAM and an eMMC interface.

Due the nature of the SoC (ARMv8) it needs a ATF and also a U-Boot that is knowing about internals of the ATF to start the board.

The Le Potato board is available since 1st October 2017 and development on upstream support of Linux kernel and U-Boot has just started a few months ago. The first notable Linux kernel with main line support for the Amlogic GXL family is 4.14. The current state of implementation is visible in the wiki of [[http://linux-meson.com/doku.php#mainline_support_matrix | linux-meson]]. So it's obvious no full support and usability available right now.

=== Current state in Debian ===
While writing there is no support build in inside the Debian ecosystem, especially in the installer and probably never will be. The main issue right now is a no free available U-Boot and knowledge how to build and use the ATF binary. If you can give further details please ad them here!

Main work to build in support into main line kernel and U-boot is done by [[http://baylibre.com/kernel-recipes-mainline-aml-s905x-cc-le-potato/ | BayLibre]] and this mostly in person of [[http://baylibre.com/author/narmstrong/ | Neil Armstrong]].

=== Links ===
 *Manufacturer https://libre.computer/products/boards/aml-s905x-cc/
 *Kickstarter project https://www.kickstarter.com/projects/librecomputer/libre-computer-board-next-gen-4k-sbc-dev-board-for
 *Ordering https://www.loverpi.com/products/libre-computer-board-aml-s905x-cc
 *Support Forum http://forum.loverpi.com/categories/libre-computer-board-aml-s905x-cc
 *Product wiki http://wiki.loverpi.com/sbc-brand:libre-computer
 *Debian based images https://www.armbian.com/lepotato/
 *U-Boot contributions of Neil Armstrong https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=67289&state=*&q=&archive=both&delegate=
 *U-Boot git tree of !BayLibre https://github.com/BayLibre/u-boot
 *ATF Arm Trusted Firmware reference implementation https://github.com/ARM-software/arm-trusted-firmware
 *Introducion into ATF (slighty outdated) https://de.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13
 *Blogpost about ATF on the [[InstallingDebianOn/96Boards/HiKey | HiKey]] boards https://prosauce.org/blog/2016/11/25/hands-on-introduction-to-arm-firmware-using-the-hikey

-----

== Cubieboard2 ==
=== Using OnBoard LED's on the Cubieboard2 ===
As the Allwinner !OnBoard LED's are specific to the DTS implementation there is no Debian package or way to configure them. To use the LED's for anything useful you have to write the wished usage of them into a trigger file. The location of these files are predefined by the Device Tree definition, for the CB2 the location for the blue LED is in {{{/sys/class/leds/cubieboard2:blue:usr/trigger}}} and the green LED is triggered via {{{/sys/class/leds/cubieboard2:green:usr/trigger}}}.

There are various things on a CB2 that can be shown by a LED activity (other Allwinner devices may contain more options!).
 *rc-feedback -> activity by a IR remote control
 *nand-disk -> R/W activity on the NAND flash
 *cpu0 -> CPU activity on core 1
 *cpu1 -> CPU activity on core 2
 *mmc0 -> R/W activity on the MMC 1 (SD-Card 1)
 *none -> show nothing

To let the kernel show any specific action on than just write the keyword into the trigger file as root. For example if you want to see on the blue LED the activity of CPU0 and on the green LED R/W actions on the MMC1 put the following lines into {{{/etc/rc.local}}} before the {{{exit 0}}} line.
{{{
....
echo cpu0 > /sys/class/leds/cubieboard2\:blue\:usr/trigger
echo mmc0 > /sys/class/leds/cubieboard2\:green\:usr/trigger
....
}}}
To enable/disable the LED activity without loosing the predefined action you can switch on/of the LED by writing into the brightness trigger as root.
{{{
echo 0 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch of LED
echo 0 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch of LED
}}}
{{{
echo 1 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch on LED, default state after boot
echo 1 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch on LED, default state after boot
}}}

=== Reading SoC Temperature on Cubieboard2 ===
The path to the temperature on the SOC is depending on the DTB, so it differs between Jessie and Stretch. For Jessie the current value of the temperature on the board is stored in the following file.
{{{
$ cat /sys/devices/soc\@01c00000/1c25000.rtp/hwmon/hwmon0/temp1_input
30600
}}}

While Stretch uses a different path.
{{{
$ cat /sys/devices/platform/soc@01c00000/1c25000.rtp/hwmon/hwmon0/temp1_input
21300
}}}

-----
Line 4: Line 171:
Note: This section isn't up2date! In the between times Patchwork has reached a version 2 with some different requirements than listed below. I've currently no time nor interests to dig into packaging patchwork.

== Source ==

{{{
git clone git://github.com/getpatchwork/patchwork
}}}

== Mailinglist/Maintainer/URL ==

 *https://ozlabs.org/mailman/listinfo/patchwork
 *Jeremy Kerr jk@ozlabs.org
 *http://jk.ozlabs.org/projects/patchwork/
Line 5: Line 186:
||'''Software'''||'''Wheezy'''||'''unstable/sid'''||
|| [[http://packages.qa.debian.org/p/python-defaults.html|Phyton]] Interpreter >= 2.7 || 2.7.3-4 || 2.7.3-4 ||
|| [[http://packages.qa.debian.org/a/apache2.html|Apache2]] Webserver >=2.2 || 2.22-13 || 2.22-13 ||
||<-3> oder ||
|| [[http://packages.qa.debian.org/lighttpd|lighttpd]] Webserver >= 1.4 || 1.4.31-3 || 1.4.31-3 ||
|| [[http://packages.qa.debian.org/d/django-ajax-selects.html|Django]] >= 1.2 Framework || 1.2.4-1 || 1.2.5-2 ||
|| mta-transport-agent || - || - ||
|| [[http://packages.qa.debian.org/d/django-ajax-selects.html|Django]] >= 1.2 Framework || 1.2.4-1 || 1.2.5-2 ||
|| [[http://packages.qa.debian.org/liba/libapache2-mod-python.html|modpython]] libapache2-mod-python >= 3.3 || 3.3.1-9 || 3.3.1-9 ||
|| [[http://packages.qa.debian.org/mysql-5.5|MySQL]] >= 5.5 || 5.5.28+dfsg-1 || 5.5.29+dfsg-1 ||
||<-3> oder ||
|| [[http://packages.qa.debian.org/p/postgresql-9.1.html|Postgres]] >= 9.0 || 9.1.8-1 || 9.1.8-1 ||

||'''Software'''||'''Version'''|| X-( '''Wheezy'''|| (./) '''unstable/sid'''||
|| [[http://packages.qa.debian.org/p/python-defaults.html|Phyton2]] Interpreter || >= 2.7 || (./) 2.7.3-4 || (./) 2.7.3-4 ||
|| [[http://packages.qa.debian.org/p/python-django.html|Phyton-Django]] || >= 1.5 || X-( 1.4.5-1+deb7u4 || (./) 1.6.1-2 ||
|| [[http://packages.qa.debian.org/p/psycopg2.html|phyton-psycopg2]] Bindings || >= 2.0 || (./) 2.4.5-1 || (./) 2.4.5-1 ||
|| [[http://packages.qa.debian.org/a/apache2.html|Apache2]] Webserver || >= 2.2 || (./) 2.22-13 || (./) 2.4.7-1 ||
||<:> or || || || ||
|| [[http://packages.qa.debian.org/l/lighttpd.html|lighttpd]] Webserver || >= 1.4 || (./) 1.4.31-4 || (./) 1.4.33-1 ||
|| mta-transport-agent || - || - || - ||
|| [[http://packages.qa.debian.org/liba/libapache2-mod-python.html|modpython]] libapache2-mod-python || >= 3.3 || (./) 3.3.1-9 || (./) 3.3.1-9 ||
|| [[http://packages.qa.debian.org/j/jquery.html|libjs-jquery]] || >= 1.3 || (./) 1.7.2+dfsg-1 || (./) 1.7.2+dfsg-1 ||
|| [[http://packages.qa.debian.org/m/mysql-5.5.html|MySQL]] || >= 5.5 || (./) 5.5.33+dfsg-1 || (./) 5.5.35+dfsg-1 ||
||<:> or || || || ||
|| [[http://packages.qa.debian.org/p/postgresql-9.1.html|Postgres]] || >= 9.0 || (./) 9.1.11-1 || (./) 9.1.11-1 ||
|| Bash (some scripts) || >= 3.0 || (./) || (./) ||

== ITP Request ==

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703226

== Old Staging Area ==

https://github.com/tijuca/patchwork

Various packaging related things

debconf stuff

Platform Specifics

Defines

As I always search for that while debugging KFreeBSD or Hurd build issues ...

gcc -dM -E -x c++ /dev/null # for C++
gcc -dM -E -x c /dev/null   # for C

Platform Endianness, Debian architectures and compiler host names

I can't remember mostly of the time what relationship between the Debian architecture names, Compiler specific host names and endianness exists ...

TODO: move this to ArchitectureSpecificsMemo

Debian architecture

Compiler host name

Endianness

RC platform

i386

i686-pc-linux-gnu

LE

amd64

x86_64-pc-linux-gnu

LE

armel

arm-unknown-linux-gnueabi

LE

armhf

arm-unknown-linux-gnueabihf

LE

arm64

aarch64-unknown-linux-gnu

LE

mips

mips-unknown-linux-gnu

BE

mips64el

mips64el-unknown-linux-gnuabi64

LE

mipsel

mipsel-unknown-linux-gnu

LE

ppc64el

powerpc64le-unknown-linux-gnu

LE

s390x

s390x-ibm-linux-gnu

BE

non RC platform

alpha

alpha-unknown-linux-gnu

LE

hppa

hppa-unknown-linux-gnu

BE

hurd-386

i686-pc-gnu

LE

kfreebsd-i386

i686-pc-kfreebsd-gnu

LE

kfreebsd-amd64

x86_64-pc-kfreebsd-gnu

LE

m68k

m68k-unknown-linux-gnu

BE

powerpc

powerpc-unknown-linux-gnu

BE

powerpcspe

powerpc-unknown-linux-gnuspe

BE

ppc64

powerpc64-unknown-linux-gnu

BE

sh4

sh4-unknown-linux-gnu

LE

sparc64

sparc64-unknown-linux-gnu

BE

x32

x86_64-pc-linux-gnux32

LE

git-buildpackage

Setting up Hooks with git-buildpackage

Every time I new set up my PC I also can't remember that. :-)

Setting up some global Hooks.

sudo mkdir /etc/pbuilder/hooks
cd !$
sudo ln -s /usr/share/doc/pbuilder/examples/C11screen
sudo ln -s /usr/share/doc/pbuilder/examples/D80no-man-db-rebuild

And enable them in the pbuilderrc.

sudo echo "HOOKDIR=/etc/pbuilder/hooks" >> /etc/pbuilderrc

Misc

Syncing source package and Debian files somethere

Instead of using scp with a complex call simply use dcmd (from devscripts package):

$ dcmd scp mypackage_99.2-1~exp1.dsc somehost.org:/foo/bar/mypackage-99.2

Searching for $package in Build-Depends,Build-Depends-Arch,Build-Depends-Indep

For preparation of a mass bug filing or simply research about the whole archive (depending on the used entries in sources.list), needs a installed package dctrl-tools and devscripts

$ grep-dctrl -FBuild-Depends,Build-Depends-Arch,Build-Depends-Indep $package /var/lib/apt/lists/*.debian.org_debian_dists_*Sources | dd-list --dctrl

make git-archive more useful

Sometimes I need to make a orig.tar.xz tarball from a upstream repo.

$ git config tar.tar.xz.command "xz -c"
git archive --format=tar.xz --output=../mypackage_99.2.orig.tar.xz mypackage-0.99.2 # use a tag or ID


ARM based boards

TODO: move this to InstallingDebianOn The following stuff should finally go into the Installing Debian On X sites in the end. If someone wants to do so feel free, otherwise it's best to sort out some more things first.

Libre Computer Board AML-S905X-CC - Le Potato

The Le Potato is a ARM64 based Raspberry Pi-Like Single-Board Computer. It's created by Libre Computer and based on the Amlogic S905 processor, a 64-bit Quad Core ARM Cortex A53 SoC, with 2GB RAM and an eMMC interface.

Due the nature of the SoC (ARMv8) it needs a ATF and also a U-Boot that is knowing about internals of the ATF to start the board.

The Le Potato board is available since 1st October 2017 and development on upstream support of Linux kernel and U-Boot has just started a few months ago. The first notable Linux kernel with main line support for the Amlogic GXL family is 4.14. The current state of implementation is visible in the wiki of linux-meson. So it's obvious no full support and usability available right now.

Current state in Debian

While writing there is no support build in inside the Debian ecosystem, especially in the installer and probably never will be. The main issue right now is a no free available U-Boot and knowledge how to build and use the ATF binary. If you can give further details please ad them here!

Main work to build in support into main line kernel and U-boot is done by BayLibre and this mostly in person of Neil Armstrong.


Cubieboard2

Using OnBoard LED's on the Cubieboard2

As the Allwinner OnBoard LED's are specific to the DTS implementation there is no Debian package or way to configure them. To use the LED's for anything useful you have to write the wished usage of them into a trigger file. The location of these files are predefined by the Device Tree definition, for the CB2 the location for the blue LED is in /sys/class/leds/cubieboard2:blue:usr/trigger and the green LED is triggered via /sys/class/leds/cubieboard2:green:usr/trigger.

There are various things on a CB2 that can be shown by a LED activity (other Allwinner devices may contain more options!).

  • rc-feedback -> activity by a IR remote control

  • nand-disk -> R/W activity on the NAND flash

  • cpu0 -> CPU activity on core 1

  • cpu1 -> CPU activity on core 2

  • mmc0 -> R/W activity on the MMC 1 (SD-Card 1)

  • none -> show nothing

To let the kernel show any specific action on than just write the keyword into the trigger file as root. For example if you want to see on the blue LED the activity of CPU0 and on the green LED R/W actions on the MMC1 put the following lines into /etc/rc.local before the exit 0 line.

....
echo cpu0 > /sys/class/leds/cubieboard2\:blue\:usr/trigger
echo mmc0 > /sys/class/leds/cubieboard2\:green\:usr/trigger
....

To enable/disable the LED activity without loosing the predefined action you can switch on/of the LED by writing into the brightness trigger as root.

echo 0 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch of LED
echo 0 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch of LED

echo 1 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch on LED, default state after boot
echo 1 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch on LED, default state after boot

Reading SoC Temperature on Cubieboard2

The path to the temperature on the SOC is depending on the DTB, so it differs between Jessie and Stretch. For Jessie the current value of the temperature on the board is stored in the following file.

$ cat /sys/devices/soc\@01c00000/1c25000.rtp/hwmon/hwmon0/temp1_input
30600

While Stretch uses a different path.

$ cat /sys/devices/platform/soc@01c00000/1c25000.rtp/hwmon/hwmon0/temp1_input
21300


Patchwork

Note: This section isn't up2date! In the between times Patchwork has reached a version 2 with some different requirements than listed below. I've currently no time nor interests to dig into packaging patchwork.

Source

git clone git://github.com/getpatchwork/patchwork

Mailinglist/Maintainer/URL

Dependencies

Software

Version

X-( Wheezy

(./) unstable/sid

Phyton2 Interpreter

>= 2.7

(./) 2.7.3-4

(./) 2.7.3-4

Phyton-Django

>= 1.5

X-( 1.4.5-1+deb7u4

(./) 1.6.1-2

phyton-psycopg2 Bindings

>= 2.0

(./) 2.4.5-1

(./) 2.4.5-1

Apache2 Webserver

>= 2.2

(./) 2.22-13

(./) 2.4.7-1

or

lighttpd Webserver

>= 1.4

(./) 1.4.31-4

(./) 1.4.33-1

mta-transport-agent

-

-

-

modpython libapache2-mod-python

>= 3.3

(./) 3.3.1-9

(./) 3.3.1-9

libjs-jquery

>= 1.3

(./) 1.7.2+dfsg-1

(./) 1.7.2+dfsg-1

MySQL

>= 5.5

(./) 5.5.33+dfsg-1

(./) 5.5.35+dfsg-1

or

Postgres

>= 9.0

(./) 9.1.11-1

(./) 9.1.11-1

Bash (some scripts)

>= 3.0

(./)

(./)

ITP Request

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703226

Old Staging Area

https://github.com/tijuca/patchwork


CategoryHomepage