Re: [yocto] TFS Urls with Git in Recipes

[Lohr, Christian [ext]]

Hello Randy,

Thanks for your reply and your efforts.
I already solved my issue and renamed the project from "FooBar 500" to 
"FooBar_500". This was the easiest and fastest solution. And luckily nobody 
complained after the renaming.

Before that I also tried that one (both of them), but it didn't work:

> It's possible that:
> PROJECT_NAME = "FooBar 500"
> or
> PROJECT_NAME = "FooBar\ 500"
> would work.


-Ursprüngliche Nachricht-
Von: Randy MacLeod  
Gesendet: Freitag, 25. Oktober 2019 21:33
An: Lohr, Christian [ext] ; yocto@yoctoproject.org
Betreff: Re: [yocto] TFS Urls with Git in Recipes

Hello Christian,

Thanks for reporting the problem. Comments and questions below.

On 10/23/19 3:36 AM, Lohr, Christian [ext] wrote:
> Hello,
> 
> I‘m using the following:
> 
> Yocto Release 2.4 (Rocko), and Bitbake 1.9.x

Can you check if the problem is still present on the master branch?

> 
> My problem is the following url (actually the “%20” is the problem in
> bitbake):
> 
> ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar%20500/_git/DummyAp
> plicationForYocto
> 
> I can do a “git clone ” without any problems. Now I wanted to 
> create a Yocto recipe similar to this:
> 
> --
> 
> 
> SUMMARY = "A demo application"
> 
> DESCRIPTION = "This application is just for demo purpose and should be 
> seen as Hello World"
> 
> LICENSE = "CLOSED"
> 
> #LIC_FILES_CHKSUM = ""
> 
> PROJECT_URL = "tfs-my-company.org:22/tfs/OWN_Projects"
> 
> PROJECT_NAME = "FooBar%20500"

It's possible that:
 PROJECT_NAME = "FooBar 500"
or
 PROJECT_NAME = "FooBar\ 500"
would work. Have you tried that already? I haven't worked on the bitbake 
fetcher code so I may be making naive suggestions.

Also, I expect that you are working around the issue by just removing the space 
in the path, right?

> 
> SRC_URI =
> "git://${PROJECT_URL}/${PROJECT_NAME}/_git/DummyApplicationForYocto;protocol=ssh"
> 
> SRCREV = "${AUTOREV}"
> 
> PV = "1.0+git${SRCPV}"
> 
> DEPENDS = "qtbase"
> 
> --
> --
> 
> The „%20“ sign will be replaced with a space “ “ in some cases:
> 
> When I try to run “bitbake dummyapp”, the following happens:
> 
> “FooBar%20500” will be transformed to “FooBar 500”
> 
> --
> --
> 
> git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar
> 500/_git/DummyApplicationForYocto  failed with exit code 128, output:
> 
> remote: Command git-upload-pack '/tfs/OWN_Projects/FooBar' is not in 
> expected format.
> 
> fatal: Could not read from remote repository.
> 
> Is it possible to prevent this because if it would leave the “%20” the 
> command would work.


The YP does have problems dealing with spaces in path names as you have seen. I 
think this prevents the MacOS port for example.

Could you open a defect in the Yocto bugzilla?
   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.yoctoproject.org%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=3OgKQDXnzp2D6wKZdZuhgVMGkMVv%2B7pjCGfWWSk1AIs%3D&reserved=0
   
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FBug_reporting_and_Information_levels&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=aQW%2Fzc7M8ZSU4yvPiiAxhev8P%2BatdmiV5XgGgW8KviM%3D&reserved=0

Ideally, it would be great if you could submit a patch but I understand that 
you may not have the time, interest or the expertise to do so.
If you are not able to do that then the defect will be triaged during the 
weekly review (next week's meeting is actually cancelled do to the Embedded 
Linux Conference - Europe) and someone will work on the defect based on it's 
importance and their interest and workload.

If you want a fix sooner than that, there are companies and consultants listed 
on the yocto project homepage:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yoctoproject.org%2Fecosystem%2Fmembers%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=%2F%2BhOUitRQRUvwpjk954BlOQtb3d5WIzsgrwjAsdAj0c%3D&reserved=0

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yoctoproject.org%2Fcommunity%2Fconsultants%2F&data=02%7C01%7C%7C73e5d9d6551a4ca871fe08d7598230fb%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637076288017573764&sdata=%2FOLhvIdhf%2FH%2BIfe09taOjhyDiDfaPBmO%2BPq0TDJbzwQ%3D&reserved=0

Thanks again for the report and
I'm sorry that I

[yocto] [meta-mingw][PATCH 1/3] libxml2: Remove python support

[Joshua Watt]

Python doesn't cross compile for MinGW, so remove it as a dependency
from the mingw32 nativesdk build

Signed-off-by: Joshua Watt 
---
 recipes-core/libxml/libxml2_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-core/libxml/libxml2_%.bbappend

diff --git a/recipes-core/libxml/libxml2_%.bbappend 
b/recipes-core/libxml/libxml2_%.bbappend
new file mode 100644
index 000..2c9f206
--- /dev/null
+++ b/recipes-core/libxml/libxml2_%.bbappend
@@ -0,0 +1 @@
+PACKAGECONFIG_remove_class-nativesdk_mingw32 = "python"
-- 
2.21.0

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

[yocto] [meta-mingw][PATCH 2/3] wayland: Disable library

[Joshua Watt]

Disable building the wayland libraries for MinGW. The libraries don't
compile for this platform, and are generally unneeded anyway. The
wayland recipe is usually only compiled for nativesdk to pull in the
wayland-scanner utility.

Signed-off-by: Joshua Watt 
---
 recipes-graphics/wayland/wayland_%.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-graphics/wayland/wayland_%.bbappend

diff --git a/recipes-graphics/wayland/wayland_%.bbappend 
b/recipes-graphics/wayland/wayland_%.bbappend
new file mode 100644
index 000..3713f2d
--- /dev/null
+++ b/recipes-graphics/wayland/wayland_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OECONF_class-nativesdk_mingw32 = "--disable-documentation 
--disable-libraries"
+
-- 
2.21.0

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

[yocto] [meta-mingw][PATCH 3/3] dbus: Set FILES

[Joshua Watt]

Set the package files correctly for MinGW

Signed-off-by: Joshua Watt 
---
 recipes-core/dbus/dbus_%.bbappend | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 recipes-core/dbus/dbus_%.bbappend

diff --git a/recipes-core/dbus/dbus_%.bbappend 
b/recipes-core/dbus/dbus_%.bbappend
new file mode 100644
index 000..76b0c3e
--- /dev/null
+++ b/recipes-core/dbus/dbus_%.bbappend
@@ -0,0 +1,11 @@
+FILES_${PN}_append_mingw32 = "\
+${bindir}/dbus-send.exe \
+${bindir}/dbus-monitor.exe \
+${bindir}/dbus-launch.exe \
+${bindir}/dbus-test-tool.exe \
+${bindir}/dbus-update-activation-environment.exe \
+"
+
+FILES_${PN}-lib_append_mingw32 = "\
+${bindir}/lib*.dll \
+"
-- 
2.21.0

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

Re: [yocto] [meta-mingw][PATCH 1/3] libxml2: Remove python support

[Ross Burton]

On 28/10/2019 15:58, Joshua Watt wrote:

Python doesn't cross compile for MinGW, so remove it as a dependency
from the mingw32 nativesdk build


+1 please push
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen K Jolley]

All,



The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:



https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs



The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.



Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 297
unassigned or newcomer bugs.



We're hoping people may be able to spare some time now and again to help
out with these.  Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system.  There are also roughly four different "priority"
classes right now, “3.1”, “3.2, "3.99" and "Future", the more
pressing/urgent issues being in "3.1" and then “3.2”.



Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

-- 

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [psplash][PATCH] Adding SPDX license identifier to psplash

[Ross Burton]

On 23/10/2019 09:00, Yann CARDAILLAC wrote:

Hi,

If you have any advice please feel free to ask.

I've put GPLV2 or later whenever it was mentioned and GPLV2 where nothing was
saying otherwise.


I'd say the license was intended to be uniform, so if there are mentions 
of v2-or-later then make it all or-later.


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

[yocto] systemd Version Going Backwards on Warrior

[robert . joslyn]

I'm using buildhistory in one of my builds that creates a package feed, and a 
recent update to systemd on warrior triggered version-going-backwards errors:

ERROR: systemd-conf-241+AUTOINC+511646b8ac-r0 do_packagedata: QA Issue: Package 
version for package systemd-conf-src went backwards which would break package 
feeds from (0:241+0+c1f8ff8d0d-r0 to 0:241+0+511646b8ac-r0) 
[version-going-backwards]

Should PE have been updated at the same time due to the hash making the version 
number go backwards? I can send a patch if that's all that's missing. Or is a 
PR server enough to prevent this? My debug builds do not use a PR server, but 
my production builds do use a PR server.

Thanks,
Robert

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

Re: [yocto] systemd Version Going Backwards on Warrior

[Ross Burton]

On 28/10/2019 16:25, robert.jos...@redrectangle.org wrote:

I'm using buildhistory in one of my builds that creates a package feed, and a 
recent update to systemd on warrior triggered version-going-backwards errors:

ERROR: systemd-conf-241+AUTOINC+511646b8ac-r0 do_packagedata: QA Issue: Package 
version for package systemd-conf-src went backwards which would break package 
feeds from (0:241+0+c1f8ff8d0d-r0 to 0:241+0+511646b8ac-r0) 
[version-going-backwards]

Should PE have been updated at the same time due to the hash making the version 
number go backwards? I can send a patch if that's all that's missing. Or is a 
PR server enough to prevent this? My debug builds do not use a PR server, but 
my production builds do use a PR server.


If you're using feeds, you need to use a PR server.  This is *exactly* 
what they are for.


Ross

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

[yocto] allarch.bbclass is not clearing ABIEXTENSION

[Darcy Watkins]

Hi,

I discovered that when I attempt to make use of variables such as WORKDIR, 
STAGING_DIR_HOST or RECIPE_SYSROOT in a recipe based on allarch.bbclass, these 
variables pointed to nonexistent path locations.  Upon investigation, I 
determined that under the "tmp/work" directory, it is specifying 
"all-poky-linux-gnueabi" when in fact it should specify "all-poky-linux".

I got it to work properly in my recipe by setting ABIEXTENSION = "" (or using 
an anonymous python function within my customized bbclass to do this only when 
the PACKAGE_ARCH == "all").

I believe that the correct action would be to clear it as part of 
allarch.bbclass.

Anyone else experience this issue?

I encountered this using 'warrior' when a custom bbclass I have that uses a 
script from within the sysroot failed for allarch even though it worked for the 
normal arch.



Regards,

Darcy

Darcy Watkins ::  Senior Staff Engineer, Firmware

SIERRA WIRELESS
Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[P2]
dwatk...@sierrawireless.com :: 
www.sierrawireless.com

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

[yocto] [layerindex-web][PATCH 0/2] dependency updates

[Paul Eggleton]

Updates to python dependencies in requirements.txt, including one
upstream CVE fix.


The following changes since commit fae9771604097896f10a4aec2f2aee7fefd8ec86:

  Fix cgit commit URL setting (2019-10-21 12:02:44 +1300)

are available in the Git repository at:

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

Paul Eggleton (2):
  requirements.txt: update to fix CVE-2019-16865
  requirements.txt: bump a couple more versions

 requirements.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.20.1

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

[yocto] [layerindex-web][PATCH 1/2] requirements.txt: update to fix CVE-2019-16865

[Paul Eggleton]

Update Pillow version to incorporate a fix for a denial-of-service
vulnerability (which should not affect this application however, as it
does not use Pillow to process external images):

  https://nvd.nist.gov/vuln/detail/CVE-2019-16865

Signed-off-by: Paul Eggleton 
---
 requirements.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/requirements.txt b/requirements.txt
index 855b7344..84f2ea54 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -19,7 +19,7 @@ gitdb2==2.0.6
 GitPython==2.1.13
 kombu==4.6.3
 mysqlclient==1.4.4
-Pillow==6.1.0
+Pillow==6.2.1
 pytz==2019.2
 six==1.12.0
 smmap2==2.0.5
-- 
2.20.1

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

[yocto] [layerindex-web][PATCH 2/2] requirements.txt: bump a couple more versions

[Paul Eggleton]

Update pytz and beautifulsoup4.

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

diff --git a/requirements.txt b/requirements.txt
index 84f2ea54..07d8495e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,5 +1,5 @@
 amqp==2.5.2
-beautifulsoup4==4.8.0
+beautifulsoup4==4.8.1
 billiard==3.6.1.0
 celery==4.3.0
 confusable-homoglyphs==3.2.0
@@ -20,7 +20,7 @@ GitPython==2.1.13
 kombu==4.6.3
 mysqlclient==1.4.4
 Pillow==6.2.1
-pytz==2019.2
+pytz==2019.3
 six==1.12.0
 smmap2==2.0.5
 soupsieve==1.9.4
-- 
2.20.1

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

[yocto] [meta-security][thud][PATCH 3/3] apparmor: Fix xargs error

[Anders Montonen]

The functions script uses flags specific to GNU xargs.
Add findutils to RDEPENDS.
Fixes: /lib/apparmor/functions: line 92: echo: write error: Broken pipe

Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index ad7f94e..d2d83ca 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -177,7 +177,7 @@ FILES_mod-${PN} = "${libdir}/apache2/modules/*"
 
 ALLOW_EMPTY_${PN} = "1"
 
-RDEPENDS_${PN} += "bash lsb"
+RDEPENDS_${PN} += "bash lsb findutils"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3 
python3-modules','', d)}"
 RDEPENDS_${PN}_remove += 
"${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
 RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib"
-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 0/3] AppArmor fixes for Thud

[Anders Montonen]

This series backports two patches from master, and fixes one xargs
incompatibility. Together, this allows AppArmor run on an Arm target
under systemd.

Anders Montonen (1):
  apparmor: Fix xargs error

Armin Kuster (2):
  apparmor: ptest fail to build on arm
  apparmor: fix systemd support so it works

 recipes-security/AppArmor/apparmor_2.12.bb | 38 ++
 1 file changed, 31 insertions(+), 7 deletions(-)

-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 2/3] apparmor: fix systemd support so it works

[Anders Montonen]

From: Armin Kuster 

[Yocto # 13568]

Signed-off-by: Armin Kuster 
(cherry picked from commit 5d049e7ef8a0a0a811e2ea1353521c6898e54e4d)
Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index 377d918..ad7f94e 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -43,7 +43,6 @@ PACKAGECONFIG[apache2] = ",,apache2,"
 PAMLIB="${@bb.utils.contains('DISTRO_FEATURES', 'pam', '1', '0', d)}"
 HTTPD="${@bb.utils.contains('PACKAGECONFIG', 'apache2', '1', '0', d)}"
 
-
 python() {
 if 'apache2' in d.getVar('PACKAGECONFIG').split() and \
 'webserver' not in d.getVar('BBFILE_COLLECTIONS').split():
@@ -83,7 +82,6 @@ do_compile () {
 do_install () {
install -d ${D}/${INIT_D_DIR}
install -d ${D}/lib/apparmor
-   
oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}" install
oe_runmake -C ${B}/binutils DESTDIR="${D}" install
oe_runmake -C ${B}/utils DESTDIR="${D}" install
@@ -104,10 +102,12 @@ do_install () {
 
install ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
install ${WORKDIR}/functions ${D}/lib/apparmor
-   if [ "${VIRTUAL-RUNTIME_init_manager}" = "systemd" ]; then
+   sed -i -e 's/getconf _NPROCESSORS_ONLN/nproc/' 
${D}/lib/apparmor/functions
+   sed -i -e 's/ls -AU/ls -A/' ${D}/lib/apparmor/functions
+
+   if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -d ${D}${systemd_system_unitdir}
-   install ${WORKDIR}/apparmor.service \
-   ${D}${systemd_system_unitdir}
+   install ${WORKDIR}/apparmor.service 
${D}${systemd_system_unitdir}
fi
 }
 
@@ -156,13 +156,19 @@ do_install_ptest_arm() {
   :
 }
 
+# We need the init script so don't rm it
+python() {
+postfuncs = 
d.getVarFlags('do_install')['postfuncs'].replace('rm_sysvinit_initddir', '')
+d.setVarFlags('do_install', { 'postfuncs': postfuncs })
+}
+
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME = "apparmor"
 INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
 
 SYSTEMD_PACKAGES = "${PN}"
 SYSTEMD_SERVICE_${PN} = "apparmor.service"
-SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_AUTO_ENABLE ?= "enable"
 
 PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'apache2', 'mod-${PN}', '', 
d)}"
 
-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 1/3] apparmor: ptest fail to build on arm

[Anders Montonen]

From: Armin Kuster 

exclude arm and aarch64 ptest tasks

[v2&3]

Sent before committing.

Signed-off-by: Armin Kuster 
(cherry picked from commit 27ddb455543b670097e252ba0d0ad5b7e4101748)
Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index e3f8dc9..377d918 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -111,6 +111,15 @@ do_install () {
fi
 }
 
+#Building ptest on arm fails.
+do_compile_ptest_aarch64 () {
+  :
+}
+
+do_compile_ptest_arm () {
+  :
+}
+
 do_compile_ptest () {
 oe_runmake -C ${B}/tests/regression/apparmor
 oe_runmake -C ${B}/parser/tst
@@ -138,6 +147,15 @@ do_install_ptest () {
cp -rf ${B}/binutils ${t}
 }
 
+#Building ptest on arm fails.
+do_install_ptest_aarch64 () {
+  :
+}
+
+do_install_ptest_arm() {
+  :
+}
+
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME = "apparmor"
 INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
-- 
2.17.1

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

Re: [yocto] [layerindex-web] Add SPDX Identifier

[Paul Eggleton]

Hi Yann

On Wednesday, 23 October 2019 2:25:48 AM NZDT Yann CARDAILLAC wrote:
> On Mon, Oct 21, 2019 at 9:37 PM Paul Eggleton 
> wrote:
> > On Tuesday, 22 October 2019 4:15:03 AM NZDT Yann CARDAILLAC wrote:
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13527
> > >
> > > I'm beginning the work of updating the layerindex-web repo, this one is a
> > > bit tricky, how should I treat the files generated using Django ?
> >
> > I believe the correct license for Django-derived files is BSD-3-Clause:
> >
> >   https://github.com/django/django/blob/master/LICENSE
> >
> > > I've yet to do html, txt and sh files, do you have any advices before I
> > > start?
> >
> > Note that some of the templates used for authentication originally came
> > from
> > here:
> >
> >   https://github.com/macdhuibh/django-registration-templates
> >
> > The LICENSE file indicates MIT for those though.
> >
> > The txt files are tricky because any stray newlines will affect
> > formatting. I would probably avoid touching them.
>
> I did not yet add MIT to html files, I don't really know if that makes
> sense or not?  I didn't do that because it seemed a bit weird to me, but I
> don't know what to think of that. Most of the time you'll find copyright on
> the footer of the page, but I'm not sure about Licensing those.
> 
> So here is a first iteration of the patch without htmls file licensed.

I think it's fine to add to the HTML as long as you add it as part of the 
Django template comment at the top and not in the actual text that gets 
rendered.

Looking over the license definitions they look fine, except the migrations - if 
these are considered derived from Django (which is fine) then they should all 
be BSD-3-Clause rather than some being MIT. It looks like some of the earlier 
ones don't have a "generated by django" comment, but they were all initially 
generated with ./manage.py makemigrations; some then had additional code added 
to them.

Cheers
Paul

-- 

Paul Eggleton
Intel System Software Products


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

Re: [yocto] systemd Version Going Backwards on Warrior

[Robert Joslyn]

On Mon, 2019-10-28 at 19:06 +, Ross Burton wrote:
> On 28/10/2019 16:25, robert.jos...@redrectangle.org wrote:
> > I'm using buildhistory in one of my builds that creates a package
> > feed, and a recent update to systemd on warrior triggered version-
> > going-backwards errors:
> > 
> > ERROR: systemd-conf-241+AUTOINC+511646b8ac-r0 do_packagedata: QA
> > Issue: Package version for package systemd-conf-src went backwards
> > which would break package feeds from (0:241+0+c1f8ff8d0d-r0 to
> > 0:241+0+511646b8ac-r0) [version-going-backwards]
> > 
> > Should PE have been updated at the same time due to the hash making
> > the version number go backwards? I can send a patch if that's all
> > that's missing. Or is a PR server enough to prevent this? My debug
> > builds do not use a PR server, but my production builds do use a PR
> > server.
> 
> If you're using feeds, you need to use a PR server.  This is *exactly* 
> what they are for.
> 
> Ross

The part I wasn't sure about was if the PR server helped in the case where
PV went backwards. I know it works when PV stays the same but the package
was rebuilt. But if it keeps the versions going forward no matter how PV
changes, then I should be good. I should probably setup a separate PR
server on my debug builds to avoid this kind of error.

Thanks,
Robert

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