**** BEGIN LOGGING AT Tue Jan 26 02:59:57 2021 Jan 26 03:50:07 Hi Everyone, I'm having an issue when I remove Wayland x11 from my distro and run on the target, I am completely unable to login (root or user), it shows login: , password: but it never logs in. Jan 26 03:50:15 Anyone have an idea why this might be the case? Jan 26 03:51:38 Without removing Wayland x11 I can login no problem on any user. Jan 26 07:41:19 good morning Jan 26 07:49:22 good morning. I try to build a go recipe, but i got the error: "...cannot find package "github.com/gorilla/mux" in any of ...". Does golang recipes need special treatment for external packages? Jan 26 07:52:54 i would have expected, that all imports will automatically handled by a go recipe Jan 26 08:04:57 RP: some pseudo changes in master-next ? https://errors.yoctoproject.org/Errors/Build/115247/ Jan 26 08:13:45 khem: no pseudo change in -next :/ Jan 26 08:14:50 OK I have binutils 2.36 in there so it could be some mix of that then Jan 26 08:15:00 yo dudX Jan 26 08:19:11 RP: seeing this http://sprunge.us/KZTM0V I wonder what can this tell me Jan 26 08:20:39 khem: my interpretation is: -EOUTOFAPPROPRIATEBEVERAGES Jan 26 08:21:03 seems that ranlib from new binutils is crashing Jan 26 08:23:16 khem: something is deleting files that pseudo can't "see". Which distro is this? New libc version? Jan 26 08:24:01 khem: strace the new ranlib and see what its deleting files with syscall wise? Jan 26 08:24:55 I am seeing it on multiple distros from ubuntu 18.04 to 20.04 or arch as well Jan 26 08:25:29 only binutils is new Jan 26 08:25:52 khem: still could be some function we're not intercepting? Jan 26 10:33:54 where can i find all available golang variables? like GO_IMPORT, GO_INSTALL, .... Jan 26 10:40:11 chris_ber: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/go.bbclass and its inherited classes? Jan 26 10:53:04 qschulz: ok, there is no reference manual? Jan 26 11:02:38 and is it possible to use golang 1.16beta1? I do not know how to set a golang version Jan 26 11:14:38 ok, i see. I should have to write my own recipe. therefor i wait till go 1.16 is released Jan 26 11:18:19 chris_ber: reference manual does not actually have anything for go.bbclass. Patches welcome :) Would probably make sense at least in https://docs.yoctoproject.org/ref-manual/classes.html Jan 26 11:26:54 yes, would make sense. The yocto docs are getting better! :thumbsup: Jan 26 11:27:40 question regarding something that I came across, on the website it says: Jan 26 11:27:43 Flexibility: Corporations use the Yocto Project many different ways. One example is to create an internal Linux distribution as a code base the corporation can use across multiple product groups. Through customization and layering, a project group can leverage the base Linux distribution to create a distribution that works for their product needs. Jan 26 11:28:48 * LetoThe2nd looks, at paper sheer, finds all the buzzwords, stands up quickly and shouts "BINGO" Jan 26 11:29:06 In the mentioned use case, I don't see why a customized yocto image would be more efficient than a ubuntu image since the criteria in this use case is definitely not the size of the image but the capabilities. And if something is not available it is easier to add and remove something so why mention the above example use case? Jan 26 11:29:49 nicnic2: two prime examples are: hardware that is not supported by your run of the mill ubuntu and: licensing. Jan 26 11:30:32 LetoThe2nd Ah you got me with the first one :) Jan 26 11:30:52 But the second point, there should be no issue with ubuntu licensing? Jan 26 11:31:52 or even the apps... Jan 26 11:31:58 nicnic2: GPLv3 Jan 26 11:32:12 nicnic2: there is. paulbarker can give you more details, but in a nutshell: there are a lot of rules and restrictions to abide when you ship hardware with ubuntu on it. some are pretty hard to overcome (like guaranteeing the source versions you can provide EXACTLY match the binaries) Jan 26 11:33:04 ok did not expect that at all to be honest D: Jan 26 11:33:08 also, Ubuntu is about trademarks too. distribution of Ubuntu images outside of ubuntu.com requires TM premissions which you can't get Jan 26 11:33:10 nicnic2: there are other nice things you can't easily do with ubuntu, like image based a/b upgrades for example. or having libraries honour specific hw optimization flags. Jan 26 11:33:35 now Debian on the other hand... Jan 26 11:33:45 nicnic2: so all in all: ubuntu is a nice thing that can do nice things. yocto is a nice thing that can do other nice things. use whatever fits your needs. Jan 26 11:34:05 noted, thanks guys Jan 26 12:20:55 i developed a webapp with go and used serveral javascript packages described in a package.json and installed via npm. My recipe is a go recipe. How to install the packages defined in the package.json? Can my recipe inherit go and npm at the same time? Then in do_prepare() { ...npm install ....} ? Is this possible? Jan 26 12:22:40 chris_ber: sounds very painful, and i doubt that it works (inheriting go and npm). two ways come to my mind - either manually integrating go and npm into the recipe (ugly!) or building the application in two seperate recipes. Jan 26 12:25:44 so, I'm back with my IKCONFIG=y in the 5.4 kernel defconfig fails my icecc-enabled poky build (on thud)... I built 5.4 linux-yocto for qemuarm64 on vanilla dunfell. I checked with menuconfig, ikconfig is enabled, I added INHERIT+="icecc" to my conf/local.conf Jan 26 12:25:54 and for some reasons, linux-yocto does not fail to build.... Jan 26 12:26:34 so do I have much luck when building vanilla poky or is there something I missed in linux-yocto recipe or git repo? Jan 26 12:26:54 JPEW: ^ pinging you maybe since we talked about this a month ago Jan 26 12:27:19 don't know bruce's nick here Jan 26 12:27:36 LetoThe2nd: hmmm...ok. Go 1.16 introduces the #embed directive, which will include all static files in the executable, therefor i think 2 recipes will not be an option. Headache! But maybe my approach is not suitable for a yocto application?!? Jan 26 12:28:32 maybe i should check in all javascript files i need. Seems to be a common approach anyway. Jan 26 12:29:12 chris_ber: you could have an npm recipe fetching what you need and your go recipe depending on it? (maybe abusing the SYSROOTDIRS at the same time, don't know) Jan 26 12:29:22 chris_ber: why is that a problem? you can always have a recipe pull in things that another one created. thats called dependencies. Jan 26 12:29:50 it might need some fiddling here and there, but the usecase certainly applies. Jan 26 12:30:06 ok Jan 26 12:30:25 and if the web frontend is independent from the actual server, it should be allarch Jan 26 12:30:39 like said, its not super trivial but certainly doable. Jan 26 12:31:04 i will give it a try Jan 26 12:33:17 the first recipe uses npm and downloads the stuff. the second recipe uses go, i there i will add something like `do_prepend` and copy the files to the destination i need ... more or less Jan 26 12:33:18 depending on the project architecture (e.g. of the web frontend) it might even mandate chaining two ci/cd instances - one generating the webapp, the other pulling it into the build Jan 26 12:33:43 but "it all depends". (badum-tsh!) Jan 26 12:34:43 ok, thx Jan 26 13:07:04 @LetoThe2nd: Oida! Jan 26 13:09:07 @RobertBerger: OIDA! Jan 26 13:26:25 @chris_ber: Can you build your magic go app with some yocto SDK? - no recipes yet Jan 26 13:45:26 RobertBerger: i didn't try. What is the origin of your question? Jan 26 13:52:24 @chris_ber: I guess once you manage to build the app via a yocto SDK you might get a better idea of what needs to be done with the recipe(s) Jan 26 13:55:11 mmmm... so... why does Yocto not build icecc instead of relying on host for it? Jan 26 13:55:31 (more specifically, icecc client, not the daemon) Jan 26 13:55:45 qschulz: It could... but it has a lot of dependencies Jan 26 13:56:15 So you'd end up waiting a while for it to be available, which eliminates some of the benefit Jan 26 13:57:21 JPEW:and now I'm wondering if we wouldn't gain from a one-time icecc-client-native build and keep building the 5.1+ kernel with icecc? Jan 26 13:57:36 (we = the company I work for, not YP) Jan 26 13:58:27 qschulz: Ya, keeping the client up-to-date is important. We (the company I work for) solved that by including the up-to-date icecc client in the Docker image we use for building Jan 26 13:59:03 qschulz: https://github.com/garmin/pyrex/blob/master/image/Dockerfile#L55 Jan 26 13:59:31 @qschulz/JPEW: maybe yocto could build it and add it buildtools-extended Jan 26 13:59:33 If you run the container with `--net=host` the client in the container will talk to the daemon running on the host via the stable IPC Jan 26 13:59:51 JPEW: yup, we're just not using any container at the moment Jan 26 14:00:13 but honestly might have to with customers still building krogoth with no desire to upgrade Jan 26 14:00:28 (and we have to build for them obviously) Jan 26 14:00:50 qschulz: Ya, that's one of our reasons for using containers. We can build with the supported ubuntu distro on old releases Jan 26 14:01:21 qschulz: You should checkout Pyrex. It's designed to be pretty seamless Jan 26 14:01:31 And already has icecc ;) Jan 26 14:01:59 JPEW: I'll at some point... for now some of our people on gentoo and arch are using handmade containers Jan 26 14:02:13 don't know how much we'll be able to re-use as we have quick some hacks here and there :) Jan 26 14:02:53 qschulz: Depends on what the quirks and hacks are Jan 26 14:04:50 JPEW: we'll see. One is pulling 6 different toolchains (ah... vendor BSPSs <3) Jan 26 14:06:06 Oh, ya. Thats always fun. We wrote Pyrex to use the "host" file system so as long as you bind in the toolchain locations properly (by default, $TOPDIR is bound) it can use them. It also means all your output is in the host as well Jan 26 14:07:29 qschulz: https://github.com/garmin/pyrex#what-doesnt-work is pretty comprehensive about what *doesn't* work; otherwise I think most things should work pretty easily Jan 26 14:13:24 JPEW: oof. I use devtool extensively for debugging and I highly recommend it in my company Jan 26 14:14:02 qschulz: Ah... ya. We haven't used it much :( I think it could be made to work, I just haven't looked into it Jan 26 14:14:31 qschulz: That might possibly already work, I've just never tested it Jan 26 14:16:24 JPEW: nothing that can't be fixed probably. Jan 26 14:18:15 i try to copy a file (for test purpose only) in the routine do_configure_prepend (`cp ${D}/static-server/static/vendor/package.json ${D}/package.json) and getting the error invalid syntax point to the first $ Jan 26 14:19:25 chris_ber: ${D} does not exist until do_install task Jan 26 14:19:46 so ${D} resolves to nothing and it tries to copy files from /static-server/static/vendor/package.json which obviously does not exist Jan 26 14:20:32 chris_ber: are you sure about ${D}? when exactly do you need this file? Jan 26 14:20:49 hi qschulz Jan 26 14:20:57 if it's configure, it's probably ${S} for the first and either ${S} or ${B} for the second Jan 26 14:22:38 JPEW: (just tagging you but no answer needed) for IRC archives: I decided to revert bc0c60457c35c895b5591f85046b1f13da5487c4 and 13610aa908dcfce77135bb799c0a10d0172da6ba from the Linux kernel to still be able to use (old; pre-1.3) icecc-client with 5.4 kernel recipe Jan 26 14:23:09 you are right, D ist totally wrong Jan 26 14:24:44 in the end, i try to tell npm where to find the package.json. Jan 26 14:25:29 * LetoThe2nd imagines chris_ber sitting in front of his computer, pointing at the screen and speaking loudly "there you will find it, npm!" Jan 26 14:25:53 finally modified the cmake and makefiles so that libmylib.so now compiles and links as libmylib.so-1.0.0 now I still get the error: QA Issue: /bin/my_program contained in package my_project requires lib/libmylib.so-1.0.0()(64bit), but no providers found in RDEPENDS_my_project? [file-rdeps] Jan 26 14:26:23 chris_ber: it seems npm is expecting package.json to be in ${S} directly Jan 26 14:26:31 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/npm.bbclass#n121 Jan 26 14:27:03 intera91: it should be libmylib.so.1.0.0 not libmylib.so-1.0.0 Jan 26 14:27:18 oh blast Jan 26 14:27:36 then you'll be good :) Jan 26 14:27:47 i will be back Jan 26 14:27:51 lol Jan 26 14:28:36 LetoThe2nd: hmmm....yeah....don't tell anybody Jan 26 14:29:29 qschulz: you can tell npm with --prefix where to find the package.json...but... you know, it's not working Jan 26 14:29:50 chris_ber: i already have pictures and am uploading them to instagram right now. plus, on tiktok, with "you can't always get what you want" as soundtrack! Jan 26 14:41:21 still complaining that the cp command can't be parsed: `cp ${S}/static-server/static/vendor/package.json ${S}/package.json` Jan 26 14:42:16 chris_ber: ah wait Jan 26 14:42:24 hehehehehehe Jan 26 14:42:35 configure is a python task on npm recipes IIRC Jan 26 14:42:45 yup Jan 26 14:43:32 so i need python syntax? Jan 26 14:43:43 so either: do_configure[prefuncs] += "cp_packagejson;" and then put your cp in cp_packagejson shell task (I think that is supported) Jan 26 14:43:57 or, do it the python way Jan 26 14:45:45 ok, i will remember that for the future. But now i will just check in the vendor packages and copy that stuff in an install task. Jan 26 14:45:50 something like srcdir = d.getVar('S'); shutil.copyfile(srcdir + '/static-server/static/vendor/package.json', srcdir)? Jan 26 14:46:31 chris_ber: well, if you need the package.json at build time, cp'ing at install time won't do it Jan 26 14:47:55 qschulz: no i meant i will check in the vendor packages in my git repo and copy them later. I don't like to check in external javascript dependencies, but a lot of guys doing it. Jan 26 14:48:55 chris_ber: ah I see, npm and js stuff are definitely not part of my knowledge :D Jan 26 14:49:21 chris_ber: expect some hurdles along the way as I am not sure we have many people/recipes using go or npm Jan 26 14:49:49 qschulz: with your approach i see writing a lot of extra stuff. one thing leads to another and i starting to add + import shutil, do this, do that.... Jan 26 14:51:22 for now it is ok to just copy the javascript dependencies. Doing it with package.json is an issue for later. Thank you guys Jan 26 14:52:56 chris_ber: recipes are rarely just inheriting npm or go :) Jan 26 14:53:07 but I understand your point Jan 26 15:29:36 is it better to "require core-image-minimal(-initramfs).bb" in your own image recipe or copy their content? Jan 26 15:33:55 vdl: In the wise words of LetoThe2nd "It depends" Jan 26 15:34:17 If you just want to add a few extra packages to your image and base it on an existing image that is a good approach Jan 26 15:34:47 i usually go for copy. Jan 26 15:36:40 If you copy you need to maintain you copy as well with every new yocto version ;) Jan 26 15:39:58 RobertBerger: well for core-image-minimal i don't really see the benefit of require-ing 3 or 4 lines, for the cost of a cross dependency. I usually like my images to be as self-contained as possible. Jan 26 15:41:12 @LetoThe2nd: just saying - this is one more item to check, and if you use poky anyhow you can require it. Jan 26 15:41:35 if you base off other, more complex imagery (pun intended) then require might be a better choice. Jan 26 15:45:16 Between dunfell and gatesgarth this changed: "", d)}" --- "" ,d)}" Spot the difference ;) Jan 26 16:02:38 https://swatbot.yoctoproject.org/ Jan 26 16:14:23 RP: waf python change 6b78a1734318fce8ee13c28c1454d3d76f52bae8 in dunfell is causing breakage in some BSP layer SW components which still use and need python2. Fix/workaround is WAF_PYTHON = "python" in the affected recipes. AFAIK, there are a lot of BSP and other layers which still need and use python2 so those may be affected. Jan 26 16:24:28 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13181 Jan 26 16:27:32 mcfrisk: Yep. We use waf extensively internally and had to add that to all our recipes Jan 26 16:30:13 JPEW: yep, I don't really mind that change right now as it took just 10 minutes to figure out what to fix but this happened on LTS branch so... these kind of changes can be a bit problematic even if they fix also real bugs Jan 26 16:34:45 qschulz Jan 26 16:34:48 am back Jan 26 16:36:21 still getting the error as the versionned lib and its link are copied to the lib subdirectory of the build folder, the software compiles ok but the library is missing from the final rpm and the error I told you about earlier is still there Jan 26 16:36:26 frustrating Jan 26 16:41:18 vmeson: were you implying I have a lot of background noise today? Jan 26 16:43:58 RP, for me, yes lots of nice comforting hiss. Jan 26 16:49:22 vmeson: sorry, that is probably the fire :/ Jan 26 17:07:30 intera91: oe-pkgdata-util find-path '*library.so.*' what's the output? Jan 26 18:08:15 INITRAMFS_SCRIPTS (from core-image-minimal-initramfs.bb) is meant to be altered from your distro conf or local.conf, right? Jan 26 19:02:38 Hi there everybody! Would somebody be kind enough to help me with a build problem I'm having? Jan 26 19:08:11 I'll try anyway:)  I'm on Sumo and meta-oe by default provids modemmanager 1.6.4, which is too old for me. Since this is literally my first recipe, all I did is to try to use the 1.14.10 recipe from meta-openembedded master (https://cutt.ly/xj8dz0c); however, the build errors are: https://pastebin.com/cgaQBm3B and I don't quite have a clue where Jan 26 19:08:11 to begin. Any help appreciated; thanks! Jan 26 21:56:56 RP: INITRAMFS_FSTYPES is plural but a single type is expected in fact, correct? Jan 26 22:12:16 vdl, what does make you think so? Jan 26 22:12:23 we use since years Jan 26 22:12:23 INITRAMFS_FSTYPES ?= "cpio.gz cpio.xz" Jan 26 22:13:48 remember to ad the correct kernel config for the decompresors :) Jan 26 22:14:19 ant__: image-live.bbclass:40: INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}" Jan 26 22:14:33 this assumes a single type, doesn't it? Jan 26 22:14:41 sory, never used that image Jan 26 22:15:00 seems so Jan 26 22:16:36 vdl, https://git.openembedded.org/meta-handheld/tree/conf/machine/include/zaurus.inc#n9 Jan 26 22:16:48 surviving since years... Jan 26 22:17:15 ant__: and I was wondering because I wanted to make the generation of my extlinux.conf more generic, with something like: Jan 26 22:17:17 UBOOT_EXTLINUX_INITRD = "../${INITRAMFS_IMAGE}.${INITRAMFS_FSTYPES}" Jan 26 22:17:57 which seems very wrong if several types are provided ;-) Jan 26 22:18:08 :/ Jan 26 22:18:44 well, usually you build a custom initramfs image, isn't? why that class? Jan 26 22:19:43 ant__: I'm not using image-live, I just grep'd INITRAMFS_FSTYPES to see how it was used and I found this Jan 26 22:20:21 seems fishy Jan 26 22:20:56 let's poke the master Jan 26 22:21:20 RP: ^ Jan 26 22:50:41 vdl, ant__: I think it can take multiple vlaues and is modelled on FSTYPES which definitely takes multiple values Jan 27 00:00:50 RP: the problem is lines like this assuming it has only one value: image-live.bbclass:40: INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}" Jan 27 00:09:52 vdl: right, that doesn't sound good :( Jan 27 00:19:17 RP: if INITRAMFS_FSTYPES support multiple values, there's no safe way to construct the full image name in fact Jan 27 00:20:45 vdl: I suspect only one value will work with the current code, that wasn't the design intent though originally afaict Jan 27 01:56:01 RP: Heh, my company firewall blocks swatbot.yoctoproject.org.... presumably because of the "bot"? **** ENDING LOGGING AT Wed Jan 27 02:59:57 2021