Thursday, 2019-09-19

*** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has quit IRC00:01
halsteadkhem, I've added your account in the right spot. Just started a build with your creds https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/129500:02
*** armpit <armpit!~armpit@2601:202:4180:c33:5563:62f6:a44e:1984> has joined #yocto00:14
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC00:40
khemhalstead cool thx01:02
halstead:)01:02
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-046-005-020-206.hsi8.kabel-badenwuerttemberg.de> has quit IRC01:30
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-046-005-020-206.hsi8.kabel-badenwuerttemberg.de> has joined #yocto01:35
khemhalstead: I submitted https://autobuilder.yoctoproject.org/typhoon/#/buildrequests/58474 but it seems its incomplete ? did I miss anything ?02:17
khemit seems the builder I requested is busy np02:18
halsteadIt takes a moment. Especially with builds in progress02:18
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC03:45
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto03:47
*** mardy <mardy!~mardy@88-115-221-237.elisa-laajakaista.fi> has quit IRC03:55
*** mardy <mardy!~mardy@88-115-221-237.elisa-laajakaista.fi> has joined #yocto04:00
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC04:28
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto04:37
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto04:51
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto05:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:02
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has joined #yocto06:28
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:32
*** seebs <seebs!~seebs@24.196.59.174> has quit IRC06:35
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC06:38
*** seebs <seebs!~seebs@24.196.59.174> has joined #yocto06:44
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto06:48
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:49
*** yann|work <yann|work!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC06:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:54
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC06:56
iceawaySo 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
iceawayThe 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 IRC07:00
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto07:02
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto07:03
LetoThe2ndiceaway: only thing that i can say ad-hoc is that we're using cpio.gz as the IMAGE_FSTYPE to bundle into fitImage07:07
LetoThe2ndmarex-cloud: ^^^^^ you can probably tell us more.07:07
marex-cloudThe dependency loops shouldn't be in recent oe versions07:08
iceawayLetoThe2nd: 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 #yocto07:10
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto07:31
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:00
palatehello :)08:04
*** prabhakar <prabhakar!c18ddb24@193.141.219.36> has joined #yocto08:06
prabhakarHello All, is it possible add COMPATIBLE_MACHINE_append in a bbappend file.08:07
LetoThe2ndprabhakar: sure08:08
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC08:08
prabhakarLetoThe2nd thank you08:08
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:12
prabhakarLetoThe2nd 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
qschulzprabhakar: do you want to modify a location whcih is already there or add a new one?08:14
prabhakarqschulz yes just the location of one source.08:15
qschulzprabhakar: you didn't answer the question :) modify or add a location?08:18
prabhakarI want to modify08:20
qschulzwhat are you trying to do exactly? (the correct asnwer depends on your use case)08:20
prabhakarqschulz 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 file08:22
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto08:22
smurrayprabhakar: it’s not pretty, but you can try to _remove the original uri and preprend the new one with =+08:22
smurrayprabhakar: though if your use case is local development using externalsrc is a saner08:23
smurrayapproach08:24
LetoThe2ndsmurray: get behind me, sanity.. i mean, stan!08:24
LetoThe2ndsatan, even.08:24
smurrayLetoThe2nd: heh08:24
smurrayLetoThe2nd: heh, the latest Periphery album is “HAIL STAN” ;)08:26
LetoThe2ndhrhrhr08:26
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC08:28
qschulzprabhakar: mmmmm are you sure you don't want to write a new recipe for that kernel instead?08:28
qschulzotherwise 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 honestly08:29
*** creich_ <creich_!~creich@2a02:8106:217:2100:d01:182b:8d17:626d> has joined #yocto08:30
prabhakarYes 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
qschulzI 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_recipe08:32
smurrayprabhakar: If you control the original recipe, you could move that line (kernel location, I’m guessing) into a variable that you could override easier08: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 well08:34
creich_BUT if i then again try to build the whole poky image (which hasthe package as a dep) that specific package fails again08: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 process08:35
creich_is there any mechanism that might influence the way that package got built during the image build?08:35
qschulzLetoThe2nd: do you happen to know if the parsing is parallelized?08:37
LetoThe2ndqschulz: nope, sorry.08:38
smurraycreich_: it’s hard to say, depends on what the failure is. I’ve seen that a few times, usually the recipe has an issue08:38
smurrayqschulz: that’s a question for RP, I can’t recall off the top of my head08:39
qschulzRP: then :) do you happen to know if the parsing is parallelized?08:39
*** seebs <seebs!~seebs@24.196.59.174> has quit IRC08:39
qschulzand 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/supported08: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 expect08:42
qschulzhttps://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 control08:42
qschulzthe directory location by setting the TMPDIR, TEMP or TMP environment variables."08:42
qschulzand... we have TMPDIR set which is a common one between all recipes08:43
creich_the root problem was that my host gawk is to new (5.0.1) and was complaining about 'namespace' to be a keyword08:43
qschulzcreich_: 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 #yocto08:43
creich_that happened when building libgpg-error08:44
creich_i try to build libgpg-error on the branch yocto-2.7.108:44
creich_bitbake core-image-sato --> fails08:45
creich_bitbake libgpg-error --> works08:45
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto08:45
creich_qschulz, thx, i am going to check08:45
*** seebs <seebs!~seebs@24.196.59.174> has joined #yocto08:47
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto08:48
smurrayqschulz: 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 value08:53
*** prabhakar <prabhakar!c18ddb24@193.141.219.36> has quit IRC08:55
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08: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 image08: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 stuff08:57
creich_when building the package directly i could easily go and clean the related stuff using 'bitbake -c cleanall libgpg-error'08:57
qschulzsmurray: 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
smurraycreich_: did you do “devtool modify” or the like on it? That’s how it’d be trying to build it from there09:00
*** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has joined #yocto09: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-error09:02
creich_so i simple renamed it and tried to rebuild09:02
creich_basically that is my first 'how to patch stuff' attemt09:02
creich_after i tried building the lib for itself and everything looked good, i tried to continue building the image09:03
creich_i am bulding poky for an raspi btw09:03
smurraycreich_: hmm, not sure why it not pick up that version in the image build, odd09:04
qschulzsmurray: 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 while09:06
creich_ok, i guess i got it... it looks like there was some kind of 'variant' built.... libgpg-error-native09: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 pacakge09:10
qschulzcreich_: 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
qschulzcreich_: native packages (which are built for use on the host, so where Yocto is run) can be compiled differently09:10
creich_can i get a list of all those variants?09:11
qschulzso cleanall wouldn't help much09:11
creich_makes sence that they might be built differently09:11
qschulzcreich_: wdym? there is -native, nativesdk- packages and then you have multilib (usually lib32- but can be something else)09:11
qschulzor should I say recipes instead of packages even though you can have all of the aforementioned one handled in the same recipe09:12
creich_i jsut didn't see why 'bitbake libgpg-error' didn't build all of those variants09:12
creich_ah ok, i start to ge it09: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 lot09:14
qschulzcreich_: 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
qschulznative, nativesdk and multilib are exceptions, you can bitbake them even though they don't have a recipe named after them09:16
qschulzcreich_: for native and nativesdk yes, not multilib ones09: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 IRC09:21
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC09: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 recipe09:47
creich_i guess i have to read more docu about how to go from there09:48
creich_thanks a lot guys :D09:48
*** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has left #yocto10:01
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto10:03
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has quit IRC10:03
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has joined #yocto10:09
*** palate <palate!~palate@unaffiliated/palate> has quit IRC10:13
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC10:21
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto10:45
cengiz_iohello there. I'm using `thud` branch and using my `meta-toolchain` output on an Arch Linux machine.10:58
cengiz_iowhenever 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_iocan anyone, for the love of god and all holy angels and cat babies, help me?10:58
cengiz_ioabout to pull my last remaning hair folliciles10:59
LetoThe2ndcengiz_io: no need to be so cheesy. have you checked if perl is properly installed and working?11:04
LetoThe2ndcengiz_io: -> https://www.archlinux.org/packages/core/x86_64/perl/files/11:04
cengiz_ioLetoThe2nd why do you call me cheesy? I couldn't understand the reason11:06
LetoThe2nd10:58 < cengiz_io> can anyone, for the love of god and all holy angels and cat babies, help me?11:06
LetoThe2ndif that is not cheessy, i don't know how to call it, sorry. :D11:07
cengiz_ioLetoThe2nd: 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); ;EOF11:09
cengiz_ioworks11:09
cengiz_ioso I think my host machine's perl has Time::HiRes module11:09
cengiz_ioperl (v5.30.0)11:10
cengiz_iobut 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_iocan I be missing something in local.conf perhaps?11:11
LetoThe2ndcengiz_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 artifact11:11
cengiz_ioLetoThe2nd didn't know that.11:11
cengiz_ioI was just trying to get a toolchain so that I can give out to developers while I prepare the machine image.11:12
LetoThe2ndplus, https://community.nxp.com/thread/44958511:12
cengiz_iothey are compiling Qt apps to be run inside my image11:12
cengiz_ioLetoThe2nd that last link is not relevant at all. it's for adding the modules *inside* the resulting image11:13
cengiz_iomy error comes from using this `source /opt/fslc-framebuffer/2.6.3/environment-setup-armv7at2hf-neon-fslc-linux-gnueabi`11:13
LetoThe2ndit might still be necessary to manually add to the generated toolchain. (which would probably be a bug)11:14
LetoThe2ndbut anyways, i'd really start with an image derived sdk11:14
rburtoncengiz_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
rburtonif a image sdk works, please file a bug for meta-toolchain11:15
cengiz_iodidn't know that it's deprecated.11:15
LetoThe2ndcengiz_io: thats why we're telling you.11:15
cengiz_iodoes that image sdk add necessary files to my image tar.gz?11:15
LetoThe2ndit does not add anything to the image11:15
cengiz_iook great11:15
LetoThe2ndbitbake -c populate_sdk YOUR_IMAGE11:15
cengiz_iothank you LetoThe2nd and rburton11:16
LetoThe2nd-> https://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html11:16
LetoThe2ndlots of very good information!11:17
rburton2.7.1?11:17
cengiz_ioI need to compile tons of stuff by end of the day so I'm in a very bitter rush here. sorry for the misunderstandings11:17
LetoThe2ndrburton: first google hit, should be good enough11:18
* cengiz_io thinks things are getting even more confusing with eSDK11:27
* cengiz_io decided to print the relevant manual pages and read 11:28
LetoThe2ndcengiz_io: then use the classic, conventional sdk, no problem11:28
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:42
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto11:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:46
KlanticusHey 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
KlanticusThe 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
kroonKlanticus, IIRC devshell doesn't prune the environment, which bitbake does for scripts run from recipes11:48
KlanticusWell, that explains the difference11:49
Klanticusdo you know how to find out why env is not locating ruby inside bitbake?11:50
kroonKlanticus, do you have ruby-native in your DEPENDS ?11:50
KlanticusYeah, ruby-native is there and I have ' ASSUME_PROVIDED += "ruby-native"' on my local.conf11:51
kroonKlanticus, hmm.. i'd assume youre not supposed to do both11:51
Klanticusreally? 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 #yocto11:53
kroonKlanticus, I'd guess ruby-native in DEPENDS is not necessary then11:53
KlanticusThat's interesting... Let me try11:54
kroonKlanticus, maybe you need to extend HOSTTOOLS11:54
Klanticusyeah, had the same problem by just removing it from DEPENDS. I have now included ruby into HOSTTOOLS and it looked like it worked11:57
Klanticuskroon: Do you know whether I have to keep it into ASSUME_PROVIDED too, now that it's in HOSTTOOLS?11:58
kroonKlanticus, if you removed it from DEPENDS, id assume you don't need it in ASSUME_PROVIDED11:58
Klanticusso adding it to HOSTTOOLS will make bitbake just hard link the system one into the sysroot, right?12:00
kroonyeah12:00
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto12:00
Klanticuskroon: looks like it worked now. Thanks a lot! The explanation about ASSUME_PROVIDED wasn't really clear to me12:03
kroonKlanticus, you mean this one ? https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ASSUME_PROVIDED12:05
Klanticusyeah.. "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
KlanticusI thought it would just use the host ruby when I put it there12:06
kroonKlanticus, yeah, I can agree, could use some improvement12:06
kroonKlanticus, you can always improve it and send in a doc patch :-)12:06
KlanticusAs soon as I really understand it's meaning, I'll do it :)12:07
KlanticusI'm a bit new in the Yocto world12:08
*** prabhakarlad <prabhakarlad!c18ddb24@193.141.219.36> has quit IRC12:11
*** berton <berton!~berton@181.220.83.67> has joined #yocto12:12
*** berton <berton!~berton@181.220.83.67> has quit IRC12:13
*** berton <berton!~berton@181.220.83.67> has joined #yocto12:14
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC12:15
tgoodwinDoes anyone have experience seeing poky/bitbake/lib/bb/data.py pick a different KERNEL_PROVIDER in the inheritFromOS method?12:24
tgoodwinIt's only happening at one developer's desk.12:27
RPtgoodwin: some kind of ordering issue?12:30
RPtgoodwin: 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 sort12:30
RPtgoodwin: totally guessing12:31
tgoodwinRP: 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
RPtgoodwin: those aren't standard variables so its hard for me to say...12:31
tgoodwinRP: I just had them start their terminal session and the vars are gone. /shrug/12:32
tgoodwinI guess it was a PEBKAC.12:32
RPtgoodwin: sounds like it12:32
RPtgoodwin: its why we filter the env by default12:32
tgoodwinRight, but those two are whitelisted.12:33
RPtgoodwin: right, I'd guessed you were allowing them one way or another12:35
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto12:35
tgoodwinRP: It's interesting to get new folks onboard and see how things can go off the rails.12:36
tgoodwinI would love to see his bash history for that session.12:36
RPtgoodwin: I've seen lots of interesting things over the years :)12:38
fullstopcmake 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
fullstopIt seems to happen when it is attempting to generate the config12:41
rburtonfullstop: using cmake? on host? at build time? what recipe?12:41
fullstoprburton: on host, using cmake12:41
rburtonfullstop: all recipes using cmake, or just one?12:42
fullstoprecipe is something that I'm trying to put together, but the package itself is dlib.  This is not in any of the yocto / oe layers12:42
fullstopjust this oen12:42
rburtonsounds like the cmakelists is broken in some way then if cmake works for all the other recipes12:42
fullstopwell that's unfortunate12:42
rburtonlibproxy or taglib are fairly easy cmake using recipes to test12:42
fullstopis there a way to enable extra verbose information from cmake so that I have a better chance of tracking it down?12:43
fullstopI know of one option which triggers it, so I can slowly narrow it down..12:43
fullstopwow, --trace-expand is busy.  :-)12:44
*** ThomasD13 <ThomasD13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto12:44
fullstopand 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 #yocto12:45
rburtonmaybe try #cmake12:46
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC12:46
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC12:46
JPEWRP: Hmm, it was working a few weeks ago right?12:46
JPEW(Hash equivalence that is)12:47
RPJPEW: yes. Something is wrong but not sure quite where/what12:47
RPJPEW: its writing out two different hashes for the same task into locked sigs locally12:47
JPEWRP: Yuck.12:47
RPJPEW: My meta-sdk change is suspicous, as is Jaewon's esdk change but local reverts say they're ok12:49
JPEWRP: 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
JPEWMy worry is that writing a test case that actually detects it might be difficult12:51
RPJPEW: I don't know. It can be very very hard to reproduce this kind of problem in a test case without knowing the root cause12:51
JPEWRP: Fair12:51
ThomasD13Hi. Does someone else have also problems to build a eSDK?12:51
RPThomasD13: I'm talking about master-next and hash equivalence so problems you're unlikely to be hitting12:52
ThomasD13Okay :)12:53
RPJPEW: I just found its my meta-ext recipe change12:53
RPJPEW: which is clearly why it shouldn't be writing to sstate and it was designed that way12:53
RPJPEW: a revert is a preexisting build isn't enough12:54
ThomasD13Nevertheless: 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
ThomasD13Package '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
ThomasD13I 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
ThomasD13So, is the right way to change this line, that the layer does not get excluded anymore?13:01
LetoThe2ndThomasD13: nope, the problem is probably that your layer is located beneath poky, which is a bad practise13:03
ThomasD13LetoThe2nd this is my structure: https://pastebin.com/X58qHkhT13:04
ThomasD13"meta-ibg" is my layer. I thought that would be the right place?13:05
LetoThe2ndThomasD13: well... actually i find the constealltion pretty bad.13:06
LetoThe2ndThomasD13: your build is inside poky, for example13:06
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC13:07
__angelohi, adding package "zip" but for some reason bitbake -g is not carching it ..13:07
LetoThe2ndThomasD13: i always recommend something like https://pastebin.com/g1pP2f8A13:07
ThomasD13LetoThe2nd okay. I'll try to fix that. Do you really think thats the cause for my problem?13:09
LetoThe2ndThomasD13: i at least guess it. no guarantees.13:09
RPThomasD13: have you tried removing that line about "being auto-generated"13:10
RPThomasD13: if its become a layer in its own right its probably not needed/appropriate any more?13:10
ThomasD13LetoThe2nd: 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
RPbtw, does anyone fancy a "simple" optimisation issue to work on: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 ?13:11
yoctiBug 13539: enhancement, Undecided, ---, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK13:11
LetoThe2ndThomasD13: well thats what i do and recommend, because that way you get a clean structure for SCMs13:11
ThomasD13RP: 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 way13:11
RPThomasD13: its where I would have started but LetoThe2nd may be right about structure too13:12
ThomasD13Okay thanks guys. I try to relocate the directories and see if that solves my issue13:13
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:16
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto13:18
palatehej :)13:18
palateWhat 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
LetoThe2ndpalate: usually an append that includes the file in SRC_URI13:19
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto13:19
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC13:19
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto13:19
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC13:23
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC13:24
palateLetoThe2nd: 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 #yocto13:28
qschulzpalate: 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 recipe13:30
palateok, let me check that13:31
qschulzwhich AFAICT, is directly in "files"13:31
qschulzthe FILESEXTRAPATHS magic will then do its work, you need one line in the bbappend and the interfaces file in the dir you put in FILESEXTRAPATHS13:32
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto13:32
RPJPEW: even with that reverted the esdk tests fail with hash mismatches13:38
JPEWRP: Did reverting it fix the other failures?13:39
RPJPEW: yes, but there is the original problem that patch was for13:40
JPEWRP: 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
JPEWRP: Do you have a link to the failed test handy?13:41
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC13:42
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC13:44
RPJPEW: I was reproducing locally with a "bitbake core-image-sato -c testsdkext" for qemux86-6413:44
RPJPEW: I don't have an online link for the exact failures there are a lot of different things on the autobuilder :(13:44
JPEWRP: OK, all I really wanted was how to start the test13:45
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC13:50
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto13:51
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC13:52
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto13:55
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has joined #yocto14:01
*** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto14:02
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC14:04
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto14:04
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC14:06
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto14:07
*** sk_tandt__ <sk_tandt__!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC14:10
*** quijote <quijote!~dqx@unaffiliated/dqx> has quit IRC14:11
*** quijote <quijote!~dqx@unaffiliated/dqx> has joined #yocto14:13
*** armpit <armpit!~armpit@2601:202:4180:c33:5563:62f6:a44e:1984> has quit IRC14:14
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto14:19
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto14:20
ThomasD13Some basic question: Whats the difference between branches warrior and warrior-next?14:35
rburton-next for any branch is the staging area for new patches14:48
rburtonpatches in it may be altered, removed, etc.  when theyre all good, merged to warrior14:48
rburtonditto for master vs master-next, etc14:48
ThomasD13alright, thank you rburton14:50
*** armpit <armpit!~armpit@2601:202:4180:c33:f8c7:8a0b:73aa:3f22> has joined #yocto14:52
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC14:57
*** ThomasD13 <ThomasD13!d472ff94@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC14:57
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:00
qschulzTrying 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
qschulzin 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 set15:02
cengiz_ioHello 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_iobecause it contains hardcoded paths to it15:10
cengiz_ioaccording to the docs you've sent, sdk can be on different machines.. isn't that the whole point?15:11
cengiz_ioLetoThe2nd: `FSLC FrameBuffer Extensible SDK installer version 2.6.3` to be exact15:12
cengiz_iobuilt*15:12
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC15:14
LetoThe2ndcengiz_io: no, you should be able to take and install it anywhere, as long as the prerequisites are all installed15:15
cengiz_ioso 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.sh15:15
cengiz_ionativesdk-standalone seems to be installed in /opt/ by default15:16
LetoThe2ndthat both sounds strange.15:16
LetoThe2ndlet me check15:17
cengiz_ioMACHINENAME-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 #yocto15:25
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC15:27
__angelogetting this error on postinst scrplets "systemctl: error: argument command: invalid choice: 'disable' (choose from 'enable', 'mask', 'preset-all')"15:38
fullstoprburton: seems to be a cmake bug with respect to cuda and at which level enable_language(CUDA) is called.15:39
rburtonfun!15:39
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC15:41
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC15:56
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto15:59
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto15:59
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:05
*** yacar_ <yacar_!~yacar@80.215.47.50> has quit IRC16:07
LetoThe2ndcengiz_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.sh16:09
LetoThe2ndcengiz_io: located under tmp/deploy/sdk16:09
LetoThe2ndah, now i got it. the first part is the distro, and yours probably is "fslc-frambuffer"16:09
LetoThe2ndyes, then it makes sense16:10
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto16:11
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:13
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:14
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:18
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto16:20
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto16:26
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC16:40
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC16:42
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto16:42
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC16:45
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC16:53
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto16:54
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto16:55
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto17:00
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC17:05
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-ymhodbfrisspmugd> has quit IRC17:09
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto17:13
*** asabil <asabil!~asabil@81.167.213.26.static.lyse.net> has quit IRC17:14
fullstopis 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 IRC17:52
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:52
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto17:53
*** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto17:56
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto17:59
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC18:00
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto18:00
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto18:04
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC18:04
*** palate <palate!~palate@unaffiliated/palate> has quit IRC18:06
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:09
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto18:10
*** frsc <frsc!~frsc@200116b824cb7a00f50f81bba1ca7221.dip.versatel-1u1.de> has quit IRC18:11
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC18:13
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:21
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto18:38
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has quit IRC18:40
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC18:47
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto18:48
LetoThe2ndfullstop: sometimes qemu is used to do things that have to be done on the target arch. i think fontconfig uses it, for example18:52
fullstophmm18:52
fullstopI 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 IRC18:58
*** rewitt <rewitt!rewitt@nat/intel/x-rulvxtbevayeutjl> has joined #yocto18:59
*** yann|work <yann|work!~yann@lfbn-1-3378-31.w90-127.abo.wanadoo.fr> has joined #yocto19:00
*** yann|work is now known as yann19:00
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC19:11
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC19:18
marler899722Hey, 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 tools19:26
rburtonfullstop: glib cross-builds fine19:26
fullstoprburton: 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
fullstopah, it uses meson19:32
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has joined #yocto19:49
marler899722nevermind, it looks like the environment script is generated by toolchain-scripts.bbclass, and it's not meant to be extended19:50
RPJPEW: could you reproduce out of interest?19:54
mischiefhow the heck do i pass extra cflags to a kernel build?19:58
JPEWRP: Got side tracked by my day job, I'll retry overnight19:59
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has joined #yocto20:00
RPJPEW: fair enough :)20:00
RPJPEW: I can't even get bugs to reproduce :/20:00
zeddiimischief, 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 kludgey20:00
mischiefargh, okay20:03
mischiefi have a warning about duplicate const in this vendor code, but it seems to only abort the build because of Werror20:04
mischiefi 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 IRC20:31
RPkanavin: not sure if https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 would interest you or not?20:33
yoctiBug 13539: enhancement, Medium+, 2.8 M4, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK20:33
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC20:35
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto20:36
marler899722Does this seem unexpected to anyone? FOO ?= "a"   FOO_someoverride_append = "b"    (Foo is now "b")     Anyone know why bitbake works this way?20:37
marler899722And if you remove "_someoverride", then Foo is "ab"20:37
marler899722I think if you originally set FOO = "a", it's the same thing as well20:38
RPmarler899722: not unexpected20:38
RPmarler899722: it expands RHS first20:38
RPso FOO_someoverride_append = "b" becomes FOO_someoverride = "b"20:39
marler899722that's not what's unexpected20:39
marler899722it's that it ignores the non-override set20:39
marler899722but if you're append deosn't have an override, then it uses the non-override set20:39
RPmarler899722: so for FOO = "a" FOO_someoverride = "b" what do you expect?20:40
marler899722"b"20:41
RPright20:41
marler899722oh20:41
marler899722so if it was FOO_append_someoverride, then what would it be?20:41
RPthat is quite different20:41
RPab20:41
marler899722trying to wrap my head around that...20:43
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC20:43
marler899722ok I think I get it20:44
marler899722thanks for the help20:44
kergothit'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
kergoththere it is, https://www.yoctoproject.org/docs/2.0/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples20:44
marler899722thanks for the link, will read20:44
kergothnp20:45
RPmarler899722: I try and process these things reading from the right hand side which is also what bitbake does20:45
kergothyeah, thinking of it as RHS first is a good idea, easier to grasp. good call20:45
marler899722yeah it makes more sense when I think of it that way20:45
kergothwonder if we sould mention that specifically int he docs20:45
RPkergoth: could be an idea20:46
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC20:46
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC20:46
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto20:47
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC20:47
*** Klanticus <Klanticus!~quassel@189.76.136.210> has joined #yocto20:47
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto20:48
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC20:52
marler899722Ok, what do you think this one will do? OVERRIDES = "foo"  A = "1"  A_append = "2"  A_append_foo = "3" ???20:57
neverpanic12320:58
RPshould be 123 as appends stack20:58
marler899722so you can't "override" an append20:58
neverpanicIf you want 13, use OVERRIDES = "foo" A = "1" A_append = "${BAR}" BAR = "2" BAR_foo = "3"20:58
neverpanicCould have fooled me today as well, I seriously doubted for a second whether A_remove = "a" A_remove = "b" did even make sense20:59
marler899722based on what I read in that section, I think this case also deserves an explanation20:59
RPmarler899722: a patch would be most welcome21:00
marler899722ugh, sending patches is difficult for me as I'm behind a proxy and git send-email doesn't work behind a proxy21:01
RPmarler899722: maybe file a bug then with the suggested change?21:01
marler899722I could do that21:01
marler899722it's on my todo21:01
neverpanicStupid 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
marler899722I do use socat21:02
*** berton <berton!~berton@181.220.83.67> has quit IRC21:02
marler899722that's how I can push fetch git repos outside our network21:02
marler899722but git send-email ignores the proxy settings21:02
neverpanicwell, 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
marler899722hmmmm, might work, though I don't know if SMTP has any host headers that would need to be fixed21:03
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto21:04
neverpanicit does, but you might get away with putting 127.0.0.1 smtp.gmail.com into your /etc/hosts21:04
marler899722oh geeze21:05
marler899722yes that would certainly work21:05
marler899722I don't think I can bring myself to do it though...just seems so wrong21:05
RPmarler899722: 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 forwarding21:06
neverpanicwhat seems wrong is your proxy or your inability to use company email to contribute, if you ask me...21:06
neverpanicso you do what you must, and we've all been there at one point or another :/21:07
RPneverpanic: indeed21:07
marler899722true, but I weight that janky setup with how much pain do I want to put myself through just to get simple patches into yocto21:08
marler899722I 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 case21:09
RPmarler899722: perhaps the bugzilla then?21:10
marler899722yes, creating issues on bugzilla is fine21:11
marler899722I suppose I could put a patch in there too?21:11
RPmarler899722: yes, just mention you can't send to the list due to firewall issues21:11
RPmarler899722: it means someone else will need to send for you (probably me) but its better than just forgetting the issue21:12
marler899722cool I will keep that in mind21:12
RPmarler899722: I'd look at the docs now but I'm in the middle of other stuff and have other problems :(21:12
marler899722speaking 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 file21:13
kergothmarler899722: 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
marler899722how do I change the env setup script to source it?21:15
kergoththere's an example of that right in meta-external-toolchain21:15
kergothyou don't need to. the main one already sources anything in environment-setup.d/ in the sysroot21:15
kergothhttps://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-sdk/sdk-env-external-toolchain/sdk-env-external-toolchain.bb21:15
marler899722oh21:15
kergothall you need is a recipe/package to install the fragment there21:16
kergothlike the above21:16
RPmarler899722: the 0/1 patch header came through, the patch was not there as a following 1/121:16
marler899722yeah I was told to just send the cover-letter, and people could look at the github link to see the patch21:17
marler899722So environment-setup.d must be special?  Does the recipe need the "-toolchain" suffix?21:17
kergothyeah that was my suggestion, since they can't use send-email directly, and gmail will mangle it otherwise21:17
kergothno, recipe name can be anything21:18
marler899722So you must just add that to TOOLCHAIN_TARGET_TASK?21:18
kergothhttps://github.com/openembedded/openembedded-core/blob/e38e56e28f2090e2b8013546f4dd76da8d59f766/meta/classes/toolchain-scripts.bbclass#L10621:19
kergothyep, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/conf/distro/include/tcmode-external.inc#n3521:19
marler899722awesome21:19
kergothit 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 any21:20
RPmarler899722: A note saying there would be no 1/1 would have helped as I assumed it would come later (it never did)21:20
kergothmost cases it won't matter, though21:20
marler899722RP: will remember that for next time21:21
RPmarler899722: 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 deterministic21:24
RPmarler899722: its looks like a valid bug though21:24
marler899722yeah that's one way to fix the determinism21:24
marler899722although, I think going one step further to assert an error with multiple would be better21:25
RPmarler899722: initially I was thinking it was related to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=41a5dbd16b0c9f5f97e7a160830cf7ca5de52ec621:25
RPmarler899722: yes, I'd probably bb.error, not fatal though21:25
marler899722sounds reasonable21:25
marler899722changed21:26
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC21:27
RPmarler899722: 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
neverpanicIsn't it kind of a bad habit to have more than one shlib provider for the same lib anyway, though?21:28
RPneverpanic: yes, showing an error would therefore be good21:28
marler899722Can do21:28
neverpanicRight, but shouldn't http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/package.bbclass#n1788 be turned into an error then?21:30
marler899722rebased and fixed commit message21:30
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto21:32
RPmarler899722: sorry, one more thing. Can we add a sorted in there please so it is deterministic :)21:33
marler899722that would only affect the determinism of the error message21:33
marler899722do you still want it?21:33
RPmarler899722: The error will flag the exit code and trigger CI failure but keep building so yes please21:34
marler899722ok, changed21: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
marler899722ah, that's why you wanted bb.error21:35
RPIts just in keeping with the rest of the code21:35
RPmarler899722: thanks, I'll queue that. I'll have to send for mailing list patch review21:36
marler899722thanks21:37
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto21:38
*** opennandra <opennandra!~marek@adsl-dyn-107.95-102-61.t-com.sk> has joined #yocto21:49
opennandrahi21:49
opennandraI 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
neverpanicideally the Makefile would be fixed to append to whatever flags Yocto provides in the environment21:52
neverpanicUnexpected things can happen when build systems ignore the flags Yocto wants them to use21:52
kergothCFLAGS in a makefiel should never be overridden by cflags in the environment unless the makefile uses ?=, or you have -e in EXTRA_OEMAKE21:55
opennandrakergoth: I have this in recipe: EXTRA_OE_MAKE = "CUSTOMER_VERSION=COMMON1 V=1"21:56
kergothit'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
opennandrabut looking at run.do_compile it adds automatically adds:  make -j 12 -e MAKEFLAGS=21:57
opennandrakergoth: Makefile use: CFLAGS += -Wall -g21:58
kergoththat's becuase you didn't set EXTRA_OEMAKE.22:01
kergothif you did, it wouldn't append -e MAKEFLAGS=, that's the default value of EXTRA_OEMAKE22:01
kergothlike i said, it's EXTRA_OEMAKE, not EXTRA_OE_MAKE :)22:01
opennandrakergoth: yes you're right22:02
*** Klanticus <Klanticus!~quassel@189.76.136.210> has quit IRC22:02
kergoththe -e argument is causing your issue, it tells make to let the environment override vars in files22:02
opennandranot I get CFLAGS from Makefile but CFLAGS from yocto are lost (I would need at least sysroot)22:03
kergothsysroot isn't in cflags, it's in cc22:03
kergothand it shouldn't be lost if it's using +=, that means append, not set22:03
kergothif you're going to override EXTRA_OEMAKE, you really need to explicitly pass every variable in22:04
kergothwell, not always, but usually22:04
kergothsince most mkakefiles don't use ?= for vars like CC22:04
kergothso you'd want to do i.e. 'CC=${CC}' in your EXTRA_OEMAKE, along with any other vars it will obey22:04
opennandrakergoth: yes sorry you're right CFLAGS are OK (ones from Makefile + from yocto)22:04
kergothyou have to read the underlying makefiles to know what it obeys in what contexts22:04
opennandrafatal error: stdio.h: No such file or directory22:04
opennandra|  #include <stdio.h>22:04
kergoththis is the downside to using custom amkefile based buildsystems, there's no standards, it's case-by-case22:05
opennandrabut it drop sysroots path22:05
kergothyeah, it's not obeying CC22:05
opennandrashould I pass somehow sysrootfs?22:05
kergothagain, it's in CC22:05
kergothgrep for CC= or EXTRA_OEMAKE in oe-core, you'll find some recipes with examples of passing such variables in EXTRA_OEMAKE22:05
*** asabil <asabil!~asabil@2a01:79d:7375:2ca4:9507:3da0:df33:ed28> has quit IRC22:05
neverpanicTBH, unless it's more than 20 source files, probably faster to write a simple CMakeLists.txt instead ¯\_(ツ)_/¯22:06
opennandraok adding CC=${CC} I move forward22:06
opennandrabut then again : s.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory22:06
opennandraneverpanic: it's proprietary binary for chinese camera and reading those makefiles I probably will bump my head to wall many many times :)22:07
opennandrajust want ot make it compilable by yocto and I win :D22:08
neverpanicAh yes, been there, seen that. My condolences :/22:08
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC22:08
kergothyou'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, etc22:09
kergothor 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 case22:10
rburtonyay plain makefiles22:10
opennandraI'll start thinking about rewriting it in cmake :)22:11
kergothugh. as much as i dislike autoconf, i'd rather that that something homerolled, anyday.22:11
marler899722what's your take on meson vs cmake?22:12
neverpanicmeson seems pretty usable and gets things right22:12
marler899722I've contribued to CMAKE, and the parts had to touch were quite ugly22:12
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto22:13
neverpanicCMake tends to have awkward syntax and its "standard library" isn't really very helpful in some cases22:13
kergothyeah.. i can't say i enjoy working with cmake at all22:13
neverpanicModern 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
marler899722yeah, I think you can do CMAKE well if you know what you're doing22:14
opennandraI think cmake is better like ninja :)22:14
kergothhttps://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ comes to mind22:14
neverpanichttps://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
marler899722opennandra: what's better?22:14
kergothha :)22:14
neverpanickergoth: ha!22:14
rburtonmarler899722: meson is awesome use meson22:15
opennandraI 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 it22:15
marler899722meson also uses ninja22:16
opennandraI 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 IRC22:18
opennandraother 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 toolchain22:20
kergothusually you also need to set EXTERNAL_TOOLCHAIN to the toolchain path22:20
marler899722I'm compiling thud with linaro22:20
kergothbut that's probably enough22:21
kergothsee the layer readme, really..22:21
marler899722compiling thud with linaro version 7.3 and 7.422:21
opennandraok cool thanks22:21
opennandraI'll give a shot22:21
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:23
RPmarler899722: what advantage does the linaro toolchain have out of interest?22:23
marler899722Apparently it has more arm-specific optimization22:24
RPmarler899722: I see, was just curious22:25
neverpanicI'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
marler899722yeah that would be good to see22:25
opennandraI 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
behanwneverpanic: As has ARM, as has Google, and many others.22:26
opennandraso currently use one from poky but in final I want to use linaro22:26
opennandrajust to be on safe side :D22:26
marler899722you say "poky", but which yocto branch are you on?22:27
neverpanicAnd the last time I looked at some assembly output of the linaro toolchain for debugging (granted that was years ago), there was obvious optimization potential22:27
opennandrapoky jethro22:27
neverpanicI think it was setting a register that it xor'd with itself right after22:27
neverpanicanecdotal, but I'd expect that would be a pretty simple optimization22:28
RPworld has changed a lot since jethro :/22:30
opennandraRP: yes this is true22:32
RPJPEW: I think there is a fix for the esdk issue in -next22:37
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC22:40
*** marler899722 <marler899722!0f41fc0d@ztxe01hpics303.austin.hp.com> has quit IRC22:48
*** opennandra <opennandra!~marek@adsl-dyn-107.95-102-61.t-com.sk> has quit IRC22:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:56
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC23:24
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto23:24
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC23:39
* armpit when does -next become -whenever ?? ; )23:44

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!