**** BEGIN LOGGING AT Thu Jan 23 02:59:57 2020 Jan 23 04:23:23 there is a proposal for systemd support in psplash lately, please check mailing lists Jan 23 04:24:31 see https://patchwork.openembedded.org/patch/169342/ Jan 23 08:31:05 New news from stackoverflow: Start an Electron app at boot on Raspberry Pi 3 with yocto Jan 23 09:44:25 What do these setscene errors "No suitable staging package found" that started coming with multiconfig build? Followed by "WARNING: Setscene task failed with exit code '1' - real task will be run instead" Jan 23 09:44:39 everything succeeds so should i ignore them or do something? Jan 23 10:57:38 HI! I have a problem building qtbase for raspberry pi, the error is Nothing PROVIDES 'virtual/libgbm'. Does anyone have an idea? Jan 23 11:32:19 alexb3600: which release are you on? Jan 23 11:58:59 Warrior Jan 23 12:00:25 alexb3600: coherently? e.g., all layers? Jan 23 12:01:01 alexb3600: are you going for kms / eglfs, what is your desired graphical backend ? Jan 23 12:03:38 LetoThe2nd: yes all layers Jan 23 12:03:47 alexb3600: ok. which would that be? Jan 23 12:04:38 dev1990: I don't want graphical backend, I just need the libQt5 for my application Jan 23 12:05:15 ah ok, so make sure to erase all graphical backend from PACKAGECONFIG that is used in qtbase Jan 23 12:05:52 meta-raspberrypi append some parameters to by bbappend take a look to it Jan 23 12:06:41 exactly. also have a look at https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb#L59 Jan 23 12:06:55 MACHINE="your-raspberry" bitbake -e qtbase | grep "^PACKAGECONFIG" Jan 23 12:07:03 to see what is on Jan 23 12:09:06 Hum, I check that and I'll tell you, thanlks a lot :) Jan 23 12:35:39 ok so I commented these parameters in qtbase_git.bb Jan 23 12:36:21 PACKAGECONFIG_GL, PACKAGECONFIG_FB, PACKAGECONFIG_X11 ,PACKAGECONFIG_KDE Jan 23 12:37:31 dev1990: then I performed your command but I got these kind of errors: ERROR: Nothing PROVIDES 'virtual/egl' (but /workdir/poky/meta-qt5/recipes-qt/qt5/qtbase_git.bb DEPENDS on or otherwise requires it) Jan 23 12:37:31 vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp Jan 23 12:38:41 alexb3600: you can set PACKAGECONFIG_GL, ... empty from your local.conf Jan 23 12:38:47 for example: PACKAGECONFIG_GL = "" Jan 23 12:39:14 to remove egl you can go with that Jan 23 12:39:24 In fact, I just want to add my application binary into the rootfs but yocto detect errors with libqt (Which is normal because I planned to add a folder into the rootfs as well wich contain the libs) Jan 23 12:39:55 * dev1990 sec Jan 23 12:40:43 PACKAGECONFIG_remove_pn-qtbase = "egl" Jan 23 12:40:57 PACKAGECONFIG_remove_pn-qtbase = "gles2" Jan 23 12:41:34 alexb3600: take a look https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb#L103 Jan 23 12:42:09 there is many PACAKGECONFIG flags that are used, those that are used pulling depedencies Jan 23 12:42:24 still i think the problem is somewhere different Jan 23 12:42:50 because "i just want" and "binary" sounds like you are trying to do somthing that screams for problems. Jan 23 12:42:54 LetoThe2nd: PACKAGECONFIG[gles2] = "-opengl es2,,virtual/libgles2 virtual/egl" Jan 23 12:43:08 gles2 pulling virtual/egl Jan 23 12:43:25 there is high probability that gles2 is active then Jan 23 12:43:46 dev1990: ok I check Jan 23 12:44:39 LetoThe2nd: yes ahah, I have a binary and a folder wich contain .so for my binary. The only thing a want is to copy them into the rootfs Jan 23 12:44:44 anyone know a example recipe that just pulls a git repo and copies it as-is to rootfs? Somehow im struggling with this Jan 23 12:44:47 alexb3600: try to modify those parameters from local.conf (or your own distro file - if exists), because you don't want to commit that comments upstream Jan 23 12:46:11 alexb3600: that sonds like the generic desciption of "problematic" Jan 23 12:46:56 alexb3600: i have a similar use case and i used https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries Jan 23 12:46:58 as inspiration Jan 23 12:47:19 LetoThe2nd: I don't use yocto very often so I'm not a specialist but it surprise me that copying a file and a folder into the rootfs is problematic Jan 23 12:47:25 (sorry i dont really know the context, i just saw your message about copying binaries) Jan 23 12:52:26 alexb3600: are you sure you want to copy already compiled binary? architecture is same? some librariers maybe incompatible? etc? Jan 23 12:53:10 dev1990: 100% sure Jan 23 13:01:04 alexb3600: why don't you just automate building the app/library in a recipe? Jan 23 13:02:55 alexb3600: i mean, the slightest variation in the ABI that you are copying to, and boom. Jan 23 13:04:56 for small qt project recipe can be super short, just inherit qmake and set path_project_file.pro path Jan 23 13:05:09 for cmake qt also Jan 23 13:12:02 is there a script or program to format bb recipes according to guidelines ? Jan 23 13:13:00 RP: I realized while looking at the logrotate bug after previous results that the tests as written still didn't make a lot of sense - checking the rotation path for a rotated log isn't all that useful, so I've resubmitted the patch with a change to include the output of logrotate -vf instead Jan 23 13:13:22 That should actually tell us what it gets hung-up on Jan 23 13:14:54 stuom1: yocto we usually don't install files to image rootfs directly. instead we create recipes to build binary packages which are then installed to images. a trivial recipe would include a repo SRC_URI and just do_install task to install the files using "install". then add the binary package with the files to an image via IMAGE_EXTRA_INSTALL etc. Jan 23 13:17:06 mcfrisk yeah I figured it out, it was just confusion with what directory shorthands to use in do_install and in FILES etc... there wasnt anything to build, just bunch of .py files for testing Jan 23 13:18:59 stuom1: good, happens to me all the time. bitbake -e output and buildhistory help in debugging details, and mega manual.. Jan 23 13:19:01 tgamblin: thanks, I'll try and include in a new set of builds soon Jan 23 13:21:42 dev1990: it's a big applmication but thanks, I think I will do that Jan 23 13:22:00 LetoThe2nd: thanks too :) Jan 23 13:22:19 milloni_: the link is very interesting Jan 23 13:32:02 New news from stackoverflow: remove systemd service in yocto? Jan 23 14:02:07 New news from stackoverflow: Read-only file-system on yocto Jan 23 14:27:25 OK, time for a question worth a million, how difficult would it be to backport glibc version from thud to krogoth (clients...........)? Jan 23 14:31:22 qschulz: go ahead and jsut give it a spin. Jan 23 14:35:45 qschulz: a bit annoying, new glibc introduces changes that means a fair bit of software might not build Jan 23 14:35:51 its *not* a trivial backport Jan 23 14:35:58 probably easier than backporting gcc though Jan 23 14:38:04 qschulz: I'd agree, probably can be done... Jan 23 14:44:57 Oh, I expected much more pessimism actually :) Jan 23 14:45:20 rburton: any issue you're foreseeing already? Jan 23 14:45:42 usually people ask for a newer gcc so i'm not sure exactly what will fail with a new glibc Jan 23 14:45:52 headers have moved around a bit, new glibc is more 'correct' Jan 23 14:46:11 so you'll get problems like functions not being available anymore as the includes are bad Jan 23 14:47:29 thanks folks! Jan 23 16:10:12 can I put PREFERRED_VERSION_linux-yocto at image level?, or does i have to be on distro? or even local.conf is required? Jan 23 16:11:50 Ad0: why not in the machine conf file? Jan 23 16:12:17 I guess I have to override it ? Jan 23 16:13:24 I don't think you can, that's a conf file and not a recipe Jan 23 16:15:25 thanks. well the machine config is not mine, it is forinstance qemux86 Jan 23 16:16:50 Depending on how many changes you want to operate, having a custom machine could make sense at one point Jan 23 16:17:18 hm maybe Jan 23 16:17:37 there are 4 "dimensions" here. local.conf / bblayers, machine, distro, image Jan 23 16:23:42 I'm not sure PREFERRED_VERSION are supposed to be in image. My thinking is that we have separate workdirs for different distros, different machines and local.conf shouldn't change much across builds. But there isn't a workdir for images, hence images only impact which packages are put into an image Jan 23 16:23:48 But that's a guess Jan 23 16:38:12 tlwoerner, I have the Rock Pi 4 booting and running weston :) Jan 23 16:38:32 JPEW: cool! Jan 23 16:41:06 * tlwoerner checks yocto-patches.... :-) Jan 23 16:41:41 qschulz: i'm proud of you, finally you get the chant Jan 23 16:41:47 tlwoerner, I CC'd you on all but one I think: "Remove u-boot-rockchip" Jan 23 16:41:54 Ad0: it totally belongs into the MACHINE Jan 23 16:44:42 JPEW: sweet! i had been looking for an excuse to drop u-boot-rockchip ;-) Jan 23 16:44:53 tlwoerner, Not parsing is a good excuse :) Jan 23 16:45:05 JPEW: hmm... it doesn't look like any MACHINE was using it, i thought veyron-speedy had been using it Jan 23 16:45:43 * JPEW checks Jan 23 16:46:26 JPEW: wrt the MACHINE name, we could just use "rock-pi-4". the reason the other MACHINE names include the SoC is because the official names of the boards from the manufacturers included the SoC in the official names Jan 23 16:47:02 tlwoerner, OK, works for me. We have an internal policy to always name our machines with the SOC to keep ourselves sane :) Jan 23 16:48:53 JPEW: okay, i'm trying to use the official name from the manufacturer, which, i guess, technically, should be: "ROCK-Pi-4" Jan 23 16:49:10 https://wiki.radxa.com/Rockpi4 Jan 23 16:50:13 I'll rename to "rock-pi-4".... I seem to have a bad feeling about uppercase machine names... Jan 23 16:50:32 tlwoerner, Should we rename the tinker-rk3288 also? Jan 23 16:50:47 "tinker-board" probably Jan 23 16:51:57 JPEW: huh, yes (i hadn't noticed) Jan 23 16:52:36 Ok, I'll do that Jan 23 16:52:50 awesome, thanks :-) Jan 23 16:53:03 i'll do a test build and on-board test :-D Jan 23 16:54:20 by the way, i missed this week's yptm but i looked over the notes, what's the entry regarding "Several: University courses for YP?"? Jan 23 16:54:56 tlwoerner: people were wondering if anyone had explored that possibility Jan 23 16:55:54 i know someone here in Toronto who introduces OE/Yocto in a college-level course he teaches Jan 23 16:56:14 i'm not 100% if he is still teaching that course, or if the curriculum has changed Jan 23 16:58:59 tgamblin: any comments on this? ^^^ Jan 23 16:59:19 * RP has limited geographic knowledge here Jan 23 17:02:55 RP: tlwoerner: Do you have that professor's name and/or a link to their course page? I was thinking that with the right pitch, the universities here in Ottawa could potentially turn learning/contributing to Yocto into something akin to a capstone project Jan 23 17:03:36 tgamblin: yes, and we could get their students going on GSoC projects... hehehe Jan 23 17:03:49 RP: we're about 4 hours' drive from there (or worse, given typical traffic) Jan 23 17:04:05 i've emailed the professor in question to poke him for more info, i'll share it here if/when i hear back Jan 23 17:04:13 tlwoerner: sounds good to me Jan 23 17:11:35 Compared to some of the money they spend on hardware for things like CubeSat capstone projects, I'm sure buying a few Pi4s/Intel boards would be a viable alternative! Jan 23 17:58:11 tgamblin: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1485 Jan 23 18:15:11 RP: aha, interesting. So it doesn't see the wtmp log Jan 23 18:15:12 Thanks Jan 23 18:15:45 tgamblin: that could be musl specific, not sure Jan 23 18:16:04 RP: yeah, if you could keep it onboard for some more builds that would be helpful Jan 23 18:16:28 tgamblin: right, its in all of that -next build and I'll keep it around Jan 23 18:16:42 musl builds faster so fails first Jan 23 18:16:50 Right Jan 23 18:16:53 * RP is stepping afk for a bit but feel free to watch it Jan 23 18:17:09 https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/656 is the link to watch Jan 23 18:17:56 RP: will do, cheers Jan 23 18:24:20 when using DEPENDS_${PN} = "foo (>= 1.2)" I see both foo (>= 1.2) and foo (>= 1.2.5) in the pkgdata. Is this expected? Jan 23 18:24:32 the package was built against 1.2.5 Jan 23 18:24:41 but I only require >= 1.2 Jan 23 18:37:11 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/640 also caught the logrotate failure Jan 23 18:44:21 fullstop: DEPENDS != RDEPENDS. DEPENDS_${PN} does nothing at all Jan 23 18:44:49 Sorry that was a typo. I do have RDEPENDS_${PN} Jan 23 18:45:11 I feel like I'm doing the same as what usb-modeswitch-data does Jan 23 18:45:28 but I end up with two entries in the package instead of just the one. Jan 23 18:46:29 RP: so odd. I'm now seeing the qemumips64 boot stumble all the way through. and I didn't do anything but rebase. Jan 23 18:46:33 time to root cause .. Jan 23 18:56:37 I wonder if this has to do with soname stuff. Jan 23 18:56:58 my rdepends is a library but the modeswitch stuff is a package version. Jan 23 19:25:45 fullstop: the 1.2.5 entry i because of the magic soname deps Jan 23 19:25:49 does it really matter? Jan 23 19:26:21 rburton: that would force me to install 1.2.5 even if it is not technically required, yes? Jan 23 19:26:37 fullstop: correct, but you've just built 1.2.5 so is that a problem Jan 23 19:26:44 in my case, yes. Jan 23 19:27:15 These packages are distributed over a cell network, some of the data plans are only a few megabytes / month. Jan 23 19:28:25 i'd be looking at an alternative updater that doesn't care for package versions so much, using reproducible builds to reduce the changes etc. Jan 23 19:28:46 so the solution would be to override the shlibs so you can tell it explicitly not to need 1.2.5 but 1.2 is fine Jan 23 19:29:05 iirc, package.bbclass can't actually read from an override file, but it should be easy to add Jan 23 19:29:13 basically the design is the same as debian's Jan 23 19:31:01 I can add EXCLUDE_FROM_SHLIBS = "1" to the libraries in question and use RPROVIDES_${PN} to specify my own ABI information I guess. Jan 23 19:31:23 yeah, that's the hack Jan 23 19:31:31 the proper solution is neater, but needs more effort Jan 23 19:32:36 I'll poke around. There's not many libraries that I want to do this with. Jan 23 19:37:43 ugh anyone seeing ssh: Could not resolve hostname github.com: Temporary failure in name resolution Jan 23 19:38:51 khem: works here, https://www.githubstatus.com/ shows all good as well Jan 23 20:03:20 New news from stackoverflow: improve deployment time of yocto based development Jan 23 20:50:10 Hi. I have worked can0 with can1 on my yocto image. But every boot I have init cans with : ($ifconfig can0 up$ip link set can1 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000dsample-point 0.8 fd on). How can I configure that can0 and can1 up and start automatically with these settings after every boot? Jan 23 20:56:58 JPEW: ping Jan 23 21:02:31 denix: Ya, OE-core would be good. Probably needs an entry in maintainers.inc? Jan 23 21:09:05 JPEW: ah, keep forgetting about that... do you want to maintain it? :) what about SoB line - do you want it? Jan 23 21:11:39 denix: No need Jan 23 21:11:43 I can maintain it Jan 23 21:12:05 JPEW: can there be 2 maintainers? Jan 23 21:12:22 denix, not sure... Jan 23 21:17:14 JPEW: hmm, I guess I can do it for now, as it's been low-maintenance once we added our platforms upstream. I can always give it up, if I don't have time any more... :) Jan 23 21:17:39 denix, Sounds good :) Jan 23 21:23:10 JPEW: as I noticed you've already been doing a lot of stuff lately, so at least with this one I can help and take it off your plate... Jan 23 21:25:50 denix, thanks! Jan 23 21:29:18 Peopleof the Pi3 and Yocto Linux why does gqrx complain when I start it Jan 23 21:29:51 https://www.irccloud.com/pastebin/zUspGPuJ/ Jan 23 21:33:26 paulbarker: any hints, this is the fosdem demo :) Jan 23 21:47:34 RP: looks like mips64 with the latest updates in core is actually working. I wonder if the clock thing was related to glibc as well as the vdso kernel issues. anyway, I'm now only seeing one failure on my AB build. I'll send the queue for consideration tomorrow. Jan 23 21:47:40 https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/894 Jan 23 21:51:51 Hi. I have worked can0 with can1 on my yocto image. But every boot I have init cans with : ($ifconfig can0 up$ip link set can1 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000dsample-point 0.8 fd on). How can I configure that can0 and can1 up and start automatically with these settings after every boot? Jan 23 21:52:32 beratiks: Add them to /etc/network/interfaces Jan 23 21:55:17 JPEW: you mean add to builded rootfs? Jan 23 21:56:01 beratiks: Ya, you can write a recipe to do that if you want it to come up that way every time Jan 23 22:32:04 zeddii, that failure is a known issue so don't worry about it Jan 23 22:32:58 if you are referring to the the selftest. Jan 23 22:33:53 reproducible.ReproducibleTests.test_reproducible_builds: FAILED (3155.78s) Jan 23 22:50:48 nice! i'm happy to see other layer maintainers chiming in regarding multiple toolchains for one "MACHINE", and ATF things Jan 23 22:50:54 "it's SoCs all the way down...." Jan 23 22:50:59 lol Jan 23 23:04:40 tlwoerner: it's been a pain point for a while. multiconfig is promising - there were few discussions already in recent months... Jan 23 23:05:02 armpit. yah. cool. so that just leaves me with one issue that I mentioned before. I'll send my series. Jan 23 23:41:05 denix:whats missing with multiconfig ? Jan 23 23:41:52 SoC might have many compute units, and we should have capability to build software for anyone of them if desired Jan 23 23:43:24 khem: why do you say something is missing? Jan 23 23:43:31 so we could have SoCs like Dual CPU X86 + ARM application processor + 3 RISC-V MCUs + 1 MIPS FPGA Jan 23 23:43:44 khem: it's just relatively new, that's all Jan 23 23:43:46 you mentioned discussions Jan 23 23:43:52 why is it a warning to have a architecture-specific recipe contain a machine-specific package? Jan 23 23:43:54 ah ok Jan 23 23:44:21 btw. above SOC is something that exists :) Jan 23 23:45:25 mischief: architecture recipe can run on multiple kind of CPUs of that architecture, while machine is specific Jan 23 23:45:41 i know that Jan 23 23:45:57 ${PN} is a architecture package, a python program, but there's also a machine specific conf file Jan 23 23:46:12 so i made ${PN}-conf and make it ${MACHINE_ARCH} Jan 23 23:46:31 but i don't understand why the warning says i should make ${PN} also ${MACHINE_ARCH} Jan 23 23:46:38 because granularity is at recipe level not package level Jan 23 23:48:28 its best to divide it into two recipes, one which is allarch ( scripting stuff ) and one be machine_arch Jan 23 23:48:38 with appripriate rrecommends Jan 23 23:49:56 hm. well, the conf files and the python program come from the same repo Jan 23 23:50:08 what are the drawbacks of having two recipes point at the same git repo? Jan 23 23:50:11 repo is not the unit Jan 23 23:50:51 no drawbacks just that it will build another recipe so will duplicate source unpacks/pack Jan 23 23:51:46 slightly annoying, but okay Jan 23 23:53:55 yes it asks one to toe the line but there is a reason for that Jan 23 23:54:53 keeps package view sane, one can start abstracting on these lines and made components portable Jan 23 23:55:00 there are many advantages Jan 23 23:55:05 mischief: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/busybox/busybox-inittab_1.31.0.bb#n28 Jan 23 23:56:13 mischief: as khem said, PACKAGE_ARCH is for the entire recipe, unfortunately Jan 23 23:56:31 zeddii: glibc would be my best guess on that Jan 23 23:56:34 Hello. How do I changes to actual recipe 'bb' file Jan 23 23:57:05 *How do I make changes to actual recipe 'bb' file* Jan 23 23:57:19 I used devtool modify command on recipe name Jan 23 23:57:35 however it did not put the bb file for the recipe in the workspace for me to modify Jan 23 23:58:03 zeddii: good its resolved though! Jan 24 00:01:43 RP: hush hush, the bug might hear you talk Jan 24 00:02:39 kiwi_29: devtool edit-recipe Jan 24 00:04:03 RP: now that we have extended buildtools changes in, would it be possible to generate a 2.2 tarball and 1.6 tarball ? so we can build these releases on ubuntu 18.04 Jan 24 00:04:16 khem : thanks ! Jan 24 00:13:39 * khem finally seeing green builds for meta-openembedded after py2 expulsion Jan 24 00:22:49 khem: we'd need to backport but maybe Jan 24 00:23:18 to a branch or layer ? Jan 24 00:23:37 * armpit backport has too many meanings Jan 24 00:24:19 armpit: first all the changes RP did need to be in that branch Jan 24 00:24:46 then we can use them to generate buildtools tarballs, which we can then use on ubuntu 18.04 Jan 24 00:30:33 Khem, what i saw is "finally seeing green builds for meta-openembedded after py2 expulsion" then RP saying we need to backport Jan 24 00:30:43 so I am trying to clarify Jan 24 00:31:18 maybe missing context in reading Jan 24 00:33:43 armpit: your jump back loop is smaller :) Jan 24 00:49:59 no, just a small brain Jan 24 00:55:08 armpit: I suggest to not use PIE/PIC code **** ENDING LOGGING AT Fri Jan 24 02:59:58 2020