Re: [yocto] Slashes in branch names

[Rudolf J Streif]

Michael,

Could you please be more specific on what the issue is? The Yocto Project's 
kernel repos use slashes in branch names.

:rjs

On Monday, February 09, 2015 07:10:49 PM Harvey, Michael wrote:
 Our git SCM infrastructure uses slashes in the branch names (android style)
 for organization, and that breaks yocto. Is there any way to support this
 in yocto?

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

Re: [yocto] gdb/gdbserver vs. eclipse

[Rudolf J Streif]

Hi Robert,
> 
> Which Yocto version do you use? I use 1.8

I am using 1.8, too. Just sent another e-mail about the TCF agent. However, 
that's only in addition since TCF is not used for debugging with GDB. Eclipse 
wraps around GDB which then communicates directly with the GDB server on the 
target.
> So let's try to summarize what seems to be necessary:
> 
> 1) right .gdbinit on the right place ;)

yeap

> 2) Debug Configurations -> Debugger -> Main -> Use full file path to set
> breakpoints (might not even be necessary)

I don't need that.

> 3) Debug Configurations -> Debugger -> Shared Libraries -> Load shared
> library symbols automatically
> 

yeap

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

Re: [yocto] gdb/gdbserver vs. eclipse

[Rudolf J Streif]

> 
> I think I made some progress - see attached image.

Good.

> 
> As you can see I stepped into printf and friends.
> 
> For this to work I needed a few more things:
> 
> 1) directory needs the be the same on host and target
> 
> the executable on the host:
> 
> /home/student/BBBworkspace/HelloBBBAutotooled/src/HelloBBBAutotooled
> 
> the executable on the target:
> 
> /home/student/BBBWorkspace/HelloBBBAutotooled/src/HelloBBBAutotooled
> 
I do not have to do that. As a matter of fact the executable on my target is 
copied to /usr/bin from the Eclipse workspace. See "Remote Absolute File Path" 
in the Debug Configuration.


> 2) .gdbinit
> 
> I copied my gdbinit on the host to
> 
> /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
> 

Yes, that's where Eclipse's Debug Configuration expects it if you do not change 
the setting of "GDB Command File" in the Main subtab of the Debugger tab in 
the Debug configuration.

> that's the .gdbinit
> 
> # don't use default libs from x86/Ubuntu:
> set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml
> set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml
> set solib-search-path  /opt/adt-target-sysroot/beagle-bone-black-ml
> # point to the libraries with debug info:
> set debug-file-directory
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug
> # point to the source code:
> set substitute-path /usr/src/debug
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
> set substitute-path /
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
> 

Yes, looks like mine except that my target is a MinnowBoard Max and I 
installed my SDK in a different location.


> 3) Once you enter the debug view you need to go to the gdb console and:
> 
> source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
> 

Strange. I don't have to do that if GDB command file is set to the path in the 
workspace. I would expect that Eclipse passes the .gdbinit from the workspace 
explicitly to GDB. However, I do have

add-auto-load-safe-path .

in my global .gdbinit (~/.gdbinit).

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

Re: [yocto] gdb/gdbserver vs. eclipse

[Rudolf J Streif]

Robert,

What version of Poky/OpenEmbedded Core (meta) are you using?

I found that including Fido (1.8) the tcf-agent built by meta was stuck at 
version 0.4.0. That causes issues with running on the target and getting the 
console output back to Eclipse. That's now updated to 1.3 in master for 
Eclipse Mars. I built 1.2 for Luna which works, but 1.3 works with Luna too.

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

Re: [yocto] Setting root password

[Rudolf J Streif]

Hi Andy, Daniel

On Thursday, September 24, 2015 11:20:37 AM Daniel. wrote:


> Still, I think is a good ideia to understand what is going wrong with
> EXTRA_USERS_PARAMS, other users may having the same problem.


EXTRA_USERS_PARAMS works for me all the time. The stanza is what I am using in 
my image recipes:

EXTRA_USERS_PARAMS = "\groupadd developers; \useradd -p `openssl passwd 
${DEV_PASSWORD}` developer; \useradd -g developers developer; \
usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \
"

If this is an accurate copy of what you are using (from you first email)

> EXTRA_USERS_PARAMS = "usermod -P  root;"

then the issue probably is the capital -P. It should be lowercase.

Cheers,
Rudi

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

Re: [yocto] Antwort: Re: Problems with do_rootfs when changing the user password

[Rudolf J Streif]

Hi,

> 
> How are the steps to (re)set the root password?

I am using something like this to set passwords:

inherit extrausers

# set image root password
ROOT_PASSWORD = "secret"
DEV_PASSWORD = "hackme"

EXTRA_USERS_PARAMS = "\
groupadd developers; \
useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
useradd -g developers developer; \
usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \
"
re, please excuse: I am explaining this and more in my book "Embedded Linux 
Systems with the Yocto Project".

> The starting point is a own layer ("myLayer") and a password 
> ("myNewPassword1234").
> 

Using your own layer for your custom distro/image configuration is the way to 
go. Just put the code above into your image recipe like this:

SUMMARY = "Custom image recipe from scratch"
DESCRIPTION = "Directly assign IMAGE_INSTALL and IMAGE_FEATURES for \
   for direct control over image contents."

LICENSE = "MIT"

# We are using the assignment operator (=) below to purposely overwrite
# the default from the core-image class.
IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended \
 ${CORE_IMAGE_EXTRA_INSTALL}"

inherit core-image
inherit extrausers

# set image root password
ROOT_PASSWORD = "secret"
DEV_PASSWORD = "hackme"

EXTRA_USERS_PARAMS = "\
   groupadd developers; \
   useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
   useradd -g developers developer; \
   usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \
   "

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

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

[Rudolf J Streif]

> 
>   hmm ... the client requirements are only that it use u-boot,
> with the mender software integrated into u-boot. so if one can
> configure and build that for powerpc, then install and boot u-boot on
> the target board, why should it then be restricted to ARM?
>
>   sure, their reference board is a BBB, but a quick glance at the docs
> doesn't seem to say that it works *only* on ARM. must look closer ...
>
Correct. However, it currently assumes the specific BeagleB* partition layout 
for the SSD card. But that I would think could be adjusted for other other 
devices. They apparently also made some modifications to u-boot itself. I don't 
know what exactly those are though.
 
:rjs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [Toaster] Production Instance Setup

[Rudolf J Streif]

Hi Everyone:

I am trying to set up Toaster in a production environment with Apache etc. The 
web server setup is ok. It is running builds where I am currently stuck.

I am using the Jethro branch from the git repo.

According to step 7 in [1] one needs to start

/var/www/toaster/poky/bitbake/lib/toaster/manage.py runbuilds

to start the runner service to dispatch builds. If there are currently no 
pending builds (non yet created using the web UI) then running this command 
immediately returns. The command gets dispatched to

poky/bitbake/lib/toaster/bldcontrol/management/commands/runbuilds.py

In its command help it states:

14: help= "Schedules and executes build requests as possible. Does not 
return (interrupt with Ctrl-C)"

However, that is apparently not the case because if there is not build request 
pending then

35:try:
36:# select the build environment and the request to build
37:   br = self._selectBuildRequest()
38:except IndexError as e:
39:logger.debug("runbuilds: No build request")
40:return

If you use the web UI and schedule (start) a build first and then execute 
runbuilds, then the command eventually fails with:

2016-01-14 21:37:54,086 DEBUG lbc_shellcmmd: () git remote -v
Traceback (most recent call last):
  File 
"/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/management/commands/runbuilds.py",
 line 59, in schedule
bec.triggerBuild(br.brbitbake_set.all(), br.brlayer_set.all(), 
br.brvariable_set.all(), br.brtarget_set.all())
  File 
"/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py",
 line 365, in triggerBuild
self.setLayers(bitbake, layers, targets)
  File 
"/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py",
 line 229, in setLayers
for remotes in self._shellcmd("git remote -v", 
self.be.sourcedir).split("\n"):
  File 
"/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py",
 line 61, in _shellcmd
p = subprocess.Popen(command, cwd = cwd, shell=True, 
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/usr/lib64/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory: ''

This is because the BuildEnvironment object in the database has empty fields 
for Sourcedir and Builddir. One can fix that by going into the Django admin 
interface and enter paths into these fields of the one BuildEnvironment object 
that is in the database.

Once the paths are entered and the build is started again then it breaks where 
runbuilds apparently waits for the Bitbake server to be available:

2016-01-14 22:14:54,565 DEBUG lbc_shellcmmd: (/home/fedora/source) bash -c 
"source 
/home/fedora/source/_toaster_clones/_git___git.yoctoproject.org_poky_master/oe-init-build-env
 /home/fedora/build 2>&1 >toaster_server.log && bitbake --read 
/home/fedora/build/conf/toaster-pre.conf --postread 
/home/fedora/build/conf/toaster.conf --server-only -t xmlrpc -B 0.0.0.0:0 2>&1 
>>toaster_server.log "
2016-01-14 22:14:55,540 DEBUG localhostbecontroller: shellcmd success
2016-01-14 22:14:55,540 DEBUG localhostbecontroller: Found bitbake server port 
33438

2016-01-14 22:14:55,543 DEBUG localhostbecontroller: Waiting bitbake server to 
start

... repeated 50 times ...

2016-01-14 22:15:20,595 ERROR runbuilds: Error launching build 
localhostbecontroller: Bitbake server did not start in 25 seconds, aborting 
(Error: '

That is in the file 
/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py 
at lines:

146 while not started and retries < 50:
147 started = _toaster_ui_started(toaster_ui_log_filepath, 
toaster_ui_log_filelength)
148 import time
149 logger.debug("localhostbecontroller: Waiting bitbake server 
to start")
150 time.sleep(0.5)
151 retries += 1

The function _toaster_ui_started() that checks if Bitbake is running is defined 
as:

133 def _toaster_ui_started(filepath, filepos = 0):
134 if not os.path.exists(filepath):
135 return False
136 with open(filepath, "r") as f:
137 f.seek(filepos)
138 for line in f:
139 if line.startswith("NOTE: ToasterUI waiting for 
events"):
140 return True
141 return False
 
Apparently, it is looking for a line to start with the string "NOTE: ToasterUI 
waiting for events" in the file toaster_ui.log which is located inside the 
build environment that is initialized with oe-init-build-env. I grepped the 
Poky code base for that string and could not find any code module that ever 
writes that string into any file. What the file does contain though is a 

Re: [yocto] Package Level Dependencies

[Rudolf J Streif]

Hi Sebastian,

> I have a recipe (say: "test123") that provides a complex piece of software
> (cmake-based). The software needs some configuration file (say
> "test123.conf"). There are multiple variants of the configuration file,
> sharing the same name, i.e. "test123.conf" exists in different variants for
> multiple hardware configurations.
>
> My aim would be to have multiple packages like "test123-config-XXX" and
> "test123-config-YYY", that cannot be installed at the same time, while
> having one of the packages is a dependency for the main package "test123".

These are two conflicting packages.

> 
> Is there a way to achieve this? From my current understanding, dependencies
> are "per-recipe" and not "per-package". Is there any way to achieve package
> level dependencies? I would like to avoid having multiple recipes as there
> are many configuration file options which are currently located in the same
> large source repository as the main software.

Look at it from the perspective of conflicting packages.

My approach to this would be the following:

1. Write an include file test123.inc that includes all of the guts of your 
recipe.

2. Write the two recipes test123-config-XXX_1.0.bb and test123-config-
YYY_1.0.bb:

test123-config-XXX_1.0.bb

require test123.inc

SRC_URI += "test123-XXX.conf"

do_install_append() {
   # install config file here
   install 544 test123-XXX.conf ${D}/
}

RCONFLICTS_${PN} = "test123-config-YYY"

Analog for test123-config-YYY_1.0.bb


You are essentially sharing all of the recipe through the test123.inc and only 
add the config file to the respective target recipe. The RCONFLICTS_${PN} 
directive will flag an error if both conflicting packages are attempted to be 
installed.

BR,
Rudi

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

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Rudolf J Streif]

Hi Ron,

On Tuesday, April 05, 2016 10:37:07 AM Ronald Oakes wrote:
> When I try to build either emulated or real 64 bit distributions on an
> isolated system running Debian 8.0.3 (using BB_NO_NETWORK = "1"),
> utilizing a downloads directory copied from a system running Centos
> 7.2.1511, I get a failure in the do_install step for Python.
> 

Could you please post the error message from the log file of the install task 
for Python?

> I plan on recopying Python.tar.xz onto my isolated station and trying
> again.  But, if this doesn't resolve the problem are there any
> suggestions?
> 

Considering that according to your info above the failure occurs during the 
install task, the source package is most likely not the culprit. However, the 
source tarball should be named something like Python-2.7.11.tar.xz which 
includes the version number.

> For what it is worth, we're probably going to be moving to newer, but
> still isolated, build stations shortly.  These new stations will be
> running RedHat instead of Debian if that might make a difference.
> 

> Thank You
>   Ron Oakes
> 


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

Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC

[Rudolf J Streif]

Hello Everyone:

If you attended OEDAM last Friday in San Diego, I very much hope that you 
enjoyed being here.

The Catamaran Hotel, where we held the meeting, would very much appreciate your 
feedback:

www.catamaranresort.com/trip

I hope you all had a safe trip back home,
Rudi


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

Re: [yocto] Problems building live image

[Rudolf J Streif]

On Monday, March 14, 2016 04:38:35 PM K Richard Pixley wrote:
> 
> What stops us from building different boot labels for different images?  
> That seems like the obvious choice.  Or perhaps, using "boot" for all 
> syslinux images and adding "install" for "live" images.

Fair question. Nothing really, I would think. The classes need to be adjusted 
to deal with different LABELS.
 :rjs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC

[Rudolf J Streif]

Since I happen to live in San Diego, I have been asking around for a potential 
meeting room (unfortunately, I don't have an office with a meeting room 
myself). I am currently working with the University of San Diego and the 
Catamaran/Bahia Hotel. Can't promise anything yet.

:rjs


On Thursday, March 24, 2016 11:10:41 AM Philip Balister wrote:
> We are up to fifteen now and as noted will have some off site attendees
> and late sign ups.
> 
> Philip
> 
> On 03/23/2016 02:11 PM, Fred Ollinger wrote:
> > I'm coming and I'm probably brining another person.
> > 
> > I still have to make the wiki account which failed for some reason before.
> > 
> > Frederick
> > 
> > From: yocto-boun...@yoctoproject.org  on 
> > behalf of Trevor Woerner 
> > Sent: Wednesday, March 23, 2016 2:08 PM
> > To: akuster808; openembedded-de...@lists.openembedded.org; 
> > openembedded-core; Yocto Project; 
> > openembedded-memb...@lists.openembedded.org
> > Subject: Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC
> > 
> > On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
> >> There are only 10 people signed up.
> >> Is that enough people to justify the expense room or even meet?
> > 
> > I have no idea what the budget might be or what a room might cost. I'll 
> > leave
> > it to those who do know to worry about the costs versus the benefits.
> > 
> > In any case I certainly think it's still worth meeting. A smaller, more
> > focused group can sometimes get more done than a larger group. Secondly, 
> > it's
> > my experience that more people always show up than sign up.
> > 
> > With a project like this there will always be things to discuss, and 
> > sometimes
> > a discussion goes better in person rather than online.
> > 
> > Best regards,
> > Trevor
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> > 
> 

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

[yocto] Building gdb-7.10 for arm with master

[Rudolf J Streif]

At least for arm (I have not tested other arch) building gdb-7.10 with

Build Configuration:
  
BB_VERSION= "1.29.0"
  
BUILD_SYS = "x86_64-linux"  
  
NATIVELSBSTRING   = "Fedora-22" 
  
TARGET_SYS= "arm-poky-linux-gnueabi"
  
MACHINE   = "beaglebone"
  
DISTRO= "poky"  
  
DISTRO_VERSION= "2.0+snapshot-20160305" 
  
TUNE_FEATURES = "arm armv7a vfp  neoncallconvention-hard
cortexa8" 
TARGET_FPU= "hard"  
  
meta
  
meta-poky   
  
meta-yocto-bsp= "master:5cd71fe432c9bdfd3ff519543e96e8caa2b7cf6c"   
  
meta-oe 
  
meta-python   = "master:36aab3f797630e3de680a88523f40ead4ca95d28"   
  
meta-qt5  = "master:88a7f264ef5f64d73881c384d22bf883b2cbf72e"

compile fails with the following error message:

| make[2]: *** No rule to make target '../readline/libreadline.a', needed by 
'gdb'.  Stop.
| make[2]: *** Waiting for unfinished jobs

The reason seems to be a broken path to the built-in readline in the makefile 
as the default configuration is 
--without-system-readline. Enabling

PACKAGECONFIG_append_pn-dbg = " readline"

solves the problem.

I wonder if anybody else has observed this problem?

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

Re: [yocto] [wic] Creating sdimage-bootpart

[Rudolf J Streif]

Hi Ed,

> 
> Interesting. I thought that this commit shoud fix the issue:
> http://cgit.openembedded.org/openembedded-core/commit/?id=264c03e854f77c3b62acb710384f66716ccbf469

Thanks. I was not aware of that patch.

> 
> Which branch do you use?
> 
Jethro. Master seems to be broken right now. It does not compile gdb-7.10.1 (at 
least not for ARM), which is what I need.

:rjs

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

[yocto] [wic] Creating sdimage-bootpart

[Rudolf J Streif]

I tried creating an image with wic using sdimage-bootpart which produces this 
error message:

-
wic create sdimage-bootpart -e core-image-base -D
Checking basic build environment...
Done.

Creating image(s)...


  File 
"/run/media/rstreif/YoctoDevelop/yocto/poky/scripts/lib/wic/imager/direct.py", 
line 67, in __init__
self.ptable_format = self.ks.bootloader.ptable
AttributeError: 'NoneType' object has no attribute 'ptable'
-


The reason for this message is that sdimage-bootpart.wks does not have a 
bootloader entry and consequently self.ks.bootloader = None.

As a workaround you can of course simply adding a bootloader entry to the wks 
even if it's not needed/used when creating an image for Beaglebone etc.

The question is what the correct behavior should be:

1. bootloader entry in wks is mandatory, then the wks parser should flag it as 
an error if it's not present.

2. bootloader entry in wks is optional, then the DirectImageCreator class 
should be able to handle that correctly.


I think the latter should be the correct behavior. However, the 
DirectImageCreator class has some troublesome reliance on that entry, in 
particular that the source plugin for the overall image creation seems to be, 
for convenience reasons supposedly, associated with it.

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

Re: [yocto] Fwd: OEDAM: New Location - Catamaran resort

[Rudolf J Streif]

We need the final headcount by next Monday.

Food, breakfast, lunch and refreshments, will be provided. If you have special 
dietary needs such as vegetarian, gluten-free etc. please indicate so behind 
you name. We'll do the best to accommodate them.

Rudi

On Tuesday, March 29, 2016 12:57:23 PM Philip Balister wrote:
> OEDAM moved. Thanks Rudi and Jefro.
> 
> Please add your name to the attendee list so Jefro can get the correct
> amount of food and coffee. He needs the number "soon".
> 
> Philip
> 
>  Forwarded Message 
> Subject: OEDAM: New Location - Catamaran resort
> Date: Mon, 28 Mar 2016 13:36:41 -0700
> From: Jeff Osier-Mixon 
> Reply-To: openembedded-memb...@lists.openembedded.org
> To: openembedded-memb...@lists.openembedded.org
> 
> 
> The OpenEmbedded meeting on Friday April 8, which was previously
> announced, has been moved to the Catamaran Resort & Hotel.
> Transportation will be provided. The meeting is still 9am-5pm.
> 
> 3999 Mission Boulevard
> San Diego, CA 92109
> 858-539-8727
> 
> Again, OEDAM will be at the Catamaran, NOT at the Marriott. The wiki
> page and this mailing list will be updated with transportation info.
> 
> Thanks to Rudi Streif for finding us a great location!
> 
> 

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

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

[Rudolf J Streif]

Hi Robert,

On Wednesday, May 25, 2016 06:18:34 AM Robert P. J. Day wrote:
> 
>   specifically in the context of powerpc systems, are there any
> suggestions for an image that could be used to boot an older powerpc
> system, running completely out of ram, and using that as an install
> utility which would then be responsible for detecting/formatting a
> hard drive, creating/formatting filesystems, downloading/installing
> the OS, post-install configuration and so on?
> 
I am not entirely sure if I understand your requirements correctly but this 
https://github.com/mendersoftware/mender[1] could eventually be a starting 
point. The good news is that it already comes with YP/OE recipes and 
integration. However, it's currently only for ARM-based systems with u-boot.

Another approach, though still in its infancy and a simple PoC, is the GENIVI 
Software Management (SWM). At the core, there are SqashFS images that may 
contain partition images, software packages, configuration files, etc. together 
with a manifest (JSON) that instructs the SWM what to do. 
(https://github.com/GENIVI/genivi_swm)[2]

Cheers,
:rjs



[1] https://github.com/mendersoftware/mender
[2] https://github.com/GENIVI/genivi_swm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding to inittab based on image content

[Rudolf J Streif]

Hi Colin,

The correct way of doing this is a package postinstallation script that is run 
by the package manager after the package containing your application is 
installed on the target system.

You add to your recipe:

pkg_postinst_${PN}() {
#!/bin/sh
echo "whateveryouneed" >> ${D}/etc/inittab
}

The build system will include this as the post install script into the package 
in the correct form for the package manager you are using e.g. RPM, DEB, IPK.

This will work when the build system installs your package into the system 
root or when executed on the target.

You can also distinguish the two cases:

pkg_postinst_${PN}() {
#!/bin/sh
if [ x"$D" = "x" ] ; then
   # shell commands for target execution
else
   # shell commands for build system execution
fi
}

In the case of target execution $D is not set.

Best regards,
Rudi


On Friday, January 6, 2017 1:39:40 PM PST colin.helliw...@ln-systems.com 
wrote:
> Hi,
> 
> I have a custom recipe for an application, and the app also needs an entry
> adding to inittab. I'd like to trigger this, obviously, only when the app is
> included in the image.
> 
> I came across some hints at how to do this -
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-c
> ore/sysvinit/sysvinit-inittab_2.88dsf.bbappend?h=dizzy - but the app isn't
> in DISTRO_FEATURES. (Right or wrong.., I include it in the image with a
> "CORE_IMAGE_EXTRA_INSTALL +=" in my image recipe).
> 
> Any suggestions on how to make this inittab addition conditional?
> 
> Thanks


-- 
Rudolf J Streif

signature.asc
Description: This is a digitally signed message part.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding to inittab based on image content

[Rudolf J Streif]

On Saturday, January 7, 2017 10:23:50 AM PST Mike Looijmans wrote:
> On 06-01-17 18:17, Rudolf J Streif wrote:
> > Hi Colin,
> > 
> > The correct way of doing this is a package postinstallation script that is
> > run by the package manager after the package containing your application
> > is installed on the target system.
> > 
> > You add to your recipe:
> > 
> > pkg_postinst_${PN}() {
> > #!/bin/sh
> > echo "whateveryouneed" >> ${D}/etc/inittab
> > }
> 
> Problems are that if you upgrade the application on target, it'll be
> included twice, and that when you remove the application, the inittab
> entry remains. If inittab itsef gets upgraded, the entry will be gone.
> 

For the former, you use your imagination and scripting skills to see if the 
entry is already there and remove it or you use pkg_preinst_${PN} to remove 
the entry before installing.

For the latter pkg_prerm_${PN} and pkg_postrm_${PN} are at your disposition.

The problem you stated is actually independent of the build system. It is part 
of the package management. For RPM, for example, the scripts get copied into 
the respective sections of the package manifest:

pgk_preinst -> %pre
pkg_post_inst -> %post
pkg_prerm -> %preun
pkg_postrm -> %postun

Accordingly for the other package management systems.


-- 
Rudolf J Streif

signature.asc
Description: This is a digitally signed message part.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: libreoffice-5.0.5.2-r0 do_package

[Rudolf J Streif]

Ravikiran,

> 
> 
> *ERROR: libreoffice-5.0.5.2-r0 do_package: QA Issue: File
> '/usr/lib/libreoffice/share/extensions/mysql-connector-ooo/libmysqlclient_r.
> so' from libreoffice was already stripped, this will prevent future
> debugging! [already-stripped]*

This error message is produced by the packaging QA. It means that the 
libreoffice's build system (make files) has already stripped the debug symbols 
from the library.

There are two ways to fix this:

The better way: Examine the make files to see where the debug symbols are 
being stripped. Create a patch so that they are not stripped during the 
regular build process. This will allow YP/OE to create the debug package with 
binaries that include the debug symbols and the regular package with the 
binaries without the debug symbols.


The quick fix: Skip this QA check by adding

INSANE_SKIP_libreoffice += "already-stripped"

to the libreoffice recipe.


:rjs

> WARNING: libreoffice-5.0.5.2-r0 do_package: libreoffice language file
> pattern not found:  /usr/lib/libreoffice/share/template/%{1}
> 
> 
> *ERROR: libreoffice-5.0.5.2-r0 do_package: Fatal QA errors found, failing
> task.ERROR: libreoffice-5.0.5.2-r0 do_package: Function failed:
> do_packageERROR: Logfile of failure stored in:
> /home/kamama-yocto/yocto/poky/build/tmp/work/cortexa15hf-neon-poky-linux-gnu
> eabi/libreoffice/5.0.5.2-r0/temp/log.do_package.23588* *ERROR: Task
> (/home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice
> /libreoffice/libreoffice.bb:do_package) failed with exit code '1'*
> NOTE: Tasks Summary: Attempted 8443 tasks of which 8385 didn't need to be
> rerun and 1 failed.
> 
> Summary: 1 task failed:
> 
> /home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice/
> libreoffice/libreoffice.bb: do_package
> Summary: There were 2 WARNING messages shown.
> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
> 
> 
> what is the issue and how to solve this ?
> 
> 
> Best Regards,
> Ravikiran


-- 
Rudolf J Streif

signature.asc
Description: This is a digitally signed message part.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What happened to 'depexp'?

[Rudolf J Streif]

On Friday, March 10, 2017 2:46:55 AM PST Burton, Ross wrote:
> On 10 March 2017 at 10:45, Gary Thomas <g...@mlbassoc.com> wrote:
> > What happened to 'depexp'?  Is 'taskexp' supposed to be the replacement?
> 
> Yes.
> 
> depexp was great at leaving things out, whereas taskexp shows everything.
> 
> It's more, but it's not missing bits.

While I can concur that it is good to have more functionality, why was it 
deemed necessary to entirely deprecate 'depexp'? I think now that the Yocto 
Project is maturing, it would be good to pay more attention to retaining 
backwards compatibility.

I may have missed it, but was there a discussion on the mailing lists about 
deprecating and replacing 'depexp'?

Cheers,



-- 
Rudolf J Streif

signature.asc
Description: This is a digitally signed message part.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core

[Rudolf J Streif]

Thank you, Mark. Much appreciated and understood.

Would you be open to tagging the layer for rocko to the right commit and
applying the patches sent to the mailing list by Armin and Kai to master
so that we have known points to move forward?

Thank you,
Rudi


On 05/11/2018 10:45 AM, Mark Hatle wrote:
> On 5/11/18 12:28 PM, Rudolf J Streif wrote:
>> Echoing this: may I ask what the current maintenance status of
>> meta-selinux is. It appears that no updates have been made for more than
>> 9 months. This is of course not to blame anybody but out of concern that
>> the layer is falling behind even more and to find a solution.
> The answer is the current set of people are horribly overworked and busy, so
> day-to-day updates have been 'sparse'.
>
> Usually we update meta-selinux about the time of a release, and thus are due.
>
> The last update of meta-selinux was about the time of the Rocko release, so 
> what
> is in master is definitely current as of Rocko.  (I did the last set of 
> updates
> -- so I know it did work as of Rocko release.)  The master needs to be 
> branched
> as Rocko... master needs to be updated to be Sumo compatible.
>
> My assumption is that once Sumo is formally released (any minute now), we'll
> collection all of the patches and get them into place and spend some time
> cleaning them up...
>
> It looks like Joe is already working through this effort.
>
> (Only speaking for myself,) I don't have time to do day-to-day maintenance of
> meta-selinux any longer -- nor do I have the indepth knowledge to understand
> when not to do something.  I filled this role purely out of necessity since
> nobody else was doing it.
>
> So with that said, if anyone wants to help, we're all open for help here...  I
> doubt there would be any objection to adding or replacing existing maintainers
> and/or giving more people push access.
>
>> In addition to Armin's patches there are two patches submitted by Kai
>> Kang at Windriver:
>>
>> * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039917.html
>> * https://lists.yoctoproject.org/pipermail/yocto/2018-February/039918.html
>>
>> Curiously enough, the second patch has been applied to master but not
>> the first one.
>>
>>
>> There is also an issue with building SELinux with systemd. The layer
>> enables auditing:
>>
>> meta-selinux/classes/enable-audit.bbclass:PACKAGECONFIG[audit] =
>> "--enable-audit,--disable-audit,audit,"
>> meta-selinux/recipes-core/systemd/systemd_%.bbappend:inherit
>> ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '', d)}
>>
>> Apparently the --enable-audit switch is passed to meson when running the
>> configure task, which meson does not appreciate. I am not that familiar
>> with the audit feature nor with meson, so I currently have no idea on
>> how to fix this the right way.
> audit feature is useful outside of selinux, so my understand was that audit
> itself was moving into core during the sumo time frame (if it hadn't already
> been oved.)
>
> I don't know anything about meson, so I can't speak to that...
>
>> Further, refpolicy_git does not build anymore as the YP specific patches
>> do not apply anymore since upstream changed.
> The refpolicy is and has always been crap.  I've been talking to a few people 
> on
> IRC about working to replace the refpolicy with a policy that can be generated
> dynamically based on the contents of the recipes.  I don't know if that is
> really going to happen, but I hate the way it's currently implemented.
>
> One of the key issues about the refpolicy is that you need to be an expert at
> this (which I never claimed to be) in order to make any reasonable decision --
> add to that any specific policy needs to userstand overall system design, and 
> I
> wouldn't trust any of the refpolicy items as they stand in meta-selinux.
>
> --Mark
>
>> Thanks,
>> Rudi
>>
>>
>>
>> On 05/07/2018 10:20 AM, akuster808 wrote:
>>> On 04/14/2018 07:08 PM, Armin Kuster wrote:
>>>> Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 
>>>> 'restorecond', 'libselinux', 'python-importlib']
>>>>
>>>> Signed-off-by: Armin Kuster <akus...@mvista.com>
>>> ping
>>>> ---
>>>>  recipes-security/selinux/libselinux.inc | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/recipes-security/selinux/libselinux.inc 
>>>> b/recipes-security/selinux/libselinux.inc
>>>> index bd5ce8d..51d0875 100644
>>>> --- a/recipe

Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core

[Rudolf J Streif]

Echoing this: may I ask what the current maintenance status of
meta-selinux is. It appears that no updates have been made for more than
9 months. This is of course not to blame anybody but out of concern that
the layer is falling behind even more and to find a solution.

In addition to Armin's patches there are two patches submitted by Kai
Kang at Windriver:

* https://lists.yoctoproject.org/pipermail/yocto/2018-February/039917.html
* https://lists.yoctoproject.org/pipermail/yocto/2018-February/039918.html

Curiously enough, the second patch has been applied to master but not
the first one.


There is also an issue with building SELinux with systemd. The layer
enables auditing:

meta-selinux/classes/enable-audit.bbclass:PACKAGECONFIG[audit] =
"--enable-audit,--disable-audit,audit,"
meta-selinux/recipes-core/systemd/systemd_%.bbappend:inherit
${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-audit', '', d)}

Apparently the --enable-audit switch is passed to meson when running the
configure task, which meson does not appreciate. I am not that familiar
with the audit feature nor with meson, so I currently have no idea on
how to fix this the right way.


Further, refpolicy_git does not build anymore as the YP specific patches
do not apply anymore since upstream changed.


Thanks,
Rudi



On 05/07/2018 10:20 AM, akuster808 wrote:
>
> On 04/14/2018 07:08 PM, Armin Kuster wrote:
>> Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 
>> 'restorecond', 'libselinux', 'python-importlib']
>>
>> Signed-off-by: Armin Kuster <akus...@mvista.com>
> ping
>> ---
>>  recipes-security/selinux/libselinux.inc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-security/selinux/libselinux.inc 
>> b/recipes-security/selinux/libselinux.inc
>> index bd5ce8d..51d0875 100644
>> --- a/recipes-security/selinux/libselinux.inc
>> +++ b/recipes-security/selinux/libselinux.inc
>> @@ -8,7 +8,7 @@ LICENSE = "PD"
>>  inherit lib_package pythonnative
>>  
>>  DEPENDS += "libsepol python libpcre swig-native"
>> -RDEPENDS_${PN}-python += "python-importlib"
>> +RDEPENDS_${PN}-python += "python-core"
>>  
>>  PACKAGES += "${PN}-python"
>>  FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"

-- 
Rudolf J Streif




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] porting gRPC into Yocto

[Rudolf J Streif]

Hi Simon,

Thank you for using the Yocto Project and reaching out.

For any open-source component that you would like to add to the Yocto
Project I recommend that you first have a look at
http://layers.openembedded.org/layerindex/branch/master/recipes/ and
enter the name of the component. Chances are that somebody already did
the work. This is indeed the case with gRPC:
http://layers.openembedded.org/layerindex/recipe/72419/.

If you cannot find a recipe for the component then you should look at
how the component is built. Most C/C++ components use some sort of a
build system such as GNU Autotools or CMake. The Yocto Project
documentation has sections for the common build systems.

I hope this answers your question.

Rudi


On 06/21/2018 11:15 AM, Simon Chamlian wrote:
> Hi,
>
> I just started using Yocto.
>
> Is there a detailed procedure on how I can port gRPC (for C or C++)
> into a Yocto project?
>
> Thanks,
>
> S
>
>
>
>
>
>
>
>
-- 
Rudolf J Streif



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to tell bitbake my prefered terminal in for devshell and access bitbake datastore?

[Rudolf J Streif]

You can use the variable OE_TERMINAL to choose your preferred terminal.
By default it's set to auto and Bitbake figures out what terminal is
available on your system. Please refer to the manual at:
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-OE_TERMINAL.

> Also, is it possible to access bitbake datastore from inside the
devshell(or devpyshell) ?

You cannot access d if you mean that, however, all the variables are
exported to the shell.

:rjs


On 07/23/2018 02:49 AM, MOHAMMAD RASIM wrote:
> Hi,
>
> when running bitbake with a recipe and giving the devshell as a
> command bitbake runs the devshell inside xterm, on my other machine it
> runs tmux.
>
> looking at the openembedded source code here
> https://github.com/openembedded/openembedded-core/blob/master/meta/lib/oe/terminal.py
>
> I can see there are multiple classes for terminals that bitbake loop
> through, but how can I tell bitbake that I prefer a certain terminal?
>
> Also, is it possible to access bitbake datastore from inside the
> devshell(or devpyshell) ?
>
> Regards
>

-- 
Rudolf J Streif




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Which bb is chosen when several versions are available

[Rudolf J Streif]

The one with the higher version number unless explicitly overridden with
PREFERRED_VERSION_php.

However, if there is also a recipe with _git.bb then that one will
be chosen as git indicates the latest.

:rjs


On 07/11/2018 12:28 PM, Simon Chamlian wrote:
> Hi,
>
> In the BSP yocto image, I have 2 recipes:
>
> /sources/meta-openembedded/meta-oe/recipes-devtools/php
>
> drwxrwxr-x 2 jay jay  4096 Jun 28 09:48 php
> -rw-rw-r-- 1 jay jay   232 Jun 28 09:48 php_5.5.38.bb
> <http://php_5.5.38.bb>
> drwxrwxr-x 2 jay jay  4096 Jun 28 09:48 php-5.6.26
> -rw-rw-r-- 1 jay jay   291 Jun 28 09:48 php_5.6.26.bb
> <http://php_5.6.26.bb>
> -rw-rw-r-- 1 jay jay 11980 Jun 28 09:48 php.inc
>
>
> If I add in my image recipe:
> CORE_IMAGE_EXTRA_INSTALL += " \
>     php \  
> "
>
> which version will be included?
>
> Thanks,
> S
>
>
>

-- 
Rudolf J Streif



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Keeping and modifying Source code in Yocto

[Rudolf J Streif]

Hi Simon,

> Is there a way to keep the source code of a package to be able to
modify it and then compile?

Yes, there is. devtool greatly simplifies this type of workflow. Please
refer to
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#using-devtool-in-your-sdk-workflow
for details.

:rjs


On 07/06/2018 08:20 AM, Simon Chamlian wrote:
> Hi,
>
> Is there a way to keep the source code of a package to be able to
> modify it and then compile?
>
> For example, with LTIB ( Linux Target Image Builder ), it was possible
> with a command to extract the source code from a package, make
> modifications and then re-compile?
>
> Thanks,
> S
>
>
>
>
>
>
>

-- 
Rudolf J Streif



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Setting up a password for the root user

[Rudolf J Streif]

Alberto,

The quotes around

`openssl passwd ${ROOT_PASSWORD}`

have to be backticks (`) not single quotes (').

:rjs


On 01/11/2019 07:41 AM, Alberto Spin wrote:
>
> Hello There,
>
>  
>
> I’m trying to set a password for the root user of my distribution
> (based rocko branch)
>
>  
>
> I’ve added the following to my image recipe:
>
>  
>
> inherit extrausers
>
>  
>
> # set image root password
>
> ROOT_PASSWORD = "secret"
>
>  
>
> EXTRA_USERS_PARAMS = "\
>
>     usermod -p 'openssl passwd ${ROOT_PASSWORD}' root; \
>
>     "
>
>  
>
> Everything builds fine, but in my image I end up with a password in my
> /etc/shadow file like this:
>
>  
>
> openssl passwd secret
>
>  
>
> so it seems like the openssl command has not been executed during the
> build, but instead the literal command is now part of my password.
>
>  
>
> Can anybody please explain what’s going on here, and how to fix this?
>
>  
>
> Kind Regards,
>
>  
>
> Alberto
>
>  
>
>  
>
>  
>
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] local.conf confusion

[Rudolf J Streif]

Greg,

I am not entirely sure why you are including a machine configuration
include file into your conf/local.conf file.

However, the "include" directive is optional include and hence if the
file is not found Bitbake will not raise an error and terminate. If you
need that behavior use "require" instead.

Machine configuration files do commonly use includes for shared
configuration. You typically find them where the machine configuration
files are: conf/machine or in a subdirectory there. The directory
conf/machine is commonly found in BSP layers such as meta-raspberrypi
which you are probably using as you are building for RPi.

:rjs

On 2/20/19 10:16 AM, Greg Wilson-Lindberg wrote:
> Hello list,
>
> I've run into a confusion that should be simple. I've got a build based on 
> sumo, at the bottom of my local.conf file is the line:
>
> include conf/distro/include/${MACHINE}.pre.inc
>
> This should be straight forward, just find the conf/distro/include directory 
> and all of the *.pre.inc files should be there. I just searched all of the 
> sources directory for  '*.pre.inc' and I get nothing. I'm building for a 
> raspberry pi3, so I would expect at least 'raspberry*.inc', still nothing. 
> I'm not getting an error for bitbake not being able to find the file.
>
> So where do I find the machine include files?
>
> Regards,
> Greg Wilson-Lindberg  
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem adding a user

[Rudolf J Streif]

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you 
use the single ones your password in the /etc/shadow ends up being 
'openssl passwd test' (without the quotes), unless the build fails 
because of a parsing error (I have not tried it). Silly question, you 
did inherit extrausers class?



Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been 
doing this a gazillion times always with success.



:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:


Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that 
I'm using reduces to:


EXTRA_USERS_PARAMS = "\
 useradd -p `openssl passwd test` sakura; \
 usermod -a -G sudo ${SAKURA_USER}; \
 "
I also, as you can see, removed the macros to eliminate as much 
confusion as possible.



I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg


*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 10:07:47 AM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the results.


:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the 
Yocto Project" to add a user to my Yocto build. In the book the sample 
code:

>
> useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to 
useradd. I have never been able to get this to work. When I run the 
openssl
> command on the cmd line I get a different value every time, this 
seems wrong, How can the password code compare against it if every encode

> produces a different value?
>
> I am getting the user added to the system, the home directory shows 
up and the user is in the passwd and group files. I just can't login 
to the

> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>

--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] problem adding a user

[Rudolf J Streif]

Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash 
algorithm if no other options are specified. e.g.


$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the 
rest is the password hash. If you want openssl to create the same result 
again:


$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The 
system reads the salt, creates the password hash and compares the results.



:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:

I'm trying to use the example in "Embedded Linux Systems with the Yocto 
Project" to add a user to my Yocto build. In the book the sample code:

useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \

uses openssl to generate the encrypted password string to pass to useradd. I 
have never been able to get this to work. When I run the openssl
command on the cmd line I get a different value every time, this seems wrong, 
How can the password code compare against it if every encode
produces a different value?

I am getting the user added to the system, the home directory shows up and the 
user is in the passwd and group files. I just can't login to the
account.

I've obviously got something confused, any help would be appreciated.

Greg Wilson-Lindberg
  


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] problem adding a user

[Rudolf J Streif]

The ! for the password in /etc/shadow indicates that the account is 
disabled:


sakura:!:18031:0:9:7:::


Either there is something wrong with the password generation or it gets 
disabled by something else. Maybe it's worth trying with a plain image 
without Boot2Qt or anything else.



:rjs



On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:


Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 
using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.



Greg


*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 11:26 AM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user

Hi Greg,


> I've also tried both the back-quote and the single-quote, no difference.


Help me to understand this. the back-quotes are the right ones. If you 
use the single ones your password in the /etc/shadow ends up being 
'openssl passwd test' (without the quotes), unless the build fails 
because of a parsing error (I have not tried it). Silly question, you 
did inherit extrausers class?



Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been 
doing this a gazillion times always with success.



:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:


Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code that 
I'm using reduces to:


EXTRA_USERS_PARAMS = "\
 useradd -p `openssl passwd test` sakura; \
 usermod -a -G sudo ${SAKURA_USER}; \
 "
I also, as you can see, removed the macros to eliminate as much 
confusion as possible.



I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg

----
*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 10:07:47 AM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt hash
algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same result
again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the 
results.



:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the 
Yocto Project" to add a user to my Yocto build. In the book the 
sample code:

>
> useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to 
useradd. I have never been able to get this to work. When I run the 
openssl
> command on the cmd line I get a different value every time, this 
seems wrong, How can the password code compare against it if every encode

> produces a different value?
>
> I am getting the user added to the system, the home directory shows 
up and the user is in the passwd and group files. I just can't login 
to the

> account.
>
> I've obviously got something confused, any help would be appreciated.
>
> Greg Wilson-Lindberg
>

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] problem adding a user

[Rudolf J Streif]

Instead of


useradd -p `openssl passwd test` sakura


which attempts to add the user and set the password which fails if the 
user already exists, use



usermod -p `openssl passwd test` sakura


which sets the user's password.


:rjs


On 5/15/19 1:18 PM, Greg Wilson-Lindberg wrote:


Ok, I had been using the useradd class in a couple of other recipes to 
allow me to copy files to the sakura user directory and another 
location, but owned by sakura. That seems to have been what was 
causing the problem.



I had been using the extrausers class in my top level image recipe.


So now how do I get all of this to work together? Do I need to put 
everything that touches the sakura user in the same recipe? It seems 
that I need to use only one of the useradd or extrausers classes?



Greg


*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 12:31 PM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user

The ! for the password in /etc/shadow indicates that the account is 
disabled:


sakura:!:18031:0:9:7:::


Either there is something wrong with the password generation or it 
gets disabled by something else. Maybe it's worth trying with a plain 
image without Boot2Qt or anything else.



:rjs



On 5/15/19 11:46 AM, Greg Wilson-Lindberg wrote:


Hi Rudolf,

1st, yes I inherit extrausers. Attached are the passwd & shadow files.


It shouldn't make any difference, but I'm building this for an RPi3 
using the Qt Boot2Qt version of the Yocto environment, distro 2.5.3.



Greg


*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 11:26 AM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user

Hi Greg,


> I've also tried both the back-quote and the single-quote, no 
difference.



Help me to understand this. the back-quotes are the right ones. If 
you use the single ones your password in the /etc/shadow ends up 
being 'openssl passwd test' (without the quotes), unless the build 
fails because of a parsing error (I have not tried it). Silly 
question, you did inherit extrausers class?



Can you post your /etc/passwd and /etc/shadow


I am surprised that this does not work with your setup. I have been 
doing this a gazillion times always with success.



:rjs




On 5/15/19 11:03 AM, Greg Wilson-Lindberg wrote:


Hi Rudolf,

Thanks for the reply, and the information on how openssl works.


I'm trying to create a user with the same group name so the code 
that I'm using reduces to:


EXTRA_USERS_PARAMS = "\
 useradd -p `openssl passwd test` sakura; \
 usermod -a -G sudo ${SAKURA_USER}; \
 "
I also, as you can see, removed the macros to eliminate as much 
confusion as possible.



I still can't login in using the password 'test'.


I've also tried both the back-quote and the single-quote, no difference.

Regards,


Greg

----
*From:* Rudolf J Streif 
*Sent:* Wednesday, May 15, 2019 10:07:47 AM
*To:* Greg Wilson-Lindberg; Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Hi Greg,

Well, I suppose I wrote the book you are referring to...


Using

useradd -p PASSWORD USER

takes the password hash for PASSWORD hence the use of openssl in:

useadd -p `openssl passwd PASSWORD` USER

openssl password creates the password hash using the original crypt 
hash

algorithm if no other options are specified. e.g.

$ openssl passwd hello
6hEsTksgRkeiI

With this the first two characters of the output is the salt and the
rest is the password hash. If you want openssl to create the same 
result

again:

$ openssl passwd -salt "6h" hello
6hEsTksgRkeiI

You can use newer algorithms like MD5 based BSD password algorithm 1:

$ openssl passwd -1 hello
$1$4Mu8Fcs.$eIKgPP7RCYrb3lFZjhADA1

$1 : password algorithm 1
$4Mu8Fcs. : salt
$eIKgPP7RCYrb3lFZjhADA1 : password hash


If you log into the system you have to use the clear password. The
system reads the salt, creates the password hash and compares the 
results.



:rjs


On 5/14/19 5:34 PM, Greg Wilson-Lindberg wrote:
> I'm trying to use the example in "Embedded Linux Systems with the 
Yocto Project" to add a user to my Yocto build. In the book the 
sample code:

>
> useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
>
> uses openssl to generate the encrypted password string to pass to 
useradd. I have never been able to get this to work. When I run the 
openssl
> command on the cmd line I get a different value every time, this 
seems wrong, How can the password code compare against it if every 
encode

> produces a different value?
>
> I am getting the user added to the system, the home directory 
shows up and the user is in the passwd and group files. I just can't 
login to the

>

Re: [yocto] Creating my own bsp

[Rudolf J Streif]

Larry,

You would want to be more specific with your question and eventually
post error messages you are encountering. It looks like you are hung up
at the machine configuration file. You may want to post that. As far as
BSP layers and machine configuration files are concerned, my advice is
to start with an existing configuration that is close to your actual
hardware.

:rjs

On 6/21/19 10:46 AM, Larry Brown wrote:
> I've come across references to "yocto-bsp" script that should help
> build a bsp.  I'm starting from scratch with an arm 7M and trying to
> use the raspberrypi bsp as a reference.  There is so much complexity
> I'm not sure where to start.
>
> After setting up the files for the Linux kernel I'm using already on
> the board and the config, it first complained about TUNE_ARCH not
> being present.  This is not present in the meta-raspberrypi content
> but based on something I came across this just wants arm.  Then it
> complains TUNE_PKGARCH is not set.  I don't know what this is looking
> for and I'm not getting effective hits searching for it.  I'm guessing
> there are going to be a lot more after these two complaints.  It would
> be nice to read what went into a simple bsp that worked under for an
> arm board.
>
> PS I'm using the warrior release as it worked for bringing up the
> raspberry pi.
>
> Any help would be greatly appreciated. 
>
> -- 
> Larry Brown
>
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto-Advocacy] Yocto Project Upcoming Conferences and Developer Days

[Rudolf J Streif]

Chiming in here

On 5/7/19 11:18 AM, Behan Webster wrote:
On May 7, 2019, at 2:47 AM, Bas Mevissen <mailto:ab...@basmevissen.nl>> wrote:


On 2019-05-07 07:20, Behan Webster wrote:

> On May 6, 2019, at 8:36 AM, Bas Mevissen <mailto:b...@emcodev.nl>> wrote:

> On 5/6/19 12:45 PM, Josef Holzmayr wrote:
> I'd actually word it a little bit differently:
> If there is only *ONE* attendee who did not properly do the 
homework, it

> will have a massive impact an the rest of the group. And that somebody
> will show up unpreparedly is absolutely certain in my opinion.
> With sufficient trainers, one can continue for most and provide 
some assistance to the one falling behind.


Usually more than one. And this is generally very disruptive to the 
class as a whole.


There are always people who are prepared to the T and others who just 
casually stroll into the class. We all know that as we all went through 
various stages of schooling. :) No matter what you do, there always will 
be a glitch. I tried it all from course preparation instructions, shell 
scripts setting up systems, USB sticks and network drives with downloads 
and shared state cache, virtual machine images, build systems set up in 
the cloud, you name it. If it is not somebody who is unprepared it is a 
technical issue: lack of disk space, network connectivity, corporate 
computers that do not allow USB sticks,... Instructors just have to deal 
with it.
>> As someone who actually got started through the YPDD beginner 
track (and
>> also often recommends it to new beginners), my opinion is clearly 
that

>> we either should have it, be it only for a handful of attendees, or
>> offer a *real* replacement, with face to face training. My 
experience is

>> that this personal thing in the very beginning is an absolutely
>> essential part of many YP/OE careers.
>
> I agree. That is how I started, next to a compressed Linux 
Foundation Yocto training that was offered just before the event then.



Yes. By me and my colleagues who train for the Linux Foundation.


> So it might be wise to ask LF or get something organised. It would 
mostly require a room and a sponsor for some small devkit.


We've run the beginner track for the last few years. The discussion 
is precisely that the YP event is proposing to not run the beginner 
track this year at all.


But why? There appears to be a constant demand.


An excellent question. I agree with you. I don’t have an answer 
however. Not my decision.


I certainly would advocate to have the beginner track. It's a good way 
of getting people interested, and eventually excited, for the Yocto 
Project. Conferences and dev days are an opportunity to do advertising 
and to grow the community. We cannot do that just by catering to people 
who are already using YP. We need new folks as we are already running 
into issues where things have to be dropped because there is nobody who 
is maintaining it.




We're happy to do it again if given the space.


Yes, both for LF and YP it are off-the-shelf trainings that do not 
require much preperation.


Speaking as a course maintainer for LF, keeping the YP course updated 
is actually a tremendous amount of work (I’m the co-maintainer for the 
LF YP course).


However, the beginner slides tend not to need more than a few hours of 
updates every 6 months (which again is something I do).


Either may appear off-the-shelf, but they aren’t from my perspective. ;)


I can wholeheartedly second that. I developed the original YP class of 
the LF and taught it many times and have since developed my own class 
material teaching classes. While the basic concept of course remains the 
same it is the little details that change. With every new version of the 
YP a course maintainer has to go through every single exercise and 
example in the course material and try it out again to see if it still 
works. And quite frankly, sometimes it is rather silly things that have 
changed and break something.


In particular for a beginner class lasting one day only, every single 
disruption sets the class back and there is no opportunity to recover 
from it. The day is already packed just to cover the core concepts.


Cheers,
Rudi




Thanks,

Behan


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf J Streif]

I tried to build for 32 bit with:

Build Configuration:
BB_VERSION   = "1.43.0"
BUILD_SYS    = "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "raspberrypi3"
DISTRO   = "poky"
DISTRO_VERSION   = "2.7+snapshot-20190519"
TUNE_FEATURES    = "arm vfp cortexa7 neon vfpv4 thumb 
callconvention-hard"

TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "master:ff472ffbb0d143de8187d84dbbf18453318f303f"
meta-raspberrypi = "master:7059c374512f1c1c0df9ecab0703d11438bdf78b"
meta-oe
meta-multimedia
meta-networking
meta-python  = "master:1ecd8b43645883cd4fa652826e93137c942dd82c"

However, mesa-gl; now fails compiling:

ld: src/gbm/cd6bfad@@gbm@sha/main_backend.c.o: in function 
`_gbm_create_device':
| 
/usr/src/debug/mesa-gl/2_19.0.3-r0/build/../mesa-19.0.3/src/gbm/main/backend.c:104: 
undefined reference to `gbm_dri_backend'


I have not encountered that before when building for raspberrypi3 before.

:rjs

On 5/19/19 9:11 AM, Khem Raj wrote:



On Sat, May 18, 2019 at 11:02 PM Rudolf Streif 
mailto:rudolf.str...@ibeeto.com>> wrote:


Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics.


Please try 32bit we only have hdmi tested in 64bit this far



On Sat, May 18, 2019, 22:13 Khem Raj mailto:raj.k...@gmail.com>> wrote:



On 5/16/19 9:01 AM, Andrei Gherzan wrote:
> HI,
>
> On 16/05/2019 16.31, Rudolf J Streif wrote:
>> I am trying to use the "official" RPi 7" touch display
>>
(https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
>> with meta-raspberrypi (most recent from master). However, I
cannot get
>> it to work. As a matter of fact the display does not even
show the GPU
>> rainbow screen making me think that the GPU firmware
packaged with
>> meta-raspberrypi does not support the DSI display. It works
just fine
>> with the latest Raspbian release (screen and touch).
>>
>> I searched the web up and down but could not find anything.
Maybe
>> somebody has an idea? Wrong firmware (maybe cannot be
distributed
>> because of licensing...)?
> Sadly we don't actively test display and other related toys
so they
> might be broken. Even so, I would be surprised if the DSI
    port doesn't
> work. What is you final config.txt (pastebin it please)?
>

are you building 64bit or 32bit images ?
are you using vc4grpahics or userland graphics ?


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf J Streif]

No, unfortunately not. HDMI works just fine but no video on the touch 
display.


On 5/16/19 9:46 AM, Andrei Gherzan wrote:

Hi,

On 16/05/2019 17.24, Rudolf J Streif wrote:

Thank you, Paul. I did read Andrei's excellent documentation and
enabled I2C and SPI etc.

And it didn't work?


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf J Streif]

Thank you, Paul. I did read Andrei's excellent documentation and enabled 
I2C and SPI etc.


:rjs

On 5/16/19 8:39 AM, Paul Barker wrote:

On Thu, 16 May 2019, at 16:33, Rudolf J Streif wrote:

I am trying to use the "official" RPi 7" touch display
(https://www.raspberrypi.org/products/raspberry-pi-touch-display/) with
meta-raspberrypi (most recent from master). However, I cannot get it to
work. As a matter of fact the display does not even show the GPU rainbow
screen making me think that the GPU firmware packaged with
meta-raspberrypi does not support the DSI display. It works just fine
with the latest Raspbian release (screen and touch).

I searched the web up and down but could not find anything. Maybe
somebody has an idea? Wrong firmware (maybe cannot be distributed
because of licensing...)?

I'd recommend looking at 
https://github.com/agherzan/meta-raspberrypi/blob/master/docs/extra-build-config.md
 to see if there's some extra option you need to enable. If there's nothing 
documented there then raise an issue on the GitHub repository.

Cheers,


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf J Streif]

Thank you, Andrei. Much appreciated.

https://pastebin.com/bHUHaRkL

It's the config.txt that is packaged with the image.

:rjs

On 5/16/19 9:01 AM, Andrei Gherzan wrote:

HI,

On 16/05/2019 16.31, Rudolf J Streif wrote:

I am trying to use the "official" RPi 7" touch display
(https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
with meta-raspberrypi (most recent from master). However, I cannot get
it to work. As a matter of fact the display does not even show the GPU
rainbow screen making me think that the GPU firmware packaged with
meta-raspberrypi does not support the DSI display. It works just fine
with the latest Raspbian release (screen and touch).

I searched the web up and down but could not find anything. Maybe
somebody has an idea? Wrong firmware (maybe cannot be distributed
because of licensing...)?

Sadly we don't actively test display and other related toys so they
might be broken. Even so, I would be surprised if the DSI port doesn't
work. What is you final config.txt (pastebin it please)?


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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Rudolf J Streif]

Khem,

Yes, the 32-bit image (raspberrypi3 machine) works.

:rjs

On 5/19/19 9:11 AM, Khem Raj wrote:



On Sat, May 18, 2019 at 11:02 PM Rudolf Streif 
mailto:rudolf.str...@ibeeto.com>> wrote:


Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics.


Please try 32bit we only have hdmi tested in 64bit this far



On Sat, May 18, 2019, 22:13 Khem Raj mailto:raj.k...@gmail.com>> wrote:



On 5/16/19 9:01 AM, Andrei Gherzan wrote:
> HI,
>
> On 16/05/2019 16.31, Rudolf J Streif wrote:
>> I am trying to use the "official" RPi 7" touch display
>>
(https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
>> with meta-raspberrypi (most recent from master). However, I
cannot get
>> it to work. As a matter of fact the display does not even
show the GPU
>> rainbow screen making me think that the GPU firmware
packaged with
>> meta-raspberrypi does not support the DSI display. It works
just fine
>> with the latest Raspbian release (screen and touch).
>>
>> I searched the web up and down but could not find anything.
Maybe
>> somebody has an idea? Wrong firmware (maybe cannot be
distributed
>> because of licensing...)?
> Sadly we don't actively test display and other related toys
so they
> might be broken. Even so, I would be surprised if the DSI
port doesn't
> work. What is you final config.txt (pastebin it please)?
>

    are you building 64bit or 32bit images ?
are you using vc4grpahics or userland graphics ?


--
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] Yocto Project @ ELC NA 2019

[Rudolf J Streif]

Hi Andrea,

Great. I can bring some wooden blocks to prop up the rear-end. People 
could sit in it and spin the wheels.


:rjs

On 5/2/19 2:39 PM, Volosincu, Andreea S wrote:

Hi Rudi,

That's awesome! I will check with LF events to see if there are any issues with 
showing that or restrictions with how people engage with it during the show.
Definitely in favor of showing the whole gokart.

Thanks!
Andreea

-Original Message-
From: Rudolf J Streif [mailto:rudolf.str...@ibeeto.com]
Sent: Thursday, May 2, 2019 2:36 PM
To: Volosincu, Andreea S ; Nicolas Dechesne 

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

Hi Andrea,

I was intending to bring the whole gokart. It's more fun to see the speedometer 
go up when you push down on the pedal and the regen to kick in when letting go 
etc. Everybody has seen hundreds of instrument cluster demos (at least when you 
work for the automotive industry). It might be a crowd catcher too (at least 
that's what I figured when I was at CES this year; a booth with a vehicle had 
many spectators :).

Please see early picture (without cluster) attached.

:rjs

On 5/2/19 2:17 PM, Volosincu, Andreea S wrote:

Hi Rudi,

That sounds super interesting. We do have a 6'x6' exhibit booth on the show 
floor, and a DevDay on Tuesday, August 20.

Are you planning to show just the instrument cluster, or the whole gokart? If 
the gokart, I would just need to check with LF and see if we are allowed to 
have that on the show floor. It's certainly a new thing we haven't tried or had 
before.

Thanks!
Andreea

-Original Message-
From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org]
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif ; Volosincu, Andreea S

Cc: Yocto list discussion 
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

hi Rudolf,

+Andreea (Yocto Advocacy)

we are definitely planning to be at ELC, with a similar setup as with past ELC 
: booth, demo, DevDay and BoF, well, at least !

cheers
nico

On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif  wrote:

I apologize if I missed any communication on this mailing list but
what are the plans for a presence of YP at ELC NA in August in San
Diego this year?

Unfortunately, I missed the deadline for submitting a speaking
proposal ("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC.
However, if YP is planning on a presence at ELC I'd be happy to
support it as I, conveniently, live in San Diego. If there is a YP
exhibition I might be able to bring my little hobby project, an
electric gokart with YP-based instrument cluster (it's a full-size
kart with 13 kW AC motor and a LiFePo battery pack producing up to 25
kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

[yocto] Yocto Project @ ELC NA 2019

[Rudolf J Streif]

I apologize if I missed any communication on this mailing list but what 
are the plans for a presence of YP at ELC NA in August in San Diego this 
year?


Unfortunately, I missed the deadline for submitting a speaking proposal 
("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However, 
if YP is planning on a presence at ELC I'd be happy to support it as I, 
conveniently, live in San Diego. If there is a YP exhibition I might be 
able to bring my little hobby project, an electric gokart with YP-based 
instrument cluster (it's a full-size kart with 13 kW AC motor and a 
LiFePo battery pack producing up to 25 kW peak power output going up to 
45 mph (electronically limited)).


Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

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

Re: [yocto] kernel modul install

[Rudolf J Streif]

Michael,

You might want to share your recipe.

Since do_install works on a private sysroot for your recipe it is
unlikely that your module conflicts with a module with the same name
from another recipe. You might install the module twice or you might
have some leftovers from your development process. You might want to
start with a clean environment: bitbake -c cleanall .

:rjs

On 8/26/19 7:15 AM, Michael Eichhorn wrote:
> Dear all,
>  
> i am new to yocto and i created a recipe for a kernel modul for my bt
> and wifi chip.
> it seems that everthing works, but in my do_install i receive an error:
> ...is trying to install files into a shared area when those files
> already exist...
> My receipe is somehow producing an bluetooth.ko which is already
> existing because
> of my linux-mainline recipe.
> What can i do? the relevant one is the one from my chip recipe.
>  
> Best regards,
> Michael
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto build failed to include service file in /deplogy/images/image.wic.gz

[Rudolf J Streif]

JH,

To enable systemd service for your application your  recipe needs to
inherit the systemd class and install the service file in the proper
directory. Here is what it should look like:

inherit systemd

SYSTEMD_SERVICE_${PN} = "my-app.service"
SYSTEMD_AUTO_ENABLE = "enable"

do_install_append () {
    install -d ${D}${systemd_system_unitdir}
    install -m 0644 ${S}/my-app.service ${D}${systemd_system_unitdir}
}

SYSTEMD_AUTO_ENABLE = "enable" is not strictly required as it is the
default. If you don't want to enable your service by default set the
variable to "disable".

:rjs

On 7/31/19 4:04 PM, JH wrote:
> HI,
>
> I have been struggling to find a fix for missing service file, I found
> another solution posted from the Internet to use FILES_${PN} +=
> "${systemd_system_unitdir}/dl-mgr.service" at the end of the bb file:
>
> install -d ${D}${systemd_system_unitdir}
> install -m 0644 ${WORKDIR}/dl-mgr.service ${D}${systemd_system_unitdir}
>
> As well as this to the end of the .bb file
>
> FILES_${PN} += "${libexecdir}/dl-mgr.sh"
> FILES_${PN} += "${systemd_system_unitdir}/dl-mgr.service"
>
> But I could not build it "unprased line FILES_${PN} +=
> "${systemd_system_unitdir}/dl-mgr.service", could anyone help please?
>
> Thank you.
>
> Kind regards,
>
> - JH

-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Meta-raspberrypi

[Rudolf J Streif]

Hi Shravan,

You need to checkout warrior from your meta-raspberrypi repo that you
cloned. It looks as it is on the latest master.

:rjs

On 7/22/19 3:07 PM, Shravan Singh wrote:
> Hello All,
>
> I am trying to create a base image for raspberry-pi cm3(compute module 3)
>
> I am using warrior-21.0.1
> I downloaded meta-raspberry-pi from 
> https://git.yoctoproject.org/git/meta-raspberrypi
> I added the layer in bblayer.conf and I have changed the machine
> variable in local.conf
> to *raspberrypi-cm3*
> I am using oe-init-build script to generate the base files
>
> Now when I run the command
> bitbake core-image-base
>
> I get the below mentioned error
> Error: No recipes available for:
> /home/blue/yacto/meta-raspberrypi/recipes-bsp/u-boot/u-boot_2019.07.bbappend
> /home/blue/yacto/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.16%.bbappend
>
>
> Any help with this?
>
>
> Regards,
> Shravan Singh
> (239) 243-0838
>
> Blue Sparq, Inc.
> 928 NE 24th Lane unit 4 and 5.
> Cape Coral, FL 33993
>
> IMPORTANT: The contents of this email and any attachments are
> confidential. They are intended for the named recipient(s) only. If
> you have received this email by mistake, please notify the sender
> immediately and do not disclose the contents to anyone or make copies
> thereof.
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Make the service the last run in boot

[Rudolf J Streif]

Adding

After=multi-user.target

to the [Unit] section in your systemd service file should do what you want.

:rjs

On 8/1/19 4:08 AM, JH wrote:
> The application requires network connection to communicate services
> via Internet, it could only work if the network connection is ready,
> so I really want to know which system servuce run at last I could put
> it in the After statement.
>
> On 8/1/19, ChenQi  wrote:
>> On 08/01/2019 03:37 PM, JH wrote:
>>> Hi,
>>>
>>> How can I find the systemd last run service I can put it in my network
>>> application After=?
>>>
>>> I need my network application service to be run at last in boot, I
>>> made After=connman and Requires=connman.service that did not work,
>>> always failed in boot, I have to manually restart the network
>>> application service which won't work in field operation.
>> I'd suggest you find out what you network service actually require.
>>
>>> Searched from Internet, there is a blog Systemd: Run it last to create
>>> a custom.target After=multi-user.target, and put my network
>>> application service WantedBy=custom.target, that works well, but it is
>>> a little bit cumbersome to configure customer.target in Yocto bb file,
>>> enabling the customer.target is called systemctl isolate
>>> custom.target, the /etc/systemd/system/default.target link needs be
>>> changed to from multi-user.target to custom.target. I am not sure how
>>> it could be done in do_install, appreciate your tips.
>>>
>>> Thank you.
>>>
>>> Kind regards,
>>>
>>> - JH
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREMIRROR

[Rudolf J Streif]

Russell,

You don't need PREMIRROR for this functionality. It's not exactly
intended for that use.

The simplest way to achieve what you are looking for is to use devtool.
If I understand you correctly you are downloading sources from a remote
repo on GitHub but want to have them locally to make modifications? If
so use:

devtool add myrecipe localsrc fetchuri

from your build environment (you have to source oe-init-build-env
first). devtool then fetches the source from fetchuri into a directory
localsrc as a git repo and automatically creates the recipe for it.

:rjs


On 7/23/19 1:49 PM, Russell Peterson wrote:
> Hello,
>
> I am looking to have bitbake pick up files for a particular recipe
> from a local git repository using the PREMIRROR functionality.
>
> Basically, the recipe (bb file) points to github but in my local build
> I add PREMIRROR_prepend = "git://.*/.* 
> git:///local/path/BASENAME;protocol=file\n"
>
> I will probably make the git regular expression more exact for my
> specific github repo but this works for now.
>
> This all works (as I deleted the github download from the local
> download directory) because I can see in the do_fetch log and the
> correct (local) repo was found and placed in the DL_DIR.
>
> Problem is, do_unpack fails because it appears to be looking for the
> original (github) SRC_URI.  Then it complains about "no up to date
> source found: clone or directory not available or not up to date
> (shallow clone not enabled)"
>
> Any help on what I am missing would be appreciated.
>
> Regards,
>
> Russell
>
>
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREMIRROR

[Rudolf J Streif]

Hi Russell,

devtool and eSDK are different things. The purpose of PREMIRRORS is to
set a mirror for all recipes. It's a way for organizations to control
where their YP builds download sources from. It's not intended to be
used for a single recipe. There is no need for that. You simply set
SRC_URI in your recipe to your local git repo. That is what devtool does
after downloading the sources from a remote repo. If you already have
the remote repo cloned locally you can just point devtool to it.

You can do it manually by creating your recipe and setting SRC_URI like
this:

SRC_URI = "git:///local/path/${PN};protocol=file"

SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

PREMIRRORS is only relevant for do_fetch not for do_unpack.

:rjs


On 7/24/19 11:28 AM, Russell Peterson wrote:
> Hi, Rudolf.
>
> Thanks for the reply.  Yes, I am aware of the eSDK functionality,
> however, I have some unique requirements that I am trying to work
> around.  Regardless... what I am doing should work, no?  I simply want
> to use a local git repo (the directory itself hence protocol=file)
> instead of what the recipe specifies.  Looks like the fetch is working
> but the do_unpack task is ignoring PREMIRRORS (or at least the
> localpath variable seems wrong).
>
> --Russ
>
>
> On Wed, Jul 24, 2019 at 12:19 PM Rudolf J Streif
> mailto:rudolf.str...@ibeeto.com>> wrote:
>
> Russell,
>
> You don't need PREMIRROR for this functionality. It's not exactly
> intended for that use.
>
> The simplest way to achieve what you are looking for is to use
> devtool. If I understand you correctly you are downloading sources
> from a remote repo on GitHub but want to have them locally to make
> modifications? If so use:
>
> devtool add myrecipe localsrc fetchuri
>
> from your build environment (you have to source oe-init-build-env
> first). devtool then fetches the source from fetchuri into a
> directory localsrc as a git repo and automatically creates the
> recipe for it.
>
> :rjs
>
>
> On 7/23/19 1:49 PM, Russell Peterson wrote:
>> Hello,
>>
>> I am looking to have bitbake pick up files for a particular
>> recipe from a local git repository using the PREMIRROR functionality.
>>
>> Basically, the recipe (bb file) points to github but in my local
>> build I add PREMIRROR_prepend = "git://.*/.* 
>> git:///local/path/BASENAME;protocol=file\n"
>>
>> I will probably make the git regular expression more exact for my
>> specific github repo but this works for now.
>>
>> This all works (as I deleted the github download from the local
>> download directory) because I can see in the do_fetch log and the
>> correct (local) repo was found and placed in the DL_DIR.
>>
>> Problem is, do_unpack fails because it appears to be looking for
>> the original (github) SRC_URI.  Then it complains about "no up to
>> date source found: clone or directory not available or not up to
>> date (shallow clone not enabled)"
>>
>> Any help on what I am missing would be appreciated.
>>
>> Regards,
>>
>> Russell
>>
>>
>>
> -- 
> -
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3396 x700
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREMIRROR

[Rudolf J Streif]

Russell,

That is exactly what devtool and the externalsrc class do. PREMIRROR is
the wrong approach for that.

:rjs

On 7/24/19 12:53 PM, Russell Peterson wrote:
> Hi, Rudolf.
>
> I apologize for not being clear.  The idea here is that my recipe
> points to github while, for my local development environment, I set a
> premirror to match a specific github repository and translate it to a
> local directory.  That works.  The fetch matches the PREMIRROR and
> places a copy of the LOCAL git repo in my DL_DIR.  The problem is, the
> do_unpack task is looking for the git repo in the DL_DIR
> (git2/etc...)... but it's looking for the git repo from github, not my
> local repo that the fetch task just put in DL_DIR.
>
> There are numerous reasons I'm doing this including the fact that I
> cannot put a reference to my local repo in the bb file since I ship
> that recipe to my customers and a local pathname is meaningless to
> them.  I prefer to simply modify my local.conf with a PREMIRROR value
> that has a specific regular expression that matches this particular
> github repo (and hence does NOT effect all recipes).  This is why I
> wanted to use the PREMIRROR function.  Unfortunately, it does not
> appear to work or at least not work as I expected.
>
> --Russ
>
>
>
>
> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif
> mailto:rudolf.str...@ibeeto.com>> wrote:
>
> Hi Russell,
>
> devtool and eSDK are different things. The purpose of PREMIRRORS
> is to set a mirror for all recipes. It's a way for organizations
> to control where their YP builds download sources from. It's not
> intended to be used for a single recipe. There is no need for
> that. You simply set SRC_URI in your recipe to your local git
> repo. That is what devtool does after downloading the sources from
> a remote repo. If you already have the remote repo cloned locally
> you can just point devtool to it.
>
> You can do it manually by creating your recipe and setting SRC_URI
> like this:
>
> SRC_URI = "git:///local/path/${PN};protocol=file"
>
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
>
> PREMIRRORS is only relevant for do_fetch not for do_unpack.
>
> :rjs
>
>
> On 7/24/19 11:28 AM, Russell Peterson wrote:
>> Hi, Rudolf.
>>
>> Thanks for the reply.  Yes, I am aware of the eSDK functionality,
>> however, I have some unique requirements that I am trying to work
>> around.  Regardless... what I am doing should work, no?  I simply
>> want to use a local git repo (the directory itself hence
>> protocol=file) instead of what the recipe specifies.  Looks like
>> the fetch is working but the do_unpack task is ignoring
>> PREMIRRORS (or at least the localpath variable seems wrong).
>>
>> --Russ
>>
>>
>> On Wed, Jul 24, 2019 at 12:19 PM Rudolf J Streif
>> mailto:rudolf.str...@ibeeto.com>> wrote:
>>
>> Russell,
>>
>> You don't need PREMIRROR for this functionality. It's not
>> exactly intended for that use.
>>
>> The simplest way to achieve what you are looking for is to
>> use devtool. If I understand you correctly you are
>> downloading sources from a remote repo on GitHub but want to
>> have them locally to make modifications? If so use:
>>
>> devtool add myrecipe localsrc fetchuri
>>
>> from your build environment (you have to source
>> oe-init-build-env first). devtool then fetches the source
>> from fetchuri into a directory localsrc as a git repo and
>> automatically creates the recipe for it.
>>
>> :rjs
>>
>>
>> On 7/23/19 1:49 PM, Russell Peterson wrote:
>>> Hello,
>>>
>>> I am looking to have bitbake pick up files for a particular
>>> recipe from a local git repository using the PREMIRROR
>>> functionality.
>>>
>>> Basically, the recipe (bb file) points to github but in my
>>> local build I add PREMIRROR_prepend = "git://.*/.* 
>>> git:///local/path/BASENAME;protocol=file\n"
>>>
>>> I will probably make the git regular expression more exact
>>> for my specific github repo but this works for now.
>>>
>>> This all works (as I deleted the github download from the
>>> local download directory) because I can see in the do_fetch
>>> log and the correct (local) 

Re: [yocto] PREMIRROR

[Rudolf J Streif]

Inlining below.

On 7/25/19 8:14 AM, Russell Peterson wrote:
> I think I have a somewhat better understanding of what is going on.
>
> First off, I was confused by the fact that the original error message
> I saw from do_unpack referenced the file (URL) at
> DL_DIR/git2/original_github_url.  What I didn't understand at the time
> was that while that file existed,/it was actually a link/ to
> DL_DIR/git2/local_url.  So, do_unpack wasn't looking at the wrong bare
> repository as I thought.  It was unhappy because it didn't see the git
> commit in the local repo that it was looking for.  I use AUTOREV for
> SRCREV.  Apparently, even with PREMIRROR set and matched, bitbake will
> still fetch the git HEAD commit hash from the original URL in the
> recipe.  The local git repo doesn't contain that commit.  When I sync
> the local git repo to the github repo things work as expected.
Correct. If the source repo or the correct commit cannot be found from
the PREMIRROR, bitbake will use SRC_URI from the recipe. You can block
that behavior by setting BB_NO_NETWORK = "1" in which case bitbake will
not be able to connect to any remote server. However, that does not help
if your PREMIRROR is a network server. In this case use BB_ALLOWED_HOSTS
to allow access to only the servers you want.
>
> Here is my problem.  What I am ultimately trying to do here is have 2
> git repos.  1 public, 1 private.  For internal development we use the
> private git repo (a local gerrit server).  Just before we ship we
> update the public github repo.  The recipe always points to the github
> (public) repo so we don't need to mess with that before a release. 
> This way we can do nightly builds (I'm just talking nightly builds
> done by Jenkins... not developers using eSDK and devtool) and test. 
> Customers using yocto will be given a recipe that points to github
> and, importantly, those customers that do NOT use yocto simply fetch
> the project from github and manually build it in their own environment
> with their own tools.
>
That is a common problem. I do this all the time. To do this add to your
conf/local.conf file:

INHERIT += "externalsrc"
EXTERNALSRC_pn-myrecipe = "/path/to/source/tree"

Alternatively, you could use a bbappend file for you recipe in a
development layer, myrecipe.bbappend:

inherit externalsrc
EXTERNALSRC = "/path/to/source/tree"

Now, that is exactly what devtool does for you but you can of course do
it manually.

:rjs



> I can't be the only one doing this.  Is there a best practices here
> (private vs. public repo)?
>
> --Russ
>
>
> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif
> mailto:rudolf.str...@ibeeto.com>> wrote:
>
> Russell,
>
> That is exactly what devtool and the externalsrc class do.
> PREMIRROR is the wrong approach for that.
>
> :rjs
>
> On 7/24/19 12:53 PM, Russell Peterson wrote:
>> Hi, Rudolf.
>>
>> I apologize for not being clear.  The idea here is that my recipe
>> points to github while, for my local development environment, I
>> set a premirror to match a specific github repository and
>> translate it to a local directory.  That works.  The fetch
>> matches the PREMIRROR and places a copy of the LOCAL git repo in
>> my DL_DIR.  The problem is, the do_unpack task is looking for the
>> git repo in the DL_DIR (git2/etc...)... but it's looking for the
>> git repo from github, not my local repo that the fetch task just
>> put in DL_DIR.
>>
>> There are numerous reasons I'm doing this including the fact that
>> I cannot put a reference to my local repo in the bb file since I
>> ship that recipe to my customers and a local pathname is
>> meaningless to them.  I prefer to simply modify my local.conf
>> with a PREMIRROR value that has a specific regular expression
>> that matches this particular github repo (and hence does NOT
>> effect all recipes).  This is why I wanted to use the PREMIRROR
>> function.  Unfortunately, it does not appear to work or at least
>> not work as I expected.
>>
>> --Russ
>>
>>
>>
>>
>> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif
>> mailto:rudolf.str...@ibeeto.com>> wrote:
>>
>> Hi Russell,
>>
>> devtool and eSDK are different things. The purpose of
>> PREMIRRORS is to set a mirror for all recipes. It's a way for
>> organizations to control where their YP builds download
>> sources from. It's not intended to be used for a single
>> recipe. There is no need for that. You simply set SRC_URI in
>> your rec

Re: [yocto] PREMIRROR

[Rudolf J Streif]

You are very welcome. Enjoy working with YP.

:rjs

On 7/25/19 4:48 PM, Russell Peterson wrote:
> Just tried the externalsrc feature.  Works perfectly.  Exactly what I
> was looking for.  Thanks so much, Rudolf!
>
> --Russ
>
>
> On Thu, Jul 25, 2019 at 4:59 PM Rudolf J Streif
> mailto:rudolf.str...@ibeeto.com>> wrote:
>
> Inlining below.
>
> On 7/25/19 8:14 AM, Russell Peterson wrote:
>> I think I have a somewhat better understanding of what is going on.
>>
>> First off, I was confused by the fact that the original error
>> message I saw from do_unpack referenced the file (URL) at
>> DL_DIR/git2/original_github_url.  What I didn't understand at the
>> time was that while that file existed,/it was actually a link/ to
>> DL_DIR/git2/local_url.  So, do_unpack wasn't looking at the wrong
>> bare repository as I thought.  It was unhappy because it didn't
>> see the git commit in the local repo that it was looking for.  I
>> use AUTOREV for SRCREV.  Apparently, even with PREMIRROR set and
>> matched, bitbake will still fetch the git HEAD commit hash from
>> the original URL in the recipe.  The local git repo doesn't
>> contain that commit.  When I sync the local git repo to the
>> github repo things work as expected.
> Correct. If the source repo or the correct commit cannot be found
> from the PREMIRROR, bitbake will use SRC_URI from the recipe. You
> can block that behavior by setting BB_NO_NETWORK = "1" in which
> case bitbake will not be able to connect to any remote server.
> However, that does not help if your PREMIRROR is a network server.
> In this case use BB_ALLOWED_HOSTS to allow access to only the
> servers you want.
>>
>> Here is my problem.  What I am ultimately trying to do here is
>> have 2 git repos.  1 public, 1 private.  For internal development
>> we use the private git repo (a local gerrit server).  Just before
>> we ship we update the public github repo.  The recipe always
>> points to the github (public) repo so we don't need to mess with
>> that before a release.  This way we can do nightly builds (I'm
>> just talking nightly builds done by Jenkins... not developers
>> using eSDK and devtool) and test.  Customers using yocto will be
>> given a recipe that points to github and, importantly, those
>> customers that do NOT use yocto simply fetch the project from
>> github and manually build it in their own environment with their
>> own tools.
>>
> That is a common problem. I do this all the time. To do this add
> to your conf/local.conf file:
>
> INHERIT += "externalsrc"
> EXTERNALSRC_pn-myrecipe = "/path/to/source/tree"
>
> Alternatively, you could use a bbappend file for you recipe in a
> development layer, myrecipe.bbappend:
>
> inherit externalsrc
> EXTERNALSRC = "/path/to/source/tree"
>
> Now, that is exactly what devtool does for you but you can of
> course do it manually.
>
> :rjs
>
>
>
>> I can't be the only one doing this.  Is there a best practices
>> here (private vs. public repo)?
>>
>> --Russ
>>
>>
>> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif
>> mailto:rudolf.str...@ibeeto.com>> wrote:
>>
>> Russell,
>>
>> That is exactly what devtool and the externalsrc class do.
>> PREMIRROR is the wrong approach for that.
>>
>> :rjs
>>
>> On 7/24/19 12:53 PM, Russell Peterson wrote:
>>> Hi, Rudolf.
>>>
>>> I apologize for not being clear.  The idea here is that my
>>> recipe points to github while, for my local development
>>> environment, I set a premirror to match a specific github
>>> repository and translate it to a local directory.  That
>>> works.  The fetch matches the PREMIRROR and places a copy of
>>> the LOCAL git repo in my DL_DIR.  The problem is, the
>>> do_unpack task is looking for the git repo in the DL_DIR
>>> (git2/etc...)... but it's looking for the git repo from
>>> github, not my local repo that the fetch task just put in
>>> DL_DIR.
>>>
>>> There are numerous reasons I'm doing this including the fact
>>> that I cannot put a reference to my local repo in the bb
>>>     file since I ship that recipe to my customers and a local
>>> pathnam

Re: [yocto] Downloading Git Archives

[Rudolf J Streif]

On 9/27/19 2:27 AM, Ross Burton wrote:
> On 27/09/2019 05:33, Chuck Wolber wrote:
>> I was hoping that there was an equally simple way of grabbing git
>> repository packages from an Internet connected host without having a
>> bitbake build cache them for me.
>
> The easy way is to get bitbake to do it for you.  A git mirror tarball
> is just a clone with a specific name and path, but the easy solution
> is definitely to run bitbake --c fetchall on a machine with
> connectivity and expose the DL_DIR to the builders.
>
> This is what the yocto autobuilder does, by the way.  The workers
> don't have connectivity to the outside internet, so the master does a
> fetchall with the proxies configured to populate DL_DIR before the
> workers do the actual build.
>
Same thing here. I run a build system instance that simply downloads all
the sources and places them on a local mirror. The only thing to think
about is that if you have different targets they might require different
source packages albeit there is always a larger overlap of packages that
are always required. However, it's not too big of a problem launching
the 'fetcher' instance repeatedly with different target since only
what's missing will of course be downloaded.

Another layer of complexity is of course added if you work with
different versions of YP and OE layers. I solve this with Gitlab and
submodules. A target project is a repo in Gitlab and the YP/OE layers
are submodules. Gitlab handles that quite nicely.

:rjs

-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Downloading Git Archives

[Rudolf J Streif]

Chuck,

Unless I am missing something (which I cannot entirely rule out), the
default PREMIRRORS should actually do what you want. For the poky distro
configuration has this:

PREMIRRORS ??= "\
bzr://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
cvs://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
git://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
gitsm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
hg://.*/.*    http://downloads.yoctoproject.org/mirror/sources/ \n \
osc://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
p4://.*/.*    http://downloads.yoctoproject.org/mirror/sources/ \n \
svn://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n"

This causes the fetcher to intercept and translate all the SCM protocols
into http downloads from the YP mirror. Since you are saying wget works
for you this should actually automatically work for you. If you build
system can at least download using http then

bitbake  --runall=fetch

should download all the sources for you. Then you can disconnect the box
from the Internet and start the build offline.

:rjs

On 9/26/19 8:06 PM, Chuck Wolber wrote:
> Hi All,
>
> Our build environment is stuck behind a firewall with no access to the
> Internet. When a Yocto build requires a new package, we normally
> extract the URL from the failed build log and "wget" the package from
> the upstream source, do our due diligence (checksums, etc), and then
> add it to the server pointed to by ${LOCAL_MIRROR}.
>
> Obviously that procedure does not work so well when a git repository
> needs to be fetched. We have tried various methods, but nothing seems
> to work reliably. Our current method is an annoying hack involving a
> virtual machine clone of the build server.
>
> I have searched far and wide, and cannot find any sort of procedure.
> Can someone point me at a procedure for translating something like
> git://git.yoctoproject.org/pseudo <http://git.yoctoproject.org/pseudo>
> into a file we can store in our ${LOCAL_MIRROR}?
>
> Thank you,
>
> ..Ch:W..
>
-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto newbie: Need help with recipe

[Rudolf J Streif]

r0/git/main.cpp
>>> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.cpp
>>> ./qtlissajous-src/usr/src/debug/qtlissajous/git-r0/git/phaselabel.h
>>> ./qtlissajous-tools/usr/bin/lissajous_explorer
>>> ./qtlissajous/usr/bin/.debug/lissajous_explorer
>>> ./qtlissajous-tools.shlibdeps
>>>
>>> My qtlissajous_git.gg file is:
>>>
>>> ---
>>> DESCRIPTION = "Explore Lissajous figures for Raspberry Pi"
>>> SECTION = "games"
>>> DEPENDS += "qtbase"
>>>
>>> PACKAGES = "${PN}"
>>>
>>> LICENSE = "MIT"
>>> LIC_FILES_CHKSUM =
>>> "file://LICENSE;md5=7e26fc87b2c255632232dc535ed2700b;sha256=c8ea5a5ce0ef734ec1d0be3e214bed71673f1ffc628fe86bbd055d61abd52cc8"
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>>
>>> SRCREV = "${AUTOREV}"
>>> SRC_URI = "git://gitlab.com/bhoel/qlissajousexplorer.git;protocol=https"
>>>
>>> S = "${WORKDIR}/git"
>>>
>>> require recipes-qt/qt5/qt5.inc
>>>
>>> FILES_${PN} = "${bindir}"
>>> FILES_${PN}-dbg += "${bindir}/.debug"
>>>
>>> do_install() {
>>>   install -d ${D}/usr/bin
>>>   install -m 0755 lissajous_explorer ${D}/usr/bin
>>> }
>>>
>>> RDEPENDS_${PN} = "qtbase-plugins"
>>> ---
>>>
>>> Why is the release executable ending up in the tools tree?
>>> Why is the debug executable ending up in the release tree?
>>> Is this the right place to ask this kind of questions?
>>>
>>> Thank you
>>> Berthold
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
-- 
Rudolf J Streif
CEO/CTO
ibeeto
1.855.442.3386 x700



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto