[yocto] [layerindex-web][PATCH 00/10] Bootstrap 3, update task enhancements, etc. (cover letter only)
A bit of a mixed bag: one bugfix, move to Bootstrap 3 for the frontend, some minor features and significant work on how update tasks for the other distro comparison functionality works. The following changes since commit 3aa6bf964d81a04b652499069f0454c546a5e296: import_layer.py: add -t option for layer_type (2018-09-20 15:53:07 +1200) are available in the Git repository at: git://git.yoctoproject.org/layerindex-web paule/fixes8 http://git.yoctoproject.org/cgit.cgi//log/?h=paule/fixes8 Paul Eggleton (10): import_otherdistro: fix update recording code Upgrade to Bootstrap 3 Add admin link to tools dropdown menu models: add a get_checkout_branch() function Show actual branch on layer detail Show update task output more smoothly Show progress when running comparison update tasks Properly show update task success/failure Allow stopping update task TODO: remove completed item README| 4 +- TODO | 1 - docker/settings.py| 4 +- layerindex/forms.py |35 +- layerindex/migrations/0025_update_retcode.py |20 + layerindex/models.py |16 +- layerindex/static/css/additional.css |59 +- .../static/css/bootstrap-responsive.css | 1109 -- .../static/css/bootstrap-responsive.min.css | 9 - layerindex/static/css/bootstrap-theme.css | 587 + layerindex/static/css/bootstrap-theme.css.map | 1 + layerindex/static/css/bootstrap-theme.min.css | 6 + .../static/css/bootstrap-theme.min.css.map| 1 + layerindex/static/css/bootstrap.css | 10591 layerindex/static/css/bootstrap.css.map | 1 + layerindex/static/css/bootstrap.min.css |13 +- layerindex/static/css/bootstrap.min.css.map | 1 + .../fonts/glyphicons-halflings-regular.eot| Bin 0 -> 20127 bytes .../fonts/glyphicons-halflings-regular.svg| 288 + .../fonts/glyphicons-halflings-regular.ttf| Bin 0 -> 45404 bytes .../fonts/glyphicons-halflings-regular.woff | Bin 0 -> 23424 bytes .../fonts/glyphicons-halflings-regular.woff2 | Bin 0 -> 18028 bytes .../static/img/glyphicons-halflings-white.png | Bin 8777 -> 0 bytes .../static/img/glyphicons-halflings.png | Bin 12799 -> 0 bytes layerindex/static/js/bootstrap.js | 3331 ++--- layerindex/static/js/bootstrap.min.js |11 +- layerindex/static/js/jquery-1.7.2.js | 9404 -- layerindex/static/js/jquery-3.3.1.js | 10364 +++ layerindex/tasks.py |23 +- layerindex/templatetags/extrafilters.py |21 +- layerindex/tools/import_otherdistro.py|14 +- layerindex/urls.py| 8 +- layerindex/utils.py | 117 +- layerindex/views.py |52 +- rrs/static/css/rrs-additional.css | 7 +- settings.py | 7 +- templates/base.html |48 +- templates/base_toplevel.html |12 +- templates/layerindex/about.html | 4 +- templates/layerindex/bulkchange.html |10 +- templates/layerindex/bulkchangeedit.html | 8 +- templates/layerindex/bulkchangereview.html| 8 +- templates/layerindex/bulkchangesearch.html|22 +- templates/layerindex/classes.html |19 +- templates/layerindex/classic_base.html| 4 +- templates/layerindex/classicrecipedetail.html | 4 +- templates/layerindex/classicrecipes.html | 166 +- templates/layerindex/classicstats.html| 2 +- .../layerindex/comparisonrecipebase.html |10 +- .../layerindex/comparisonrecipeselect.html|97 +- .../comparisonrecipeselectdetail.html |90 +- templates/layerindex/deleteconfirm.html | 4 +- templates/layerindex/detail.html | 122 +- templates/layerindex/distros.html |20 +- templates/layerindex/duplicates.html |92 +- templates/layerindex/editlayer.html |32 +- templates/layerindex/editlayernote.html | 4 +- templates/layerindex/layers.html |50 +- templates/layerindex/machines.html|20 +- templates/layerindex/profile.html | 8 +- templates/layerindex/recipedetail.html|30 +- templates/layerindex/recipes.html |25 +- templates/layerindex/reviewdetail.html|32 +- templates/layerindex/reviewlist.html | 6 +- templates/layerindex/stats.html | 2 +- templates/layerindex/task.html|94 +- templates/layerindex/updatedetail.html| 6 +- templates/layerindex/updatelist.html | 9 +-
[yocto] [meta-selinux] cannot apply misc_create_inode.c-label_rootfs.patch from e2fsprogs
I have an iMX6 board with meta-freescale. I'm using yocto sumo with meta-security and I want to try to add meta-selinux (without meta-virtualization) to do some experiments. However, while building I receive this error: ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc /home/ks89/git/poky/build/tmp/work/x86_64-linux/e2fsprogs-native/1.43.8-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output: Applying patch misc_create_inode.c-label_rootfs.patch patching file misc/create_inode.c Hunk #1 FAILED at 979. frHunk #2 FAILED at 987. 2 out of 2 hunks FAILED -- rejects in file misc/create_inode.c Patch misc_create_inode.c-label_rootfs.patch does not apply (enforce with -f) ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /home/ks89/git/poky/build/tmp/work/x86_64-linux/e2fsprogs-native/1.43.8-r0/temp/log.do_patch.62867 ERROR: Task (virtual:native:/home/ks89/git/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch) failed with exit code '1' Is it safe to remove misc_create_inode.c-label_rootfs.patch without issues? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Native yocto compile in docker container without cross compile
Yes, that's it. On Wed, 19 Sep 2018 at 21:07, Fabian Sturm wrote: > > Hmm I guess I was way overthinking this. The idea seems to just create > a secong image definition like this it seems: > > > core-image-minimal-dev.bb: > > require core-image-minimal.bb > > DESCRIPTION = "A small image just capable of allowing a device to > boot and \ > is suitable for development work." > > IMAGE_FEATURES += "dev-pkgs tools-sdk" > IMAGE_INSTALL += "cmake" > > dev-pkg: selects e.g. all header files for the image packages > tools-sdk: install the toolchain packages into the image > IMAGE_INSTALL += "cmake": here I define any other development tool that > I need in my image > > I this correct? At least it seems the created image contains everything > I need! > > Kind regards, > Fabian > > > Am Mittwoch, den 19.09.2018, 18:21 +0100 schrieb Burton, Ross: > > If you're targeting just x86 then you can build an image with the > > tools-sdk IMAGE_FEATURE defined, and use something like systemd- > > nspawn > > (insert your preferred container system) to get a shell in it. > > > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Native yocto compile in docker container without cross compile
Hmm I guess I was way overthinking this. The idea seems to just create a secong image definition like this it seems: core-image-minimal-dev.bb: require core-image-minimal.bb DESCRIPTION = "A small image just capable of allowing a device to boot and \ is suitable for development work." IMAGE_FEATURES += "dev-pkgs tools-sdk" IMAGE_INSTALL += "cmake" dev-pkg: selects e.g. all header files for the image packages tools-sdk: install the toolchain packages into the image IMAGE_INSTALL += "cmake": here I define any other development tool that I need in my image I this correct? At least it seems the created image contains everything I need! Kind regards, Fabian Am Mittwoch, den 19.09.2018, 18:21 +0100 schrieb Burton, Ross: > If you're targeting just x86 then you can build an image with the > tools-sdk IMAGE_FEATURE defined, and use something like systemd- > nspawn > (insert your preferred container system) to get a shell in it. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Native yocto compile in docker container without cross compile
If you're targeting just x86 then you can build an image with the tools-sdk IMAGE_FEATURE defined, and use something like systemd-nspawn (insert your preferred container system) to get a shell in it. Ross On Wed, 19 Sep 2018 at 18:14, Fabian Sturm wrote: > > Hi, > > no this is not what I am searching for. What I want is gcc cmake and > other tools to be installed inside of the Yocto image, so that I can > compile natively in Yocto without having to hack build scripts to work > with a cross compiler. > But of course I don'T want to deliver gcc and others with the image on > a device. One solution would be to build a separate image that contains > the tools. But my hope is to use the original image and just add those > tools later on. > > Any ideas how to set something like this up best? > > Kind regrads, > Fabian > > Am Mittwoch, den 19.09.2018, 10:07 +0200 schrieb Alexander Kanavin: > > I think what you are looking for is a Yocto generated SDK for your > > image? > > > > bitbake -c populate_sdk > > > > 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] Native yocto compile in docker container without cross compile
Hi, no this is not what I am searching for. What I want is gcc cmake and other tools to be installed inside of the Yocto image, so that I can compile natively in Yocto without having to hack build scripts to work with a cross compiler. But of course I don'T want to deliver gcc and others with the image on a device. One solution would be to build a separate image that contains the tools. But my hope is to use the original image and just add those tools later on. Any ideas how to set something like this up best? Kind regrads, Fabian Am Mittwoch, den 19.09.2018, 10:07 +0200 schrieb Alexander Kanavin: > I think what you are looking for is a Yocto generated SDK for your > image? > > bitbake -c populate_sdk > > Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
Dell - Internal Use - Confidential > On Wed, 19 Sep 2018 12:33:37 +0100 > "Burton, Ross" wrote: > > > On Tue, 18 Sep 2018 at 22:21, Seebs wrote: > > > > Are the databases supposed to be shareable between different build > > > > machines? IIRC, the answer is no. Could you store the native inode > > > > type as a sqlite BLOB? Not necessarily a good idea Just an > > > > idea. > > > > > > I think coercing the values into range is probably safer. It should > > > be trivial enough... > > > > That is an excellent catch and I'm hopeful that this explains the > > failures in glibc-locales too that I still see occasionally. > > > > Is anyone actually writing a patch? > > I can try to get a proposed patch out sometime soon, I don't have an > easy way to check it. > > -s You can send the patch to me, it is easy to reproduce here. I think the "coercing" of the values is a good path, when the inodes are high, they are usually all high, except for the rare case where inode values are just on either side of the Signed limit. That happened one time and was the final proof of why this was happening. A little more background, we have two build environments, the developer workstations and the automated build cluster. The developers never saw this, because they are stand-alone boxes with typical 4 TB hardrives, max inode counts around a couple million. Our automated build system is a bunch of virtual machines which are setup and torn down with each build. What we noticed though is each newly created builder gets a new inode starting value, which is an increment from previous ones. This is why completely restarting the build cluster 'fixed' the issue for a while, it reset the inode numbering. So each builder gets assigned a non-overlapping new block of inodes, e.g. 1 - 1M, 1M+1 - 2M, 2M+1 - 3M, etc. Eventually this climbs up into the range above 1.5B and the problems begin. The build managers are investigating if there is a way in the cluster config to limit the inode upper limit and force the numbers to wrap around sooner. One thing I am curious about, is that Pseudo 1.6.x never gave us this problem, was the reference inside the database different? Or maybe it's just a case of never hitting the issue. Thanks, Jack Fewx jack.f...@dell.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
On Wed, 19 Sep 2018 12:33:37 +0100 "Burton, Ross" wrote: > On Tue, 18 Sep 2018 at 22:21, Seebs wrote: > > > Are the databases supposed to be shareable between different build > > > machines? IIRC, the answer is no. Could you store the native inode > > > type as a sqlite BLOB? Not necessarily a good idea Just an > > > idea. > > > > I think coercing the values into range is probably safer. It should > > be trivial enough... > > That is an excellent catch and I'm hopeful that this explains the > failures in glibc-locales too that I still see occasionally. > > Is anyone actually writing a patch? I can try to get a proposed patch out sometime soon, I don't have an easy way to check it. -s -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding nInvaders game package recipe
Please remember to reply to the list.
On Wed, 19 Sep 2018 at 13:08, Mohamed Youseif
wrote:
> Thanks, Ross for replying, I had changed the recipe and tried to get the
> source code of ninvaders package from SourceForge with .tar extension,
> so the new recipe created was different than the old one that inherits
> Autotools and it modifies the do_compile routine to run "oe_runmake" and this
> passes the compilation but the do_install is empty, so when I build new image
> after adding this package to the image using
> IMAGE_INSTALL_append = " ninvaders " in conf/local.conf file and boot the
> image on my machine i do not find the package in the new
> image, so what I should add in the do_install routine?.
Well your makefile doesn't have an install target, so you'll need to
manually copy the files from ${S} to ${D}${bindir}.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
On Tue, 18 Sep 2018 at 22:21, Seebs wrote: > > Are the databases supposed to be shareable between different build > > machines? IIRC, the answer is no. Could you store the native inode > > type as a sqlite BLOB? Not necessarily a good idea Just an idea. > > I think coercing the values into range is probably safer. It should be > trivial enough... That is an excellent catch and I'm hopeful that this explains the failures in glibc-locales too that I still see occasionally. Is anyone actually writing a patch? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding nInvaders game package recipe
The problem is most likely that you're not using automake but the generated recipe (would have been useful to include that) is using the autotools class, which assumes correct use of both autoconf and automake. Specifically, your hand-written Makefile doesn't handle out-of-tree builds. Change the inherit from autotools to autotools-brokensep, and I expect that will fix the build. Ross On Wed, 19 Sep 2018 at 12:08, Mohamed Youseif wrote: > > Hi, I want to add the invaders game package to my image that I had built > before and tested, so I used the command "recipetool create -V 1.0 > https://github.com/TheZ3ro/ninvaders.git; to make my custom recipe, then I > had to append this package to my image by appending the package name to > IMAGE_INSTALL variable (like this IMAGE_INSTALL_append = "ninvaders", but > before I build the new image I tried to test my recipes' task to be done > correctly by running this command > "bitbake -b ninvaders_git.bb" but there is an error while executing the > do_compile task and it prints out that: > > ERROR: ninvaders-1.0+gitAUTOINC+c6ab4117ba-r0 do_compile: oe_runmake failed > ERROR: ninvaders-1.0+gitAUTOINC+c6ab4117ba-r0 do_compile: Function failed: > do_compile (log file is located at > /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813) > ERROR: Logfile of failure stored in: > /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813 > Log data follows: > | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', > 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] > | DEBUG: Executing shell function do_compile > | NOTE: make -j 4 > | make: *** No rule to make target 'globals.o', needed by 'nInvaders'. Stop. > | ERROR: oe_runmake failed > | WARNING: exit code 1 from a shell command. > | ERROR: Function failed: do_compile (log file is located at > /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813) > ERROR: Task > (/home/yusuf/rpi/meta-rpi/recipes-misc/nInvaders/ninvaders_git.bb:do_compile) > failed with exit code '1' > NOTE: Tasks Summary: Attempted 8 tasks of which 0 didn't need to be rerun and > 1 failed. > > Summary: 1 task failed: > /home/yusuf/rpi/meta-rpi/recipes-misc/nInvaders/ninvaders_git.bb:do_compile > Summary: There was 1 WARNING message shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > so should i modify the do_compile task? > Thanks, > Yusuf > -- > ___ > 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] Adding nInvaders game package recipe
Hi, I want to add the invaders game package to my image that I had built before and tested, so I used the command "recipetool create -V 1.0 https://github.com/TheZ3ro/ninvaders.git; to make my custom recipe, then I had to append this package to my image by appending the package name to IMAGE_INSTALL variable (like this IMAGE_INSTALL_append = "ninvaders", but before I build the new image I tried to test my recipes' task to be done correctly by running this command "bitbake -b ninvaders_git.bb" but there is an error while executing the do_compile task and it prints out that: ERROR: ninvaders-1.0+gitAUTOINC+c6ab4117ba-r0 do_compile: oe_runmake failed ERROR: ninvaders-1.0+gitAUTOINC+c6ab4117ba-r0 do_compile: Function failed: do_compile (log file is located at /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813) ERROR: Logfile of failure stored in: /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813 Log data follows: | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] | DEBUG: Executing shell function do_compile | NOTE: make -j 4 | make: *** No rule to make target 'globals.o', needed by 'nInvaders'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /home/yusuf/rpi/build/tmp_sumo_RPI/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ninvaders/1.0+gitAUTOINC+c6ab4117ba-r0/temp/log.do_compile.25813) ERROR: Task (/home/yusuf/rpi/meta-rpi/recipes-misc/nInvaders/ninvaders_git.bb:do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 8 tasks of which 0 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/yusuf/rpi/meta-rpi/recipes-misc/nInvaders/ninvaders_git.bb:do_compile Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. so should i modify the do_compile task? Thanks, Yusuf -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Native yocto compile in docker container without cross compile
I think what you are looking for is a Yocto generated SDK for your image? bitbake -c populate_sdk Alex 2018-09-18 23:00 GMT+02:00 Fabian Sturm : > Hi, > > I am wondering, there does not seem to be any information about native > compile of projects in a Yocto docker container. It seems that most of > the people use cross compile even though that imho is not necessary if > your target is x86 too. So here is what I want to do: > > - Create a docker container with Yocto Linux, possibly same as the > target image > - Install gcc, cmake, autotools etc. in the docker container > - Run the docker container on a vanilla Ubuntu Linux > - Run build jobs in this docker container directly > > Rational. I have several projects with fully functioning build systems, > e.g. make, cmake or autotools which I need to compile for different > platforms, e.g. Windows, Ubuntu Linux and Yocto Linux. I now don't want > to write recipes just for the Yocto cross compile which I need to > additionally maintain and I also don't want to make the original build > systems cross compile aware. This can soon get really hard if the build > system generates intermediate binaries that are called in the build > itself and if it is not prepared for this. > Since my target and host platform are both x86 I do not see the need > for a cross compile anyways. Usually it is necessary since the target > platform might be a very slow ARM system that can't handle all the > builds itself. But I do not have this limitation. > > With such a solution my original build systems should still be able to > run unmodified. Within the docker container the environment would be > almost the same as in an Ubuntu Linux. The compiler can be accessed > without any cross compile settings and any intermediate binaries can > also be directly executed etc. > > If there are some fundamental reasons why this is a bad idea, I would > like to know. I also would appreciate any tips on how to create such a > docker image. Usually my Yocto image for the target would not contain a > compiler or make tool. So I need a way to add those after the fact. > > > Thanks a lot! > Fabian > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
