[yocto] [mono][msbuild][nuget] Building c# application for mono

[Alberto Spin]

Hello,

I'm trying to build my c# application for mono with yocto, by using nuget and 
msbuild.

I encountered several problems:

MsBuild:

  *   During the build of msbuild the cibuild.sh script is invoked. This script 
uses the tool 'curl' to download the msbuild.zip form Microsoft. This action 
failes with a certificate error because there are no certificates present. I 
fixed this issue with a bbappend script for msbuild which contains:
DEPENDS += "ca-certificates"

Nuget:

  *   When trying to restore the packages for my c# application, the execution 
of Nuget fails because it has no certificates.
  *   Apparently NuGet is using the mono certificate store, because it fails to 
detect the certificates present in:  /recipe-sysroot-native/etc/ssl/certs
  *   I also verified that the mono certificate store is empty by issuing the 
command: certmgr -list -c Trust

I tried to extend the recipe that builds my c# application with a do_configure 
task, in which I'm trying to synchronize the mono certificate store with the 
ca-certifates.crt.
cert-sync ${sysconfdir}/ssl/certs/ca-certificates.crt

But the cert-sync tool somehow wants to use a path outside my build environment 
/usr/share/.mono, which fails with an access denied error.

Can anybody help me to get past this problem?

Kind Regards,

Alberto Spin

Branch: Rocko
Mono 5.4.1.6
Nuget 4.1
Msbuild 15.4



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

[yocto] Yocto Project Status WW40’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M4.
Next Deadline: YP 2.6 M4 Build Target is Oct. 1, 2018

SWAT Team Rotation:

  *   SWAT lead is currently: Armin
  *   SWAT team rotation: Armin -> Paul on Oct. 5, 2018
  *   SWAT team rotation: Paul -> Ross on Oct. 12, 2018
  *   https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

  *   2.6 M3 rc1 has been built and is in QA; currently 94% complete.  See 
https://wiki.yoctoproject.org/wiki/2.6_QA_Status.
  *   One potential M3 blocking issue has been identified in build appliance, 
#12894.
  *   We’re now past feature freeze and all major changes planned for 2.6 have 
been merged so only bug fixes will be accepted now.
  *   We have also seen multiple reports of a reproducibility problem for 
non-IA binaries in the debug symbol sections, this is concerning and may hold 
up the release.

Planned Releases for YP 2.6:

  *   YP 2.6 M3 Release Target was Sept. 7, 2018
  *   YP 2.6 M4 Build Target is Oct. 1, 2018
  *   YP 2.6 M4 Release Target is Oct. 26, 2018

Planned upcoming dot releases:

  *   YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.
  *   YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.

Tracking Metrics:

  *   WDD 2534 (last week 2562) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Poky Patch Metrics
 *   Total patches found: 1657 (last week 1658)
 *   Percentage of patches in the Pending State: 732 (44%) [last week 732 
(44%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

Re: [yocto] [yocto-docs][PATCH] kernel-dev: document the change detection of kernel feature files

[Bruce Ashfield]

On 2018-10-01 8:42 AM, Urs Fässler wrote:

Recommend to add recipe-space features to SRC_URI so that changes to them
are detected automatically.

Signed-off-by: Urs Fässler 
Signed-off-by: Pascal Bach 
---
  documentation/kernel-dev/kernel-dev-common.xml | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 83b02b1c1..6289ce8d4 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -2623,6 +2623,9 @@
  .scc file in the
  SRC_URI statement to reference multiple 
kernel
  features.
+Since BitBake only detects changes on files listed in
+SRC_URI, it is best to add all


This is not necessarily true. It would be better stated that if you
are modifying the .cfg files in the layer directly, you should list
them on the SRC_URI to have the changes picked up by bitbake.

It is not a matter of "best", so it should be stated that way.


+.cfg to SRC_URI.
  
  
  

@@ -2674,10 +2677,10 @@
  
  
  Add the Feature File to 
SRC_URI:
-Add the .scc file to the
+Add the .cfg and 
.scc file to the
  recipe's SRC_URI statement:
  
- SRC_URI_append = " file://test.scc"
+ SRC_URI_append = " file://test.cfg file://test.scc"


This is wrong. You should not have both on the SRC_URI

Bruce


  
  The leading space before the path is important as the
  path is appended to the existing path.



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

Re: [yocto] [layerindex-web] RFC: layer index docker fixes

[Konrad Scherer]

On 09/05/2018 08:04 AM, Paul Eggleton wrote:

On Thursday, 30 August 2018 11:44:10 AM NZST Paul Eggleton wrote:

On Wednesday, 29 August 2018 10:46:27 PM NZST Paul Eggleton wrote:

I know Konrad promised to update the docker-compose setup to be closer
to what we'd done recently with the docker setup, but I needed something
urgently and wanted to learn how to use docker-compose anyway, so I've
put this together:

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

Let me know what you think - it works well enough for me here, although the
setup commands are now a bit ugly on their own.


I realised this morning that "docker-compose run" can simplify a lot of the
docker run commands, so I've just converted most of the commands in
docker/README and pushed the branch again.


So, any comments?


Sorry for the delay. I just rebased our internal layerindex to the 
latest and made some updates to the Dockerfiles and other files.


https://github.com/WindRiver-OpenSourceLabs/layerindex-web/tree/rebase-20181002

Dockerfile:
- added the wheel package to avoid errors in pip package installation
- Used ADD --chown to add all the files with the correct permissions to 
avoid a second chown RUN step
- Used an entrypoint.sh script instead of CMD to handle things like db 
initialization, creating a superuser, overriding default configuration 
with environment variables and collecting static files. The same 
entrypoint is used to start either the celery-worker or gunicorn.


https://github.com/WindRiver-OpenSourceLabs/layerindex-web/blob/rebase-20181002/docker/entrypoint.sh

docker/docker-compose.yaml:
- separating the gunicorn and the celery-worker is a good idea
- the blacklabelops/nginx image generates the nginx config from env 
variables which makes development easier. Changing an env var in 
docker-compose.yaml is easier than rebuilding the image or bind-mounting 
in a new version.
- One thing I didn't put in passing in the DB username and password 
because I am using this as a test instance, not a production one. Should 
be a simple change.


I had problems setting up a reverse proxy for the layerindex-web app 
when using a subpath (ie. http:///li/). In urls.py, the leading 
slash on the last redirect works as a redirect to an absolute path and 
breaks the redirect when using a subpath . Fortunately the fix is simple 
and doesn't break usage without a subpath.


https://github.com/WindRiver-OpenSourceLabs/layerindex-web/commit/4586ff3f4fa477daa6e0bee6c6e9e0602105c8d2#diff-de6dd4b4c889fe0882cfd3f6df5aa451L29

Thanks!

--
Konrad Scherer, MTS, Linux Products Group, Wind River
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] changing kernel config in Morty build

[Greg Wilson-Lindberg]

I'm trying to change some kernel configuration flags in a raspberrypi3 Morty 
build and I get warnings that it isn't working.


Here is the build info and warnings:


Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "b2qt"
DISTRO_VERSION= "2.2.4"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
SDKMACHINE= "x86_64"
meta
meta-poky = "HEAD:df76669bdd70aa0d903c4211dde731221c7e756d"
meta-raspberrypi  = "HEAD:2a192261a914892019f4f428d7462bb3c585ebac"
meta-oe
meta-python
meta-networking
meta-initramfs
meta-multimedia   = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
meta-boot2qt
meta-raspberrypi-extras = ":"
meta-mingw= "HEAD:1c2e155111dce94423cc227ea69f7f50f316c78e"
meta-qt5  = "HEAD:49e9d9a73b5c6e3d6eab88dc0005305e85b1a62d"
meta-sakura   = ":"

Initialising tasks: 100% 
|#|
 Time: 0:00:00
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it into 
the kernel's final configuration:

-- CONFIG_SND_SOC_MAX9768 -
Config: CONFIG_SND_SOC_MAX9768
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg
Requested value:  CONFIG_SND_SOC_MAX9768=y
Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:

Dependency values are:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg
Requested value:  CONFIG_MAX1363=m
Actual value: # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
  I2C (value: "y")
Dependency values are:
  I2C [y]

-- CONFIG_CAN_EMS_USB -
Config: CONFIG_CAN_EMS_USB
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg
Requested value:  CONFIG_CAN_EMS_USB=m
Actual value: # CONFIG_CAN_EMS_USB is not set

Config 'CAN_EMS_USB' has the following conditionals:
  (none)
Dependency values are:


Here is my linux-raspberrypi_4.4.bbappend for the kernel:

# Scribe additions to Kernel configuration

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/files:"
FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URI += "file://Scribe.scc"
SRC_URI += "file://mcp251x.c.patch"



The Scribe.scc file:

# Scribe additions to kernel configuration
kconf hardware Scribe.cfg



And the Scribe.cfg file:

# Scribe additions to kernel configuration

# Enable MAX9768
#CONFIG_SOC_ALL_CODECS=m
#CONFIG_COMPILE_TEST=y
CONFIG_SND_SOC_MAX9768=y

# Enable MAX11606
#IIO=y
CONFIG_MAX1363=m

# Enable EMS CPC-USB
CONFIG_CAN_EMS_USB=m


Here is my directory tree:

Qt-5.9.6

 Yocto-mirror # Yocto 
build mirror
 Yocto-build-RPi3  # Yocto 
build root
build-raspberrypi   # build 
directory
sources # yocto 
sources
   meta-sakura   # our 
recipes
   recipes-kernel# 
directory for kernel changes
   linux   # 
directory that contains linux-raspberrypi_4.4.bbappend
  files # 
directory that contains .scc & .cfg files

As seen above none of the changes are accepted although there is nothing that 
blocks any of them.

Any help understanding this would be greatly appreciated.

Regards,

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

Re: [yocto] [layerindex-web][PATCH 000/242] Integrate and improve Recipe Reporting System (cover letter only)

[Anibal Limon]

Hi Paul,

Good to know that is integrated now.

Cheers,
Anibal

On Tue, 1 May 2018 at 15:09, Paul Eggleton 
wrote:

> Hi Alex,
>
> On Tuesday, 1 May 2018 9:58:03 PM NZST Alexander Kanavin wrote:
> > On 05/01/2018 05:23 AM, Paul Eggleton wrote:
> > > The Recipe Reporting System (RRS - live instance at
> > > http://recipes.yoctoproject.org) was originally developed as a fork of
> > > the layer index (live instance at http://layers.openembedded.org) -
> this
> > > set of changes rebases it on top of master and makes the functionality
> > > possible to activate for other layers. I've introduced the concept of a
> > > "Maintenance Plan" to tie together the recipe maintenance information
> > > for one or more layers and used it to replace all the parts that
> assumed
> > > Poky or OE-Core were the repositories/layers being tracked. I've also
> > > made it possible again for the application to gather data going back to
> > > 1.6 across the python 2/3 divide, and made various cleanups and
> > > optimisations in the code.
> >
> > Thanks! Is this already taken into use on the recipes.yoctoproject.org?
>
> No, what you see there is still the old version. I haven't discussed it
> yet
> with Michael but I would propose that once this gets merged and
> layers.openembedded.org is updated, then recipes.yoctoproject.org would
> simply
> become a redirect to the OE-Core maintenance plan on
> layers.openembedded.org.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
> --
> ___
> 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] [mono][msbuild][nuget] Building c# application for mono

[Driesen Jef (JDI)]

On 10/01/2018 04:50 PM, Alberto Spin wrote:
> I’m trying to build my c# application for mono with yocto, by using 
> nuget and msbuild.
> 
> I encountered several problems:
> 
> MsBuild:
> 
>   * During the build of msbuild the cibuild.sh script is invoked. This
> script uses the tool ‘curl‘ to download the msbuild.zip form
> Microsoft. This action failes with a certificate error because there
> are no certificates present. I fixed this issue with a bbappend
> script for msbuild which contains:
> 
> DEPENDS += "ca-certificates"

I submitted a similar patch last week:

https://lists.yoctoproject.org/pipermail/yocto/2018-September/042661.html

Note that adding the ca-certificates dependency wasn't enough for me. 
The curl recipe builds curl with:

--with-ca-bundle=${sysconfdir}/ssl/certs/ca-certificates.crt

For curl-native that expands to something like:

$HOME/yocto/build/tmp/work/x86_64-linux/curl-native/7.58.0-r0/recipe-sysroot-native/etc/ssl/certs/ca-certificates.crt

But if "rm_work" is enabled, this directory is gone by the time you're 
building msbuild, and it still fails. It should point to the msbuild 
native sysroot instead. I did that with the CURL_CA_BUNDLE env variable.

> Nuget:
> 
>   * When trying to restore the packages for my c# application, the
> execution of Nuget fails because it has no certificates.
>   * Apparently NuGet is using the mono certificate store, because it
> fails to detect the certificates present in:
>   /recipe-sysroot-native/etc/ssl/certs
>   * I also verified that the mono certificate store is empty by issuing
> the command: certmgr -list -c Trust
> 
> I tried to extend the recipe that builds my c# application with a 
> do_configure task, in which I’m trying to synchronize the mono 
> certificate store with the ca-certifates.crt.
> 
>      cert-sync ${sysconfdir}/ssl/certs/ca-certificates.crt
> 
> But the cert-sync tool somehow wants to use a path outside my build 
> environment /usr/share/.mono, which fails with an access denied error.
> 
> Can anybody help me to get past this problem?

I encountered the same problem. I did workaround it with the --user 
parameter:

cert-sync --user ${sysconfdir}/ssl/certs/ca-certificates.crt

As you can see from my commit message, it works, but it's not perfect:

"Install the CA certificates for mono

Mono uses its own CA certificate store. By default it is empty, which 
causes nuget to fail when trying do download packages over https.

This is a very ugly hack. Ideally the CA certificates should be packaged 
separately and installed system-wide. But unfortunately the cert-sync 
tool (or the other mono tools) use hardcoded directory paths and thus 
don't support cross environments. Even with the --user option, the 
certificates are installed on the host system, and not the yocto native 
sysroot. Not really great, but at least it works."

If you find a better solution, I'm interested to hear about that!

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

[yocto] ac_nonexistent.h error in do_configure

[Muhlenkamp, Lewis]

Hello,

I get a failure when trying to build the core-image-x11 image with the 
intel-corei7-64 MACHINE.  The error message that appears in the 
build/tmp-glibc/corei7-64-oe-linux/xf86-video-intel/2_2.99.917+gitAUTOINC+e4fe79cf0d-r0/build/config.log
 file is as follows:

=== Start excerpt ===
configure:4381: checking how to run the C preprocessor
configure:4451: result: x86_64-oe-linux-gcc -E 
--sysroot=/home/lmuhlenkamp/build-target02/tmp-glibc/work/corei7-64-oe-linux/xf86-video-intel/2_2.99.917+gitAUTOINC+e4fe79cf0d-r0/recipe-sysroot
  -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2
configure:4471: x86_64-oe-linux-gcc -E 
--sysroot=/home/lmuhlenkamp/build-target02/tmp-glibc/work/corei7-64-oe-linux/xf86-video-intel/2_2.99.917+gitAUTOINC+e4fe79cf0d-r0/recipe-sysroot
  -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2  conftest.c
configure:4471: $? = 0
configure:4485: x86_64-oe-linux-gcc -E 
--sysroot=/home/lmuhlenkamp/build-target02/tmp-glibc/work/corei7-64-oe-linux/xf86-video-intel/2_2.99.917+gitAUTOINC+e4fe79cf0d-r0/recipe-sysroot
  -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2  conftest.c
conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory
#include 
  ^~
compilation terminated.
configure:4485: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "xf86-video-intel"
| #define PACKAGE_TARNAME "xf86-video-intel"
| #define PACKAGE_VERSION "2.99.917"
| #define PACKAGE_STRING "xf86-video-intel 2.99.917"
| #define PACKAGE_BUGREPORT 
"https://bugs.freedesktop.org/enter_bug.cgi?product=xorg";
| #define PACKAGE_URL ""
| #define PACKAGE "xf86-video-intel"
| #define VERSION "2.99.917"
| /* end confdefs.h.  */
| #include 
=== End excerpt ===

I understand that ac_nonexistent.h is not supposed to exist, and that the 
autoconf stuff is supposed to handle this failure as a successful test if the 
gcc compiler handles things properly, but it does not look like the gcc 
compiler is handling things properly, and I do not know why.

What I am trying to do is to get an image using the minimal amount of meta 
layers as possible, and to not use poky.  I am still learning Yocto.  This is a 
step in my learning process, but I do not understand Yocto enough to determine 
how to proceed.

I did the following


  *   cd /home/lmuhlenkamp
  *   git clone git://git.yoctoproject.org/meta-intel
  *   git clone git://git.openembedded.org/meta-openembedded
  *   git clone git://git.openembedded.org/openembedded-core oe-core
  *   cd oe-core/
  *   git clone git://git.openembedded.org/bitbake
  *   . ./oe-init-build-env ~/build-target02

I made the following modifications to bblayers.conf:


  *   diff bblayers.conf .#bblayers.conf.orig
10,16d9
<   /home/lmuhlenkamp/meta-openembedded/meta-python \
<   /home/lmuhlenkamp/meta-openembedded/meta-gnome \
<   /home/lmuhlenkamp/meta-openembedded/meta-filesystems \
<   /home/lmuhlenkamp/meta-openembedded/meta-oe \
<   /home/lmuhlenkamp/meta-openembedded/meta-networking \
<   /home/lmuhlenkamp/meta-openembedded/meta-initramfs \
<   /home/lmuhlenkamp/meta-intel \

I made the following modifications to local.conf:


  *   diff local.conf .#local.conf.orig
28,31d27
< # From the meta-intel BSP layer
< #MACHINE ?= "intel-core2-32"
< MACHINE ?= "intel-corei7-64"
< #
46c42
< DL_DIR ?= "/downloads"
---
> #DL_DIR ?= "${TOPDIR}/downloads"
221,224d216
< PACKAGE_CLASSES = "package_rpm"
< VIRTUAL-RUNTIME_init_manager = "systemd"
< DISTRO_FEATURES_append = " systemd"
< DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"


As you may have guessed by some of the above changes, I eventually want to be 
able to use the meta-intel BSP with the meta-anaconda layer.  My end goal is to 
be able to create a bootable DVD that can be given to our field engineers to be 
able to do either fresh installs in the field, or upgrade existing hardware in 
the field.  I am familiar with Anaconda from doing a lot of work with Red Hat 
derived OSes.  So, seemed liked a good way to go.

I'm thinking I need to make some other change to local.conf to get the 
ac_nonexistent.h test "succeed".  I am not sure what that change is.

I've looked through a lot of online documentation.  I have done a lot of Google 
searches.  I have not found anything helpful.

Any help anyone can provide would be greatly appreciated, mainly on the 
ac_nonexistent.h error, but if anyone has any helpful pointers or such for 
combining meta-intel and meta-anaconda, I would really appreciate that too.

Thank you

Lewis Muhlenkamp

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