**** BEGIN LOGGING AT Sat Jan 18 02:59:59 2020 Jan 18 08:08:43 New news from stackoverflow: Confugiure Linux IP Setting (IP address, netmask, gateway, dhcp[enabled, disabled], DNS Server,.....) with Python Jan 18 08:38:49 New news from stackoverflow: Configure Linux IP Setting (IP address, netmask, gateway, dhcp[enabled, disabled], DNS Server,.....) with Python Jan 18 09:08:54 New news from stackoverflow: Configure Linux IP Setting (IP address, netmask, gateway, dhcp[enabled, disabled], DNS Server,.....) with Python [closed] Jan 18 10:27:05 (while updating a setup from sumo to warrior) I'm getting an error on do_rootfs, but can't really see what's amiss from the output: https://pastebin.com/e8ZjgA0n - what tools do we have to deal with this ? looks like others hit this in the past but the Mighty Internet is clueless : https://stackoverflow.com/questions/51989838/finding-dependency-issues-in-yocto-do-rootfs-activity or https://www.toradex.com/community/questions/19849/bitbake-do-ro Jan 18 10:27:05 otfs-failed-with-rocko-and-dev-pkgs-i.html Jan 18 13:03:38 ZipCPU Good morning. What ver of verialtor are you using. Jan 18 13:18:55 Hi everybody, I have problems with bitbake for a long time. Can i ask and write my problems here for get any help? Jan 18 13:29:32 https://stackoverflow.com/questions/59801039/yocto-bitbake-fsl-image-qt5-validaiton-imx-always-error Jan 18 13:39:42 New news from stackoverflow: Yocto Bitbake fsl-image-qt5-validaiton-imx always error Jan 18 14:10:38 beratiks: Don't ask to ask - just ask Jan 18 14:12:45 paulbarker is right Jan 18 14:12:51 If you're new to Yocto I'd recommend following the quick start guide first to confirm you can successfully build an image before you try to use any third-party BSP or distro Jan 18 14:36:33 i could build core-image-minimal already without errors. Jan 18 14:42:54 beratiks: Could you post the bitbake command you execute and the full output via a pastebin? Jan 18 14:44:16 paulbarker: of course. i prepare Jan 18 14:55:47 paulbarker: This is my maybe 3rd try. I remove /build/tmp before every bitbake :https://pastebin.pl/view/32340cfa Jan 18 14:58:03 theres a lot of stuff going crazy. Jan 18 14:58:38 can't get the tesseract sources, have you checked that the url/access is valid? line 43 Jan 18 14:58:55 and tensorflow breaks too. Jan 18 14:59:35 but, you're all on master. maybe try a more stabilized release? like zeus? there can always be "funny" things happening when you're using the latest and coolest suff Jan 18 14:59:39 s/suff/stuff/ Jan 18 15:01:02 What LetoThe2nd said. Try the latest stable branch. I'd also recommend trying a simpler image with those layers first Jan 18 15:02:06 "Killed" on line 375 is a bit weird though - maybe check dmesg to see if the OOM killer did something Jan 18 15:02:22 LetoThe2nd: I saw do_fetch error. It was internet problem. now i rebuild it will dissappear. Jan 18 15:02:40 paulbarker: yeah i saw that too but undecided on what to conclude Jan 18 15:03:57 "Killed" is what bash prints when a child process got SIGKILL if I remember rightly Jan 18 15:05:32 paulbarker: There is a lot of message on my dmesg like that : [27640.598932] nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] Jan 18 15:07:29 Do you see different tasks fail each time you run the build? Jan 18 15:08:02 paulbarker: i'm still undecided, but might be heat/bad ram. what do ou think? Jan 18 15:09:41 paulbarker: yes, first times started with vulkan and qt. But now i am at 5th build. now problem at tenserflow. Jan 18 15:10:45 Bad RAM or not enough of it. Set `BB_NUMBER_THREADS = "1"` and `PARALLEL_MAKE = "4"`, see if a slow build works Jan 18 15:11:40 paulbarker: Ok I am going to try with these after remove tmp dir. Jan 18 15:11:49 I usually want at least 2GB per thread, more when building QT or a browser Jan 18 15:13:07 on SO you stated 16GB, which is usually enough. but yeah, qt or tensorflow might give you headaches. just as webkit, vulkan or arcane shader stuff. Jan 18 15:15:00 LetoThe2nd: You are right. When build packages which you said, my pc goes slow. Jan 18 15:16:08 The other possibility is bad RAM. If possible I'd recommend trying the same build on different hardware. Jan 18 15:16:25 Yocto builds are an excellent stress test of a machine Jan 18 15:23:50 Unable to look up github.com (port 9418) (Name or service not known) Jan 18 15:24:17 perhaps this src_uri should use https protocol instead of git protocol Jan 18 15:26:10 bad RAM while possible highly unlikey, system would act up even without building yocto Jan 18 15:26:30 khem: depends on the utilization. but yes, its not exactly likely Jan 18 15:27:07 I would also recommend to rein in xz Jan 18 15:28:14 XZ_DEFAULTS = "--threads=4" or some thing otherwise it goes amok on large files Jan 18 15:29:12 I have seen a mem use of 67G on machines during packaging ( of course with 128G RAM machines ) Jan 18 15:31:59 does my "none of the providers can be installed" do_rootfs issue above talks to anyone ? Jan 18 15:34:25 * khem cant scroll -ENOCOFFEEYET Jan 18 15:34:50 (while updating a setup from sumo to warrior) I'm getting an error on do_rootfs, but can't really see what's amiss from the output: https://pastebin.com/e8ZjgA0n - what tools do we have to deal with this ? Jan 18 15:37:50 yann: well that message indicates that you want to build something that depends on syscinit, but that is not about to be installed. Jan 18 15:38:00 well, it could be terse I agree, but its showing the problem Jan 18 15:38:03 right Jan 18 15:38:28 perhaps try bitbake sysvinit and see if it builds or not Jan 18 15:38:45 perhaps some distro features are coming in way or its being masked somehow Jan 18 15:39:15 "bitbake sysvinit" completes fine, I see no clue why it is refused Jan 18 15:41:42 there must be a reason for the "cannot be installed" condition, we could get more details in some way ? Jan 18 15:43:37 yann: are you building for systemd? Jan 18 15:43:46 shadow_ghost that seems unfamiliar, what customizations are in place? Jan 18 15:44:09 LetoThe2nd: no, just sysvinit Jan 18 15:44:39 LetoThe2nd: you asked about Timezone other day, :) I am in UTC Jan 18 15:44:48 khem: wheee Jan 18 15:45:10 yann: i'd say, bitbake -e that image and grep for sysvinit Jan 18 15:45:24 khem: we have our own layer with quite some package customisations Jan 18 15:45:29 to get some pointers what might be happening. Jan 18 15:45:46 yann: and vice versa, take a good look at the release and migration notes Jan 18 15:45:50 yann: so I would suggest, first disable that layer, and see if it works Jan 18 15:45:55 localise the problem Jan 18 15:50:14 make sense to bisect - just that would be bisecting inside a bisect here :) As context, I have that layer working with sumo and a (fixed) meta-rockchip, and an updated version of that layer for warrior and the new-gen meta-rockchip, both of which "working enough but with problems", and as part of bisecting one of those problems, I'm trying to build the original layer with the new-gen meta-rockchip Jan 18 15:51:54 yann: I understand, but I think since you are the best person to know your customization, usually its best to first isolate it to specific areas preferably cutomized one since then you know what can be the issue Jan 18 15:52:09 right Jan 18 15:52:56 it seems that customized layers are adding fair bit to core packagegroups and you might have hard deps on init system etc Jan 18 15:53:03 I am just guessing Jan 18 15:53:06 just I was thinking this "none of the providers can be installed" issue can surely be tracked down to a specific reason Jan 18 15:53:37 khem: yet a guess by you is often worth more than a "statement" by most of us :) Jan 18 15:54:01 I tried to locate where the message comes from but could not find it yet Jan 18 15:55:13 Hi, I'm trying to get a wic image to depend on another imagetype and I can't seem to set the dependencies properly. Is that something I can do? Jan 18 15:55:53 LetoThe2nd: not really but I try, I learn a lot from reading the channel whenever I have time Jan 18 15:56:55 yann: the message is too late and I think packager pours its gut out on errors, that could be improved but in your case its doing ok and message is clear Jan 18 15:57:26 look for shadow_ghost Jan 18 15:57:38 where is this being built ? Jan 18 15:57:54 that will be a good point of insertion for debugging Jan 18 16:04:16 liambeguin[m]: perhaps try to use task[depends] = "recipe:task" Jan 18 16:10:14 khem: your recommend to rein xz is so logical. I will also try. Maybe my build tries xz on 12 threads although "BB_NUMBER_THREADS = 3". Is it like that? Jan 18 16:12:19 yeah it does not respect thst Jan 18 16:12:28 since it has mind of its own Jan 18 16:12:46 it looks at available cpu/memory and decides how many threads to spawn Jan 18 16:13:11 and that hurts when you are packaging large packages e.g. qt, webkit, llvm etc Jan 18 16:14:27 khem: I tried using task[depends] with no luck.. My first imagetype generates a file in IMGDEPLOYDIR and the documentation for IMAGE_BOOT_FILES says it looks for files in DEPLOY_DIR_IMAGE. Should I edit my first imagetype to not use IMGDEPLOYDIR? Jan 18 16:14:42 khem: thanks I added in my notes. Jan 18 16:16:25 khem: shadow-ghost is the MACHINE_NAME Jan 18 16:18:12 I guess it appears in packagegroup-core-boot's PR because of a MACHINE_EXTRA_RDEPENDS in machine/shadow-ghost.conf, would that make sense ? Jan 18 16:18:36 yann: yes Jan 18 16:18:57 liambeguin[m]: hmm depends should have worked Jan 18 16:20:29 khem: okay, I'll investigate more. Thanks Jan 18 16:21:00 btw. first image should define do_deploy where it copies it to DEPLOY_DIR_IMAGE Jan 18 16:22:08 khem: I probably forgot that. I'll give it a try Jan 18 16:27:24 khem: can I just copy my output file to DEPLOY_DIR_IMAGE at the end of my IMAGE_CMD function? Jan 18 16:27:27 I'm still baffled that you find the message clear - all I see is pointing a problem with sysvinit, whereas I am between 2 stable commits A and B, and I can see nothing impacking sysvinit between either of those commits and the one I'm on. There must be a reason why opkg thinks it's not installable, but I'd like it to spit that to my face :) Jan 18 16:29:47 Try `OPKG_ARGS_append = " -v"` or `-vv`, that might get you some extra noise Jan 18 16:29:48 I find this message quite akin to a C compiler just telling me "I did not produce you exe, because foo.c does not compile", in some way :) Jan 18 16:30:07 thx paulbarker Jan 18 17:31:09 Hello. Jan 18 17:33:24 I'm using poky rocko with meta raspberrypi,on start boot messages are hidden I only see 'please wait:booting' .can somebody tell me how to show those boot messages please ? Jan 18 17:56:18 jww: you probably have a boot partition on your sdcard image, you can mount it from a PC and remove the "quiet" boot option - or find out where the "quiet" option is added and arrange to remove it Jan 18 18:40:18 yann what is your DISTRO and MACHINE setting Jan 18 20:37:04 khem: they are likely not to help, in-house stuff :) MACHINE is shadow-ghost, an rk3399 platform, and DISTRO is ShadowOS, poky-based with not much changes. We have plans to publish this, but there is a bit of layer-splitting to be done first Jan 18 20:41:02 New news from stackoverflow: Yocto Bitbake fsl-image-qt5-validaiton-imx always error (SOLVED) Jan 18 20:46:36 paulbarker: LetoThe2nd: khem: I could finally build fsl-imx-wayland distro. Thanks for your helps. I want to say all problems about PC hardware. I trust my machine to build speedly but not enough for that. Reduced build speed and rebuild at every fail led me to success. Jan 18 20:47:13 beratiks: thanks for reporting back Jan 18 20:48:02 beratiks: another reason why people usually only build images tailored to what they actually need. Jan 18 20:49:52 LetoThe2nd: yes, totally true. Jan 18 21:21:35 yann: I was interested in just name shadow is also a package and I was wondering if that could be conflicting Jan 18 21:44:40 I took care to avoid that :) Jan 18 21:44:43 So I've tried with OPKG_ARGS_append=" -V3", but unfortunately that does not give much information I can use **** BEGIN LOGGING AT Sun Jan 19 03:30:12 2020 **** ENDING LOGGING AT Sun Jan 19 03:34:18 2020 **** BEGIN LOGGING AT Sun Jan 19 03:41:10 2020 Jan 19 07:12:52 New news from stackoverflow: A20-OLinuXino-LIME-4GB yocto image Jan 19 10:13:21 New news from stackoverflow: A20-OLinuXino-LIME-4GB yocto image [closed] Jan 19 11:28:09 where do those "Solver encountered %d problem(s)" come, in fact ? I don't find them in bitbake, nor in opkg Jan 19 11:36:28 yann: Possible the dependency resolver library used by opkg Jan 19 11:51:04 paulbarker: good catch - I missed it in the .bb because it's conditionned by PACKAGECONFIG :| Jan 19 13:59:40 khem: sorry! Jan 19 14:36:05 Hi, I create a new layer and added new machine and u-boot. I added to fix some machine errors " COMPATIBLE_MACHINE = "|machine_name"" but i got an error. Is there anyone any idea? .ERROR: imx-sc-firmware-0.9-r0 do_fetch: The recipe LICENSE should include Proprietary but is MIT.ERROR: imx-sc-firmware-0.9-r0 do_fetch: ERROR: imx-sc-firmware-0.9-r0 Jan 19 14:36:05 do_fetch: Function failed: do_fetchERROR: Logfile of failure stored in: /home/berat/imx-yocto-bsp/build/tmp/work/tqma8xqp_mba8xx-poky-linux/imx-sc-firmware/0.9-r0/temp/log.do_fetch.19573ERROR: Task (/home/berat/imx-yocto-bsp/sources/meta-freescale/recipes-bsp/imx-sc-firmware/imx-sc-firmware_0.9.bb:do_fetch) failed with exit code '1' Jan 19 14:38:59 beratiks: Maybe search your layers for what is printing that phrase - I've never seen that one before. Could be something in the Freescale BSP Jan 19 16:44:27 New news from stackoverflow: How to set environment variable in bitbake? Jan 19 17:40:00 anyone around familiar with libsolv ? I've started to dig into how to improve opkg diags for my problem, and found that opkg uses solver_findproblemrule(), which is documented as "Actually a pretty hopeless task that may leave the user puzzled. To get all of the needed information use solver_findallproblemrules() instead." Jan 19 17:41:09 if anyone could shade light on libsolv's usage of a single Id type for all its object types, it might speed up my conversion of those ideas into hopefully intelligible hints Jan 19 20:46:04 RP: didnt get it Jan 19 21:41:50 RP: perhaps it was better to wait to merge py2 removal atleast until it showed up in meta-py2, its broken all distros downstream Jan 19 21:42:26 losing precious CI time Jan 19 22:15:23 New news from stackoverflow: Yocto recipe to update /etc/fstab Jan 19 22:25:35 Hello. Is there a way to 1) create a file structure under the ${WORKDIR} directory and 2) package that file structure in a tar file? Could anybody point me to the sources where I can find out? Jan 19 22:41:59 khem: finally got my neurons back and finalized my opkg patch. The output becomes https://pastebin.com/eMCiAj2W which indeed points me to the real problem (openssl11 was a hack I hadded in sumo, which poluted my first warrior builds, as there were 2 providers of this libssl soversion). Jan 19 22:44:09 khem: the trouble is nobody is doing anything until they have to :( Jan 19 22:44:10 where do we go from now ? I'd argue libsolv selects the wrong message, but its doc does say this API asks for the impossible. Is it reasonable to include the full list of reasons, maybe flagging those that solver_findproblemrule() think are the most relevant Jan 19 22:45:00 yann: You should talk to Alejandro (opkg maintainer) Jan 19 22:45:00 or should this be seen as "extended diag" and conditionned by a new opkg flag, maybe for backward-compatibility of some sort ? Jan 19 22:45:22 RP: ok will do that Jan 19 22:47:26 cc: oe-core maybe ? Jan 19 23:43:48 yann: sure **** BEGIN LOGGING AT Mon Jan 20 01:50:52 2020 **** ENDING LOGGING AT Mon Jan 20 02:59:57 2020