Re: [linux-yocto] [yocto-kernel-cache] [PATCH 0/4] Enable more kernel driver features for Broxton

[Bruce Ashfield]

On Mon, Aug 8, 2016 at 2:31 AM,  wrote:

> From: "Chang, Rebecca Swee Fun" 
>
> Hi Bruce,
>
> Broxton supports the following kernel driver features:
> - LPC bridge for Intel ICH and SCH
> - iSMT support
> - iTCO watchdog
> I have enabled the features under broxton soc config.
>
> I have also expanded the usb-net coverage to support more
> USB network devices for Intel Common BSP.
>
> This patch set is target for yocto-4.1 branch.
>
>
merged and pushed.

I'm out of the office this week, but did merge these changes .. but with me
being not being at a computer full time, I won't be sending SRCREV updates
until Monday.

Cheers,

Bruce


> Please review and provide your feedback if you have any.
>
> Thank you very much.
>
> Regards,
> Rebecca
>
> Chang, Rebecca Swee Fun (4):
>   features: broxton: enable LPC bridge function for Intel ICH and SCH
>   features: broxton: enable iSMT support
>   features: broxton: enable iTCO watchdog support
>   features: usb-net: provide more coverage on USB network devices
>
>  features/soc/broxton/broxton.cfg | 11 +++
>  features/usb-net/usb-net.cfg |  7 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> --
> 1.9.1
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] Set MMC_CAP_AGGRESSIVE_PM for Broxton controllers

[Bruce Ashfield]

On 2016-08-09 9:43 PM, Pranav Tipnis wrote:

Hi Bruce,

Resubmitting a patch for storage driver to enable aggressive PM
for Broxton. This is for bxt-rebase branch.


merged to linux-yocto-4.4 standard/intel/bxt-rebase.

Bruce



Adrian Hunter (1):
  mmc: sdhci-pci: Set MMC_CAP_AGGRESSIVE_PM for Broxton controllers

 drivers/mmc/host/sdhci-pci-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)



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

[linux-yocto] [PATCH] Set MMC_CAP_AGGRESSIVE_PM for Broxton controllers

[Pranav Tipnis]

Hi Bruce,

Resubmitting a patch for storage driver to enable aggressive PM
for Broxton. This is for bxt-rebase branch.

Adrian Hunter (1):
  mmc: sdhci-pci: Set MMC_CAP_AGGRESSIVE_PM for Broxton controllers

 drivers/mmc/host/sdhci-pci-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[linux-yocto] [PATCH] mmc: sdhci-pci: Set MMC_CAP_AGGRESSIVE_PM for Broxton controllers

[Pranav Tipnis]

From: Adrian Hunter 

Upstream-Staus: Submitted [https://patchwork.kernel.org/patch/8809631/]

Set MMC_CAP_AGGRESSIVE_PM for Broxton host controllers.

Signed-off-by: Adrian Hunter 
---
 drivers/mmc/host/sdhci-pci-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pci-core.c 
b/drivers/mmc/host/sdhci-pci-core.c
index e85a81d..83ec752 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -400,8 +400,10 @@ static int byt_sd_probe_slot(struct sdhci_pci_slot *slot)
slot->cd_override_level = true;
if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BXT_SD ||
slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BXTM_SD ||
-   slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD)
+   slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD) {
slot->host->mmc_host_ops.get_cd = bxt_get_cd;
+   slot->host->mmc->caps |= MMC_CAP_AGGRESSIVE_PM;
+   }
 
return 0;
 }
-- 
1.9.1

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

Re: [linux-yocto] missing MMC patches on bxt-rebase tree

[Bruce Ashfield]

On 2016-08-09 4:36 PM, Renganathan, Prabu wrote:

Hi Bruce,



I see some patches were submitted for storage driver to enable
aggressive PM for Broxton. One of the patch in the below series I don’t
see it merged in bxt-rebase tree.



Patch series:

https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04622.html



missing patch in bxt-rebase tree:

https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04627.html



Not sure how it got missed.



resend the patches to the list, that's the right thing to do.

Cheers,

Bruce






-Prabu





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

Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 7, 2016 8:00 AM US Pacific Time

[akuster808]

On 08/09/2016 12:36 PM, Khem Raj wrote:
> 
>> On Aug 3, 2016, at 8:17 AM, akuster808  wrote:
>>
>> On 8/3/16 6:19 AM, Philip Balister wrote:
>>>
>>> On 08/02/2016 11:23 AM, Jolley, Stephen K wrote:
 Attendees: Saul, David Wolfe, Joshua, Belen, Ross, Mark, Bill

>>> 
>>>
Poky - LTS/LTM Branch
- Community Driven
- 2 Years
- Companies continue to push on older branches that they are
 interested in.
- Most patches would be in Oe-Core meta-data
>>> This kind of jumped out at me. Can anyone explain why the Yocto Project
>>> needs an LTS version of the reference distribution?
>>
>> I am glad you asked.
>>
>> In order for a Yocto Member to be Yocto Compatible, any changes made to
>> Bitbake or OE-core have to be submitted to the mailing list. If I have
>> to submit changes then is makes sense that there be a central place like
>> a repo where these changes can live. We have this for the first year.
>> MontaVista and I am sure other Member's support products beyond the
>> first year.  It seems natural to have a process in place to continue the
>> behavior and work Yocto Members are required to perform to maintain
>> Yocto compatibility. Or are you saying Yocto Compatible is only good for
>> 1 year?
> 
> Dont we accept patches indefinitely as long as they keep coming?

Are far as I know we do.

> so in theory every branch is LTS for someone if one cares enough
> about compatibility with compliance programs.

Only if patches make it into a stable branch will they count, it makes
it more official. It is the overhead placed upon Richard and his minions
to take those patches and check them into the appropriate stable
branches. This drops off dramatically once a stable branch transitions
to EOL.


 However, LTS does provide
> a cushion for decision makers, practically, I see we are doing it
> ever since.
> 
>>
>> It not so much having an LTS Poky as much as having LTS branches for OE
>> core and bitbake. This means Poky would not have to be kept updated nor
>> would the Yocto Project need to build or QA the LTS branches.
>>
>> As I see it, an LTS branch would only exist if there is a need and is
>> supported by the ones who desire the LTS branch.  I am sure there will
>> be some prerequisites in doing this.  I don't see this as a bad thing
>> for the community or the Project.
>>
>> regards,
>> Armin
>>
>>
>>
>>>
>>> Philip
>>>
>>>
 * Team Sharing - 10 min
 RP has branch with multi-config in parallel
  - fixes various other tools
  - Distributed builds in 2.2 is unlikely due to resource constraits

 Thanks,

 Sau!

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

[linux-yocto] missing MMC patches on bxt-rebase tree

[Renganathan, Prabu]

Hi Bruce,

I see some patches were submitted for storage driver to enable aggressive PM 
for Broxton. One of the patch in the below series I don't see it merged in 
bxt-rebase tree.

Patch series:
https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04622.html

missing patch in bxt-rebase tree:
https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04627.html

Not sure how it got missed.


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

[yocto] Power button not shutting down the OS

[Paul Knopf]

Hey guys,

I am having an issue with trying to get my power button (i.MX6) to shutdown
the OS.

My kernel has no configuration options for acpi, and acpid gives me the
following error:

---
root@seco-uq7-dl-256mbx4:~# /usr/sbin/acpid
RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink
---

So, my guess is that I have to use udev. If I use udevadm monitor, no
events get raised when I press the power switch.

After digging through the kernel source code (Linux seco-uq7-dl-256mbx4
3.0.101 #1 SMP PREEMPT Thu Jun 2 10:49:45 PDT 2016 armv7l GNU/Linux) and
the imx6 drivers, I finally found something that may help me.

1. I found the power button driver in the OS at
/sys/bus/platform/drivers/imx_seco_pwrb.

2. Some more info that may be helpful.

root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/power_button/enable
disable
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/power_button/en_flash
disable
root@seco-uq7-dl-256mbx4:~# ls /sys/bus/platform/drivers/imx_seco_pwrb/
binduevent  unbind
3. I found /proc/ectrl/events/event_state/power_button which stores the
current state of the power button.

root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
active
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
active
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
active
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
inactive
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
inactive
root@seco-uq7-dl-256mbx4:~# cat /proc/ectrl/events/event_state/power_button
inactive
My embedded operating system is using sysvinit, if that helps.

I effectively need the power button to perform a shutdown -h now. Any ideas
why it isn't currently?

Thanks,
Paul Knopf
Software Engineer
Med X Change, Inc
pkn...@medxchange.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 7, 2016 8:00 AM US Pacific Time

[Khem Raj]

> On Aug 3, 2016, at 8:17 AM, akuster808  wrote:
> 
> On 8/3/16 6:19 AM, Philip Balister wrote:
>> 
>> On 08/02/2016 11:23 AM, Jolley, Stephen K wrote:
>>> Attendees: Saul, David Wolfe, Joshua, Belen, Ross, Mark, Bill
>>> 
>> 
>> 
>>>Poky - LTS/LTM Branch
>>>- Community Driven
>>>- 2 Years
>>>- Companies continue to push on older branches that they are
>>> interested in.
>>>- Most patches would be in Oe-Core meta-data
>> This kind of jumped out at me. Can anyone explain why the Yocto Project
>> needs an LTS version of the reference distribution?
> 
> I am glad you asked.
> 
> In order for a Yocto Member to be Yocto Compatible, any changes made to
> Bitbake or OE-core have to be submitted to the mailing list. If I have
> to submit changes then is makes sense that there be a central place like
> a repo where these changes can live. We have this for the first year.
> MontaVista and I am sure other Member's support products beyond the
> first year.  It seems natural to have a process in place to continue the
> behavior and work Yocto Members are required to perform to maintain
> Yocto compatibility. Or are you saying Yocto Compatible is only good for
> 1 year?

Dont we accept patches indefinitely as long as they keep coming?
so in theory every branch is LTS for someone if one cares enough
about compatibility with compliance programs. However, LTS does provide
a cushion for decision makers, practically, I see we are doing it
ever since.

> 
> It not so much having an LTS Poky as much as having LTS branches for OE
> core and bitbake. This means Poky would not have to be kept updated nor
> would the Yocto Project need to build or QA the LTS branches.
> 
> As I see it, an LTS branch would only exist if there is a need and is
> supported by the ones who desire the LTS branch.  I am sure there will
> be some prerequisites in doing this.  I don't see this as a bad thing
> for the community or the Project.
> 
> regards,
> Armin
> 
> 
> 
>> 
>> Philip
>> 
>> 
>>> * Team Sharing - 10 min
>>> RP has branch with multi-config in parallel
>>>  - fixes various other tools
>>>  - Distributed builds in 2.2 is unlikely due to resource constraits
>>> 
>>> Thanks,
>>> 
>>> Sau!
>>> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] nightly-musl.conf: add world build

[Bill Randle]

Add world build for musl.

[YOCTO #10105]

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-musl.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildset-config.controller/nightly-musl.conf 
b/buildset-config.controller/nightly-musl.conf
index 1f6aba5..cc2aea0 100644
--- a/buildset-config.controller/nightly-musl.conf
+++ b/buildset-config.controller/nightly-musl.conf
@@ -12,7 +12,7 @@ steps: [{'SetDest':{}},
 'buildhistory' : False, 'distro': 'poky',
 'atextappend' : '\nTCLIBC="musl"\n' }},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
-{'BuildImages': {'images':  'core-image-minimal 
core-image-full-cmdline core-image-sato'}},
+{'BuildImages': {'images':  'core-image-minimal 
core-image-full-cmdline core-image-sato world'}},
 {'DownloadErrorReports': {}},
 {'SendErrorReport': {}}]
 
-- 
2.5.5

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

[yocto] [yocto-autobuilder][PATCH] SendQAEmail.py: use sendmail instead of mail to send QA email

[Bill Randle]

When sending QA emails, the autobuilder uses the 'mail' command (typically
installed as /usr/bin/mail or /bin/mail). However, most distributions do not
install this program by default. They generally always install the 'sendmail'
program, though, so use 'sendmail' as the mail agent, rather than 'mail'.

[YOCTO #10082]

Signed-off-by: Bill Randle 
---
 .../autobuilder/buildsteps/SendQAEmail.py  | 26 --
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/SendQAEmail.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/SendQAEmail.py
index 0cd76d5..3691cc6 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/SendQAEmail.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/SendQAEmail.py
@@ -47,9 +47,9 @@ class SendQAEmail(ShellCommand):
 properties = self.build.getProperties().asDict()
 repoprops = {}
 mailsubject = "Build available for QA"
-email_header = '''
-A build identified as needing QA has finished on the autobuilder. This
-build is located at:\n\n
+email_base = '''
+A build identified as needing QA has finished on the autobuilder. This
+build is located at:\n\n
 %s''' % (self.getProperty('DEST').replace(web_root, web_url))
 
 if str(self.getProperty("custom_release_me")) == "True":
@@ -68,9 +68,9 @@ class SendQAEmail(ShellCommand):
 poky_number = self.getProperty("custom_poky_number")+prefix
 yocto_number = self.getProperty("custom_yocto_number")+prefix
 rel_name = 'yocto-'+ yocto_number
-email_header = '''
+email_base = '''
 A release candidate build for %s is now available at:\n\n
-%s\n\n
+%s\n\n
 Please begin QA on this build as soon as possible.''' % (rel_name, 
self.getProperty('DEST').replace(web_root, web_url))
 mailsubject = "Release Candidate Build for " + rel_name + 
snapshot + " now available."
 
@@ -85,16 +85,18 @@ Please begin QA on this build as soon as possible.''' % 
(rel_name, self.getPrope
 for k, v in repoprops.iteritems():
 email_body = email_body + '%s : %s \n' % (k, v[1])
 
-mailcmd = 'echo -e "' + email_header + '\n' + email_body + '\n' + 
mailsig + ' " | mail -s \'' + mailsubject + '\''
-
+email_header = ""
+if mailto is not None and mailto is not "":
+email_header += "To: " + mailto + "\n"
 if mailcc is not None and mailcc is not "":
-mailcmd += " -c '" + mailcc + "' "
-
+email_header += "Cc: " + mailcc + "\n"
 if mailbcc is not None and mailbcc is not "":
-mailcmd += " -b '" + mailbcc + "' "
+email_header += "Bcc: " + mailbcc + "\n"
+
+email_header += "Subject: " + mailsubject + "\n"
+
+mailcmd = 'echo -e "' + email_header + "\n" + email_base + '\n' + 
email_body + '\n' + mailsig + ' " | sendmail -t'
 
-if mailto is not None and mailto is not "":
-mailcmd += " '" + mailto + "' "
 self.command = mailcmd
 else:
 self.command = 'echo "Not a QA build"'
-- 
2.5.5

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

Re: [yocto] How to build yocto as a root user?

[Brian Avery]

Yocto includes pseudo which handles the things fakeroot does and a bit more
https://www.yoctoproject.org/tools-resources/projects/pseudo.

-brian
an Intel employee

On Tue, Aug 9, 2016 at 7:27 AM, Jan Lindåker  wrote:

>
> 
> From: yocto-boun...@yoctoproject.org  on
> behalf of Philip Balister 
> Sent: Tuesday, August 9, 2016 15:39
> To: jags gediya; yocto@yoctoproject.org; meta-freesc...@yoctoproject.org
> Subject: Re: [yocto] How to build yocto as a root user?
>
> On 08/09/2016 09:32 AM, jags gediya wrote:
> > > I am facing issues while build yocto as root user on ubuntu 14.04.
> > > How can i build as a root user?
> >
> > Do not do this, it is a terrible idea. Create a user account and build
> > there.
> >
> > Philip
>
> You are right Philip, for building with yocto/bitbake it is a bad idea. I
> only read the part with becoming root, and forgot that I do not build as
> root.
>
> However,  to be able to build a usable file system that installs on target
> I think installing fakeroot is necessary:
> $ sudo apt-get install fakeroot
> $ man fakeroot
>
> /BR Jan
>
> >
> >
> >
> --
> ___
> 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] [RFT] binutils 2.27

[Richard Purdie]

On Tue, 2016-08-09 at 07:42 -0700, Khem Raj wrote:
> I could also see it on ppc. backtrace, shows the segfault is in exit
> path and happens in libc
> at this point, I think the problem is how libc is compiled with
> binutils 2.27, connman itself
> is ok. 

Its the issue here:

https://sourceware.org/ml/glibc-bugs/2015-01/msg00274.html
https://sourceware.org/bugzilla/show_bug.cgi?id=17908

Basically, if you remove the global _IO_stdin_used symbol, it triggers
compatibility code which crashes.

I've confirmed that if I add that symbol to the version-script in
connman, things work again.

Any idea how we raise the priority of this issue. There are no comments
on the bug despite it having been posted a while ago :(.

Cheers,

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

Re: [yocto] [OE-core] [RFT] binutils 2.27

[Khem Raj]

> On Aug 8, 2016, at 4:16 PM, Burton, Ross  wrote:
> 
> 
> On 8 August 2016 at 16:59, Richard Purdie  > wrote:
> FWIW, I think the connmand segfault on mips and powerpc is hinted at
> with this bug:
> 
> https://bugs.launchpad.net/ubuntu/+source/lua5.3/+bug/1570055 
> 
> 
> connmand is a binary linked with a linker version-script. If I build
> connmand without that option, it doesn't segfault, at least on mips.
> 
> The binutils manuals say you shouldn't build binaries with version
> scripts:
> 
> http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html 
> 
> 
> Its suspected connman might do this to limit the function exposure to
> its plugins.
> 
> Now sure exactly what needs to happen here without more research but it
> certainly hits at where the problem is. I suspect its the same issue on
> ppc.
> 
> I've verified that with binutils 2.26 on x86-64, a minimal test case for an 
> executable using a version script to limit exported symbols to dlopen()d 
> modules does in fact work.  A toolchain is building now to see what happens 
> in different environments.

I could also see it on ppc. backtrace, shows the segfault is in exit path and 
happens in libc
at this point, I think the problem is how libc is compiled with binutils 2.27, 
connman itself
is ok.

> 
> Ross



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to build yocto as a root user?

[Jan Lindåker]

From: yocto-boun...@yoctoproject.org  on behalf 
of Philip Balister 
Sent: Tuesday, August 9, 2016 15:39
To: jags gediya; yocto@yoctoproject.org; meta-freesc...@yoctoproject.org
Subject: Re: [yocto] How to build yocto as a root user?

On 08/09/2016 09:32 AM, jags gediya wrote:
> > I am facing issues while build yocto as root user on ubuntu 14.04.
> > How can i build as a root user?
> 
> Do not do this, it is a terrible idea. Create a user account and build
> there.
> 
> Philip

You are right Philip, for building with yocto/bitbake it is a bad idea. I only 
read the part with becoming root, and forgot that I do not build as root.

However,  to be able to build a usable file system that installs on target I 
think installing fakeroot is necessary:
$ sudo apt-get install fakeroot 
$ man fakeroot

/BR Jan

>
>
>
--
___
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] How to build yocto as a root user?

[Philip Balister]

On 08/09/2016 09:32 AM, jags gediya wrote:
> I am facing issues while build yocto as root user on ubuntu 14.04.
> How can i build as a root user?

Do not do this, it is a terrible idea. Create a user account and build
there.

Philip

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

[yocto] How to build yocto as a root user?

[jags gediya]

I am facing issues while build yocto as root user on ubuntu 14.04.
How can i build as a root user?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] augeas: Move to meta-python optional layer

[Joe MacDonald]

Augeas lives in meta-python, but meta-selinux shouldn't specifically
require meta-python in every build, so make the bbappend optional using
the standard mechanism already present in the layer.conf.

Signed-off-by: Joe MacDonald 
---
 meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend | 1 +
 recipes-extended/augeas/augeas_%.bbappend| 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
 delete mode 100644 recipes-extended/augeas/augeas_%.bbappend

diff --git a/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend 
b/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
new file mode 100644
index 000..c1e8ed6
--- /dev/null
+++ b/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
@@ -0,0 +1 @@
+inherit with-selinux
diff --git a/recipes-extended/augeas/augeas_%.bbappend 
b/recipes-extended/augeas/augeas_%.bbappend
deleted file mode 100644
index c1e8ed6..000
--- a/recipes-extended/augeas/augeas_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-inherit with-selinux
-- 
1.9.1

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

[yocto] useradd does not creates user in rootfs but sysroot ?

[Kumar, Shrawan]

Dear Team,

Downloaded   " krogoth" release ,  with intension  to use the above bb  file  
to create users( user1,user2 etc.)  The expectation was that the users should 
get created in the "rootfs" .
But to dismay, this get created in the sysroot 
(poky/build/tmp/sysroots/qemux86/etc/passwd).

This works as expected in  "jethro"  release.  Do we have alternate way to 
achieve the same in  " krogoth" release   ?

Regards
Shrawan




useradd-example.bb
Description: useradd-example.bb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 7, 2016 8:00 AM US Pacific Time

[Anders Darander]

* akuster808  [160803 17:18]:

> On 8/3/16 6:19 AM, Philip Balister wrote:

> > On 08/02/2016 11:23 AM, Jolley, Stephen K wrote:
> >> Attendees: Saul, David Wolfe, Joshua, Belen, Ross, Mark, Bill

> > 

> >> Poky - LTS/LTM Branch
> >> - Community Driven
> >> - 2 Years
> >> - Companies continue to push on older branches that they are
> >> interested in.
> >> - Most patches would be in Oe-Core meta-data
> > This kind of jumped out at me. Can anyone explain why the Yocto Project
> > needs an LTS version of the reference distribution?

> It not so much having an LTS Poky as much as having LTS branches for OE
> core and bitbake. This means Poky would not have to be kept updated nor
> would the Yocto Project need to build or QA the LTS branches.

I'm pretty sure that this is the point Philip was after, that it really
doesn't make sense for Poky.

LTS branches in oe-core and bitbake, OTOH, makes sense, and would be
appreciated by quite some. 

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the simplest way to test a new kernel configuration in a Yocto Project?

[robert.berger@gmane]

Hi,

On 2016-08-09 07:20, Daniel. wrote:

Hi Patrick,

If you are running your image embedded at some board, and have easy
access to the board, you can plug it to network and make u-boot
download kernel from your machine. So that deploy a new kernel becomes
simple as copy the new kernel to the tftp folder, and rebooting
target. This is also true for device-trees. And if you have NFS
support is true for all userspace too. :)


To be precise the statically linked kernel + dtb can be loaded by u-boot 
over tftp (and nfs). The kernel modules are typically part of the rootfs 
so they would be exported by nfs in our scenario.


I usually use symbolic links in my tftp export as well as which nfs 
rootfs I export so I don't need to change the u-boot environment to boot 
from something different. Like this it's just a matter of copying things 
around on your PC and adjusting the symlinks.


Regards,

Robert



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