Re: [yocto] X display touch calibration

[Maxin B. John]

Hi,

On Mon, Aug 29, 2016 at 05:52:31PM +0200, Gary Thomas wrote:
> On 2016-08-29 13:49, Maxin B. John wrote:
> >Hi Gary,
> >
> >On Mon, Aug 29, 2016 at 11:09:25AM +0200, Gary Thomas wrote:
> >>How is the touchscreen calibration supposed to work now (after
> >>the recent changes dropping pointercal, tslib, etc)?  I can
> >>see when I launch X that the screen calibration program runs,
> >>but I think only briefly as the main [matchbox] screen immediately
> >>comes up and without calibration, my pointer (touchscreen) is pretty
> >>useless...
> >
> >Could you share some more details about the device that you are using?
> 
> I'm using an i.MX6Q SabreLite (Boundary Devices) with a 7" LCD that has
> a TSC-2004 resistive touch screen.
> 
> >
> >Most likely, the layer which supports your device, already provides a
> >default "/etc/pointercal.xinput" file. Removing that file and restarting
> >the device should bring back the screen calibration program during boot.
> 
> I removed that file and still the same behavior.

Looks a bit strange :(

> >
> >>Ideas / pointers?
> >
> >Please update that .bbappend file or provide a "reasonable"(which works
> >with the latest xinput_calibrator) set of default values in the
> >pointercal.xinput file.
> 
> Since the autocalibrate isn't working, can you give some guidance
> what this looks like?  The one created by the [erroneous] .bbappend
> looks like this:
>   xinput set-int-prop "EETI eGalax Touch Screen" "Evdev Axis Calibration" 
> 42060 2062 -8 -783544 1 1549 65536
>   xinput set-int-prop "EETI eGalax Touch Screen" "Evdev Axes Swap" 8 0
> 
> Note: the reason you didn't see my error when you built for imx28 was
> that this specific file is i.MX6 specific.

Oh, ok.

> Also, in the past I used a [manually crafted] file:
> = /etc/X11/xorg.conf.d/11-touchscreen.conf
> Section "InputClass"
> Identifier "tsc2004"
> MatchProduct "tsc2004"
> MatchDevicePath "/dev/input/event*"
> Driver "evdev"
> Option "InvertX" "true"
> Option  "Calibration"   "85 4045 166 3991"
> EndSection
> 
> The touchscreen still works if I include this but I was trying to play
> by the new rules and use the new configuration tools, so I removed it
> and /etc/pointercal*

Good to hear that it works with the manually created file. To debug the problem
further, is it possible to share the output from the target ?
# xinput_calibrator --list

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] u-boot-mkimage in SDK

[Anicic Damir (PSI)]

Hi all,


I have built Yocto 2.1, for PowerPC (E6500):

Build Configuration:
BB_VERSION= "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "powerpc-poky-linux"
MACHINE   = "powerpc-ppce6500"
DISTRO= "gfa-ppce6500"
DISTRO_VERSION= "2.1"
TUNE_FEATURES = "m32 fpu-hard e6500 altivec"
TARGET_FPU= ""





Now, if I am cross-compiling additional uImage kernels outside bitbake,
I need mkimage.
But it is not in SDK.

I have managed to get mkimage into rootfs, (added to IMAGE_INSTALL +=...)
but how to get it inside cross-toolchain?

Regards,
Damir

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Automating imaging building and testing, what aproach to use!?

[Daniel.]

Thanks Randy and Mark for the replies!

In my case we have a two boards running basically the same distribuition,
diverging only on some peripherals. I was planing to install/wire
everything up and then use https://mender.io/ to automate update process.
After that I can create post installations tests and see they run at every
image update. I'll have to design the tests so that the output of then goes
to some web interface or pdf+email but this is not a problem.

Another option is using buildbot to automate recipe builing and using it to
feed some intranet rpm/debi/ipk repo. Configure my testing targets with
something like "auto-update". After that is the same mater of creating post
install tests. The pro here is that this way I'll be testing by recipe
builds too, and that updates are faster. The con is that mender updates are
safer ...

The major complexity comes from the fact that we're using distribuited
hardware as may be the case of other people here. We have a "master"
hardware that connects to "slave" hardware, where master is the Linux and
slave are some embedded boards. To test everything up I need to wire
everything up before testing. I would like to hear people solutions for
that case since mulitple "setups" are possible testing every possible setup
is not feasible.

By the way, that LAVA seems promissing! I'll take a closer look on it!
Thanks for sharing :)

Regards,


2016-08-31 2:59 GMT-03:00 Mike Looijmans :

> On 30-08-16 22:18, Daniel. wrote:
> > Hey everybody!
> >
> > While writing software we're used to delivery packages, libraries and
> > stacks. There are out there a lot of continuos integration solutions
> > to automaticaly build and test these kinds of software. But when
> > dealing to images the thing is more tricky.
> >
> > I can't run the tests at the same machine that build the image because
> > crosscompilation take place on 99% of the cases. What is aproach that
> > you guys are using to automate and increase the quality of your
> > images?
> >
> > Automating the build is the easy part my concert is about automating
> > the runtime tests that need the target board to run. In my case I
> > depend on hardware to fully test the image features. Is there any
> > reliable way to automate image installation and boot!?
>
> It helps a lot if you take testing into account when designing the
> hardware.
>
> We have a bunch of hardware targets in a corner. The board can be powered
> on/off forcibly by controlling/monitoring the RTS/DTR/CTS/DSR lines of the
> serial debug port (FTDI chip).
>
> A python script on a PC boots a board, puts it into USB "DFU" mode by
> "typing"
> commands into u-boot, and then sends an image over USB into RAM. The board
> then configures its USB OTG port as network, and the Python script
> connects to
> the board via SSH (paramiko) over that USB connection when it sees the
> "network" come up. Using the SSH connection, it can run whatever tests it
> needs doing (send data and even executables, run shell commands, and get
> reliable feedback on process completion).
>
> One test PC can control multiple boards (each board needs two USB
> connectors
> in this setup).
>
> I'd also be interested to know what other projects are doing.
>
>
>
> Kind regards,
>
>
>
> Mike Looijmans
>
> System Expert
>
>
>
>
>
> *TOPIC Products*
>
>
>
>
>
> Materiaalweg 4
>
>
>
>
>
> 5681 RJ Best
>
> T:
>
> +31 (0) 499 33 69 69
>
> Postbus 440
>
> E:
>
> mike.looijm...@topicproducts.com
>
> 5680 AK Best
>
> W:
>
> www.topicproducts.com
> The Netherlands
>
> 
> 
> 
> Please consider the environment before printing this e-mail
>
> Topic zoekt gedreven (embedded) software specialisten!
> 
>
>


-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] u-boot-mkimage in SDK

[Daniel.]

I had to add nativesdk-u-boot-mkimage to
nativesdk-packagegroup-sdk-host.bbappend RDEPNDS_${PN} variable.

[geckos@csi24 yocto-daisy]$ cat
./sources/meta-fsl-arm/recipes-core/packagegroup/nativesdk-packagegroup-sdk-host.bbappend
RDEPENDS_${PN} += " \
nativesdk-elftosb \
nativesdk-mxsldr \
nativesdk-u-boot-mkimage \
"

2016-08-31 9:52 GMT-03:00 Anicic Damir (PSI) :
> Hi all,
>
>
> I have built Yocto 2.1, for PowerPC (E6500):
>
> Build Configuration:
> BB_VERSION= "1.30.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "powerpc-poky-linux"
> MACHINE   = "powerpc-ppce6500"
> DISTRO= "gfa-ppce6500"
> DISTRO_VERSION= "2.1"
> TUNE_FEATURES = "m32 fpu-hard e6500 altivec"
> TARGET_FPU= ""
>
>
>
>
>
> Now, if I am cross-compiling additional uImage kernels outside bitbake,
> I need mkimage.
> But it is not in SDK.
>
> I have managed to get mkimage into rootfs, (added to IMAGE_INSTALL +=...)
> but how to get it inside cross-toolchain?
>
> Regards,
> Damir
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] man: Add NAME section

[Igor Gnatenko]

From: Andrew Shadura 

Each manual page should start with a "NAME" section, which lists the
name and a brief description of the page separated by "\-".

Signed-off-by: Igor Gnatenko 
---
 pseudo.1| 2 ++
 pseudolog.1 | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/pseudo.1 b/pseudo.1
index 13f6bbe..63a6782 100644
--- a/pseudo.1
+++ b/pseudo.1
@@ -16,6 +16,8 @@
 .\" version 2.1 along with this program; if not, write to the Free Software
 .\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
 .TH pseudo 1 "pseudo - pretending to be root"
+.SH NAME
+pseudo \- run a command in a virtual root environment
 .SH SYNOPSIS
 .B pseudo
 .RB [ \-dflv ]
diff --git a/pseudolog.1 b/pseudolog.1
index b6e76f9..ebf8443 100644
--- a/pseudolog.1
+++ b/pseudolog.1
@@ -16,6 +16,8 @@
 .\" version 2.1 along with this program; if not, write to the Free Software
 .\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
 .TH pseudolog 1 "pseudo - pretending to be root"
+.SH NAME
+pseudolog \- pseudo log parser
 .SH SYNOPSIS
 .B pseudolog \-l
 .RB [ \-Pv ]
-- 
2.9.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto and Google protobuffer

[Pietro]

Hi all,

I am new to the Yocto building system and I could be talking nonsense. I
used to work with buildroot time ago and I remember there is an area
where compiled software/packages/tools previously built are "staged" and
used when building other packages.

Is there something like that available with Yocto ? Specifically I would
like to add a package which uses the Google Protocol Buffer, I do not have
administrator rights on the machine and I can't install the packages I
need system wise.

Is it possible to add recipes and use them at building time without
including them in the image being generated ?

A good example for that would be the protoc, the protocol buffer description
file compiler.

Thanks in advance,
Pietro.



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] cleanup and restart crashed vnc server

[Joshua Lock]

On Wed, 2016-08-17 at 17:12 +0100, Joshua G Lock wrote:
> On Wed, 2016-08-17 at 16:09 +, Randle, William C wrote:
> > On Wed, 2016-08-17 at 16:59 +0100, Joshua G Lock wrote:
> > 
> > > On Tue, 2016-08-16 at 17:09 -0700, Bill Randle wrote:
> > > > > > > > Use a common script to check for a running vnc server, and if
not
> > > > running
> > > > cleanup dangling lock files and restart the server.
> > > > 
> > > > [YOCTO #8210]
> > > > 
> > > > > > > > Signed-off-by: Bill Randle 
> > > > ---
> > > > > > > >  bin/checkvnc  
 | 10
> > > > ++
> > > > > > > >  .../site-packages/autobuilder/buildsteps/RunESDKSanityTests.py 
|  3
> > > > +--
> > > > > > > >  .../site-
packages/autobuilder/buildsteps/RunOeSelftest.py  |  3
> > > > +--
> > > > > > > >  .../site-
packages/autobuilder/buildsteps/RunSDKSanityTests.py  |  3
> > > > +--
> > > > > > > >  .../site-
packages/autobuilder/buildsteps/RunSanityTests.py |  3
> > > > +--
> > > >  5 files changed, 14 insertions(+), 8 deletions(-)
> > > >  create mode 100755 bin/checkvnc
> > > > 
> > > > diff --git a/bin/checkvnc b/bin/checkvnc
> > > > new file mode 100755
> > > > index 000..574ba48
> > > > --- /dev/null
> > > > +++ b/bin/checkvnc
> > > > @@ -0,0 +1,10 @@
> > > > +#!/bin/sh
> > > > +#
> > > > > > > > +# check if vnc server is running, and if not, cleanup and
restart
> > > > +#
> > > > +pid=$(pidof Xvnc)
> > > > +if [[ $? != 0 ]]; then
> > > > +echo "Xvnc not running, attempting restart"
> > > > +vncserver -kill :1
> > > > +vncserver
> > > 
> > > > > > The vncserver is currently started with `vncserver :1`, whereas
this
> > > script just calls `vncserver` — is that intentional/desirable?
> > > 
> > > > > > Would it be a little cleaner/more robust if we didn't assume only
one
> > > > > > Xvnc instance was running and instead write the pid of the
process we
> > > start to a file and use that file to check the status?
> > > 
> > > Regards,
> > > 
> > > Joshua
> > > 
> > > 
> > 
> > 
> > 
> > 
> > > > The vncserver program is a shell script and uses :1 as the default
display.
> > 
> > 
> > 
> > 
> > 
> > > > > > > > The pid of Xvnc is written to a file already. The problem is, if
Xvmc crashes, the pid file (and lock file) are left around, so just
looking at the pid file existance, you can't tell if it's actually
running or not.
> > 
> 
> 
> > > > Can we read the pid from the pidfile and do the tidy up if the
process isn't running? My main concern here is that we assume only a
single instance of Xvnc is running, I'm not sure if that is a safe
assumption to make?

It turns out we implicitly assume only one vncserver is running (on
display 1) in several places throughout the AB codebase. Therefore I've
pushed this change to master.

Thanks,

Joshua
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][yocto-autobuilder] nightly-qa-systemd.conf: Add create_eventlog property

[Joshua Lock]

On Tue, 2016-08-30 at 10:46 -0500, Aníbal Limón wrote:
> This buildset also needs the create_eventlog property for only
> enable the toaster event log creation when required. See rev [1].
> 
> [1] 0b083509beaf7421f1dde4b679a934741ac4a3bc

Pushed to master, thanks!

Joshua

> 
> Signed-off-by: Aníbal Limón 
> ---
>  buildset-config.controller/nightly-qa-systemd.conf | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/buildset-config.controller/nightly-qa-systemd.conf
> b/buildset-config.controller/nightly-qa-systemd.conf
> index f95021dc..662caa6 100644
> --- a/buildset-config.controller/nightly-qa-systemd.conf
> +++ b/buildset-config.controller/nightly-qa-systemd.conf
> @@ -4,6 +4,10 @@ repos: [{'poky':
>  {'repourl':'git://git.yoctoproject.org/poky',
>   'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-
> bsp', 'yocto':'meta-yocto', 'poky':'meta-poky'},
>   'branch':'master'}}]
> +props: [{'create_eventlog':{'prop_type':'ChoiceStringParameter',
> +   'choices': ['False', 'True'],
> +   'name': 'create_eventlog',
> +   'label':'Create Toaster event log as part
> of image creation?:'}}]
>  steps: [{'SetDest':{}},
>  {'CheckOutLayers': {}},
>  {'RunPreamble': {}},
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Automating imaging building and testing, what aproach to use!?

[Paul Eggleton]

Hi Daniel,

On Tue, 30 Aug 2016 17:18:44 Daniel. wrote:
> While writing software we're used to delivery packages, libraries and
> stacks. There are out there a lot of continuos integration solutions
> to automaticaly build and test these kinds of software. But when
> dealing to images the thing is more tricky.
> 
> I can't run the tests at the same machine that build the image because
> crosscompilation take place on 99% of the cases. What is aproach that
> you guys are using to automate and increase the quality of your
> images?
> 
> Automating the build is the easy part my concert is about automating
> the runtime tests that need the target board to run. In my case I
> depend on hardware to fully test the image features. Is there any
> reliable way to automate image installation and boot!?

There are some folks here working on automated hardware tests (on CC), perhaps
they can expand on what we're currently doing in that area. At least in the
existing code we do have basic support for running tests on real hardware that
may be worth looking into - at the moment though it's pretty rudimentary when
it comes to interacting directly with the hardware though. You can see what
we've currently got here:

  
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#hardware-image-enabling-tests

We've looked at LAVA several times, and I'm sorry to say the conclusion each
time is that its a mess - both from a usage perspective and looking at the
code. It was disappointing to us because initially it looked like it was going
to solve a lot of our problems. Maybe others have had different experiences -
I'd love to hear details if anyone is prepared to share.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Automating imaging building and testing, what aproach to use!?

[Bruce Ashfield]

On 2016-08-31 6:23 PM, Paul Eggleton wrote:

Hi Daniel,

On Tue, 30 Aug 2016 17:18:44 Daniel. wrote:

While writing software we're used to delivery packages, libraries and
stacks. There are out there a lot of continuos integration solutions
to automaticaly build and test these kinds of software. But when
dealing to images the thing is more tricky.

I can't run the tests at the same machine that build the image because
crosscompilation take place on 99% of the cases. What is aproach that
you guys are using to automate and increase the quality of your
images?

Automating the build is the easy part my concert is about automating
the runtime tests that need the target board to run. In my case I
depend on hardware to fully test the image features. Is there any
reliable way to automate image installation and boot!?


There are some folks here working on automated hardware tests (on CC), perhaps
they can expand on what we're currently doing in that area. At least in the
existing code we do have basic support for running tests on real hardware that
may be worth looking into - at the moment though it's pretty rudimentary when
it comes to interacting directly with the hardware though. You can see what
we've currently got here:

  
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#hardware-image-enabling-tests

We've looked at LAVA several times, and I'm sorry to say the conclusion each
time is that its a mess - both from a usage perspective and looking at the
code. It was disappointing to us because initially it looked like it was going
to solve a lot of our problems. Maybe others have had different experiences -
I'd love to hear details if anyone is prepared to share.


We've been using LAVA extensively within WRind River, and haven't run
into any major issues with the code and usage. Perhaps it depends on
the type of test cases that are being run ?

LAVA was active, extensible and able to integrate with our wide range
of targets.

That's not to say that we didn't add a lot of our own tests,
infrastructure, etc, but that was expected work with whatever we
chose.

Cheers,

Bruce



Cheers,
Paul



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] resource-agents: 3.9.6 -> 3.9.7

[Wang Xin]

Upgrade resource-agents from 3.9.6 to 3.9.7.

Signed-off-by: Wang Xin 
---
 .../{resource-agents_3.9.6.bb => resource-agents_3.9.7.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename 
meta-cgl-common/recipes-cgl/cluster-resource-agents/{resource-agents_3.9.6.bb 
=> resource-agents_3.9.7.bb} (95%)

diff --git 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.6.bb 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.7.bb
similarity index 95%
rename from 
meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.6.bb
rename to 
meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.7.bb
index 18ef1e8..a0d4e1f 100644
--- 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.6.bb
+++ 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_3.9.7.bb
@@ -20,8 +20,8 @@ SRC_URI = 
"https://codeload.github.com/ClusterLabs/resource-agents/tar.gz/v${PV}
file://03-fix-header-defs-lookup.patch \
   "
 
-SRC_URI[md5sum] = "6873d5a217aee3026193fb85bfa18a4a"
-SRC_URI[sha256sum] = 
"39722cdee68ff96d06788f05f325bd21ec2fc59c59d847e5e4b23c6df23bf678"
+SRC_URI[md5sum] = "c59096b1bacc704e8a5a285f15729109"
+SRC_URI[sha256sum] = 
"e5bd62658fbc236acb83b709f64b2cd9fae52aa4a420a44fed5eb667e928b152"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
 file://COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c \
-- 
2.7.4



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] samhain-client: 4.1.4 -> 4.1.5

[Wang Xin]

Upgrade samhain-client from 4.1.4 to 4.1.5.

Signed-off-by: Wang Xin 
---
 .../samhain/{samhain-client_4.1.4.bb => samhain-client_4.1.5.bb}  | 0
 recipes-security/samhain/samhain.inc  | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename recipes-security/samhain/{samhain-client_4.1.4.bb => 
samhain-client_4.1.5.bb} (100%)

diff --git a/recipes-security/samhain/samhain-client_4.1.4.bb 
b/recipes-security/samhain/samhain-client_4.1.5.bb
similarity index 100%
rename from recipes-security/samhain/samhain-client_4.1.4.bb
rename to recipes-security/samhain/samhain-client_4.1.5.bb
diff --git a/recipes-security/samhain/samhain.inc 
b/recipes-security/samhain/samhain.inc
index 907f431..5bf2ee7 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -9,8 +9,8 @@ SRC_URI = 
"http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
   file://${INITSCRIPT_NAME}.default \
  "
 
-SRC_URI[md5sum] = "1ab697b7000d0a272d9ade05bb1bc6e0"
-SRC_URI[sha256sum] = 
"32ee7477af11d9f2f64f30b9cb316c351897c1c994c7b98b0ef17fc0ca5e1d1a"
+SRC_URI[md5sum] = "bdb6d2653d706f3180e37ef3d95c824d"
+SRC_URI[sha256sum] = 
"4ff4c38765c942abbaac2577df4c8c4940482a1bffc4a719f181c4fca6f173a7"
 
 S = "${WORKDIR}/samhain-${PV}"
 
-- 
2.7.4



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto