[yocto] [RFT] GCC 8.1

[Khem Raj]

Hi All

As you might have noticed that gcc 8.1 was released this week, I am
calling out for some testing help on testing branch so we can weed out
issues you might see in your setups. so if you have your
builders idling over weekend, then you know what they can do this weekend :)

Highlighted changes are

https://gcc.gnu.org/gcc-8/changes.html

and porting doc is

https://gcc.gnu.org/gcc-8/porting_to.html

The branch is here

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8

Its uptodate on top of current master oe-core

May fourth be with you !!

Cheers!

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

[yocto] How to locate this yocto git rep?

[Raymond Yeung]

I've changed the subject heading in hope I getting better luck.


I found a file/driver of interest to me via googling:  
https://lists.yoctoproject.org/pipermail/linux-yocto/2015-May/003647.html


The file is tlk10232.c.  The thread above seems to say that I could get it via


git clone git://git.yoctoproject.org/linux-yocto-contrib


And so I did the clone.  However, I'm unable to find the file after all.  Am I 
on the right track?  And how do I check history to see perhaps it was removed 
later?


Thanks,

Raymond




From: Raymond Yeung 
Sent: Tuesday, May 1, 2018 12:51 PM
To: yocto@yoctoproject.org
Subject: TI TLK10031 Driver Needed


What is the best way to search for existing driver support (in particular, 
driver for TLK10031) in YP?  I search my own Poky source and its build tree, 
but find nothing.  I saw on google returned result mentioning of one instance 
for a similar chip (TLK10232), but don't know which branch/repo it's from.


Thanks,

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

Re: [yocto] PXE booting ISO image fails with message "Waiting for removable media..."

[Raymond Yeung]

Perhaps you could try NFS kernel boot option.  Set up the remote (tftp root) 
directory to reflect the path the init code expects.


I tried this for a little while but ran into what 2 issues - network driver 
init is later than NFS (due to it being a LKM rather than part of kernel), and 
Avahi screwing around with IP addresses.  I looked into the log to confirm 
timing for the first one, and fixed this with kernel reconfiguration.  However, 
I've yet to try fixing Avahi (remove it) as I'm not sure how to do it yet.


My time ran out, and I got another workable solution.  So I shelved this NFS 
approach.  If you get this working, would appreciate it if you could publish 
it, and any issues you run into implementing it.


Raymond



From: Vincent Daanen 
Sent: Thursday, May 3, 2018 11:43 PM
To: Raymond Yeung; yocto@yoctoproject.org
Subject: RE: [yocto] PXE booting ISO image fails with message "Waiting for 
removable media..."


Hi Raymond,



> I'd recently gone through similar issue that you're experiencing.  The 
> "Waiting for Removable Media" hang had been there for at least 7-8 years.  A 
> workaround was put in around 2013.  See here: 
> https://patchwork.openembedded.org/patch/42291/

>

> Add "debugshell=30" (30 is in second, for timeout, or any other reasonable 
> value that you like) to the append

> statement in your pxelinux.cfg/default file.  Then you'd timeout when you 
> "normally" hangs, break into a shell,

> where you could initiate udhcpc to configure networking, after which you 
> could transfer your bootable image onto

> your RAM, and write out onto your HDD/SSD.



Unfortunately, we cannot use this trick because the MB which boots using PXE is 
not accessible and we want to use PXE booting  for every boot…



> It seems this kernel boot option of debugshell isn't documented officially in 
> kernel-parameters.txt file.



>  You could also look for init-live.sh on your yocto tree, and look for 
> "Waiting for Removable Media", and see the

> surrounding code to get a fell how this debugshell thing works.

I think this is what we will have to do ..



I read the description of the internals of the initrd provided by Archlinux. 
The main difference is that Yocto initrd searches for the final rootfs on 
physical device (/dev/sdX) whereas the Archlinux initrd identifies (using 
LABEL) the support it was launched from and then searches on this support for 
the final rootfs.



I guess this approach would unify all booting: from USB, CD-ROM and PXE.. But 
at the moment, I don’t know how to reproduce the archlinux initrd works with 
Yocto…



If only a guru of Yocto could help …



Vincent



Date: Thu, 3 May 2018 14:27:46 +
From: Vincent Daanen 
>
To: "yocto@yoctoproject.org" 
>
Subject: [yocto] PXE booting ISO image fails with message "Waiting for
removable media..."
Message-ID:

>

Content-Type: text/plain; charset="utf-8"

Hi,

We want to deploy image created with Yocto (Rocko) via PXE.
The target board is a Intel-based SBC (AAEON GENE BT05).

At first, we tried with a ISO from Archlinux and the target-board successfully 
booted.

Then we create a ISO using Yocto but boot hangs with a message ?Waiting for 
removable media ...?.
Googling this message points me to this post: 
http://thread.gmane.org/gmane.linux.embedded.yocto.general/20611 which relates 
exactly the same problem, explain why the issue raises, gives an indication to 
how to fix .. and that?s all ?

So at this point, we know that the problem comes from the 
/recipes-core/initrdscripts/files/init-live.sh file.
It seems searching for an /dev/sdx should be protected by a timeout set by 
default to 30 secs but during our trials, no timeout seems to exist.

What we do not understand, is how to highlight the differences between the 
Yocto-based and the Archlinux ISO files so that we can ?unblock? the boot using 
the Yocto-based ISO file.

Is the someone here how could help?

Thanks

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

Re: [yocto] Enabling SD Card Detection for USB SD Card Reader

[Khem Raj]

On Fri, May 4, 2018 at 4:33 AM, Tom Gibson  wrote:
> Hi,
>
>
>
> We would like to enable our Yocto distribution to auto-detect when an SD
> card is inserted in a USB SD card reader, in much the same way as a card is
> detected on desktop linux such as Ubuntu. We have got our USB card reader
> working with the generic-storage driver, but at the moment we have to do
> something like ‘fdisk -l’ to refresh the attached storage after a card is
> inserted or removed in order for it to it to be listed in /dev. The card
> reader shows up as /dev/sda regardless of whether there is a card present or
> not, but the partition on the card only shows up as /dev/sda1 after forcing
> the refresh.
>
>
>
> Any pointers towards which service we need to install to enable this
> functionality appreciated!
>

perhaps you should be able to use udisks2
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is the a reason for adding the + to SRCPV?

[Martin Jansa]

This might help you:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glib-2.0/glib-2.0/0002-gdbus-codegen-also-replace-character-with-underscore.patch

On Wed, Apr 11, 2018 at 5:59 PM, Måns Zigher  wrote:

> Hi,
>
> Thanks for your help. It is a cmake project in which they have specified a
> custom command calling gdbus-codegen. It definitely looks like they are
> passing the absolute path to it thanks for the help I think I can solve
> that.
>
> Br
> Mans Zigher
>
> On Apr 11, 2018 15:50, "Burton, Ross"  wrote:
>
> There is no "dbus codegen".  dbus-glib has a code generator but that
> doesn't write include guards like that, so it must be something else.
> gdbus-codegen appears to be doing the right thing to unless it breaks
> if you pass it an absolute path?
>
>
> Ross
>
>
> On 11 April 2018 at 10:12, Måns Zigher  wrote:
> > I believe dbus codegen is the tools generating the code.
> >
> > Br
> > Mans Zigher
> >
> > On Tue, Apr 10, 2018, 14:44 Burton, Ross  wrote:
> >>
> >> What tool is generating the code?  It probably shouldn't be using the
> >> full path of the header...
> >>
> >> Ross
> >>
> >> On 10 April 2018 at 09:29, Måns Zigher  wrote:
> >> > Hi,
> >> >
> >> > I am having some problems with one of my recipes when using the SRCPV
> >> > the
> >> > get_srcrev is returning "AUTOINC+" + rev. This will cause problem in
> my
> >> > compile because I am using dbus codegen and it looks like the
> >> > auto-generated
> >> > code cannot handle the + sign in the paths. Is there a reason for
> this +
> >> > sign. The generated code that causes my build to fail looks like this
> >> >
> >> > #ifndef
> >> >
> >> > ___HOME_EXTZIG_WORKSPACE_MOZART_MOZART_WORKSPACE_
> BUILDS_MOZART_RASPBERRYPI_BUILD_TMP_WORK_CORTEXA7HF_
> NEON_VFPV4_MOZART_LINUX_GNUEABI_MOZART_DAEMON_1_0_
> GITAUTOINC+8FD4C803AE_R3_GIT_SRC_LIBS_MOZART_BLE_SETUP_
> CODEGEN_ORG_BLUEZ_LE_ADVERTISEMENT_INTERFACE_H__
> >> >
> >> > Currently the only way for me to get the build to work is not use the
> >> > SRCPV.
> >> > Could it actually be a better way then using the + sign or is there a
> >> > logical requirement for it?
> >> >
> >> > BR
> >> > Mans Zigher
> >> >
> >> > --
> >> > ___
> >> > 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Peter,

See
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the re-ordered list.

Thanks,
Scott

On Fri, May 4, 2018 at 9:53 AM, Scott Rifenbark 
wrote:

> Sorry man... I just stuck the new one in there.  Alphabetical would be
> best.  I will fix that.
>
> Thanks,
> Scott
>
> On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
>> Not sure why you reordered the descriptions of the features from
>> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
>> since that kept them sorted alphabetically), but apart from that it looks
>> fine to me.
>>
>>
>>
>> //Peter
>>
>>
>>
>> *From:* Scott Rifenbark [mailto:srifenb...@gmail.com]
>> *Sent:* den 3 maj 2018 15:58
>> *To:* Peter Kjellerstedt 
>> *Cc:* Richard Purdie ;
>> openembedded-core ; Yocto
>> discussion list 
>>
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> Hi Peter,
>>
>> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
>> Project Reference Manual (see https://yoctoproject.org/docs/
>> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
>> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html
>> #var-BUILDHISTORY_FEATURES for the commit in the yocto-docs repository.
>>
>> Please look it over as I did a bit of modification for manual purposes.
>>
>> Regards,
>>
>> Scott
>>
>>
>>
>> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
>> peter.kjellerst...@axis.com> wrote:
>>
>>
>>
>>
>>
>> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
>> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
>> Rifenbark
>> *Sent:* den 1 maj 2018 16:56
>> *To:* Richard Purdie 
>> *Cc:* openembedded-core 
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
>> richard.pur...@linuxfoundation.org> wrote:
>>
>> Hi,
>>
>> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
>> > I'm relatively new to OE; I've written a couple of pre-alpha layers
>> > to try some idea, and worked on meta-openembedded, but I've not had a
>> > chance to go in depth on the Yocto documentation, and at the some
>> > there see to be things (based on the lists) that are out of date, or
>> > new things that aren't even mentioned, which makes getting up speed
>> > somewhat difficult.
>>
>> Writing down where you think there are issues would be a help so that
>> we can see if there is some way we can improve that.
>>
>>
>>
>> Yes - please indicate any areas in the documentation you believe need
>> updated, changed, or added.  I have been trying to bring things up-to-date
>> in several manuals during the 2.5 process.  So, identifying areas in the
>> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
>> manuals use the following form for the URL:
>>
>>   yoctoproject.org/docs/2.5//.html
>>
>>   where  is
>>
>>brief-yoctoprojectqs
>>
>>bsp-guide
>>
>>overview-manual
>>
>>dev-manual
>>
>>sdk-manual
>>
>>profile-manual
>>
>>kernel-dev
>>
>>ref-manual
>>
>>toaster-manual
>>
>>bitbake-user-guide
>>
>> Thanks
>>
>> Scott
>>
>> Is there any special process to get manual updates accepted? I am asking
>> because I sent an update for the BUILDHISTORY_FEATURES variable to the
>> Yocto mailing list (https://lists.yoctoproject.or
>> g/pipermail/yocto/2018-January/039787.html) at the end of January (last
>> pinged a month ago) and it still has not made it into the manual AFAICT and
>> it has not received any feedback.
>>
>> //Peter
>>
>>
>>
>>
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Sorry man... I just stuck the new one in there.  Alphabetical would be
best.  I will fix that.

Thanks,
Scott

On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> Not sure why you reordered the descriptions of the features from
> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
> since that kept them sorted alphabetically), but apart from that it looks
> fine to me.
>
>
>
> //Peter
>
>
>
> *From:* Scott Rifenbark [mailto:srifenb...@gmail.com]
> *Sent:* den 3 maj 2018 15:58
> *To:* Peter Kjellerstedt 
> *Cc:* Richard Purdie ;
> openembedded-core ; Yocto
> discussion list 
>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> Hi Peter,
>
> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
> Project Reference Manual (see https://yoctoproject.org/docs/
> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.
> html#var-BUILDHISTORY_FEATURES for the commit in the yocto-docs
> repository.
>
> Please look it over as I did a bit of modification for manual purposes.
>
> Regards,
>
> Scott
>
>
>
> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
>
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie 
> *Cc:* openembedded-core 
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie  linuxfoundation.org> wrote:
>
> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>
>
>
> Yes - please indicate any areas in the documentation you believe need
> updated, changed, or added.  I have been trying to bring things up-to-date
> in several manuals during the 2.5 process.  So, identifying areas in the
> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
> manuals use the following form for the URL:
>
>   yoctoproject.org/docs/2.5//.html
>
>   where  is
>
>brief-yoctoprojectqs
>
>bsp-guide
>
>overview-manual
>
>dev-manual
>
>sdk-manual
>
>profile-manual
>
>kernel-dev
>
>ref-manual
>
>toaster-manual
>
>bitbake-user-guide
>
> Thanks
>
> Scott
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-
> January/039787.html) at the end of January (last pinged a month ago) and
> it still has not made it into the manual AFAICT and it has not received any
> feedback.
>
> //Peter
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] 2.6 planning proposals and meeting

[Peter Kjellerstedt]

Not sure why you reordered the descriptions of the features from 
image,package,sdk,task to image,task,package,sdk (I added “task” at the end 
since that kept them sorted alphabetically), but apart from that it looks fine 
to me.

//Peter

From: Scott Rifenbark [mailto:srifenb...@gmail.com]
Sent: den 3 maj 2018 15:58
To: Peter Kjellerstedt 
Cc: Richard Purdie ; openembedded-core 
; Yocto discussion list 

Subject: Re: [OE-core] 2.6 planning proposals and meeting

Hi Peter,
Thanks for the patch.  I have applied it to the 2.5 version of the Yocto 
Project Reference Manual (see 
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).
  You can also see 
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
 for the commit in the yocto-docs repository.
Please look it over as I did a bit of modification for manual purposes.
Regards,
Scott

On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt 
> wrote:


From: 
openembedded-core-boun...@lists.openembedded.org
 
[mailto:openembedded-core-boun...@lists.openembedded.org]
 On Behalf Of Scott Rifenbark
Sent: den 1 maj 2018 16:56
To: Richard Purdie 
>
Cc: openembedded-core 
>
Subject: Re: [OE-core] 2.6 planning proposals and meeting

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie 
> 
wrote:
Hi,

On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> I'm relatively new to OE; I've written a couple of pre-alpha layers
> to try some idea, and worked on meta-openembedded, but I've not had a
> chance to go in depth on the Yocto documentation, and at the some
> there see to be things (based on the lists) that are out of date, or
> new things that aren't even mentioned, which makes getting up speed
> somewhat difficult.

Writing down where you think there are issues would be a help so that
we can see if there is some way we can improve that.

Yes - please indicate any areas in the documentation you believe need updated, 
changed, or added.  I have been trying to bring things up-to-date in several 
manuals during the 2.5 process.  So, identifying areas in the 2.5 manual set 
would be very helpful.  To be sure you are viewing 2.5 manuals use the 
following form for the URL:
  
yoctoproject.org/docs/2.5//.html
  where  is
   brief-yoctoprojectqs
   bsp-guide
   overview-manual
   dev-manual
   sdk-manual
   profile-manual
   kernel-dev
   ref-manual
   toaster-manual
   bitbake-user-guide
Thanks
Scott
Is there any special process to get manual updates accepted? I am asking 
because I sent an update for the BUILDHISTORY_FEATURES variable to the Yocto 
mailing list 
(https://lists.yoctoproject.org/pipermail/yocto/2018-January/039787.html) at 
the end of January (last pinged a month ago) and it still has not made it into 
the manual AFAICT and it has not received any feedback.
//Peter


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

Re: [yocto] Writing a functional Dockerfile to run a container with a package revision (PR) server

[Iván Castell]

I found the right way to fix my issue. First I wrote this script:

$ cat start.sh
#! /bin/sh

cd /home/yocto/poky
source ./oe-init-build-env ../build
bitbake-prserv --start --file /home/yocto/prserv/sqlite3.db --log
/tmp/prserv.log --port 8585
tail -f /tmp/prserv.log

And after modified the Dockerfile adding this stuff:

ADD start.sh /home/yocto/start.sh
RUN chmod 755 /home/yocto/start.sh
RUN chown yocto.yocto /home/yocto/start.sh
...
CMD /home/yocto/start.sh

Now it works as expected. Hope this helps somebody else!



2018-05-04 15:57 GMT+02:00 Iván Castell :

> The purpose is deploying a yocto PR server using a docker container. More
> info about PR server can be found in the following link: https://wiki.
> yoctoproject.org/wiki/PR_Service
>
> To try doing that I wrote this "Dockerfile" to generate a docker image:
>
> FROM ubuntu:16.04
> MAINTAINER Yocto 
>
> # Update, upgrade and install
> RUN apt-get update
> RUN apt-get upgrade -y
> RUN apt-get install -y gawk wget git git-core diffstat unzip texinfo
> gcc-multilib build-essential chrpath socat xterm curl parted python python3
> python3-pip python3-pexpect xz-utils debianutils iputils-ping libsdl1.2-dev
> net-tools
>
> # Set up locales
> RUN apt-get -y install locales apt-utils sudo && dpkg-reconfigure locales
> && locale-gen en_US.UTF-8 && update-locale LC_ALL=en_US.UTF-8
> LANG=en_US.UTF-8
> ENV LANG en_US.utf8
>
> # Clean up APT when done
> RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
>
> # Replace dash with bash
> RUN rm /bin/sh && ln -s bash /bin/sh
>
> # Yocto user management
> RUN groupadd -g 1000 yocto && useradd -u 1000 -g 1000 -ms /bin/bash yocto
> && usermod -a -G sudo yocto && usermod -a -G users yocto
> ENV HOME /home/yocto
> USER yocto
>
> # Download poky
> RUN git clone --branch rocko git://git.yoctoproject.org/poky
> /home/yocto/poky
>
> # Create some directories
> RUN mkdir -p /home/yocto/build /home/yocto/prserv
>
> # Make /home/yocto/poky the working directory
> WORKDIR /home/yocto/poky
>
> # Expose listen port
> EXPOSE 8585
>
> # Run PR-server
> CMD /bin/sh -c " \
> source ./oe-init-build-env ../build \
> && bitbake-prserv --start --file /home/yocto/prserv/sqlite3.db --log
> /tmp/prserv.log --port 8585 \
> "
> Using previous Dockerfile I build a docker image:
>
> $ docker build -t docker-prserver .
> [...]
> Successfully built 362f4599b1b6
> Successfully tagged docker-prserver:latest
>
> As you can see before, the process ends successfully. After that, I run a
> container:
>
> $ docker run -ti docker-prserver
> yocto@b3c9fd06d8af:~/poky$
>
> The previous command creates a shell. I check if the process
> “bitbake-prserver” is running:
>
> $ netstat -nat
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address   Foreign Address State
>
> As you can see, the “bitbake-prserver” process is not running (no listen
> port). However, if I log into the container and execute the CMD command:
>
> yocto@b3c9fd06d8af:~/poky/build$ source ./oe-init-build-env ../build/ &&
> bitbake-prserv --start --file /home/yocto/prserv/sqlite3.db --log
> /tmp/prserv.log --port 8585
>
> Then it works fine:
>
> yocto@b3c9fd06d8af:~$ netstat -nat
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address   Foreign AddressState
> tcp0  0 0.0.0.0:85850.0.0.0:*  LISTEN
>
> It’s supposed that CMD is executed when the container is instantiated, but
> this is not happening. What is the right way to write a Dockerfile to run a
> bitbake-prserv server listening on the exposed port?
>
> Hope some of you have some experience on this and can provide some useful
> feedback.
>
> Thanks a lot in advance! :)
>
>


-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: i...@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains 

[yocto] Writing a functional Dockerfile to run a container with a package revision (PR) server

[Iván Castell]

The purpose is deploying a yocto PR server using a docker container. More
info about PR server can be found in the following link:
https://wiki.yoctoproject.org/wiki/PR_Service

To try doing that I wrote this "Dockerfile" to generate a docker image:

FROM ubuntu:16.04
MAINTAINER Yocto 

# Update, upgrade and install
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y gawk wget git git-core diffstat unzip texinfo
gcc-multilib build-essential chrpath socat xterm curl parted python python3
python3-pip python3-pexpect xz-utils debianutils iputils-ping libsdl1.2-dev
net-tools

# Set up locales
RUN apt-get -y install locales apt-utils sudo && dpkg-reconfigure locales
&& locale-gen en_US.UTF-8 && update-locale LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
ENV LANG en_US.utf8

# Clean up APT when done
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# Replace dash with bash
RUN rm /bin/sh && ln -s bash /bin/sh

# Yocto user management
RUN groupadd -g 1000 yocto && useradd -u 1000 -g 1000 -ms /bin/bash yocto
&& usermod -a -G sudo yocto && usermod -a -G users yocto
ENV HOME /home/yocto
USER yocto

# Download poky
RUN git clone --branch rocko git://git.yoctoproject.org/poky
/home/yocto/poky

# Create some directories
RUN mkdir -p /home/yocto/build /home/yocto/prserv

# Make /home/yocto/poky the working directory
WORKDIR /home/yocto/poky

# Expose listen port
EXPOSE 8585

# Run PR-server
CMD /bin/sh -c " \
source ./oe-init-build-env ../build \
&& bitbake-prserv --start --file /home/yocto/prserv/sqlite3.db --log
/tmp/prserv.log --port 8585 \
"
Using previous Dockerfile I build a docker image:

$ docker build -t docker-prserver .
[...]
Successfully built 362f4599b1b6
Successfully tagged docker-prserver:latest

As you can see before, the process ends successfully. After that, I run a
container:

$ docker run -ti docker-prserver
yocto@b3c9fd06d8af:~/poky$

The previous command creates a shell. I check if the process
“bitbake-prserver” is running:

$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State

As you can see, the “bitbake-prserver” process is not running (no listen
port). However, if I log into the container and execute the CMD command:

yocto@b3c9fd06d8af:~/poky/build$ source ./oe-init-build-env ../build/ &&
bitbake-prserv --start --file /home/yocto/prserv/sqlite3.db --log
/tmp/prserv.log --port 8585

Then it works fine:

yocto@b3c9fd06d8af:~$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign AddressState
tcp0  0 0.0.0.0:85850.0.0.0:*  LISTEN

It’s supposed that CMD is executed when the container is instantiated, but
this is not happening. What is the right way to write a Dockerfile to run a
bitbake-prserv server listening on the exposed port?

Hope some of you have some experience on this and can provide some useful
feedback.

Thanks a lot in advance! :)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with Bitbake: (bitbake-layers show-recipes)

[Trevor Woerner]

*$ git clone git://git.linaro.org/openembedded/jenkins-setup.git
*

Since the repository from which you're working comes from Linaro, maybe
you'll have better luck getting support from their mailing list?
openembedded-c...@lists.openembedded.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Paulo Neves]

Ouch you are right. Damn me for using pyro still?
After applying this patch I will report on the remaining issues.

On Fri, May 4, 2018 at 2:41 PM, Alexander Kanavin
 wrote:
> On 05/04/2018 03:42 PM, Paulo Neves wrote:
>>
>> I will propose a patch with a default bb.debug, and always have the
>> verbose on dnf. Let's see how it affects the performance. I cannot
>> test this in a docker container because of the problems described
>> below:
>>
>> In the mean time I found what was happening with my slow do_rootfs. I
>> was running bitbake with RPM packaging in a docker instance. It seems
>> there is a problem with RPM/dnf in bitbake where it is extremely slow
>> inside a docker container (1 file per second). After changing to IPK
>> packages everything went smoothly.
>>
>> Others have had the same problem[1]. I will later report this to
>> openembedded mailing list as this effectively makes RPM unusable in a
>> container. I will also provide a Dockerfile to reproduce this problem.
>>
>> [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008
>
>
> No need to report. We have already fixed this and reported upstream:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opened-files-before-exec-fr.patch
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1537564
>
>
> Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Alexander Kanavin]

On 05/04/2018 03:50 PM, Scott Rifenbark wrote:
If ROOTFS_RPM_DEBUG should be a documented variable in the Yocto Project 
Reference Manual, could someone please provide me with some base 
explanation of the variable and any usage specifics?


No need, we're going to remove it.

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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Scott Rifenbark]

If ROOTFS_RPM_DEBUG should be a documented variable in the Yocto Project
Reference Manual, could someone please provide me with some base
explanation of the variable and any usage specifics?

Thanks,
Scott

On Fri, May 4, 2018 at 5:41 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 05/04/2018 03:42 PM, Paulo Neves wrote:
>
>> I will propose a patch with a default bb.debug, and always have the
>> verbose on dnf. Let's see how it affects the performance. I cannot
>> test this in a docker container because of the problems described
>> below:
>>
>> In the mean time I found what was happening with my slow do_rootfs. I
>> was running bitbake with RPM packaging in a docker instance. It seems
>> there is a problem with RPM/dnf in bitbake where it is extremely slow
>> inside a docker container (1 file per second). After changing to IPK
>> packages everything went smoothly.
>>
>> Others have had the same problem[1]. I will later report this to
>> openembedded mailing list as this effectively makes RPM unusable in a
>> container. I will also provide a Dockerfile to reproduce this problem.
>>
>> [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008
>>
>
> No need to report. We have already fixed this and reported upstream:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/rec
> ipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opene
> d-files-before-exec-fr.patch
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1537564
>
>
>
> Alex
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Alexander Kanavin]

On 05/04/2018 03:41 PM, Alexander Kanavin wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1537564


Obviously you and anyone else affected need to make noise in the redhat 
bugzilla, otherwise they're likely to keep this low priority.


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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Alexander Kanavin]

On 05/04/2018 03:42 PM, Paulo Neves wrote:

I will propose a patch with a default bb.debug, and always have the
verbose on dnf. Let's see how it affects the performance. I cannot
test this in a docker container because of the problems described
below:

In the mean time I found what was happening with my slow do_rootfs. I
was running bitbake with RPM packaging in a docker instance. It seems
there is a problem with RPM/dnf in bitbake where it is extremely slow
inside a docker container (1 file per second). After changing to IPK
packages everything went smoothly.

Others have had the same problem[1]. I will later report this to
openembedded mailing list as this effectively makes RPM unusable in a
container. I will also provide a Dockerfile to reproduce this problem.

[1] https://github.com/moby/moby/issues/23137#issuecomment-359097008


No need to report. We have already fixed this and reported upstream:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opened-files-before-exec-fr.patch

https://bugzilla.redhat.com/show_bug.cgi?id=1537564


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

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

[Paulo Neves]

I will propose a patch with a default bb.debug, and always have the
verbose on dnf. Let's see how it affects the performance. I cannot
test this in a docker container because of the problems described
below:

In the mean time I found what was happening with my slow do_rootfs. I
was running bitbake with RPM packaging in a docker instance. It seems
there is a problem with RPM/dnf in bitbake where it is extremely slow
inside a docker container (1 file per second). After changing to IPK
packages everything went smoothly.

Others have had the same problem[1]. I will later report this to
openembedded mailing list as this effectively makes RPM unusable in a
container. I will also provide a Dockerfile to reproduce this problem.

[1] https://github.com/moby/moby/issues/23137#issuecomment-359097008

Paulo Neves

On Thu, May 3, 2018 at 3:03 PM, Alexander Kanavin
 wrote:
> On 05/03/2018 01:42 PM, Paulo Neves wrote:
>>
>> # Add ROOTFS_RPM_DEBUG to the documentation;
>
>
> I'd rather get rid of it, the less variables the better :)
>
>> # Detect if we are running with debug output and enable the debugging
>> output. This is the most elegant solution but I do not know how to
>> detect if debug log level is turned on;
>
>
> I don't think you are meant to detect that; bitbake's debug level is not
> meant to affect what is being printed, but merely whether it's printed or
> discarded.
>
>> # Have dnf always print in verbose mode and print the output to
>> bb.debug instead of bb.note.
>
>
> I think this is the best solution actually.
>
>> I am happy to provide a patch upon decision or suggestions.
>
>
> Thank you :) Do measure the performance before and after as we don't want to
> introduce a significant slowdown here.
>
>
> Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH 3/3] detail: Fix layer description not wrapping properly

[Paul Eggleton]

In 3adddf6a25977cb576f8fcefd307d947e43d637b I changed the style to allow
pre-formatted text to work in the layer description, but this broke
wrapping so that text could go behind the "Dependencies" box. Use the
"pre-wrap" style instead so that both pre-formatting and wrapping work
here.

Signed-off-by: Paul Eggleton 
---
 templates/layerindex/detail.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/templates/layerindex/detail.html b/templates/layerindex/detail.html
index d1e807be..220d475b 100644
--- a/templates/layerindex/detail.html
+++ b/templates/layerindex/detail.html
@@ -76,7 +76,7 @@
 
 
 
-{{ layeritem.description }}
+{{ layeritem.description 
}}
 
 {% if layeritem.usage_url %}
 
-- 
2.14.3

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

[yocto] [layerindex-web][PATCH 2/3] requirements.txt: fix some conflicting requirements

[Paul Eggleton]

pip (strangely only in the python 2 version when I test it here) reports
that some of the versions in requirements.txt were incompatible:

django-nvd3 0.9.7 has requirement python-nvd3==0.14.2, but you'll have
python-nvd3 0.15.0 which is incompatible.
django-registration 2.4.1 has requirement confusable-homoglyphs~=3.0,
but you'll have confusable-homoglyphs 2.0.2 which is incompatible.
python-nvd3 0.14.2 has requirement python-slugify==1.1.4, but you'll
have python-slugify 1.2.5 which is incompatible.

I'm not particularly keen on downgrading these but it seems like we
don't have much choice. Luckily looking over the changelogs it doesn't
seem like that will cause us any problems though.

Thanks to Yi Zhao  for pointing this out.

Signed-off-by: Paul Eggleton 
---
 requirements.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/requirements.txt b/requirements.txt
index 604c653e..5ca7cf6e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -2,7 +2,7 @@ amqp==2.2.2
 anyjson==0.3.3
 billiard==3.5.0.3
 celery==4.1.0
-confusable-homoglyphs==2.0.2
+confusable-homoglyphs==3.0.0
 Django>1.11.0,<1.12
 django-cors-headers==1.1.0
 django-nvd3==0.9.7
@@ -19,8 +19,8 @@ kombu==4.1.0
 MarkupSafe==1.0
 mysqlclient==1.3.12
 Pillow==5.1.0
-python-nvd3==0.15.0
-python-slugify==1.2.5
+python-nvd3==0.14.2
+python-slugify==1.1.4
 pytz==2018.4
 six==1.11.0
 smmap==0.9.0
-- 
2.14.3

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

[yocto] [layerindex-web][PATCH 1/3] views: fix regression in publish email sending code

[Paul Eggleton]

In e902b67bccddf34d8bbd65ad6c81d078e945ebb8 I missed a couple of Context
usages in the layer publish view and the result was that it broke
publishing a layer (and apparently I didn't run a final test on that,
shame on me).

Thanks to Yi Zhao  for pointing this out.

Signed-off-by: Paul Eggleton 
---
 layerindex/views.py | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/layerindex/views.py b/layerindex/views.py
index c84982ae..bc3cddfa 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -20,7 +20,6 @@ from django.db import transaction
 from django.contrib.auth.models import User, Permission
 from django.db.models import Q, Count, Sum
 from django.template.loader import get_template
-from django.template import Context
 from django.utils.decorators import method_decorator
 from django.contrib.auth.decorators import login_required
 from django.contrib import messages
@@ -277,19 +276,19 @@ def publish_view(request, name):
 break
 
 # create subject from subject template
-d = Context({
+d = {
 'layer_name': layeritem.name,
 'site_name': request.META['HTTP_HOST'],
-})
+}
 subject = subjecttext.render(d).rstrip()
 
 #create body from body template
-d = Context({
+d = {
 'maintainers': maintainer_names,
 'layer_name': layeritem.name,
 'layer_url': layer_url,
 'help_contact': help_contact,
-})
+}
 body = bodytext.render(d)
 
 tasks.send_email.apply_async((subject, body, from_email, [m.email for m in 
maintainers]))
-- 
2.14.3

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

[yocto] [layerindex-web][PATCH 0/3] Fixes for some recent changes

[Paul Eggleton]

Fix a few regressions I recently introduced.


The following changes since commit b4cfb049d9fda7fe82f97f8532abdb7272cf0a76:

  requirements.txt: bump Django and other dependency versions (2018-05-01 
10:10:21 +1200)

are available in the Git repository at:

  git://git.yoctoproject.org/layerindex-web paule/fixes1
  http://git.yoctoproject.org/cgit.cgi//log/?h=paule/fixes1

Paul Eggleton (3):
  views: fix regression in publish email sending code
  requirements.txt: fix some conflicting requirements
  detail: Fix layer description not wrapping properly

 layerindex/views.py  | 9 -
 requirements.txt | 6 +++---
 templates/layerindex/detail.html | 2 +-
 3 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.14.3

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

[yocto] Enabling SD Card Detection for USB SD Card Reader

[Tom Gibson]

Hi,

We would like to enable our Yocto distribution to auto-detect when an SD card 
is inserted in a USB SD card reader, in much the same way as a card is detected 
on desktop linux such as Ubuntu. We have got our USB card reader working with 
the generic-storage driver, but at the moment we have to do something like 
'fdisk -l' to refresh the attached storage after a card is inserted or removed 
in order for it to it to be listed in /dev. The card reader shows up as 
/dev/sda regardless of whether there is a card present or not, but the 
partition on the card only shows up as /dev/sda1 after forcing the refresh.

Any pointers towards which service we need to install to enable this 
functionality appreciated!

Regards,

Tom Gibson
C Software Limited

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

Re: [yocto] PXE booting ISO image fails with message "Waiting for removable media..."

[Vincent Daanen]

Hi Raymond,

> I'd recently gone through similar issue that you're experiencing.  The 
> "Waiting for Removable Media" hang had been there for at least 7-8 years.  A 
> workaround was put in around 2013.  See here: 
> https://patchwork.openembedded.org/patch/42291/
>
> Add "debugshell=30" (30 is in second, for timeout, or any other reasonable 
> value that you like) to the append
> statement in your pxelinux.cfg/default file.  Then you'd timeout when you 
> "normally" hangs, break into a shell,
> where you could initiate udhcpc to configure networking, after which you 
> could transfer your bootable image onto
> your RAM, and write out onto your HDD/SSD.

Unfortunately, we cannot use this trick because the MB which boots using PXE is 
not accessible and we want to use PXE booting  for every boot...

> It seems this kernel boot option of debugshell isn't documented officially in 
> kernel-parameters.txt file.

>  You could also look for init-live.sh on your yocto tree, and look for 
> "Waiting for Removable Media", and see the
> surrounding code to get a fell how this debugshell thing works.
I think this is what we will have to do ..

I read the description of the internals of the initrd provided by Archlinux. 
The main difference is that Yocto initrd searches for the final rootfs on 
physical device (/dev/sdX) whereas the Archlinux initrd identifies (using 
LABEL) the support it was launched from and then searches on this support for 
the final rootfs.

I guess this approach would unify all booting: from USB, CD-ROM and PXE.. But 
at the moment, I don't know how to reproduce the archlinux initrd works with 
Yocto...

If only a guru of Yocto could help ...

Vincent

Date: Thu, 3 May 2018 14:27:46 +
From: Vincent Daanen 
>
To: "yocto@yoctoproject.org" 
>
Subject: [yocto] PXE booting ISO image fails with message "Waiting for
removable media..."
Message-ID:

>

Content-Type: text/plain; charset="utf-8"

Hi,

We want to deploy image created with Yocto (Rocko) via PXE.
The target board is a Intel-based SBC (AAEON GENE BT05).

At first, we tried with a ISO from Archlinux and the target-board successfully 
booted.

Then we create a ISO using Yocto but boot hangs with a message ?Waiting for 
removable media ...?.
Googling this message points me to this post: 
http://thread.gmane.org/gmane.linux.embedded.yocto.general/20611 which relates 
exactly the same problem, explain why the issue raises, gives an indication to 
how to fix .. and that?s all ?

So at this point, we know that the problem comes from the 
/recipes-core/initrdscripts/files/init-live.sh file.
It seems searching for an /dev/sdx should be protected by a timeout set by 
default to 30 secs but during our trials, no timeout seems to exist.

What we do not understand, is how to highlight the differences between the 
Yocto-based and the Archlinux ISO files so that we can ?unblock? the boot using 
the Yocto-based ISO file.

Is the someone here how could help?

Thanks

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