*** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has quit IRC | 00:01 | |
halstead | khem, I've added your account in the right spot. Just started a build with your creds https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/1295 | 00:02 |
---|---|---|
*** armpit <armpit!~armpit@2601:202:4180:c33:5563:62f6:a44e:1984> has joined #yocto | 00:14 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:40 | |
khem | halstead cool thx | 01:02 |
halstead | :) | 01:02 |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-046-005-020-206.hsi8.kabel-badenwuerttemberg.de> has quit IRC | 01:30 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-046-005-020-206.hsi8.kabel-badenwuerttemberg.de> has joined #yocto | 01:35 | |
khem | halstead: I submitted https://autobuilder.yoctoproject.org/typhoon/#/buildrequests/58474 but it seems its incomplete ? did I miss anything ? | 02:17 |
khem | it seems the builder I requested is busy np | 02:18 |
halstead | It takes a moment. Especially with builds in progress | 02:18 |
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 03:45 | |
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 03:47 | |
*** mardy <mardy!~mardy@88-115-221-237.elisa-laajakaista.fi> has quit IRC | 03:55 | |
*** mardy <mardy!~mardy@88-115-221-237.elisa-laajakaista.fi> has joined #yocto | 04:00 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 04:28 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 04:37 | |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 04:51 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 05:40 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 06:02 | |
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has joined #yocto | 06:28 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:32 | |
*** seebs <seebs!~seebs@24.196.59.174> has quit IRC | 06:35 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 06:38 | |
*** seebs <seebs!~seebs@24.196.59.174> has joined #yocto | 06:44 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:48 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:49 | |
*** yann|work <yann|work!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC | 06:53 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:54 | |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 06:56 | |
iceaway | So I'm trying to create a kernel+dtb+initrd inside a fitimage. In my machine configuration I have set KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPES += "fitImage". In my local.conf I have INITRAMFS_IMAGE = "my-initrd-image". This fails with a dependecy loop, where it seems like it tries to run "do_bundle_initramfs" even though I have not configured it to bundle the initramfs and kernel together. | 06:59 |
iceaway | The only way to get around it is to comment out the INITRAMFS_IMAGE line, but then I won't get my initrd in the fitimage. | 06:59 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:00 | |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 07:02 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 07:03 | |
LetoThe2nd | iceaway: only thing that i can say ad-hoc is that we're using cpio.gz as the IMAGE_FSTYPE to bundle into fitImage | 07:07 |
LetoThe2nd | marex-cloud: ^^^^^ you can probably tell us more. | 07:07 |
marex-cloud | The dependency loops shouldn't be in recent oe versions | 07:08 |
iceaway | LetoThe2nd: I'm using cpio.gz too for the initrd image recipe. I am on Yocto 2.5 if that matters. | 07:08 |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 07:10 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 07:31 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:00 | |
palate | hello :) | 08:04 |
*** prabhakar <prabhakar!c18ddb24@193.141.219.36> has joined #yocto | 08:06 | |
prabhakar | Hello All, is it possible add COMPATIBLE_MACHINE_append in a bbappend file. | 08:07 |
LetoThe2nd | prabhakar: sure | 08:08 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 08:08 | |
prabhakar | LetoThe2nd thank you | 08:08 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:12 | |
prabhakar | LetoThe2nd how do we override a SRC_URI in a bbappend file I want to just change one location in bbappend, rest of the SRC_URI I would like to use the same as in original bb file. | 08:13 |
qschulz | prabhakar: do you want to modify a location whcih is already there or add a new one? | 08:14 |
prabhakar | qschulz yes just the location of one source. | 08:15 |
qschulz | prabhakar: you didn't answer the question :) modify or add a location? | 08:18 |
prabhakar | I want to modify | 08:20 |
qschulz | what are you trying to do exactly? (the correct asnwer depends on your use case) | 08:20 |
prabhakar | qschulz I want to change the linux source location in the append file, but I want to reuse the other SRC_URI's pointed by the bb file | 08:22 |
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto | 08:22 | |
smurray | prabhakar: it’s not pretty, but you can try to _remove the original uri and preprend the new one with =+ | 08:22 |
smurray | prabhakar: though if your use case is local development using externalsrc is a saner | 08:23 |
smurray | approach | 08:24 |
LetoThe2nd | smurray: get behind me, sanity.. i mean, stan! | 08:24 |
LetoThe2nd | satan, even. | 08:24 |
smurray | LetoThe2nd: heh | 08:24 |
smurray | LetoThe2nd: heh, the latest Periphery album is “HAIL STAN” ;) | 08:26 |
LetoThe2nd | hrhrhr | 08:26 |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 08:28 | |
qschulz | prabhakar: mmmmm are you sure you don't want to write a new recipe for that kernel instead? | 08:28 |
qschulz | otherwise yes, _remove could work, but use the exact same line as the one in the original recipe with the variables not expanded/resolved but that's weird honestly | 08:29 |
*** creich_ <creich_!~creich@2a02:8106:217:2100:d01:182b:8d17:626d> has joined #yocto | 08:30 | |
prabhakar | Yes I dont want write a new recipe, I just want to change the source. | 08:30 |
creich_ | hi there. i am currently starting to get used to yocto and tried building poky for that. now i've got a problem with one package, that i tried to fix, which was really nice to get in touch with devtool btw :) | 08:31 |
creich_ | prabhakar, sry, i didn't see your original question, but you only wanne change sources? | 08:32 |
qschulz | I don'[t understand the use case? I'd personally be not very happy if by adding your layer to my Yocto layers you modify where I get the linux kernel without changing anything in my conf files. Why do you need to change the source location? | 08:32 |
creich_ | prabhakar, maybe check this wiki: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe | 08:32 |
smurray | prabhakar: If you control the original recipe, you could move that line (kernel location, I’m guessing) into a variable that you could override easier | 08:33 |
creich_ | here is my problem, i don't understand: after pathing my sources i built the package directly using bitbake <package> and everything works well | 08:34 |
creich_ | BUT if i then again try to build the whole poky image (which hasthe package as a dep) that specific package fails again | 08:34 |
creich_ | how can that be? i though building the specific package and building it as a dep of a whole image might run the same build process | 08:35 |
creich_ | is there any mechanism that might influence the way that package got built during the image build? | 08:35 |
qschulz | LetoThe2nd: do you happen to know if the parsing is parallelized? | 08:37 |
LetoThe2nd | qschulz: nope, sorry. | 08:38 |
smurray | creich_: it’s hard to say, depends on what the failure is. I’ve seen that a few times, usually the recipe has an issue | 08:38 |
smurray | qschulz: that’s a question for RP, I can’t recall off the top of my head | 08:39 |
qschulz | RP: then :) do you happen to know if the parsing is parallelized? | 08:39 |
*** seebs <seebs!~seebs@24.196.59.174> has quit IRC | 08:39 | |
qschulz | and the reason for that question is: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/externalsrc.bbclass#n207 what happens if two externalsrc recipes are executing the same block starting at the line 207? | 08:41 |
creich_ | smurray, hmm ok.. yeah, i just didn't want to waste your times by debugging that issue, since i tried to use yocto on an ARCH system, which is not oficcialy tested/supported | 08:42 |
creich_ | it was more the question if it is possible, that the package could get built in twi different ways, which i wouldn't expect | 08:42 |
qschulz | https://docs.python.org/3/library/tempfile.html#tempfile.NamedTemporaryFile then you go up the inheritance chain up to https://docs.python.org/3/library/tempfile.html#tempfile.mkstemp which says "If dir is not None, the file will be created in that directory; otherwise, a default directory is used. The default directory is chosen from a platform-dependent list, but the user of the application can control | 08:42 |
qschulz | the directory location by setting the TMPDIR, TEMP or TMP environment variables." | 08:42 |
qschulz | and... we have TMPDIR set which is a common one between all recipes | 08:43 |
creich_ | the root problem was that my host gawk is to new (5.0.1) and was complaining about 'namespace' to be a keyword | 08:43 |
qschulz | creich_: look at what's inside the image recipe and if it's not changing some variables in there? | 08:43 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:43 | |
creich_ | that happened when building libgpg-error | 08:44 |
creich_ | i try to build libgpg-error on the branch yocto-2.7.1 | 08:44 |
creich_ | bitbake core-image-sato --> fails | 08:45 |
creich_ | bitbake libgpg-error --> works | 08:45 |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:45 | |
creich_ | qschulz, thx, i am going to check | 08:45 |
*** seebs <seebs!~seebs@24.196.59.174> has joined #yocto | 08:47 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 08:48 | |
smurray | qschulz: afaik that should be unlikely to be a problem, it would be different temp files as mkstemp generates unique names even when a prefix is given. As well, you’d need two recipes both specifying the same EXTERNALSRC value | 08:53 |
*** prabhakar <prabhakar!c18ddb24@193.141.219.36> has quit IRC | 08:55 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 08:56 | |
creich_ | the only difference during build i can tell is that if i build the package directly, i ge ta notice 'NOTE: libgpg-error: compiling from external source tree /home/unknown/coding/yocto/poky/build/workspace/sources/libgpg-error' | 08:56 |
creich_ | which i don't get if i try to build the image | 08:56 |
creich_ | anyway to clean that up besides cleanall on the whole image build process? | 08:56 |
creich_ | seems to me a problem with some cached stuff | 08:57 |
creich_ | when building the package directly i could easily go and clean the related stuff using 'bitbake -c cleanall libgpg-error' | 08:57 |
qschulz | smurray: True! Completely missed prefix= in the line in externalsrc! So, that one, unlikely, or if it ever happens an issue in Python itself.. | 08:59 |
smurray | creich_: did you do “devtool modify” or the like on it? That’s how it’d be trying to build it from there | 09:00 |
*** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has joined #yocto | 09:01 | |
creich_ | smurray, yes i did! that's intentional.. as i mentioned, i have gawk-5.0.1 which complaine about 'namespace' to be a keyword... but it's used inside one of the autoconf scripts of libgpg-error | 09:02 |
creich_ | so i simple renamed it and tried to rebuild | 09:02 |
creich_ | basically that is my first 'how to patch stuff' attemt | 09:02 |
creich_ | after i tried building the lib for itself and everything looked good, i tried to continue building the image | 09:03 |
creich_ | i am bulding poky for an raspi btw | 09:03 |
smurray | creich_: hmm, not sure why it not pick up that version in the image build, odd | 09:04 |
qschulz | smurray: PREFERRED_PROVIDER/VERSION in some recipe? | 09:05 |
creich_ | smurray, ok.. worst case would be a clean all and try to rebuild. but that might take a while | 09:06 |
creich_ | ok, i guess i got it... it looks like there was some kind of 'variant' built.... libgpg-error-native | 09:09 |
creich_ | i did not see that directly, since the error was pointing to libgpg-error (virtual:native was only written in front of smoe error message) | 09:10 |
creich_ | and i though cleanall might clean all variants of the pacakge | 09:10 |
qschulz | creich_: ok, try to build this one now but I'm pretty sure it won't build :) | 09:10 |
creich_ | yep, that's what i think to ;) | 09:10 |
qschulz | creich_: native packages (which are built for use on the host, so where Yocto is run) can be compiled differently | 09:10 |
creich_ | can i get a list of all those variants? | 09:11 |
qschulz | so cleanall wouldn't help much | 09:11 |
creich_ | makes sence that they might be built differently | 09:11 |
qschulz | creich_: wdym? there is -native, nativesdk- packages and then you have multilib (usually lib32- but can be something else) | 09:11 |
qschulz | or should I say recipes instead of packages even though you can have all of the aforementioned one handled in the same recipe | 09:12 |
creich_ | i jsut didn't see why 'bitbake libgpg-error' didn't build all of those variants | 09:12 |
creich_ | ah ok, i start to ge it | 09:13 |
creich_ | i can get the idea of one recipe building different packages... | 09:13 |
creich_ | i am new to yocto, but i am an active gentoo user and used portage a lot | 09:14 |
qschulz | creich_: you bitbake a recipe only (you also DEPENDS only on a recipe, but you RDEPENDS on a package (which can be named after the recipe)) | 09:15 |
creich_ | those 'variants' come through the BBCLASSEXTEND, right? | 09:16 |
qschulz | native, nativesdk and multilib are exceptions, you can bitbake them even though they don't have a recipe named after them | 09:16 |
qschulz | creich_: for native and nativesdk yes, not multilib ones | 09:17 |
creich_ | if i want to fix that variant (or is that even the right name?) i use devtool again, but on .. say 'libgpg-error-native' | 09:17 |
*** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 09:21 | |
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC | 09:38 | |
creich_ | ok. now i know, that both variants can be fixed with the same bugfix. but i can not use devtool modify to modify both at the same time, since they are both based on the same recipe | 09:47 |
creich_ | i guess i have to read more docu about how to go from there | 09:48 |
creich_ | thanks a lot guys :D | 09:48 |
*** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has left #yocto | 10:01 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:03 | |
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has quit IRC | 10:03 | |
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has joined #yocto | 10:09 | |
*** palate <palate!~palate@unaffiliated/palate> has quit IRC | 10:13 | |
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC | 10:21 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 10:45 | |
cengiz_io | hello there. I'm using `thud` branch and using my `meta-toolchain` output on an Arch Linux machine. | 10:58 |
cengiz_io | whenever I source sdk environment, I got this error: `Can't locate Time/HiRes.pm in @INC (you may need to install the Time::HiRes module)` | 10:58 |
cengiz_io | can anyone, for the love of god and all holy angels and cat babies, help me? | 10:58 |
cengiz_io | about to pull my last remaning hair folliciles | 10:59 |
LetoThe2nd | cengiz_io: no need to be so cheesy. have you checked if perl is properly installed and working? | 11:04 |
LetoThe2nd | cengiz_io: -> https://www.archlinux.org/packages/core/x86_64/perl/files/ | 11:04 |
cengiz_io | LetoThe2nd why do you call me cheesy? I couldn't understand the reason | 11:06 |
LetoThe2nd | 10:58 < cengiz_io> can anyone, for the love of god and all holy angels and cat babies, help me? | 11:06 |
LetoThe2nd | if that is not cheessy, i don't know how to call it, sorry. :D | 11:07 |
cengiz_io | LetoThe2nd: that can be summed up as someone in desperate need of help. | 11:08 |
LetoThe2nd | *sigh* anyways. did you check perl? | 11:08 |
cengiz_io | $ perl -mTime::HiRes <<EOF use Time::HiRes qw( clock_nanosleep ); clock_nanosleep(CLOCK_REALTIME, 1.5e9); ;EOF | 11:09 |
cengiz_io | works | 11:09 |
cengiz_io | so I think my host machine's perl has Time::HiRes module | 11:09 |
cengiz_io | perl (v5.30.0) | 11:10 |
cengiz_io | but the toolchain has module skeleton for 5.24.4 ie: `/opt/fslc-framebuffer/2.6.3/sysroots/x86_64-fslcsdk-linux/usr/lib/perl/5.24.4/ ` | 11:10 |
cengiz_io | can I be missing something in local.conf perhaps? | 11:11 |
LetoThe2nd | cengiz_io: ok. any particular reason you're using meta-toolchain instead of an image-derived sdk? AFAIK, those are to be preferred, with meta-toolchain rather being a historic artifact | 11:11 |
cengiz_io | LetoThe2nd didn't know that. | 11:11 |
cengiz_io | I was just trying to get a toolchain so that I can give out to developers while I prepare the machine image. | 11:12 |
LetoThe2nd | plus, https://community.nxp.com/thread/449585 | 11:12 |
cengiz_io | they are compiling Qt apps to be run inside my image | 11:12 |
cengiz_io | LetoThe2nd that last link is not relevant at all. it's for adding the modules *inside* the resulting image | 11:13 |
cengiz_io | my error comes from using this `source /opt/fslc-framebuffer/2.6.3/environment-setup-armv7at2hf-neon-fslc-linux-gnueabi` | 11:13 |
LetoThe2nd | it might still be necessary to manually add to the generated toolchain. (which would probably be a bug) | 11:14 |
LetoThe2nd | but anyways, i'd really start with an image derived sdk | 11:14 |
rburton | cengiz_io: possbly a bug in meta-toolchain because its basically deprecated now. better to build a SDK from your image, (bitbake myimage -c populate_sdk) | 11:14 |
rburton | if a image sdk works, please file a bug for meta-toolchain | 11:15 |
cengiz_io | didn't know that it's deprecated. | 11:15 |
LetoThe2nd | cengiz_io: thats why we're telling you. | 11:15 |
cengiz_io | does that image sdk add necessary files to my image tar.gz? | 11:15 |
LetoThe2nd | it does not add anything to the image | 11:15 |
cengiz_io | ok great | 11:15 |
LetoThe2nd | bitbake -c populate_sdk YOUR_IMAGE | 11:15 |
cengiz_io | thank you LetoThe2nd and rburton | 11:16 |
LetoThe2nd | -> https://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html | 11:16 |
LetoThe2nd | lots of very good information! | 11:17 |
rburton | 2.7.1? | 11:17 |
cengiz_io | I need to compile tons of stuff by end of the day so I'm in a very bitter rush here. sorry for the misunderstandings | 11:17 |
LetoThe2nd | rburton: first google hit, should be good enough | 11:18 |
* cengiz_io thinks things are getting even more confusing with eSDK | 11:27 | |
* cengiz_io decided to print the relevant manual pages and read | 11:28 | |
LetoThe2nd | cengiz_io: then use the classic, conventional sdk, no problem | 11:28 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 11:42 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 11:44 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:46 | |
Klanticus | Hey guys, I'm having a few issues running ruby (ruby native) inside a recipe. I noticed that I can call 'env ruby' inside devshell, but if I try to bitbake the recipe, ruby cannot be found. | 11:46 |
Klanticus | The PATH var has my host path included (/usr/bin, /bin...), but when I bitbake it directly, it doesn't (which is what I actually expected). | 11:47 |
kroon | Klanticus, IIRC devshell doesn't prune the environment, which bitbake does for scripts run from recipes | 11:48 |
Klanticus | Well, that explains the difference | 11:49 |
Klanticus | do you know how to find out why env is not locating ruby inside bitbake? | 11:50 |
kroon | Klanticus, do you have ruby-native in your DEPENDS ? | 11:50 |
Klanticus | Yeah, ruby-native is there and I have ' ASSUME_PROVIDED += "ruby-native"' on my local.conf | 11:51 |
kroon | Klanticus, hmm.. i'd assume youre not supposed to do both | 11:51 |
Klanticus | really? I want bitbake to just use my host's ruby. Isn't that the way to do it? | 11:52 |
*** yacar_ <yacar_!~yacar@80.215.47.50> has joined #yocto | 11:53 | |
kroon | Klanticus, I'd guess ruby-native in DEPENDS is not necessary then | 11:53 |
Klanticus | That's interesting... Let me try | 11:54 |
kroon | Klanticus, maybe you need to extend HOSTTOOLS | 11:54 |
Klanticus | yeah, had the same problem by just removing it from DEPENDS. I have now included ruby into HOSTTOOLS and it looked like it worked | 11:57 |
Klanticus | kroon: Do you know whether I have to keep it into ASSUME_PROVIDED too, now that it's in HOSTTOOLS? | 11:58 |
kroon | Klanticus, if you removed it from DEPENDS, id assume you don't need it in ASSUME_PROVIDED | 11:58 |
Klanticus | so adding it to HOSTTOOLS will make bitbake just hard link the system one into the sysroot, right? | 12:00 |
kroon | yeah | 12:00 |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto | 12:00 | |
Klanticus | kroon: looks like it worked now. Thanks a lot! The explanation about ASSUME_PROVIDED wasn't really clear to me | 12:03 |
kroon | Klanticus, you mean this one ? https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ASSUME_PROVIDED | 12:05 |
Klanticus | yeah.. "An example is git-native, which when specified, allows for the Git binary from the host to be used rather than building git-native." | 12:05 |
Klanticus | I thought it would just use the host ruby when I put it there | 12:06 |
kroon | Klanticus, yeah, I can agree, could use some improvement | 12:06 |
kroon | Klanticus, you can always improve it and send in a doc patch :-) | 12:06 |
Klanticus | As soon as I really understand it's meaning, I'll do it :) | 12:07 |
Klanticus | I'm a bit new in the Yocto world | 12:08 |
*** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has quit IRC | 12:11 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 12:12 | |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 12:13 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 12:14 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 12:15 | |
tgoodwin | Does anyone have experience seeing poky/bitbake/lib/bb/data.py pick a different KERNEL_PROVIDER in the inheritFromOS method? | 12:24 |
tgoodwin | It's only happening at one developer's desk. | 12:27 |
RP | tgoodwin: some kind of ordering issue? | 12:30 |
RP | tgoodwin: some python versions don't sort dict keys which leads to differences in behaviour. We do our best to avoid such problems but environment is one area we probably don't sort | 12:30 |
RP | tgoodwin: totally guessing | 12:31 |
tgoodwin | RP: I'm not sure...I'm trying to triage it and I can't reproduce it. It's like they accidentally set KERNEL_PROVIDER and KERNEL_TAG ahead of running bitbake. | 12:31 |
RP | tgoodwin: those aren't standard variables so its hard for me to say... | 12:31 |
tgoodwin | RP: I just had them start their terminal session and the vars are gone. /shrug/ | 12:32 |
tgoodwin | I guess it was a PEBKAC. | 12:32 |
RP | tgoodwin: sounds like it | 12:32 |
RP | tgoodwin: its why we filter the env by default | 12:32 |
tgoodwin | Right, but those two are whitelisted. | 12:33 |
RP | tgoodwin: right, I'd guessed you were allowing them one way or another | 12:35 |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 12:35 | |
tgoodwin | RP: It's interesting to get new folks onboard and see how things can go off the rails. | 12:36 |
tgoodwin | I would love to see his bash history for that session. | 12:36 |
RP | tgoodwin: I've seen lots of interesting things over the years :) | 12:38 |
fullstop | cmake in yocto warrior.. terminate called after throwing an instance of 'std::logic_error' -- is this a known issue / how do I work around it? | 12:41 |
fullstop | It seems to happen when it is attempting to generate the config | 12:41 |
rburton | fullstop: using cmake? on host? at build time? what recipe? | 12:41 |
fullstop | rburton: on host, using cmake | 12:41 |
rburton | fullstop: all recipes using cmake, or just one? | 12:42 |
fullstop | recipe is something that I'm trying to put together, but the package itself is dlib. This is not in any of the yocto / oe layers | 12:42 |
fullstop | just this oen | 12:42 |
rburton | sounds like the cmakelists is broken in some way then if cmake works for all the other recipes | 12:42 |
fullstop | well that's unfortunate | 12:42 |
rburton | libproxy or taglib are fairly easy cmake using recipes to test | 12:42 |
fullstop | is there a way to enable extra verbose information from cmake so that I have a better chance of tracking it down? | 12:43 |
fullstop | I know of one option which triggers it, so I can slowly narrow it down.. | 12:43 |
fullstop | wow, --trace-expand is busy. :-) | 12:44 |
*** ThomasD13 <ThomasD13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 12:44 | |
fullstop | and doesn't actually show me anything useful after the crash. | 12:44 |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 12:45 | |
rburton | maybe try #cmake | 12:46 |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 12:46 | |
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 12:46 | |
JPEW | RP: Hmm, it was working a few weeks ago right? | 12:46 |
JPEW | (Hash equivalence that is) | 12:47 |
RP | JPEW: yes. Something is wrong but not sure quite where/what | 12:47 |
RP | JPEW: its writing out two different hashes for the same task into locked sigs locally | 12:47 |
JPEW | RP: Yuck. | 12:47 |
RP | JPEW: My meta-sdk change is suspicous, as is Jaewon's esdk change but local reverts say they're ok | 12:49 |
JPEW | RP: Ya. Do you think it would be worth while to try and write a test case that can reproduce that problem and then use it to bisect? | 12:50 |
JPEW | My worry is that writing a test case that actually detects it might be difficult | 12:51 |
RP | JPEW: I don't know. It can be very very hard to reproduce this kind of problem in a test case without knowing the root cause | 12:51 |
JPEW | RP: Fair | 12:51 |
ThomasD13 | Hi. Does someone else have also problems to build a eSDK? | 12:51 |
RP | ThomasD13: I'm talking about master-next and hash equivalence so problems you're unlikely to be hitting | 12:52 |
ThomasD13 | Okay :) | 12:53 |
RP | JPEW: I just found its my meta-ext recipe change | 12:53 |
RP | JPEW: which is clearly why it shouldn't be writing to sstate and it was designed that way | 12:53 |
RP | JPEW: a revert is a preexisting build isn't enough | 12:54 |
ThomasD13 | Nevertheless: Could I ask a question regarding building eSDK with bitbake? During the build process I got an error: "ERROR: Failed to generate filtered task list for extensible SDK:" "Nothing provides 'xy' " | 12:58 |
ThomasD13 | Package 'xy' is defined in layer "meta-ibg". A few lines above I noticed this output: "NOTE: Excluding local workspace layer /home/ewtd/poky/meta-ibg from extensible SDK" | 12:59 |
ThomasD13 | I looked at the python code, and it's getting excluded, because the first line of the layer.config matches with ""# ### workspace layer auto-generated by devtool ###" | 13:00 |
ThomasD13 | So, is the right way to change this line, that the layer does not get excluded anymore? | 13:01 |
LetoThe2nd | ThomasD13: nope, the problem is probably that your layer is located beneath poky, which is a bad practise | 13:03 |
ThomasD13 | LetoThe2nd this is my structure: https://pastebin.com/X58qHkhT | 13:04 |
ThomasD13 | "meta-ibg" is my layer. I thought that would be the right place? | 13:05 |
LetoThe2nd | ThomasD13: well... actually i find the constealltion pretty bad. | 13:06 |
LetoThe2nd | ThomasD13: your build is inside poky, for example | 13:06 |
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC | 13:07 | |
__angelo | hi, adding package "zip" but for some reason bitbake -g is not carching it .. | 13:07 |
LetoThe2nd | ThomasD13: i always recommend something like https://pastebin.com/g1pP2f8A | 13:07 |
ThomasD13 | LetoThe2nd okay. I'll try to fix that. Do you really think thats the cause for my problem? | 13:09 |
LetoThe2nd | ThomasD13: i at least guess it. no guarantees. | 13:09 |
RP | ThomasD13: have you tried removing that line about "being auto-generated" | 13:10 |
RP | ThomasD13: if its become a layer in its own right its probably not needed/appropriate any more? | 13:10 |
ThomasD13 | LetoThe2nd: I'm just wondering. I cloned poky and started working with the given structure. So I have to move all the layers to the outside of poky first? | 13:10 |
RP | btw, does anyone fancy a "simple" optimisation issue to work on: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 ? | 13:11 |
yocti | Bug 13539: enhancement, Undecided, ---, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK | 13:11 |
LetoThe2nd | ThomasD13: well thats what i do and recommend, because that way you get a clean structure for SCMs | 13:11 |
ThomasD13 | RP: Yes I did. Then I get different errors (thousand of red lines) but I didn't worked through yet. Just wanna ask before, if that would be the right way | 13:11 |
RP | ThomasD13: its where I would have started but LetoThe2nd may be right about structure too | 13:12 |
ThomasD13 | Okay thanks guys. I try to relocate the directories and see if that solves my issue | 13:13 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:16 | |
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 13:18 | |
palate | hej :) | 13:18 |
palate | What happens if, say, I want to change the default /etc/network/interfaces? Do I write a new recipe just to copy the file in the right place? Or is there another mechanism for that? | 13:18 |
LetoThe2nd | palate: usually an append that includes the file in SRC_URI | 13:19 |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 13:19 | |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC | 13:19 | |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto | 13:19 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 13:23 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 13:24 | |
palate | LetoThe2nd: right, but in this case /etc/network/interfaces doesn't come with a package of mine, right? So I just make an "empty" recipe that appends only the file? | 13:28 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 13:28 | |
qschulz | palate: you have a .bbappend with FILESEXTRAPATH_prepend := "${THIsDIR}/files:" and you put your interfaces at the same place in "files" dirs that in the original recipe | 13:30 |
palate | ok, let me check that | 13:31 |
qschulz | which AFAICT, is directly in "files" | 13:31 |
qschulz | the FILESEXTRAPATHS magic will then do its work, you need one line in the bbappend and the interfaces file in the dir you put in FILESEXTRAPATHS | 13:32 |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 13:32 | |
RP | JPEW: even with that reverted the esdk tests fail with hash mismatches | 13:38 |
JPEW | RP: Did reverting it fix the other failures? | 13:39 |
RP | JPEW: yes, but there is the original problem that patch was for | 13:40 |
JPEW | RP: Ok. I'm not terribly suprised that hash equivalence messes with the eSDK, they both are trying to do related things. I'll run the tests locally to see if I can dig into it. | 13:41 |
JPEW | RP: Do you have a link to the failed test handy? | 13:41 |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:42 | |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC | 13:44 | |
RP | JPEW: I was reproducing locally with a "bitbake core-image-sato -c testsdkext" for qemux86-64 | 13:44 |
RP | JPEW: I don't have an online link for the exact failures there are a lot of different things on the autobuilder :( | 13:44 |
JPEW | RP: OK, all I really wanted was how to start the test | 13:45 |
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 13:50 | |
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 13:51 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 13:52 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 13:55 | |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto | 14:01 | |
*** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 14:02 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 14:04 | |
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 14:04 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 14:06 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 14:07 | |
*** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 14:10 | |
*** quijote <quijote!~dqx@unaffiliated/dqx> has quit IRC | 14:11 | |
*** quijote <quijote!~dqx@unaffiliated/dqx> has joined #yocto | 14:13 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:5563:62f6:a44e:1984> has quit IRC | 14:14 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 14:19 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 14:20 | |
ThomasD13 | Some basic question: Whats the difference between branches warrior and warrior-next? | 14:35 |
rburton | -next for any branch is the staging area for new patches | 14:48 |
rburton | patches in it may be altered, removed, etc. when theyre all good, merged to warrior | 14:48 |
rburton | ditto for master vs master-next, etc | 14:48 |
ThomasD13 | alright, thank you rburton | 14:50 |
*** armpit <armpit!~armpit@2601:202:4180:c33:f8c7:8a0b:73aa:3f22> has joined #yocto | 14:52 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:57 | |
*** ThomasD13 <ThomasD13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 14:57 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:00 | |
qschulz | Trying again earlier today, maybe my question will catch the attention of more people :) I'm debugging an issue with symlinks to dirs used in SRC_URI where file://symlink-dir does not work but file://symlink-dir/ works. | 15:01 |
qschulz | in the first situation, file-checksums is empty, but in the second, it is correctly set. So I'm trying to understand where and how this file-checksums is set | 15:02 |
cengiz_io | Hello again LetoThe2nd I've build the populate_sdk_ext just to make sure I get everything, does it have to be in the same machine as my yocto build system? | 15:10 |
cengiz_io | because it contains hardcoded paths to it | 15:10 |
cengiz_io | according to the docs you've sent, sdk can be on different machines.. isn't that the whole point? | 15:11 |
cengiz_io | LetoThe2nd: `FSLC FrameBuffer Extensible SDK installer version 2.6.3` to be exact | 15:12 |
cengiz_io | built* | 15:12 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 15:14 | |
LetoThe2nd | cengiz_io: no, you should be able to take and install it anywhere, as long as the prerequisites are all installed | 15:15 |
cengiz_io | so I have x86_64-buildtools-nativesdk-standalone-2.6.sh and fslc-framebuffer-glibc-x86_64-MACHINENAME-base-image-armv7at2hf-neon-toolchain-ext-2.6.3.sh | 15:15 |
cengiz_io | nativesdk-standalone seems to be installed in /opt/ by default | 15:16 |
LetoThe2nd | that both sounds strange. | 15:16 |
LetoThe2nd | let me check | 15:17 |
cengiz_io | MACHINENAME-base-image is my image name, consored by me :) | 15:17 |
* cengiz_io enterprise problems.. | 15:17 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 15:25 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 15:27 | |
__angelo | getting this error on postinst scrplets "systemctl: error: argument command: invalid choice: 'disable' (choose from 'enable', 'mask', 'preset-all')" | 15:38 |
fullstop | rburton: seems to be a cmake bug with respect to cuda and at which level enable_language(CUDA) is called. | 15:39 |
rburton | fun! | 15:39 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 15:41 | |
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 15:56 | |
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 15:59 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 15:59 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:05 | |
*** yacar_ <yacar_!~yacar@80.215.47.50> has quit IRC | 16:07 | |
LetoThe2nd | cengiz_io: so, i just verified: if you do a populate_sdk on an image, the resulting name should be something like poky-glibc-x86_64-IMAGE_NAME-TUNE-MACHINE-toolchain-2.7.1.sh | 16:09 |
LetoThe2nd | cengiz_io: located under tmp/deploy/sdk | 16:09 |
LetoThe2nd | ah, now i got it. the first part is the distro, and yours probably is "fslc-frambuffer" | 16:09 |
LetoThe2nd | yes, then it makes sense | 16:10 |
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:11 | |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:13 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:14 | |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:18 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 16:20 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 16:26 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 16:40 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 16:42 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 16:42 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 16:45 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 16:53 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 16:54 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 16:55 | |
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 17:00 | |
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 17:05 | |
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-ymhodbfrisspmugd> has quit IRC | 17:09 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:13 | |
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC | 17:14 | |
fullstop | is it possible to use qemu to build things as the native architecture for packages which don't really support cross compiling? | 17:47 |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC | 17:52 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:52 | |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto | 17:53 | |
*** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto | 17:56 | |
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 17:59 | |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC | 18:00 | |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto | 18:00 | |
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto | 18:04 | |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC | 18:04 | |
*** palate <palate!~palate@unaffiliated/palate> has quit IRC | 18:06 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 18:09 | |
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 18:10 | |
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has quit IRC | 18:11 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 18:13 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:21 | |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto | 18:38 | |
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has quit IRC | 18:40 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 18:47 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 18:48 | |
LetoThe2nd | fullstop: sometimes qemu is used to do things that have to be done on the target arch. i think fontconfig uses it, for example | 18:52 |
fullstop | hmm | 18:52 |
fullstop | I wonder if glib does as well. That package does not like to be cross compiled. | 18:53 |
*** rewitt <rewitt!~rewitt@134.134.139.74> has quit IRC | 18:58 | |
*** rewitt <rewitt!rewitt@nat/intel/x-rulvxtbevayeutjl> has joined #yocto | 18:59 | |
*** yann|work <yann|work!~yann@lfbn-1-3378-31.w90-127.abo.wanadoo.fr> has joined #yocto | 19:00 | |
*** yann|work is now known as yann | 19:00 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 19:11 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 19:18 | |
marler899722 | Hey, we are using an EXTERNAL_TOOLCHAIN, but when we build the SDK, the path to the external toolchain is not in the "environment-setup*" file, but the programs such as CC do not contain paths so then the environment can't find the tools | 19:26 |
rburton | fullstop: glib cross-builds fine | 19:26 |
fullstop | rburton: I'll have to check out the recipe. When I tried it, a while ago and without yocto, it required specifying stuff in some .cache file because it wanted to build tools to discover attributes about the target system.. but it tried to run those natively. | 19:28 |
fullstop | ah, it uses meson | 19:32 |
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has joined #yocto | 19:49 | |
marler899722 | nevermind, it looks like the environment script is generated by toolchain-scripts.bbclass, and it's not meant to be extended | 19:50 |
RP | JPEW: could you reproduce out of interest? | 19:54 |
mischief | how the heck do i pass extra cflags to a kernel build? | 19:58 |
JPEW | RP: Got side tracked by my day job, I'll retry overnight | 19:59 |
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has joined #yocto | 20:00 | |
RP | JPEW: fair enough :) | 20:00 |
RP | JPEW: I can't even get bugs to reproduce :/ | 20:00 |
zeddii | mischief, the kernel generates its own flags. so you'll need to patch things. there's no flow of whatever userspace is using -> the kernel build. You can do somethings via the CC=, etc, but it is kludgey | 20:00 |
mischief | argh, okay | 20:03 |
mischief | i have a warning about duplicate const in this vendor code, but it seems to only abort the build because of Werror | 20:04 |
mischief | i thought i could just turn off the duplicate const warning but i guess ill just make a patch. | 20:04 |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 20:31 | |
RP | kanavin: not sure if https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 would interest you or not? | 20:33 |
yocti | Bug 13539: enhancement, Medium+, 2.8 M4, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK | 20:33 |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 20:35 | |
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 20:36 | |
marler899722 | Does this seem unexpected to anyone? FOO ?= "a" FOO_someoverride_append = "b" (Foo is now "b") Anyone know why bitbake works this way? | 20:37 |
marler899722 | And if you remove "_someoverride", then Foo is "ab" | 20:37 |
marler899722 | I think if you originally set FOO = "a", it's the same thing as well | 20:38 |
RP | marler899722: not unexpected | 20:38 |
RP | marler899722: it expands RHS first | 20:38 |
RP | so FOO_someoverride_append = "b" becomes FOO_someoverride = "b" | 20:39 |
marler899722 | that's not what's unexpected | 20:39 |
marler899722 | it's that it ignores the non-override set | 20:39 |
marler899722 | but if you're append deosn't have an override, then it uses the non-override set | 20:39 |
RP | marler899722: so for FOO = "a" FOO_someoverride = "b" what do you expect? | 20:40 |
marler899722 | "b" | 20:41 |
RP | right | 20:41 |
marler899722 | oh | 20:41 |
marler899722 | so if it was FOO_append_someoverride, then what would it be? | 20:41 |
RP | that is quite different | 20:41 |
RP | ab | 20:41 |
marler899722 | trying to wrap my head around that... | 20:43 |
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 20:43 | |
marler899722 | ok I think I get it | 20:44 |
marler899722 | thanks for the help | 20:44 |
kergoth | it's a common source of confusion, but provides a fair bit of flexibility. iirc we highlight that at least somewhat in the bitbake manual. | 20:44 |
kergoth | there it is, https://www.yoctoproject.org/docs/2.0/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples | 20:44 |
marler899722 | thanks for the link, will read | 20:44 |
kergoth | np | 20:45 |
RP | marler899722: I try and process these things reading from the right hand side which is also what bitbake does | 20:45 |
kergoth | yeah, thinking of it as RHS first is a good idea, easier to grasp. good call | 20:45 |
marler899722 | yeah it makes more sense when I think of it that way | 20:45 |
kergoth | wonder if we sould mention that specifically int he docs | 20:45 |
RP | kergoth: could be an idea | 20:46 |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 20:46 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 20:46 | |
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 20:47 | |
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 20:47 | |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto | 20:47 | |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 20:48 | |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 20:52 | |
marler899722 | Ok, what do you think this one will do? OVERRIDES = "foo" A = "1" A_append = "2" A_append_foo = "3" ??? | 20:57 |
neverpanic | 123 | 20:58 |
RP | should be 123 as appends stack | 20:58 |
marler899722 | so you can't "override" an append | 20:58 |
neverpanic | If you want 13, use OVERRIDES = "foo" A = "1" A_append = "${BAR}" BAR = "2" BAR_foo = "3" | 20:58 |
neverpanic | Could have fooled me today as well, I seriously doubted for a second whether A_remove = "a" A_remove = "b" did even make sense | 20:59 |
marler899722 | based on what I read in that section, I think this case also deserves an explanation | 20:59 |
RP | marler899722: a patch would be most welcome | 21:00 |
marler899722 | ugh, sending patches is difficult for me as I'm behind a proxy and git send-email doesn't work behind a proxy | 21:01 |
RP | marler899722: maybe file a bug then with the suggested change? | 21:01 |
marler899722 | I could do that | 21:01 |
marler899722 | it's on my todo | 21:01 |
neverpanic | Stupid question, though -- why don't you just socat (or whatever tunneling utility you use) your SMTP port through the proxy and configure git to connect to that instead? | 21:01 |
marler899722 | I do use socat | 21:02 |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 21:02 | |
marler899722 | that's how I can push fetch git repos outside our network | 21:02 |
marler899722 | but git send-email ignores the proxy settings | 21:02 |
neverpanic | well, but can't you just start a socat in one terminal to proxy localhost:4567 to smtp.gmail.com:587 and configure git send-email to use localhost:4567 as smtp? | 21:03 |
marler899722 | hmmmm, might work, though I don't know if SMTP has any host headers that would need to be fixed | 21:03 |
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 21:04 | |
neverpanic | it does, but you might get away with putting 127.0.0.1 smtp.gmail.com into your /etc/hosts | 21:04 |
marler899722 | oh geeze | 21:05 |
marler899722 | yes that would certainly work | 21:05 |
marler899722 | I don't think I can bring myself to do it though...just seems so wrong | 21:05 |
RP | marler899722: it can't be worse than one setup I was forced into that had firefox running as root to run a java app that did individual port forwarding | 21:06 |
neverpanic | what seems wrong is your proxy or your inability to use company email to contribute, if you ask me... | 21:06 |
neverpanic | so you do what you must, and we've all been there at one point or another :/ | 21:07 |
RP | neverpanic: indeed | 21:07 |
marler899722 | true, but I weight that janky setup with how much pain do I want to put myself through just to get simple patches into yocto | 21:08 |
marler899722 | I contribute to hundreds of projects and I can't keep track of the janky setup for each one...I have to pick my battles in that case | 21:09 |
RP | marler899722: perhaps the bugzilla then? | 21:10 |
marler899722 | yes, creating issues on bugzilla is fine | 21:11 |
marler899722 | I suppose I could put a patch in there too? | 21:11 |
RP | marler899722: yes, just mention you can't send to the list due to firewall issues | 21:11 |
RP | marler899722: it means someone else will need to send for you (probably me) but its better than just forgetting the issue | 21:12 |
marler899722 | cool I will keep that in mind | 21:12 |
RP | marler899722: I'd look at the docs now but I'm in the middle of other stuff and have other problems :( | 21:12 |
marler899722 | speaking of patches, I sent one out 3 days ago manually from my gmail account. I'm not sure if it got sent to the mailing list properly, can anyone confirm? Subject is [OE-core] [PATCH 0/1] Assert error when there are multiple shlib_providers for the same file | 21:13 |
kergoth | marler899722: you can extend the sdk environment script in multiple ways. the easiest is to just install a script fragment into one of the sysroots. that is, create a recipe that installs an extra script that the env setup will source. | 21:14 |
marler899722 | how do I change the env setup script to source it? | 21:15 |
kergoth | there's an example of that right in meta-external-toolchain | 21:15 |
kergoth | you don't need to. the main one already sources anything in environment-setup.d/ in the sysroot | 21:15 |
kergoth | https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-sdk/sdk-env-external-toolchain/sdk-env-external-toolchain.bb | 21:15 |
marler899722 | oh | 21:15 |
kergoth | all you need is a recipe/package to install the fragment there | 21:16 |
kergoth | like the above | 21:16 |
RP | marler899722: the 0/1 patch header came through, the patch was not there as a following 1/1 | 21:16 |
marler899722 | yeah I was told to just send the cover-letter, and people could look at the github link to see the patch | 21:17 |
marler899722 | So environment-setup.d must be special? Does the recipe need the "-toolchain" suffix? | 21:17 |
kergoth | yeah that was my suggestion, since they can't use send-email directly, and gmail will mangle it otherwise | 21:17 |
kergoth | no, recipe name can be anything | 21:18 |
marler899722 | So you must just add that to TOOLCHAIN_TARGET_TASK? | 21:18 |
kergoth | https://github.com/openembedded/openembedded-core/blob/e38e56e28f2090e2b8013546f4dd76da8d59f766/meta/classes/toolchain-scripts.bbclass#L106 | 21:19 |
kergoth | yep, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/conf/distro/include/tcmode-external.inc#n35 | 21:19 |
marler899722 | awesome | 21:19 |
kergoth | it pulls the scripts from either the target or nativesdk/native sysroot actually, so can have a recipe for either one, depending on what variables you need to access in the metadata, if any | 21:20 |
RP | marler899722: A note saying there would be no 1/1 would have helped as I assumed it would come later (it never did) | 21:20 |
kergoth | most cases it won't matter, though | 21:20 |
marler899722 | RP: will remember that for next time | 21:21 |
RP | marler899722: looking at your patch it won't apply to master as there are other changes in that area. Normally we'd put sorted() around the .keys() to at least make this deterministic | 21:24 |
RP | marler899722: its looks like a valid bug though | 21:24 |
marler899722 | yeah that's one way to fix the determinism | 21:24 |
marler899722 | although, I think going one step further to assert an error with multiple would be better | 21:25 |
RP | marler899722: initially I was thinking it was related to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=41a5dbd16b0c9f5f97e7a160830cf7ca5de52ec6 | 21:25 |
RP | marler899722: yes, I'd probably bb.error, not fatal though | 21:25 |
marler899722 | sounds reasonable | 21:25 |
marler899722 | changed | 21:26 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 21:27 | |
RP | marler899722: for completeness, the commit short log needs to start "package:" to give people an idea of the area of code it touches and I'd remove the word "assert" as that means something very specific in python that doesn't apply here. Can you rebase it against master? | 21:28 |
neverpanic | Isn't it kind of a bad habit to have more than one shlib provider for the same lib anyway, though? | 21:28 |
RP | neverpanic: yes, showing an error would therefore be good | 21:28 |
marler899722 | Can do | 21:28 |
neverpanic | Right, but shouldn't http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/package.bbclass#n1788 be turned into an error then? | 21:30 |
marler899722 | rebased and fixed commit message | 21:30 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 21:32 | |
RP | marler899722: sorry, one more thing. Can we add a sorted in there please so it is deterministic :) | 21:33 |
marler899722 | that would only affect the determinism of the error message | 21:33 |
marler899722 | do you still want it? | 21:33 |
RP | marler899722: The error will flag the exit code and trigger CI failure but keep building so yes please | 21:34 |
marler899722 | ok, changed | 21:35 |
RP | (we do that so that you get a list of failures rather than a dead build which you restart then get the next issue) | 21:35 |
marler899722 | ah, that's why you wanted bb.error | 21:35 |
RP | Its just in keeping with the rest of the code | 21:35 |
RP | marler899722: thanks, I'll queue that. I'll have to send for mailing list patch review | 21:36 |
marler899722 | thanks | 21:37 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:38 | |
*** opennandra <opennandra!~marek@adsl-dyn-107.95-102-61.t-com.sk> has joined #yocto | 21:49 | |
opennandra | hi | 21:49 |
opennandra | I have some Makefile based binary and this project setup CFLAGS but CFLAGS gets overwritten by yocto CFLAGS is there way how to suppress this? | 21:49 |
neverpanic | ideally the Makefile would be fixed to append to whatever flags Yocto provides in the environment | 21:52 |
neverpanic | Unexpected things can happen when build systems ignore the flags Yocto wants them to use | 21:52 |
kergoth | CFLAGS in a makefiel should never be overridden by cflags in the environment unless the makefile uses ?=, or you have -e in EXTRA_OEMAKE | 21:55 |
opennandra | kergoth: I have this in recipe: EXTRA_OE_MAKE = "CUSTOMER_VERSION=COMMON1 V=1" | 21:56 |
kergoth | it's EXTRA_OEMAKE, not EXTRA_OE_MAKE, but if that's the case, the cflags ij the environment shouldn't be overriding the makefile unless the makefile explicitly allows it through use of ?=. | 21:57 |
opennandra | but looking at run.do_compile it adds automatically adds: make -j 12 -e MAKEFLAGS= | 21:57 |
opennandra | kergoth: Makefile use: CFLAGS += -Wall -g | 21:58 |
kergoth | that's becuase you didn't set EXTRA_OEMAKE. | 22:01 |
kergoth | if you did, it wouldn't append -e MAKEFLAGS=, that's the default value of EXTRA_OEMAKE | 22:01 |
kergoth | like i said, it's EXTRA_OEMAKE, not EXTRA_OE_MAKE :) | 22:01 |
opennandra | kergoth: yes you're right | 22:02 |
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC | 22:02 | |
kergoth | the -e argument is causing your issue, it tells make to let the environment override vars in files | 22:02 |
opennandra | not I get CFLAGS from Makefile but CFLAGS from yocto are lost (I would need at least sysroot) | 22:03 |
kergoth | sysroot isn't in cflags, it's in cc | 22:03 |
kergoth | and it shouldn't be lost if it's using +=, that means append, not set | 22:03 |
kergoth | if you're going to override EXTRA_OEMAKE, you really need to explicitly pass every variable in | 22:04 |
kergoth | well, not always, but usually | 22:04 |
kergoth | since most mkakefiles don't use ?= for vars like CC | 22:04 |
kergoth | so you'd want to do i.e. 'CC=${CC}' in your EXTRA_OEMAKE, along with any other vars it will obey | 22:04 |
opennandra | kergoth: yes sorry you're right CFLAGS are OK (ones from Makefile + from yocto) | 22:04 |
kergoth | you have to read the underlying makefiles to know what it obeys in what contexts | 22:04 |
opennandra | fatal error: stdio.h: No such file or directory | 22:04 |
opennandra | | #include <stdio.h> | 22:04 |
kergoth | this is the downside to using custom amkefile based buildsystems, there's no standards, it's case-by-case | 22:05 |
opennandra | but it drop sysroots path | 22:05 |
kergoth | yeah, it's not obeying CC | 22:05 |
opennandra | should I pass somehow sysrootfs? | 22:05 |
kergoth | again, it's in CC | 22:05 |
kergoth | grep for CC= or EXTRA_OEMAKE in oe-core, you'll find some recipes with examples of passing such variables in EXTRA_OEMAKE | 22:05 |
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has quit IRC | 22:05 | |
neverpanic | TBH, unless it's more than 20 source files, probably faster to write a simple CMakeLists.txt instead ¯\_(ツ)_/¯ | 22:06 |
opennandra | ok adding CC=${CC} I move forward | 22:06 |
opennandra | but then again : s.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory | 22:06 |
opennandra | neverpanic: it's proprietary binary for chinese camera and reading those makefiles I probably will bump my head to wall many many times :) | 22:07 |
opennandra | just want ot make it compilable by yocto and I win :D | 22:08 |
neverpanic | Ah yes, been there, seen that. My condolences :/ | 22:08 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 22:08 | |
kergoth | you'll need to cover all the usual suspects, variable wise. cc alone won't do. you need anything it's using. cc, cflags, ldflags, ld, etc | 22:09 |
kergoth | or you leave the -e in and hope it doesn't blow away anything required, and also that the variable names are the same, which isn't always the case | 22:10 |
rburton | yay plain makefiles | 22:10 |
opennandra | I'll start thinking about rewriting it in cmake :) | 22:11 |
kergoth | ugh. as much as i dislike autoconf, i'd rather that that something homerolled, anyday. | 22:11 |
marler899722 | what's your take on meson vs cmake? | 22:12 |
neverpanic | meson seems pretty usable and gets things right | 22:12 |
marler899722 | I've contribued to CMAKE, and the parts had to touch were quite ugly | 22:12 |
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 22:13 | |
neverpanic | CMake tends to have awkward syntax and its "standard library" isn't really very helpful in some cases | 22:13 |
kergoth | yeah.. i can't say i enjoy working with cmake at all | 22:13 |
neverpanic | Modern CMake is actually quite nice too, but people don't conistently use targets, and once you've moved into things that aren't properly set up as targets, you'll be in a world of pain :/ | 22:13 |
marler899722 | yeah, I think you can do CMAKE well if you know what you're doing | 22:14 |
opennandra | I think cmake is better like ninja :) | 22:14 |
kergoth | https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ comes to mind | 22:14 |
neverpanic | https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ is the best how-to I've found so far. If you do CMake and follow that, you'll be fine. | 22:14 |
marler899722 | opennandra: what's better? | 22:14 |
kergoth | ha :) | 22:14 |
neverpanic | kergoth: ha! | 22:14 |
rburton | marler899722: meson is awesome use meson | 22:15 |
opennandra | I have hard times when hacking somethign in google-chrome to understand all those dependencies in ninja file. I worked for quite some years with cmake (nothing special) but I really like it | 22:15 |
marler899722 | meson also uses ninja | 22:16 |
opennandra | I don't have anything against generated ninja (as it compiles) | 22:16 |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 22:18 | |
opennandra | other thing I want to ask I want to use external toolchain (linaro 4.9.4), it's enough to pull meta-linaro and change TCMODE in local.conf? I plan to use it wil older poky as with latest it cannot compile with such toolchain | 22:20 |
kergoth | usually you also need to set EXTERNAL_TOOLCHAIN to the toolchain path | 22:20 |
marler899722 | I'm compiling thud with linaro | 22:20 |
kergoth | but that's probably enough | 22:21 |
kergoth | see the layer readme, really.. | 22:21 |
marler899722 | compiling thud with linaro version 7.3 and 7.4 | 22:21 |
opennandra | ok cool thanks | 22:21 |
opennandra | I'll give a shot | 22:21 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:23 | |
RP | marler899722: what advantage does the linaro toolchain have out of interest? | 22:23 |
marler899722 | Apparently it has more arm-specific optimization | 22:24 |
RP | marler899722: I see, was just curious | 22:25 |
neverpanic | I'd be interested in a comparison with a modern clang-based toolchain. I'd figure Apple has put some serious work into their ARM backend. | 22:25 |
marler899722 | yeah that would be good to see | 22:25 |
opennandra | I need to stick to linaro as SDK I'm integrating in yocto was compiled with 4.9.4 linaro toolchain (I tried to compile with poky toolchain 7.3) but kernel fails to build as it's some chinese vendor 3.18 with lot of assembly so I have to stick with linaro (also use poky jethro where 4.9 is available) | 22:25 |
behanw | neverpanic: As has ARM, as has Google, and many others. | 22:26 |
opennandra | so currently use one from poky but in final I want to use linaro | 22:26 |
opennandra | just to be on safe side :D | 22:26 |
marler899722 | you say "poky", but which yocto branch are you on? | 22:27 |
neverpanic | And the last time I looked at some assembly output of the linaro toolchain for debugging (granted that was years ago), there was obvious optimization potential | 22:27 |
opennandra | poky jethro | 22:27 |
neverpanic | I think it was setting a register that it xor'd with itself right after | 22:27 |
neverpanic | anecdotal, but I'd expect that would be a pretty simple optimization | 22:28 |
RP | world has changed a lot since jethro :/ | 22:30 |
opennandra | RP: yes this is true | 22:32 |
RP | JPEW: I think there is a fix for the esdk issue in -next | 22:37 |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:40 | |
*** marler899722 <marler899722!0f41fc0d@ztxe01hpics303.austin.hp.com> has quit IRC | 22:48 | |
*** opennandra <opennandra!~marek@adsl-dyn-107.95-102-61.t-com.sk> has quit IRC | 22:53 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:56 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 23:24 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 23:24 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:39 | |
* armpit when does -next become -whenever ?? ; ) | 23:44 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!