Re: [yocto] Trying to set up a debian package repository for yocto.
Peter, Thanks for sharing, this is something I may also encounter. M. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a newer alternative to tcpflow?
Robert, You should try to create a recipe by yourself, using devtool. I used it for the 1st time some weeks ago, and was positively surprised by how easy it is to create a new recipe! I spent more time learning devtool (but I'm of the kind that likes to read the whole doc before attempting something) than producing the recipes. devtool is very clever at understanding the source and since tcpflow is autoconfigure-based I bet this should be easy. Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk_ext: Huge(?) differences between RPM & DEB
Ross, > From: "Ross Burton" > Sent: Friday, 25 November, 2016 6:34:01 PM > I fixed this in oe-core master a few weeks ago. oe-core > a0aa5bb709547ce0b65a4563e4217c3c3d9f. Thank you for your answer. I applied your commit. And after struggling a little with some side-effects that led to erasing my build/tmp, everything is now fine, both with rpm & deb. Well… When I say "fine", I mean no errors during the baking. But the results are a bit different: RPM-based Installer is 1.7 GiB. SDK is 10.3 GiB, 168361 files & 35049 folders. Debian-based: Installer is 1.3GiB. 8.9GiB, 172366 files & 34795 folders. What is the same in both runs is the emptiness of the manifest files! Both target.manifests are empty. And the host manifests only have a single line (meta-environment-extsdk) Does that make sense? Thanks Michel-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] When shall one erase tmp and sstate-cache?
Hi, I "frequently" have the same problem as Gary: > From: "Gary Thomas" > To: yocto@yoctoproject.org > Sent: Tuesday, 29 November, 2016 9:32:39 AM > Subject: [yocto] New error > > I recently updated my Poky/Yocto repo to > 12a0ee049e453b6d0d2ce2f3fa981d1b6e02bd78 and now I'm seeing > messages like this: >ERROR: When reparsing > > /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, >the >basehash value changed from 3c2401cc61fce5eb899de19dbf78862f to >558516a74162944aff656a7d01321b12. The metadata is >not deterministic and this needs to be fixed. I then erase the build/tmp and (maybe) the sstate-cache folders... and most of the time, the errors disappear. However if erasing tmp is not such a big deal to re-bake everything, it is much longer when the sstate cache is removed! So my question is: when shall I erase those folders? My understanding is that bitbake is very good at detecting changes in recipes. But on the other hand, it doesn't check for changes in python libs. So every time one upgrades a layer (through git), it is advised to erase build/tmp. But when is it also better to erase sstate-cache? Thanks for your insightful explanations. Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New error
Hi, > I recently updated my Poky/Yocto repo to > 12a0ee049e453b6d0d2ce2f3fa981d1b6e02bd78 and now I'm seeing messages Did you try to erase your build/tmp folder? Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to use pdb together with pyshell?
Hi, I want to do a step by step debug of the populate_sdk_ext task, and unfortunately I'm not fluent in python. I tried to put a pdb.set_trace() call at the beginning of the do_populate_sdk_ext function and then call: bb.build.exec_func('do_populate_sdk_ext', d) But this didn't work... And I also noticed that the log of the task, with & without pyshell, is quite different. Is there something I should do before? Thanks for your help (to improve the debian PM side of the world). Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to add user with nologin shell
> Still same error even if I used -U option. > > I tried even groupadd but still I get below error. Can you try this: EXTRA_USERS_PARAMS = "useradd -r -s /sbin/nologin user1;" According to my man page: By default, a group will also be created for the new user must be last -r also implies -M Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to add user with nologin shell
Hi, > From: "Abhinav Bipnesh (Abhinav)" > Sent: Thursday, 24 November, 2016 11:05:59 AM > I am trying to add an user to image with /sbin/nologin but it fails > with below error > ERROR: Function failed: set_user_group (log file is located at > /home/abhinav/bitbake/…/test-image/1.0-r0/temp/log.do_rootfs.54725) The problem seems to be with the group. According to my man page, the group must already exist. > I am using below section in my recipe to achieve it > EXTRA_USERS_PARAMS = “useradd -M -g user1 user1 -r -s /sbin/nologin;” Why don't you use the -U flag? Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy
Hi Paul, I'm still investigating the whole thing because nothing works so far! The SDK I managed to produce didn't install, and now I can't even produce an SDK anymore :'-( I chose Debian PM because this is what I already know and thought it would be easier than to learn about the RPM world. Not sure it was my best move ;-) During the install, the error was: ERROR: e2fsprogs-native-1.43-r1 do_populate_sysroot_setscene: Error executing a python function in exec_python_func() autogenerated: [...] File: '/mnt/Yocto/sdk/greenfeed/layers/poky/meta/lib/oe/qa.py', lineno: 102, function: getWord 0101:def getWord(self, offset): *** 0102:return struct.unpack_from(self.sex+"i", self.data, offset)[0] Exception: struct.error: unpack_from requires a buffer of at least 4 bytes And now, the build fails with: Exception: FileNotFoundError: [Errno 2] No such file or directory: '/mnt/Yocto/build/tmp/sysroots/vtc7110/locked-sigs/locked-sigs-extsdk-toolchain.inc' ERROR: image-greenfeed-0.1-r0 do_populate_sdk_ext: Function failed: copy_buildsystem This is just FYI, I'm still working on it... I'll try the devpyshell for the 1st time! > OK, so it may only be working by chance then - if you did have the > nativesdk-perl package built then I suspect you'd find it would get installed. > I'm puzzled as to why it hasn't been built though, since it is a > dependency of > some of the other items we do include in buildtools (notably git) and > does get built when you use rpm as the backend, last I checked anyway. Well, a lot of nativesdk-perl packages exist, but I didn't see them in the manifest. Be back soon Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy
> From: "Paul Eggleton" > Sent: Monday, 21 November, 2016 10:15:16 PM > I suspect it has to do with the arch mapping that goes on in > meta/classes/package_deb.bbclass; it probably doesn't understand the > dummy > architecture we're giving it. The thing is even if it were to be > "corrected" > to fall back to "all" instead of "allarch" that probably still > wouldn't work > properly because the architecture of the perl packages would be a > higher > priority than "all" and thus the dummy package wouldn't take > precedence. It seems to be OK. The only other package with 'perl' in its name is 'nativesdk-git-perltools'. But I have (another) problem with the manifest files: - all "target" manifest files are empty - the 'poky-systemd-blah-blah-toolchain-ext-2.2.host.manifest' has a single entry: meta-environment-extsdk-vtc7200 So maybe I don't see everything... > In any case feel free to file a bug under "OE-Core -> Core" in > bugzilla, that > would be a reasonable category for this issue. Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10700 Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy
> From: "Paul Eggleton" > Sent: Friday, 18 November, 2016 2:46:07 AM > I think the issue is this hasn't really been tested with deb > packaging. You > have hit a genuine bug though - would you mind filing a bug at > http://bugzilla.yoctoproject.org? I still don't fully understand the problem, so I don't know where to file the bug! But I think apt-native and buildtools-tarball are OK. Right now I believe this is related to the ARCH value of the dummy debian packages. It is "allarch" (in the filename and the Packages corresponding summary file) whereas similar packages have the "all" arch. I'm trying to understand why there is such a difference... If someone has some knowledge on the subject to help me, it'd be great :-) Cheers Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy
Paul, > From: "Paul Eggleton" > Sent: Friday, 18 November, 2016 2:46:07 AM > I think the issue is this hasn't really been tested with deb > packaging. You > have hit a genuine bug though - would you mind filing a bug at > http://bugzilla.yoctoproject.org? Thanks for your help. I'll file a bug report as soon as I better understand the whole problem :-D Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] devshell, KDE konsole & python3 TypeError
Hi, I'm on Morty and I hit the following bugs when trying to launch a devshell… I did a quick search and don't think they are solved. In poky/meta/lib/oe/terminal.py, the option "--nofork" doesn't exist in my konsole v16.08. I replaced it by option "--new-tab", which solved the problem. And with my python 3.5.2, the oe.terminal.ExecutionError triggers another exception when printing the output: File: '/mnt/Yocto/sources/poky/bitbake/lib/bb/process.py', lineno: 46, function: __str__ 0042:message = "" 0043:if self.stderr: 0044:message += self.stderr 0045:if self.stdout: *** 0046:message += self.stdout 0047:if message: 0048:message = ":\n" + message 0049:return (CmdError.__str__(self) + 0050:" with exit code %s" % self.exitcode + message) Exception: TypeError: Can't convert 'bytes' object to str implicitly If this can help others… Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy
Hi, I try to produce an extensible SDK for core-image-sato with the following configuration: BB_VERSION = "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "vtc7200" DISTRO = "poky-systemd" DISTRO_VERSION = "2.2" TUNE_FEATURES = "m64 corei7" The machine is based on an intel-corei7, with some features removed. And the distro is poky-based, with only systemd (as detailed in the ref manual). And I get the following error: ERROR : buildtools-tarball-1.0-r0 do_populate_sdk: Unable to install packages. Command '/mnt/Yocto/vedecom-x86/build/tmp/sysroots/x86_ 64-linux/usr/bin/apt-get install --force-yes --allow-unauthenticated nativesdk-locale-base-en-us nativesdk-git nativesdk-make native sdk-ca-certificates nativesdk-tar nativesdk-python3-modules nativesdk-texinfo nativesdk-python3-git nativesdk-ncurses-terminfo-base n ativesdk-chrpath nativesdk-python3-misc nativesdk-git-perltools nativesdk-buildtools-perl-dummy nativesdk-pigz nativesdk-wget natives dk-python3-core' returned 100: Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package nativesdk-buildtools-perl-dummy The package exists and is in: tmp/deploy/deb/buildtools-dummy-nativesdk/nativesdk-buildtools-perl-dummy_1.0-r2_allarch.deb while the other listed packages are in tmp/deploy/deb/x86_64-nativesdk. It seems this package is empty, so maybe I should simply remove it from poky/meta/recipes-core/meta/buildtools-tarball.bb. Thanks for your help Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using debian packages management
Thanks Jussi, it solved my issue (more explanation below). > From: "Jussi Kukkonen" > I suspect this is related to meta-oe taking over some X > initialization when you add it to bblayers -- this maybe exposes a > bug in the deb packaging implementation. In any case I can say that > a deb-based core-image-sato builds fine without meta-oe. You were right... With the bitbake-layers utility, I checked the "appends" but not the "overlayed" (BTW, -overlaid- would be better!?). And meta-oe provides a version 2.0 of xserver-nodm-init, which triggers some problems with debian. > Note that you may have to wipe TMPDIR after bblayers changes if > you're testing this. I didn't have to. I simply set PREFERRED_VERSION_xserver-nodm-init to "1.0" and I got my image! But this raises another comment: I added the whole meta-oe layer for a single recipe (ttf-dejavu). And I inherited unwanted side effects. So what is the best practice? - to copy/paste the recipe into a dedicated layer? - to modify the conf/layer.conf of meta-oe to include a single folder? > I have a bug on improving the X initialization mess in oe-core vs > meta-oe ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546 ) > but please file one on the debian packaging issue if it does not > exist yet. I just read your bug report… and this problem is quite old. Before it gets corrected in 2.3, it could be helpful to put a note in the different Yocto manuals, to draw attention of newcomers to this rather frequent problem. @Khem Raj: I realized my answer was maybe a bit harsh and I want to apologize. This was just an amused comment that every time I try something described in the manuals, this fails miserably. And every time, I have the feeling that my config is close to the default one. But the goal of Yocto is highly ambitious and it implies knowledge in many Linux fields! Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using debian packages management
> > So my question is: > > Is using debian packages management definitely broken in Yocto? Or > > has someone managed to use it with some tweaking? > > dpkg is a supported platform in OE/Yocto Yes, according to the manuals, it is supported... But my config wasn't fancy at all and I was unable to produce core-image-sato. To be sure, I'll try again with the plain config described in the quick start. And I'll give you an update :-D Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using debian packages management
Hi, >From time to time I try to use the debian packages management instead of RPM >because I feel more "at home"... And every time, there is a problem -- but >this time, I felt like I'll try to understand and solve it! I tried first with core-image-minimal, and it worked. But then I switched to core-image-sato and had the following error: ERROR : core-image-sato-1.0-r0 do_rootfs: Unable to install packages. Command '/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/apt-get install --force-yes --allow-unauthenticated apt packagegroup-base-extended packagegroup-core-ssh-dropbear dpkg packagegroup-core-x11-base packagegroup-core-boot packagegroup-core-x11-sato-games psplash packagegroup-core-x11-sato' returned 100: Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is not going to be installed E: Unable to correct problems, you have held broken packages. I checked: The package exists in /tmp/deploy/deb/all/packagegroup-core-x11-utils_1.0-r40_all.deb, but it is *empty*. It looks as if it is just there to create some RDEPENDS in the recipe. So... I played the game to explicitly add packages one by one to the image: IMAGE_INSTALL_append_pn-core-image-sato = " packagegroup-core-x11-utils xserver-nodm-init x11-common xserver-common" But now I have the following error: The following packages have unmet dependencies: xserver-common : Conflicts: x11-common but 0.1-r47 is to be installed So my question is: Is using debian packages management definitely broken in Yocto? Or has someone managed to use it with some tweaking? Many thanks for your feedbacks Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Merging a custom SDK with meta-toolchain-qt5
Hi Karim, I understand your problem but unfortunately I still have a limited understanding of the intrication of the whole metadata system… The good news is that the meta-toolchain-qt5 recipe is quite empty. So I think your best option is to patch the populate_sdk task to include what is added by the qt5 layer. Once you have something working, you can then think on how to make it more permanent. grep & find will be your best friends --- at least, they are for me ;-) M. - Mail original - > De: "Karim ATIKI" > À: "Michel D'HOOGE" > Envoyé: Jeudi 13 Octobre 2016 17:46:59 > Objet: RE: [yocto] Merging a custom SDK with meta-toolchain-qt5 > Hi Michel, > Indeed, with my first image, I've generated the sdk as follow: > $ bitbake -c populate_sdk my-image-name > In the "my-image-name.bb" I've added features : > IMAGE_INSTALL_append = " foo gtk+3 libstdc++ " > SDKIMAGE_FEATURES_append = " libstdc++-dev " > So the resulting sdk contained all the necessary headers I needed, > including libgtk+.so and its respective header files. > I've created a new image, my-qtimage.bb" based on "my-image-name.bb". > I've included all Qt5 stuff with IMAGE_INSTALL_append = " qtbase qt3d > ... " > The image is generated fine. Good. > Then, to generate the SDK instead of doing that: > $ bitbake -c populate_sdk my-qtimage > I've prefered using the dedicated recipe of meta-qt5: > $ bitbake meta-toolchainqt5 > But of course it did not include my features above. > I just wonder what would be the best solution to achieve it correctly > ? > Writing a meta-toolchainqt5.bbapend ? > Karim > De : Michel D'HOOGE > Envoyé : jeudi 13 octobre 2016 17:11 > À : yocto > Cc : Karim ATIKI > Objet : Re: [yocto] Merging a custom SDK with meta-toolchain-qt5 > Hi, > > Is there a way to customize the meta-toolchain-qt5 so that it > > installs the features declared in the SDKIMAGE_FEATURES above ? > How did you generate the Qt5 toolchain? Because according to the > reference manual: > The SDKIMAGE_FEATURES is e quivalent to IMAGE_FEATURES. However, this > variable applies to the SDK generated from an image using the > following command: > $ bitbake -c populate_sdk imagename > There is a populate_sdk_qt5 class in meta-qt5. But I don't know how > to merge this with the previous command :-/ > Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
After solving all the QA issues, this bbappend creates RPM packages with fonts in the expected folder. I didn't try to generate an image but I'm quite confident about the result. Michel do_install() { install -d ${D}${libdir}/fonts/ find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${libdir}/fonts/ \; install -d ${D}${sysconfdir}/fonts/conf.d/ install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf ${D}${sysconfdir}/fonts/conf.d/ } FILES_${PN}-sans= "${libdir}/fonts/DejaVuSans.ttf ${libdir}/fonts/DejaVuSans-*.ttf" FILES_${PN}-sans-mono = "${libdir}/fonts/DejaVuSansMono*.ttf" FILES_${PN}-sans-condensed = "${libdir}/fonts/DejaVuSansCondensed*.ttf" FILES_${PN}-serif = "${libdir}/fonts/DejaVuSerif.ttf ${libdir}/fonts/DejaVuSerif-*.ttf" FILES_${PN}-serif-condensed = "${libdir}/fonts/DejaVuSerifCondensed*.ttf" FILES_${PN}-mathtexgyre = "${libdir}/fonts/DejaVuMathTeXGyre.ttf" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Merging a custom SDK with meta-toolchain-qt5
Hi, > Is there a way to customize the meta-toolchain-qt5 so that it > installs the features declared in the SDKIMAGE_FEATURES above ? How did you generate the Qt5 toolchain? Because according to the reference manual: The SDKIMAGE_FEATURES is e quivalent to IMAGE_FEATURES. However, this variable applies to the SDK generated from an image using the following command: $ bitbake -c populate_sdk imagename There is a populate_sdk_qt5 class in meta-qt5. But I don't know how to merge this with the previous command :-/ Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Hello, thanks a lot the build work now ! I'm very proud: this is the 1st time I can help someone on Yocto! This means a lot to me ;-) But i have another issue, i would like to install the font in /usr/lib/fonts, this is not the case for the moment (it 's for Qt5.7 use). How i can said to yocto to install font (.ttf) on this folder please ? I also need to use Qt5.7, but since I'm currently on other tasks, you discover the troubles a couple of hours before me. So let's try to debug this together… 1/ File ttf-dejavu_2.37.bb includes (requires) `ttf.inc` that is in the same folder. 2/ File ttf.inc has the following method: do_install() { install -d ${D}${datadir}/fonts/truetype/ find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${datadir}/fonts/truetype/ \; } which is in turn appended by dejavu with: do_install_append () { install -d ${D}${sysconfdir}/fonts/conf.d/ install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf ${D}${sysconfdir}/fonts/conf.d/ } 3/ The log of the install task of the recipe is /tmp/work/all-poky-linux/ttf-dejavu/2.37-r7/temp/run.do_install We have: export datadir="/usr/share" export sysconfdir="/etc" I compared to my Debian system: the files are stored in the same folders. So it seems this is qt that doesn't search in the "correct" place. 4/ After some grepping in meta-qt5, I have: classes/qmake5_paths.bbclass OE_QMAKE_PATH_LIBS = "${libdir}" classes/qmake5_paths.bbclass OE_QMAKE_PATH_QT_FONTS = "${OE_QMAKE_PATH_LIBS}/fonts" 5/ But I don't know what is the best solution now. We could change the OE_QMAKE_PATH_QT_FONTS variable. But this implies to recompile many pieces, I believe. So I opt for changing the do_install function. The quick & dirty solution is to create a ttf-dejavu_2.37.bbappend file that totally redefine the do_install method. do_install() { install -d ${D}${datadir}/fonts/truetype/ find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${ libdir }/fonts/truetype/ \; install -d ${D}${sysconfdir}/fonts/conf.d/ install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf ${D}${sysconfdir}/fonts/conf.d/ } I can't test it right now, but I hope this helps you. Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Hello, In fact, the ttf-dejavu recipe doesn't provide a package with the same name. If you look at the PACKAGES variable, you'll find that it provides ${PN}-sans, ${PN}-sans-mono, ${PN}-sans-condensed, ${PN}-serif , ${PN}-serif-condensed & ${PN}-mathtexgyre. So you have to explicitly choose the packages you want. Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [x32 ABI] Bit size mismatch in grub-efi
Hi, I'd like to give the x32 ABI a try, so I followed the steps in section 4.4 of the reference manual. First, I tried the core-image-sato recipe, and then switched to core-image-minimal because it is faster to recompile from scratch… However I assume both should work since Sato is explicitly referred to in the manual, and minimal should always work! And for completeness, I am on the master branch of poky. So, this doesn't work and I get many lines like the following ones from grub-efi: ERROR: grub-efi-2.00-r3 do_package_qa: QA Issue: Bit size did not match (32 to 64) grub-efi on /work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/kernel.img Bit size did not match (32 to 64) grub-efi on /work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/trig.mod Bit size did not match (32 to 64) grub-efi on /work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/cs5536.mod Bit size did not match (32 to 64) grub-efi on /work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/usb.mod Bit size did not match (32 to 64) grub-efi on /work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/usbserial_common.mod And then, it fails: ERROR: grub-efi-2.00-r3 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: grub-efi-2.00-r3 do_package_qa: Function failed: do_package_qa ERROR: Logfile of failure stored in: /mnt/Yocto/Fabric-x32/build/tmp/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/temp/log.do_package_qa.11229 ERROR: Task (/mnt/Yocto/Fabric-x32/sources/poky/meta/recipes-bsp/grub/grub-efi_2.00.bb:do_package_qa) failed with exit code '1' AFAIK, the image won't use EFI. And I guess this package is only required by the native part "by default". What is the proper solution to bypass these errors? Thanks Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [pseudo-native] No real function for mknod -- SOLVED
Thank you Jussi, > > No real function for mknod: > > /mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: > > undefined symbol: mknod > > No real function for mknodat: > > /mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: > > undefined symbol: mknodat > I believe this issue was fixed with a patch in poky master with > commit e090775f7e in May (and later in an upstream pseudo release). > Are you sure you are seeing this with poky master? I did so many tests that I mixed all the problems and errors I met… With the master branch, the problem was with the sanity check about the locale. I re-enabled en_US.utf8 on my console and the image creation succeeded! So I guess the problem appeared after an upgrade of my debian unstable system. But I was lost and getting crazy. So thanks again :-) M. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [pseudo-native] No real function for mknod
Dear all, Since the end of last week, I try to produce any kind of images, with no success :-( Note that even though I'm not a seasoned Yocto user, in more than a year I managed many times to produce images & SDKs. And this time, I tried several configs, erased everything and restarted from scratch, etc., but with always the same problem. I have the following logs (in grey, so I guess not a warning nor an error) when running bitbake: No real function for mknod: /mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod No real function for mknodat: /mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknodat And at the end, this crashes with: ERROR: core-image-minimal-initramfs-1.0-r0 do_rootfs: Unable to install packages. Command '/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/smart --log-level=warning --data-dir=/mnt/Yocto/Fabric-x64/build/tmp/work/genericx86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs/var/lib/smart install --attempt -y ' returned 1: I tried the poky git repo with krogoth (HEAD & mid-september) and master; with recipes core-image-minima & core-image-sato. I know that I always have a warning from bitbake about "Debian-unstable" not being validated, but so far, it worked. So if any of you has an idea, I'd be most grateful! Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto