| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 00:54 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 01:11 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 01:25 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.159.151> has quit IRC | 01:38 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 01:39 | |
| *** camus <camus!~Instantbi@222.67.188.181> has joined #yocto | 01:39 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 01:40 | |
| *** camus is now known as kaspter | 01:41 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 01:58 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 02:11 | |
| *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined #yocto | 02:33 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 03:03 | |
| *** clopez <clopez!~tau@neutrino.es> has quit IRC | 03:04 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 03:05 | |
| *** clopez <clopez!~tau@neutrino.es> has joined #yocto | 03:06 | |
| *** sgw <sgw!~sgw@134.134.139.74> has joined #yocto | 03:17 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 03:37 | |
| *** Domin1k <Domin1k!c1669b04@193.102.155.4> has joined #yocto | 04:07 | |
| *** sgw <sgw!~sgw@134.134.139.74> has quit IRC | 04:08 | |
| *** georgem_ <georgem_!~georgem@216.21.169.52> has joined #yocto | 04:20 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 04:20 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:28 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:32 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:32 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:33 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 04:56 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 05:01 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 05:08 | |
| *** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC | 05:09 | |
| *** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto | 05:21 | |
| *** ECDHE_RSA_AES256 <ECDHE_RSA_AES256!~quassel@unaffiliated/ecdhe> has joined #yocto | 05:22 | |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC | 05:26 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 05:27 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 05:27 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:33 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 05:36 | |
| *** Domin1k <Domin1k!c1669b04@193.102.155.4> has quit IRC | 05:39 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 05:52 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 06:00 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 06:05 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 06:09 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 06:16 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 06:17 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 06:19 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 06:21 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:21 | |
| *** frsc <frsc!~frsc@200116b82436f300d4a878b0f423563c.dip.versatel-1u1.de> has joined #yocto | 06:22 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 06:23 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 06:24 | |
| *** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:25 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:34 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 06:35 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 06:39 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 06:42 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:49 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 06:59 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:06 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has quit IRC | 07:08 | |
| RP | JPEW: that does seem to have helped... | 07:14 |
|---|---|---|
| *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has quit IRC | 07:21 | |
| *** yacar_ <yacar_!~yacar@87-88-162-38.abo.bbox.fr> has joined #yocto | 07:22 | |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto | 07:25 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 07:28 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 07:31 | |
| *** kanavin_ <kanavin_!~kanavin@141.113.67.203> has quit IRC | 07:31 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 07:36 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:38 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:40 | |
| *** mckoan|away is now known as mckoan | 07:49 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yldgakqlswxgvrhd> has joined #yocto | 07:58 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 08:00 | |
| yocti | New news from stackoverflow: YOCTO : How to add LIBSOC library to my Linux image <https://stackoverflow.com/questions/58112136/yocto-how-to-add-libsoc-library-to-my-linux-image> | 08:05 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:07 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 08:10 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 08:11 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 08:14 | |
| alessioigor | jwessel: ping | 08:17 |
| alessioigor | jwessel: I would like merge our patches but I don't have idea how to do it: I never did it before. Could you help me, please? | 08:19 |
| *** Saur <Saur!pkj@nat/axis/x-kuvdaoaeglpurope> has quit IRC | 08:25 | |
| *** yacar_ <yacar_!~yacar@87-88-162-38.abo.bbox.fr> has quit IRC | 08:29 | |
| yocti | New news from stackoverflow: How to run a shell script while compiling a recipe in Yocto <https://stackoverflow.com/questions/55572567/how-to-run-a-shell-script-while-compiling-a-recipe-in-yocto> || Node-red with Yocto Os <https://stackoverflow.com/questions/58112222/node-red-with-yocto-os> | 08:35 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:40 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:45 | |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has joined #yocto | 08:49 | |
| RP | alessioigor: apply both in your git tree, then "squash" them. I find "git rebase -i" helpful | 08:53 |
| alessioigor | RP: Thanks for help. Could you suggest me how "squash" commit messages, please? How I should do with the two Signed-off-by? | 09:05 |
| LetoThe2nd | RP: rebase -i FTW | 09:05 |
| RP | alessioigor: edit the message so that it includes details for both commits and probably include both signoffs in this case (since I know which commits these are) | 09:13 |
| RP | alessioigor: you could just send both patches in series | 09:13 |
| alessioigor | RP: I would prefer "squash" to avoid noise during a hypothetical bisect session. | 09:15 |
| * alessioigor hopes to have done a good job squashing the two commits... | 09:39 | |
| RP | alessioigor: fair enough | 09:40 |
| alessioigor | RP: Thanks | 09:40 |
| iceaway_ | In our production boards, we want a root filesystem that we keep as small as possible, but a large data partition. I would prefer not to include this data partition in the .wic-image, as it does not make sense to write 15GB of nothing in production. Would it be sensible to instead have a script that runs at startup, which checks if the partition is there, and if not, creates and formats it on the fly? | 09:48 |
| iceaway_ | Is there any kind of support for this in Yocto/POky? | 09:48 |
| *** iceaway_ <iceaway_!~pelle@37.233.78.69> has quit IRC | 09:49 | |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has quit IRC | 09:49 | |
| iceaway | Strange, I managed to have two simultaneus connections to freenode. No wonder my nickname was "busy". | 09:49 |
| LetoThe2nd | iceaway: that would just be a neatly written systemd unit | 09:50 |
| LetoThe2nd | probably with something like Before=mount.service or such | 09:50 |
| iceaway | LetoThe2nd: Sounds reasonable. Not using systemd at the moment though, but I guess a regular init script would work as well? | 09:51 |
| LetoThe2nd | or WantedBy=local-fs.target | 09:51 |
| LetoThe2nd | iceaway: whatever, it'd just advise to make sure it really runs and is checked before the usual mount mechanisms kick in | 09:52 |
| iceaway | LetoThe2nd: Yes will check that! | 09:52 |
| iceaway | THanks! | 09:52 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:57 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:02 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 10:03 | |
| yocti | New news from stackoverflow: yocto jetson nano image with nvidia sdk binaries: Unable to find file cuda-repo-ubuntu1604-10-0-local-10.0.326-410.108_1.0-1_amd64.deb <https://stackoverflow.com/questions/58114143/yocto-jetson-nano-image-with-nvidia-sdk-binaries-unable-to-find-file-cuda-repo> || How to conditionally install and ship files in yocto bb recipe? <https://stackoverflow.com/questions/58114055/how-to-conditionally-install-and-ship-files-in-yocto-bb-recipe> | 10:05 |
| *** Saur <Saur!pkj@nat/axis/x-uienismpsqbfwfai> has joined #yocto | 10:12 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 10:17 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 10:20 | |
| *** learningc <learningc!~learningc@121.121.98.53> has joined #yocto | 10:34 | |
| yocti | New news from stackoverflow: Unable to stream RTSP from VLC on Yocto-based distribution <https://stackoverflow.com/questions/58114822/unable-to-stream-rtsp-from-vlc-on-yocto-based-distribution> | 10:35 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:36 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:37 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 11:00 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 11:01 | |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has joined #yocto | 11:04 | |
| *** vlo86 <vlo86!551700fe@85-23-0-254.bb.dnainternet.fi> has joined #yocto | 11:13 | |
| yocti | New news from stackoverflow: How to fix error 501 while using yocto build tool? <https://stackoverflow.com/questions/57957722/how-to-fix-error-501-while-using-yocto-build-tool> | 11:35 |
| *** MiskaX <MiskaX!zkm6aym95u@2001:2060:72::3> has quit IRC | 11:36 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:39 | |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 11:43 | |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 11:44 | |
| vlo86 | A very basic question for which I could not find a direct answer by googling. I'm trying to add cmake to my image. I've added "inherit cmake" to the app recipe, and "IMAGE_INSTALL_append = " cmake cmake-native"" to /build/conf/local.conf. When baking the image I'm getting an error: "console-image.bb rdepends upon non-existent task | 11:44 |
| vlo86 | do_package_write_ipk in poky-thud/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb". If I remove the IMAGE_INSTALL_append directive, bitbake claims "cmake: command not found". Any advice would be appreciated =) | 11:44 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:45 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:46 | |
| LetoThe2nd | vlo86: you are mixing up things. IMAGE_INSTALL += "cmake" adds cmake to the image. inherit cmake in a recipe says that this recipe need cmake for its build and install process. and thrid, adding cmake-native to IMAGE_INSTALL is outright wrong. | 11:47 |
| vlo86 | So stating IMAGE_INSTALL_append = " cmake" should be enough in my local.conf? | 11:48 |
| LetoThe2nd | vlo86: to get cmake on the target, yes. not that cmake by itself is of much use on the target, and generally compiling in-target is ... meh.. but yes. | 11:49 |
| vlo86 | Right, I guess my first problem was the "cmake: command not found" during bitbaking/cross-compiling my library. So I ended up trying to add cmake to my image to see whether that helps. | 11:51 |
| LetoThe2nd | vlo86: outright wrong that sounds, young padawan | 11:51 |
| vlo86 | Learning all the time =) | 11:51 |
| thomasd13 | Whats the proper way to update an eSDK installation? Should I just rm the previous installation directory, and installing the new one? | 11:53 |
| PinkSnake | thomasd13 install the new SDK in the same path | 11:55 |
| thomasd13 | PinkSnake without removing the previous one before? | 11:56 |
| PinkSnake | thomasd13 The script will ask you if you want to :) | 11:56 |
| PinkSnake | just make a try ;) | 11:57 |
| thomasd13 | Cool ;) thank you | 11:57 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:03 | |
| fullstop | Is there any sort of guide on adding a boring makefile shared library recipe? I've gone through the documentation and have my shared library building with -Wl,-soname= and that all seems to work. My library is libname.so.1.0 and do_compile creates a symlink from that to libname.so. During package qa, though, somehow the -dev package has libname.so as the shared library and not the symlink, causing the build to fail. | 12:06 |
| fullstop | I'm not trying to do rocket surgery here, it's a really simple makefile | 12:06 |
| LetoThe2nd | fullstop: simple makefiles are often rocket science, because they often break crosscompiling in awful ways | 12:07 |
| fullstop | LetoThe2nd: These particular makefiles, oddly enough, have _only_ been used to cross compile. | 12:08 |
| LetoThe2nd | fullstop: i'd say, look at the "adding a new recipe" section in the dev or ref manuel (can't remember which one), there is a makefile recipe example | 12:08 |
| fullstop | It's not building it for the wrong arch.. I'm just not understanding what yocto wants. | 12:08 |
| LetoThe2nd | fullstop: hence, look at the example :) | 12:08 |
| *** coretec <coretec!d43ed5a2@212.62.213.162> has joined #yocto | 12:09 | |
| fullstop | If I remember correctly that example is for a binary and not a library, but I'll check again. | 12:09 |
| *** anujm <anujm!~anujm@134.134.139.76> has joined #yocto | 12:11 | |
| coretec | Hi, i have a question regarding yocto 2.7 (Warrior). | 12:11 |
| coretec | The mega-manual states under 24.9.11 "ADT Removed: The Yocto Project Eclipse IDE Plug-in is still supported and is not affected by this change." | 12:12 |
| coretec | However under 24.15.2 it states: "Eclipse™ Support Removed". | 12:12 |
| coretec | Which one is correct, or am i missinterpreting these statements? | 12:12 |
| kroon | fullstop, I'd assume its the do_install that should create the symlink, no ? | 12:12 |
| thomasd13 | coretec I tried to work with Eclipse ADT - Got no success | 12:12 |
| fullstop | kroon: yes, it does, although I believe that it could happen at the end of do_compile as well. | 12:12 |
| LetoThe2nd | coretec: if in doubt, consider anything eclipse related as unsupported and nonfunctional | 12:13 |
| LetoThe2nd | coretec: there are reports now and then of people making it work, but do not *expect* it. officially, it has been deprecated. | 12:13 |
| coretec | LetoThe2nd why is this the case ? I find this a very handy feature for some of my users. | 12:13 |
| LetoThe2nd | coretec: insert coin | 12:13 |
| LetoThe2nd | coretec: there have been many attempts to find somebody who actually maintains and supports it over the years, and all failed. hence, the emergency brake has been pulled. | 12:14 |
| thomasd13 | coretec which advantages does the ADT-plugin offer? | 12:15 |
| fullstop | This is probably important, and it's something that I don't understand: WARNING: libblock-1.0-r0 do_package: libname-dev-1.0 was registered as shlib provider for libname.so.1.0, changing it to libname-1.0 because it was built later | 12:15 |
| coretec | @Leto | 12:15 |
| coretec | LetoThe2nd: Thank you for the clarification | 12:15 |
| LetoThe2nd | coretec: yw. | 12:15 |
| fullstop | cat's out of the bag, package is actually called libblock, I was trying to keep that anonymous for some reason. | 12:15 |
| coretec | thomasd13: Well my application developers seem to be unable to work without eclipse or any other full feature IDE :) | 12:17 |
| LetoThe2nd | coretec: then either hire sombody to make things work for them, or invest in training them to use other tools :) | 12:18 |
| thomasd13 | coretec I setup Eclipse in such a way that it works with eSDK together. For on target debugging, I wrote a script which deploys the executable on the target and start a gdbserver | 12:20 |
| coretec | LetoThe2nd: Well yeah, guess i have to | 12:20 |
| thomasd13 | I don't know if this is enough or ADT offered more | 12:20 |
| coretec | thomasd13: what do you mean by eSDK ? | 12:21 |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has quit IRC | 12:21 | |
| thomasd13 | extensible sdk | 12:21 |
| coretec | thomasd13: and i think ADT is also deprecated, its only the SDK now right | 12:21 |
| fullstop | okay, I think that I see what is going on. How do I keep .so files out of the -dev package? How does the build system know which files to put in -dev? | 12:24 |
| LetoThe2nd | fullstop: usually by setting FILES_${PN}-dev and FILES_${PN} accordingly | 12:25 |
| LetoThe2nd | fullstop: yet i'd say this means that the install stage of that lib is b0rk3d | 12:25 |
| fullstop | Well, the install stage is done entirely in do_install() since there is no "install" target in the makefile | 12:26 |
| fullstop | so if it's borked I've borked it myself | 12:26 |
| qschulz | fullstop: FILES_${PN} has libdir/*.so.* and FILES_${PN}-dev has libdir/*.so IIRC | 12:26 |
| fullstop | qschulz: are -dev packages supposed to have shared libraries in them? | 12:27 |
| qschulz | I think the point is PN has the shared library and -dev has the symlink .so to .so.x.y.z | 12:27 |
| fullstop | and PN does not have a symlink? | 12:28 |
| qschulz | SOLIBS, SOLIBSDEV, FILES_SOLIBSDEV is what is handling this | 12:28 |
| qschulz | well it can, but it can't be named lib*.so and not in libdir | 12:29 |
| qschulz | by default | 12:29 |
| fullstop | so confusing | 12:29 |
| qschulz | you could technically have N different versions of the same library on the system | 12:29 |
| qschulz | if all of them installed lib*.so symlink, Yocto wouldn't know which one to take | 12:30 |
| fullstop | got it | 12:30 |
| fullstop | maybe. :-) | 12:31 |
| *** learningc <learningc!~learningc@121.121.98.53> has quit IRC | 12:32 | |
| fullstop | I created the symlink during the do_install phase but did not install it to libdir.. this built and packaged without warning/error, but the -dev package has no symlink. | 12:32 |
| *** georgem_ is now known as georgem | 12:32 | |
| qschulz | fullstop: could you explain again your issue then :)? | 12:40 |
| fullstop | haha, give me a second.. let me see if my latest change actually worked or not. | 12:40 |
| fullstop | I'm on warrior if this makes a difference | 12:40 |
| fullstop | okay, failed again. One second. | 12:41 |
| fullstop | okay, here's the recipe (somewhat made anonymous): https://pastebin.com/raw/Ku3kGuZC | 12:43 |
| fullstop | the FILES_ lines are new | 12:43 |
| fullstop | The makefile builds lib/libblock.so.1.0 in S, with the soname set correctly in the elf headers | 12:44 |
| fullstop | And, in short, I just want this thing to build so that I can use this library with other recipes. | 12:45 |
| fullstop | when I set FILES_${PN}-dev to include lib*.so the symlink is .. ignored? It ends up being the actual library and not a symlink. | 12:47 |
| LetoThe2nd | i just want a dollar for each time i hear "i jsut want ..." in here :) | 12:48 |
| fullstop | I'm coming from buildroot, so the GIT_VERSION thing isn't right just yet, it will eventually pop the git hash into the source. | 12:48 |
| qschulz | LetoThe2nd: everything is always supposed to be simple in people's mind :) (at least always in mine, and then it's not simple at all :D) | 12:48 |
| *** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 12:48 | |
| fullstop | LetoThe2nd: :-) | 12:48 |
| fullstop | I understand that it's not simple, but I also don't want it to be magic. | 12:49 |
| LetoThe2nd | fullstop: as usual bitbake -e is your friend | 12:49 |
| LetoThe2nd | fullstop: i guess things jsut are not what you think in reality | 12:49 |
| fullstop | Isn't that how learning works? | 12:49 |
| qschulz | fullstop: SOEXT=".so" is that expected? | 12:50 |
| fullstop | qschulz: let me see if that is still used. | 12:50 |
| qschulz | what I expect is that this line creates a libblock.so AND a libblock.so.x.y with SONAME= | 12:50 |
| qschulz | then, ln -s ${PN}.so.${PV} lib/${PN}.so is a noop | 12:50 |
| fullstop | It's not used by my makefile | 12:50 |
| JPEW | RP: Perhaps report_unihash should raise bb.fatal if the tid is not in self.setscenetasks? | 12:51 |
| fullstop | back up a sec.. | 12:51 |
| fullstop | oe_runmake should create libblock.so (symlink) and libbloxk.so.x.y, yes? | 12:51 |
| qschulz | does your Makefile create those? | 12:52 |
| fullstop | no. It creates libblock.so.x.y | 12:52 |
| fullstop | and I took care of the symlink in do_install | 12:52 |
| fullstop | but I can easily have the makefile create the symlink if that actually makes a difference. | 12:52 |
| qschulz | well, apparently not since it's not a symlink :D | 12:52 |
| fullstop | It is a symlink, though. | 12:52 |
| fullstop | 15 Sep 26 08:41 libblock.so -> libblock.so.1.0 | 12:53 |
| fullstop | it's only when it's added to the -dev package when it is suddenly not. | 12:53 |
| qschulz | ah fuck | 12:53 |
| qschulz | what does install do on a symlink? | 12:53 |
| fullstop | seriously | 12:53 |
| qschulz | does it copy the symlink or the reference? | 12:53 |
| fullstop | let me do it manually and see | 12:54 |
| fullstop | the reference | 12:54 |
| fullstop | so I need to cp instead of install? | 12:54 |
| qschulz | not necessarily | 12:55 |
| qschulz | you can use ln to install the symlink directly in ${D} | 12:56 |
| qschulz | fyi, you might hit errors wrt to how symlinks are handled in Yocto. https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#migration-2.3-absolute-symlinks | 12:56 |
| qschulz | not everything will work | 12:56 |
| qschulz | from what I gather, ln -s ${PN}.so.${PV} ${D}{libdir}/${PN}.so should work | 12:58 |
| qschulz | (you don't need a '/' between ${D} and ${libdir} or ${includedir} btw :) | 12:58 |
| qschulz | https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf | 12:59 |
| fullstop | right, I had the absolute symlink error before, that's how I got this far. | 12:59 |
| fullstop | I have to say ${D}${libdir} doesn't look as nice as ${D}/${libdir} | 13:00 |
| *** coretec <coretec!d43ed5a2@212.62.213.162> has quit IRC | 13:00 | |
| qschulz | fullstop: matter of taste, I hate seeing paths in logs with two // :) | 13:00 |
| fullstop | :-) | 13:01 |
| *** ECDHE_RSA_AES256 is now known as ecdhe | 13:03 | |
| fullstop | qschulz: LetoThe2nd: thanks for the help, it's behaving as expected now. | 13:04 |
| fullstop | thanks for putting up with me. :-) | 13:04 |
| RP | JPEW: just realised we have a problem with the way the mixin interacts with the OE-core class extension | 13:06 |
| rburton | fullstop: ever considered using a proper build system instead of bare make? :) | 13:07 |
| fullstop | rburton: bah! I've used the same makefile for years now! | 13:07 |
| rburton | well if its not a versioned library you don't need to install a symlink, its just that FILES* defaults to assuming versioned and symlinks | 13:08 |
| rburton | as that's typical | 13:08 |
| fullstop | I understand now that I had two ways of getting past this. Three if you count changing from make. | 13:09 |
| fullstop | I have a love/hate relationship with cmake right now. | 13:09 |
| rburton | easiest is to write a makefile that behaves like a typical library: install libfoo.so.1, libfoo.so symlink, etc. | 13:10 |
| rburton | soname, version, etc. | 13:10 |
| rburton | then if you do switch to a proper build system you can do it seamlessly, and everyone else who sees your library knows what to expect. | 13:10 |
| rburton | if you want to keep it unversioned then https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries is useful | 13:11 |
| fullstop | thanks, rburton | 13:12 |
| rburton | i endorse meson if you want to replace make ;) | 13:12 |
| qschulz | rburton: let me jump on the library train then :) | 13:12 |
| RP | JPEW: its a class inheritance order problem: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=d14ae9db270897bc8df7606b8c38277c7424caf3 | 13:13 |
| *** vmeson <vmeson!~rmacleod@dhcp-108-168-104-98.cable.user.start.ca> has joined #yocto | 13:13 | |
| qschulz | rburton: we have recipe A with a binary which has NEEDED libasound.so but in recipe alsalib we have only libasound.so.x.y.z which is provided | 13:13 |
| qschulz | For me, this is the opposite as what's explained in the link you pasted, right? | 13:14 |
| rburton | qschulz: that NEEDED is wrong | 13:14 |
| rburton | how did that happen | 13:14 |
| rburton | the linker will follow symlinks to get the full versioned name | 13:14 |
| RP | JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=709c6c1be4189853cea808b883ef1dd93700e96d is a bigger issue on how we handle this :/ | 13:15 |
| RP | JPEW: currently its writing out junk filenames, this fixes that but opens a new barrel of problems | 13:15 |
| JPEW | RP: oj? | 13:15 |
| JPEW | RP: oh? | 13:15 |
| qschulz | rburton: tell that to the ultra big corporation who sent us this binary, they do it for almost all their NEEDED :) | 13:16 |
| rburton | they're idiots | 13:16 |
| qschulz | is it really? | 13:17 |
| rburton | its a horrible way of avoiding version conflicts but assumes you'll have dev packages installed | 13:17 |
| RP | JPEW: should sigdata files show unihashes or task hashes? | 13:17 |
| qschulz | rburton: exactly, how is it handled normamlyl this kind of conflicts? | 13:17 |
| rburton | closed source blob i presume? | 13:17 |
| qschulz | rburton: yes | 13:18 |
| rburton | i'd start with 1) moan at vendor | 13:18 |
| JPEW | RP: Are you talking about the text dump of the hash contents? Unihash I would expect. | 13:18 |
| rburton | i wonder if you can tweak the linkage | 13:18 |
| qschulz | What is the proper way for people providing binaries to avoid version conflicts? (I'm curious now :)) | 13:19 |
| RP | JPEW: right, but then the computed value and the actual hash don't match which is confusing | 13:19 |
| rburton | qschulz: the binaries should have defined version needs. its not like libasound.so has been changing hugely over the years. | 13:20 |
| JPEW | RP: In the name of the file? | 13:20 |
| RP | JPEW: and/or its contents | 13:20 |
| qschulz | rburton: that would mean a binary per combination of NEEDED library versions right? | 13:20 |
| rburton | qschulz: many libraries don't actually change their library version that much | 13:20 |
| qschulz | for this company, that is absolutely not scalable. | 13:20 |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has joined #yocto | 13:21 | |
| RP | zeddii: around? How long will we need to get that ppc fix in from stable? | 13:22 |
| qschulz | rburton: back to Yocto :) I could patchelf the thing in Yocto but it feels not right. | 13:24 |
| tgamblin | rburton: I'm combing over the systemd.bbclass file regarding the nativesdk bug we've been discussing via email. I see a commit from khem last month that changed the way the do_install[postfuncs] to limit their use to target (not native) builds, but I'm not 100% on what the right fix would be to avoid effectively reverting what khem did | 13:25 |
| rburton | tgamblin: run it for target and nativesdk? | 13:26 |
| JPEW | RP: The dependent task hashes in the sigdata are already unihash... I'd lean toward naming the sigdata with the unihash also. Perhaps there is a way we can make it easy to cross reference for users (symlinks or the like?) | 13:26 |
| rburton | tgamblin: or reverse the logic: RMINITDIR_class-native = "" | 13:27 |
| RP | JPEW: we perhaps should write the unihash and the hash to the files | 13:27 |
| tgamblin | rburton: the latter sounds cleaner. I'll have a look at that | 13:28 |
| JPEW | RP: Ya, that would work too.... those aren't ever actually hashed in their entirety correct (i.e. adding more things won't change the actual hashes)? | 13:29 |
| RP | JPEW: the data is pulled out so no, we're free to add data | 13:30 |
| JPEW | RP: I can work up a patch to do that if you want | 13:31 |
| khem | rburton: tgamblin I dont think extending it to anything besides target makes sense | 13:32 |
| rburton | iirc, systemd isn't enabled in nativesdk distro features so that purge code would go and clean the files away, which is what we want | 13:33 |
| khem | are we shipping system services in nativesdk that should be run on sdk host ? | 13:33 |
| rburton | there are recipes that ship service files that don't serve any purpose in a nativesdk | 13:33 |
| rburton | and we can either 1) delete them in every recipe or 2) just make the class remove them | 13:33 |
| RP | JPEW: I think we need to look into that, the patches in -next show its fragile | 13:34 |
| khem | I see, ok I was thinking that we want to ship them which would be disaster | 13:34 |
| RP | JPEW: also can we please fix the module error when the hashserv connection fails? :) | 13:34 |
| JPEW | RP: Yes | 13:35 |
| *** vmeson <vmeson!~rmacleod@dhcp-108-168-104-98.cable.user.start.ca> has quit IRC | 13:35 | |
| tgamblin | khem: my original patch was to have the dnf recipe remove them, but rburton pointed out that multiple recipes experience it, meaning a fix for the systemd.bbclass file instead | 13:36 |
| khem | rburton: so what we then do is enforce sysvinit for nativesdk always ? | 13:36 |
| tgamblin | err, the dnf fix would add them, rather | 13:36 |
| rburton | khem: there's no need for service files in nativesdk at all | 13:36 |
| rburton | so i wouldn't be surprised if the init scripts are being deleted already | 13:36 |
| RP | JPEW: I did spot one other problem - the keys in unitaskhashes have the full paths in - which is why the eSDK ignores them | 13:37 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:38 | |
| khem | rburton: yes thats what I thought but my only concern is that it starts accounting for hashes to rebuild nativesdk-llvm etc when DISTRO_FEATURE changes from sysvinit to systemd | 13:38 |
| rburton | the distro features for nativesdk is tightly controlled | 13:38 |
| rburton | DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr" | 13:39 |
| rburton | DISTRO_FEATURES_NATIVESDK ?= "x11" | 13:39 |
| rburton | so not sure how changing the features caused a rebuild of native code | 13:39 |
| khem | in that case I think add RMINITDIR_class-nativesdk = " rm_sysvinit_initddir rm_systemd_unitdir " | 13:39 |
| RP | JPEW: patch for that is ready for testing | 13:40 |
| khem | inverting the logic would enable it for cross classes as well so thats not good so lets be surgical | 13:40 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 13:41 | |
| tgamblin | Makes sense to me | 13:41 |
| tgamblin | I'll test it then cc you guys on the patch | 13:42 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:46 | |
| rburton | thanks | 13:47 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 13:47 | |
| tgamblin | thanks for the clarification! | 13:48 |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 13:50 | |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 13:51 | |
| *** thomasd13 <thomasd13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 13:51 | |
| khem | tgamblin:I would like you to try a case where you replace systemd with sysvinit in DISTRO_FEATURES and see what all ends up rebuilding especially in nativesdk recipes | 13:52 |
| khem | typical case I have is nativesdk-clang | 13:52 |
| rburton | maybe we shoud have a selftest for that | 13:52 |
| khem | does this cause it to rebuild | 13:53 |
| rburton | toolchain shouldn't rebuild with distro feature changes | 13:53 |
| khem | it shouldn't but it did atleast the native case was causing clang-native to rebuild | 13:53 |
| khem | so now it would be prudent to check if this would now happen for nativesdk | 13:54 |
| khem | as well if we re-add the post funcs | 13:54 |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has quit IRC | 13:55 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 13:55 | |
| tgamblin | alright | 13:56 |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 13:56 | |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 13:57 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 14:06 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:08 | |
| JPEW | RP: I think I might set the hashserver timeout to 20 seconds by default for better user experience. Does that sounds OK? You might need to change it on the AB | 14:09 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:09 | |
| RP | JPEW: yes, I'm ok with that | 14:12 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 15:00 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 15:02 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 15:07 | |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto | 15:07 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 15:08 | |
| kpo | hey, I've got a question - I need to add secondary (e.g. gid >= 1000) group "users" with bitbake, however after inheriting extrausers and adding GROUPADD_PARAM += "users" it creates group "users" with gid 100. Is there any way to explicitly tell extrausers to add group with some gid? | 15:11 |
| fray | you can specify int eh parameters to groupadd exactly what you want/need | 15:12 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 15:12 | |
| fray | I believe you can do users -g 1000 | 15:14 |
| kpo | thanks fray, checking it out right now - will report back :) | 15:14 |
| kpo | i missed -g, and wrote "users 1000", probably that was it | 15:15 |
| kpo | a few minutes for build and I'll get back | 15:16 |
| qschulz | why is ntp taking ages to compile and install? I gathered that it's doing a config.status --recheck in both tasks and it takes really an awfully big amount of time... why is this needed in the first place since it's done in configure? | 15:24 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 15:29 | |
| kpo | fray: unfortunately it didn't work - I'm on thud btw | 15:31 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 15:31 | |
| kpo | i've tried gid 1000 and 3000, no difference - cat /etc/group | grep users shows 100 :( | 15:31 |
| kpo | however, when I run "groupadd users2 -g 3000" on the running system it works perfectly | 15:33 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 15:35 | |
| *** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-kjtoabvdmpipkelq> has quit IRC | 15:41 | |
| RP | zeddii: around? | 15:42 |
| rburton | qschulz: sounds like ntp is broken | 15:42 |
| *** kanavin <kanavin!~kanavin@141.113.64.159> has joined #yocto | 15:42 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 15:45 | |
| *** yacar_ <yacar_!~yacar@vel78-h03-87-88-162-38.dsl.sta.abo.bbox.fr> has quit IRC | 15:48 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 15:54 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 15:57 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 16:00 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 16:05 | |
| *** vlo86 <vlo86!551700fe@85-23-0-254.bb.dnainternet.fi> has quit IRC | 16:09 | |
| *** vlo86 <vlo86!551700fe@85-23-0-254.bb.dnainternet.fi> has joined #yocto | 16:10 | |
| alessioigor | I'll receive a board with two type of CPU (a big Intel CPU and a little ARM cpu) soon. Is it possible to produce an image with both compilers? | 16:11 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:40e0:1cd6:848:14bf> has quit IRC | 16:13 | |
| *** vlo8695 <vlo8695!551700fe@gateway/web/cgi-irc/kiwiirc.com/ip.85.23.0.254> has joined #yocto | 16:16 | |
| *** mckoan is now known as mckoan|away | 16:17 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:23 | |
| __angelo | hi, i have a module built from yocto, in recipes-kernel/linux/mymodule.bb and would like to apply patch only for a certain version of kernel, is this possible ? | 16:26 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:29 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 16:29 | |
| zeddii | __angelo, not easily. that's why out of tree modules can be problematic. best to just make the code check the version in the code and use the version #ifdefs | 16:31 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 16:32 | |
| zeddii | but if you are inheriting (directly or indirectly) linux-kernel-base, it does have get_kernelversion_headers | 16:37 |
| RP | zeddii: got a second to talk about this ppc issue? | 16:38 |
| zeddii | i'm sitting in a conference room @ Linaro Connect, and will have to present a demo in a few minutes. but until they call on me, I'm here :D | 16:39 |
| qschulz | rburton: wdym? in general or on my local builds? | 16:39 |
| zeddii | RP is the ppc issue the fsl one that I saw bugzilla updates about ? | 16:40 |
| RP | zeddii: I see you replied in the bug | 16:40 |
| RP | zeddii: sorry, I'm behind now :) | 16:40 |
| RP | zeddii: that leaves the strace issue, did you get anywhere with that? | 16:41 |
| zeddii | not a solution, but I was interruped. I've talked to a few people about it here, so I have some ideas to try (I fly home tonight). | 16:41 |
| RP | zeddii: ok. These issues block M4 and M4 is next week which is why I'm asking questions | 16:42 |
| zeddii | I haven't been getting any optimistic feedback about a really quick solution, but I'll write something up ASAP. | 16:42 |
| RP | zeddii: thanks | 16:42 |
| RP | zeddii: meanwhile I'll get the stable updates tested | 16:42 |
| *** litb <litb!~js@pd907fca9.dip0.t-ipconnect.de> has joined #yocto | 16:43 | |
| litb | is it correct that .bbappend files must be in the same directory as those .bb files that are appended | 16:43 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:43 | |
| RP | litb: no | 16:43 |
| litb | i.e a recipes-extended/foo/foo.bb file can only be appended by a recipes-extended/foo/foo.bbappend ? | 16:43 |
| litb | somewhere I think I read that | 16:43 |
| RP | its wrong | 16:44 |
| litb | I wanted to do a appends/recipes-*/*/*.bbappend folder because I find it's clearer if one knows all appends are at a single place and not scattered around | 16:45 |
| litb | is this a good idea? | 16:45 |
| zeddii | RP: but since that issue is with the fsl board, we need to bump the SRCREVs for the reference boards, I didn't send that, but can .. I just can't boot them. | 16:45 |
| zeddii | but the patch is definitely in my tree. | 16:45 |
| RP | zeddii: if you could please, we should probably just bump and test they build... | 16:45 |
| zeddii | yup. my script can do it. So I'll do it and send it. | 16:46 |
| litb | the problem is that PAM's sshd and PAM's su file don't load the pam_limits.so . So I need a bbappend to modify those files before they get packaged | 16:46 |
| RP | zeddii: thanks | 16:46 |
| fray | litb, this is how I've done it in the past. Edited the components via a bbappend and make sure that bbappend only modifies if my custom distribution is enabled.. | 16:47 |
| fray | that conforms to the YP best practices and keeps things clearly as 'your' change | 16:48 |
| fray | I do wish we had a better way to handle those sort of configuration files, but I don't know of one at this point. | 16:48 |
| litb | fray, ah so far I'm not checking whether my distribution is enabled | 16:53 |
| fray | ya, so any user of your layer will get your change (unconditionally) which can cause issues and is not best practice.. | 16:53 |
| fray | What I usually do is something like.. (looking for an example) | 16:53 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:54 | |
| fray | http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/tree/recipes-connectivity/openssh | 16:54 |
| fray | look at the openssh_8.%.bbappend .. it uses a system conditition to determine to active or not, which then pulls in nothing or openssl_fips.inc file | 16:54 |
| fray | in thi case, it's using just a variable.. | 16:54 |
| fray | but with your own distro, you could select on the distro name (part of the distro name) or a distro feature.. | 16:55 |
| fray | (or an override even) | 16:55 |
| zeddii | RP: sent. you'll see there are two patches. the fix we want is in with the v5.2.17, and I didn't want the reference boards ahead of qemu*, so I sent one to oe-core the other to yocto. but they are both 5.2.17 | 16:57 |
| zeddii | and have the fix | 16:57 |
| litb | fray, ah thanks | 17:00 |
| litb | I see that you put your override in a "normal" recipes-folder | 17:00 |
| litb | would you see it as bad idea to put all overrides below a "appends/" folder? (and put appends/ in BBFILES in the layer conf) | 17:01 |
| fray | that will work, but it makes it harder for somone new to come in and find the tiems.. if you use the same structure as the layer (recipes) you are appending, it's been easier to maintain in mye xperience.. | 17:01 |
| fray | I have seen cases where people do: | 17:01 |
| fray | recipes-.../recipe.bb and appends/recipe-.../recipe.bbappend | 17:01 |
| fray | so they've moved appends, but they keep the diretory structure.. but it's much more rare then the regular case | 17:02 |
| litb | ah I see. I'll stick with the regular rules then. | 17:02 |
| * litb undoes his git mv .. | 17:02 | |
| fray | there is another case BTW.. if you may be bbappending layers that are optional.. | 17:03 |
| fray | appending -to- layers.... | 17:03 |
| fray | you need to use a dynamic configuration for that | 17:03 |
| fray | https://github.com/WindRiver-OpenSourceLabs/wrlinux/tree/master-wr | 17:03 |
| fray | you can see the 'dynamic-layers' directory, under that is a directory per 'optional' layer.. and then regular structure under that | 17:04 |
| fray | https://github.com/WindRiver-OpenSourceLabs/wrlinux/blob/master-wr/conf/layer.conf | 17:04 |
| fray | that shows how to setuo the 'BBFILES_DYNAMIC' | 17:04 |
| litb | dynamic layers? head explodes. still need to look into that | 17:05 |
| fray | ya, in that (complex) example.. meta-gnome [gnome-layer] is optional.. but if it's there, the distro configures things in it | 17:06 |
| litb | nice! | 17:07 |
| litb | fray, this sentence in the manual appears to be broken: "Use the BBFILES_DYNAMIC variable to avoid .bbappend files whose corresponding .bb file is in a layer that attempts to modify other layers through .bbappend but does not want to introduce a hard dependency on those other layers." | 17:12 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 17:12 | |
| litb | I think it should read "Use the BB_FILES_DYNAMIC variable to have a layer that attempts to modify other layers ... but does not want to introduce a hard dependency..." ? | 17:14 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 17:15 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 17:17 | |
| fray | yes.. you should suggest that to the docs people | 17:18 |
| JPEW | litb: Send a patch please | 17:19 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:20 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 17:21 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:21 | |
| *** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-35-186.w90-57.abo.wanadoo.fr> has joined #yocto | 17:37 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 17:55 | |
| *** emg <emg!~emg@47.180.176.91> has joined #yocto | 17:58 | |
| emg | I've added samba to my build but I don't have winbind. Looking at samba_4.7.6.bb it looks like I should have a winbind.service and /sbin/winbindd etc. but nothing from FILES winbind seems to be present. | 18:00 |
| emg | http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb?h=sumo | 18:00 |
| emg | What am I missing/doing wrong? How do I make sure those get added to my image? | 18:01 |
| *** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-tludqpdsdfshhupd> has joined #yocto | 18:04 | |
| *** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto | 18:09 | |
| *** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC | 18:10 | |
| kergoth | emg: recipes can emit multiple binary packages. its up to you to install those packages in your imagew iwth IMAGE_INSTALL or equivalent. in this case, you'd need to install 'winbind', as that's what's in PACKAGES and referenced in FILES_ | 18:11 |
| tgamblin | khem: I've been running into build failures trying to run that test on nativesdk-clang. I am seeing the failure in https://github.com/kraj/meta-clang/issues/162 on my local machine, even though I have the patch, but this may just be my build machine | 18:13 |
| tgamblin | That being said, I tested with nativesdk-dnf with systemd and then sysvinit in DISTRO_FEATURES and did not see any rebuilds | 18:13 |
| emg | kergoth: when I add winbind to my RDEPENDS_${PN} = "... in my packagegroup... ^U I swear that I tried that and it didn't work and now here it's working. I'm beginning to doubt my sanity | 18:15 |
| emg | kergoth: thank you | 18:15 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 18:17 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 18:26 | |
| *** frsc <frsc!~frsc@200116b82436f300d4a878b0f423563c.dip.versatel-1u1.de> has quit IRC | 18:27 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yldgakqlswxgvrhd> has quit IRC | 18:29 | |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 18:29 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 18:44 | |
| khem | tgamblin:I thought I laid that monster to rest | 18:58 |
| khem | tgamblin:do you have multiple python installs on your machine | 18:58 |
| khem | it is a shortcomping in clang build I know | 18:58 |
| tgamblin | khem: it could just be my build machine, not sure yet. I have python and python3 in /usr/bin | 18:58 |
| kergoth | Hm, wonder if anyone has looked into creating a script to automate merging a bbappend+filespath into the main recipe for upstream submissions | 19:04 |
| fray | I've thought about it, but couldn't figure out a way to do it in the cases where things were based on distro, machine or other flags.. | 19:06 |
| *** litb <litb!~js@pd907fca9.dip0.t-ipconnect.de> has quit IRC | 19:06 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 19:07 | |
| tgamblin | khem: actually I have three versions installed | 19:11 |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 19:12 | |
| *** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 19:12 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 19:25 | |
| kergoth | Hmm, yeah, wouldn't be able to merge those. Need to brush up on the available functions in the recipetools and scriptools/utils modules | 19:26 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 19:28 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto | 19:29 | |
| *** vlo86 <vlo86!551700fe@85-23-0-254.bb.dnainternet.fi> has quit IRC | 19:32 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC | 19:33 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 19:43 | |
| RP | nrossi: any idea on https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1078 (also happened as https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1076) | 19:46 |
| RP | JPEW: autobuilder hashequiv tests looked better again, just this selftest failure to fix now | 19:47 |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC | 19:48 | |
| RP | That one at least reproduces | 19:48 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:56 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 20:00 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 20:17 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 20:18 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC | 20:19 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 20:20 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 20:21 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:21 | |
| khem | RP: what are these strace failures ? | 20:52 |
| khem | RP:are they new ? | 20:53 |
| RP | khem: 5.2 kernel | 20:53 |
| khem | I think the kernel API changes in 5.2 are biting us | 20:54 |
| RP | khem: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13556 and see the linked 13506 | 20:54 |
| yocti | Bug 13556: normal, High, 2.8 M4, bruce.ashfield, NEW , [2.8 M3 RC1] strace failure in ptest | 20:54 |
| khem | changes to clock_t and time_t | 20:54 |
| RP | khem: its not that, its some specific freezer patches around ptrace | 20:54 |
| khem | RP: do you want to try https://github.com/strace/strace/releases/tag/v5.3 | 20:56 |
| RP | khem: if someone sends a patch, sure :) | 20:57 |
| RP | khem: I think we did test tip of git and it didn't help | 20:57 |
| khem | OK I can do that tell me how can I run the given self test alone | 20:57 |
| khem | oh | 20:57 |
| RP | khem: it should be in 13506 | 20:58 |
| RP | khem: the test would be to run qemux68-64-ptest on the branch with the upgarde | 20:58 |
| RP | khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/81 | 20:58 |
| RP | khem: the tip of git was pre-release | 20:59 |
| khem | will need poky not oe-core right ? | 21:04 |
| RP | khem: right | 21:05 |
| khem | RP:preparing a patch and I will submit it via poky-contrib | 21:12 |
| khem | to AB | 21:12 |
| khem | on top of master-next lets see :) | 21:12 |
| khem | RP: one issue I am seeing is version-going-backwards when I switch from musl to glibc on some packagegroups, these packagesgroups have different packages being pulled based on which libc is in play | 21:13 |
| khem | RP: packagegroups are 'all' types but then we conditionalize them based on libc seems wrong to me | 21:14 |
| RP | khem: right, that is bad :( | 21:15 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:15 | |
| RP | true allarch are very hard/rare | 21:16 |
| RP | JPEW: thanks for the patches :) | 21:19 |
| *** yann|work <yann|work!~yann@aputeaux-653-1-137-254.w86-195.abo.wanadoo.fr> has joined #yocto | 21:19 | |
| JPEW | RP: No problem. It was nice that they ended up being straight forward | 21:20 |
| RP | JPEW: yes, nice when that happens! | 21:20 |
| JPEW | I've probably angered some ancient god with that statement and untold wrath will befall me now :) | 21:21 |
| RP | JPEW: that selftest was simple when I finally understood what was wrong too | 21:21 |
| khem | RP: is there a way to address it ? | 21:21 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:21 | |
| RP | JPEW: I think they've been angry with me for a month or two already ;-) | 21:21 |
| RP | JPEW: If you want insight into our next problem, the warnings on: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1087 :( | 21:22 |
| khem | some of oe AB I have musl world build and glibc world build share sstate and buildhistory | 21:22 |
| RP | JPEW: Ignore the nativesdk bit, its missing shadow which setscenes later | 21:22 |
| RP | khem: it won't hurt sstate its just saying you couldn't have a working shared package feed | 21:22 |
| RP | khem: making them non-all arch is probably the only solution | 21:23 |
| khem | RP: yeah which is logical I think | 21:23 |
| RP | my tweak/fixes in -next are a right mess. I think I have to sort them into sensible patches tomorrow... | 21:24 |
| RP | JPEW: current build is fun as its using hashequiv with larger code changes | 21:25 |
| JPEW | RP: Does it look like it's helping? | 21:25 |
| RP | JPEW: Its seems to be running quite quickly but hard to say :) | 21:26 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 21:26 | |
| RP | JPEW: we need to enable reproducibile builds by default next to really start to make a difference | 21:26 |
| JPEW | RP: Ya, that would be awesome.... are there any images other than core-image-minimal and core-image-sato that the AB uses? | 21:27 |
| RP | JPEW: quite a few (full-cmdline, sato-sdk, -dev, weston and more) | 21:27 |
| RP | and world builds | 21:28 |
| RP | khem: FWIW we turned that test off on our buildhistory | 21:32 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 21:35 | |
| khem | RP: you mean version-going-backward QA test ? | 21:37 |
| RP | khem: yes | 21:37 |
| khem | hmm maybe its a better option | 21:37 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 21:37 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 21:37 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 21:38 | |
| RP | khem: its fine if you're maintaining a package feed but we're not and don't have the people to right now | 21:38 |
| khem | would you be open for patches to mark these packagegroups as non-all ? | 21:39 |
| RP | khem: how many are there? | 21:40 |
| RP | khem: I'm hoping its just one or two | 21:40 |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 21:44 | |
| khem | yes its os-release, packagegroup-core-tools-debug, packagegroup-core-standalone-sdk-target packagegroup-self-hosted | 21:48 |
| RP | that is more than I'd hoped :( | 21:49 |
| RP | khem: os-release doesn't look libc specific? | 21:50 |
| RP | khem: the others I don't mind changing after looking at them... | 21:51 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:05 | |
| *** pdemier <pdemier!~phildemie@cpe-98-26-2-10.nc.res.rr.com> has joined #yocto | 22:05 | |
| *** tesaddict <tesaddict!cfedac16@phoenixplumb07.p.subnet.rcn.com> has joined #yocto | 22:14 | |
| khem | RP: cool, os-release is also doing the switch back so maybe it has some dependency somehow ... I will hunt it down | 22:14 |
| tesaddict | How is it going guys? I was wondering what is the best practice to modify a few drivers within recipes-kernel | 22:15 |
| tesaddict | Specifically from meta-atmel. I can directly make changes, but I realize this is bad practice | 22:15 |
| RP | khem: it may be you've configured it to add a dependency? Is this with poky or nodistro or ??? | 22:17 |
| *** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-35-186.w90-57.abo.wanadoo.fr> has quit IRC | 22:20 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto | 22:31 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:31 | |
| *** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC | 22:37 | |
| khem | RP: I know the problem is I define different DISTRO for musl | 22:41 |
| khem | and DISTRO is one of the elements in there for os-release | 22:41 |
| RP | khem: right, that would explain it | 22:41 |
| khem | that I think I need to address differently | 22:41 |
| RP | khem: reality is that you'd likely have different package feeds for glibc and musl so this may not be a problem for allarch | 22:44 |
| * RP should sleep | 22:44 | |
| khem | that is true though | 22:44 |
| khem | yes should I send a RESTful API cmd :) | 22:45 |
| RP | khem: :) | 22:49 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:04 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:40e0:1cd6:848:14bf> has joined #yocto | 23:12 | |
| *** MiskaX <MiskaX!qokhufe4u1@rankki.sonarnerd.net> has joined #yocto | 23:13 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 23:27 | |
| *** stephano <stephano!stephano@nat/intel/x-wxqftanpnkmnytgf> has joined #yocto | 23:32 | |
| *** stephano <stephano!stephano@nat/intel/x-wxqftanpnkmnytgf> has quit IRC | 23:41 | |
| *** tesaddict <tesaddict!cfedac16@phoenixplumb07.p.subnet.rcn.com> has quit IRC | 23:53 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!