Re: [yocto] Trying to set up a debian package repository for yocto.

[Michel D'HOOGE]

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?

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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?

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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?

[Michel D'HOOGE]

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

[Michel D'HOOGE]

> 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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

> 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

[Michel D'HOOGE]

> 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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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

Re: [yocto] Using debian packages management

[Michel D'HOOGE]

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

[Michel D'HOOGE]

> > 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

[Michel D'HOOGE]

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] add dejavu-fonts to image

[Michel D'HOOGE]

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] add dejavu-fonts to image

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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

[Michel D'HOOGE]

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