Tuesday, 2019-11-19

RPadelcast: I think I've perhaps done the best I can with this and it may be better to let you take a look from here00:01
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:01
RPadelcast: I'm hoping you can at least reproduce it now you know where the double free is and the kind of package that is triggering it00:01
RPadelcast: let me know if you need more info from me I guess or if I can help further00:02
adelcastthanks RP, I quickly looked at the ticket and I think I have everything I need to fix the particular bug00:03
adelcastafter that, I'll try to get rid of the error buffering00:03
adelcastI agree, that buffering is  just confusing00:03
RPadelcast: thanks, much appreciated!00:03
adelcastnp, =)00:04
RPadelcast: I still haven;t figured out how reproducibile builds generate empty packages but I'm not sure I want to know ;-)00:04
adelcasthehe, mm, well, I assume maybe those are virtual packages to group packagroups?00:05
*** armpit <armpit!~armpit@2601:202:4180:a5c0:a049:e40e:fb9e:4d3d> has quit IRC00:06
RPadelcast: yes, I'm guessing timestamps disappear from the tar file or something which makes it empty00:08
RPadelcast: and we probably only detect double free on some libcs00:08
RPhmm, locally it has module info in that package00:10
RPok, a problem for tomorrow, should sleep!00:12
*** likewise <likewise!~circuser-@145.132.74.106> has quit IRC00:12
RPadelcast: thanks again. I put my fix the double free patch into the bug, I suspect there is a bit more needed to avoid the underlying empty file error though00:13
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto00:30
*** vineela <vineela!~vtummala@134.134.139.83> has quit IRC00:43
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto00:46
*** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has joined #yocto00:53
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC01:14
*** vdehors_ <vdehors_!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC01:16
*** khem <khem!~khem@unaffiliated/khem> has quit IRC01:26
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has joined #yocto01:30
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto01:36
*** kaspter <kaspter!~Instantbi@58.38.93.197> has joined #yocto01:43
*** dv_ <dv_!~dv@62.178.50.190> has quit IRC01:46
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC01:47
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC01:54
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC01:58
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto02:00
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has joined #yocto02:03
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC02:04
*** kaspter <kaspter!~Instantbi@58.38.93.197> has quit IRC02:13
*** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto02:14
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC02:29
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto02:29
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC02:59
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto03:00
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC03:09
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto03:18
*** rcw <rcw!~rcw@unknown-6-52.windriver.com> has quit IRC03:47
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC03:47
*** armpit <armpit!~armpit@12.206.219.171> has joined #yocto03:52
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC04:37
moto-timokhem: if I want to include compiler on target image (but it might be gcc or musl)... best practices?05:18
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-yktwnucpoevgtygk> has joined #yocto05:19
khemmoto-timo: EXTRA_IMAGE_FEATURES_append = " tools-sdk packagegroup-core-buildessential"05:24
moto-timokhem: right. thank you. must be tired05:25
*** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto05:47
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto06:00
*** chandana73 <chandana73!~ckalluri@149.199.62.131> has quit IRC06:28
*** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC07:01
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has quit IRC07:06
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:07
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto07:11
*** hpsy <hpsy!~hpsy@85.203.15.122> has quit IRC07:24
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto07:25
*** johnnylintw <johnnylintw!~johnnylin@softbank126040025146.bbtec.net> has quit IRC07:26
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto07:37
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:39
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto07:42
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto07:46
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has quit IRC07:46
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:07
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto08:18
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto08:18
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto08:35
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto08:40
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto08:44
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto08:46
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto08:57
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto09:01
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-zxujeybqqwbxcbfk> has joined #yocto09:02
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto09:03
T_UNIXhi09:25
T_UNIXis my understanding correct, that the mesa recipe packages a copy of the *same* file for every driver?09:27
T_UNIXi.e. a copy of the megadriver?09:28
qschulzbluelightning: hi, I'm trying to get qt4-embedded to compile on warrior but that does not work well ATM. I fixed builds for qemux86, qemuarm, qemuarm64 and beaglebone-yocto and one error on qemux86-64 but the latter is still failing (missing lrelease in native-sysroot)09:59
qschulzbluelightning: the qt4-embedded issue on warrior is because GCC v8 now refuses to compile `asm volatile` lines. As per the documentation, volatile is the default qualifier for asm so we should be good removing it10:00
bluelightningqschulz: ok - if you could send your patch(es) I can apply them10:00
qschulzhowever, I saw this error only in some JavascriptCore JStubs file and nowhere else even though asm volatile is present in different files10:01
qschulzare you fine with a patch that is fixing the issues I saw even though it's not fixing all the `asm volatile` occurences?10:01
*** khem <khem!~khem@unaffiliated/khem> has quit IRC10:02
bluelightningqschulz: yep that's fine, if others become problematic they can be fixed as and when10:02
*** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC10:03
qschulzbluelightning: ok! Expect some mails today and if not, scream at me tomorrow :)10:04
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:07
*** florian_kc is now known as florian10:12
rburtonT_UNIX: no, it packages hardlinks10:16
T_UNIXok10:17
rburtonlook like in the mesa i have, there are two real libraries and lots of hardlinks10:18
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto10:25
*** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has quit IRC10:26
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:39
T_UNIXyeah. My fault. Got mislead by `scp -r` instead of `rsync -rH`10:42
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:43
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:47
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC10:51
LetoThe2ndwhen trying to use tmux on a rather simple image, i get "tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968"10:53
LetoThe2ndany pointers?10:53
LetoThe2ndmight the IAMGE_LINGUAS + GLIBS_GENERATE_LOCALES dance fix this?10:58
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto11:00
*** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto11:07
hyper_daveHey everyone, How do I download a file with SRC_URI with different name?11:13
hyper_daveI am using SRC_URI = "https://fonts.google.com/download?family=Roboto" and it is downloading a the file as download?familly=Roboto11:13
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC11:19
RPhyper_dave: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher11:20
RPLetoThe2nd: does sound like you need a locale installed11:21
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto11:21
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC11:24
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto11:24
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto11:26
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:38
*** bradleyb <bradleyb!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto11:39
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC11:40
*** berton <berton!~berton@181.220.83.67> has quit IRC11:44
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:45
LetoThe2ndRP: yeah something along those lines11:49
*** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC11:51
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC11:54
jofrIf recipe A required artifacts from recipe B, but only for building, does recipe B need a "do_install" section for putting everything into like a STAGING_DIR_NATIVE?11:58
jofrrequires*11:59
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:02
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:02
T_UNIXjofr: thats usually the difference betwenn `DEPENDS` and `RDEPENDS`. Where `R` is short for runtime.12:03
T_UNIXdo `A.bb` would contain a line like `DEPENDS += "B"`12:04
jofrYeah, I haven't been able to fully wrap my head around that. i.e. the full relation between DEPENDS vs. RDEPENDS and then native-recipes.12:04
T_UNIXdid you read about `cross-canadian` in the context of compilation?12:05
jofrYes yes.12:05
jofrSo in my head, native recipes are for doing basically what I want. Provide stuff that should be used at compile-time12:06
jofrBut what then is the difference between depending and rdepending on a native recipe?12:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto12:06
T_UNIXusually you need the `-native` version only if you need to execute an architecture binary tool12:07
jofr(when I say native, I mean a recipe the classextends and is used with the -native suffix)12:07
yoctiNew news from stackoverflow: About the use of yocto toaster? <https://stackoverflow.com/questions/58933755/about-the-use-of-yocto-toaster>12:07
T_UNIXjofr: look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/psplash/psplash_git.bb12:11
T_UNIXas you can see it invokes http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh12:11
T_UNIXwhich, in turn, invokes `gdk-pixbuf-csource`12:12
T_UNIXso `psplash` eventually requires `gdk-pixbuf-native`, which might `DEPENDS`ed on `libpng-native` to be built and `RDEPENDS` on `libpng-native` to execute.12:15
T_UNIXbut at the point of executing the recipe for `psplash`, it neglects the `DEPENDS` of `gdk-pixbuf-native` and only stages the files covered by mentioned `RDEPENDS`.12:16
T_UNIXwhich - in this very case - *might* be the same.12:16
T_UNIXjofr: if you think about linking architecture specific applications statically, it might make more sense.12:18
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has quit IRC12:22
rburtonjofr: B should install its stuff into the sysroot like normal.  A will depend on B, and A's sysroot has stuff from B in.12:22
jofrrburton: Ok. I'll make up some paths then  :)12:22
jofrBut thanks both of you  :)12:22
rburtonjofr: rdepending on a native recipe makes no sense at all12:23
jofrrburton: I just found out.. QA gave me a warning12:23
rburton(unless you're a native recipe)12:23
rburtonjofr: so native recipes are entirely for stuff that *runs* at build time.  if you've a recipe that just ships a pile of data that another recipe needs, then its still a target recipe.12:24
T_UNIXrburton: then, I assume, `-native` packages are depending on the corresponding `-native` version automagically? or are the handled in some parallel namespace?12:24
rburtonnot sure i understand, got a concrete example?12:25
jofrBut for such an do_install section.. I think I might be too verbose: {D}${STAGING_DIR_NATIVE}${includedir}?12:25
jofr(missing $)12:25
rburtonnot STAGING_DIR_NATIVE12:25
jofrAight.12:25
rburtoninstall like normal, ${D}${includedir}12:25
jofrThanks!12:25
rburtonone day we'll do something awesome and lock down writes during builds so do_install can't write into directories it shouldn't be writing into12:26
jofrrburton: And recipe A should DEPENDS on B-native?12:29
jofrOr RDEPENDS on B?12:30
T_UNIXjofr: `-native` is not necessary if your data is not architecture specific to your build system :)12:30
T_UNIXjofr: do you need the data to be there, when you want to execute A on the target?12:30
jofrNope. Recipe generates (among other things) a header-file that recipe A uses when building.12:31
jofrNope. Recipe B generates (among other things) a header-file that recipe A uses when building.12:31
jofrIt's a bit convoluted, I know. But those artifacts from B are required my more than recipe-A. i.e. there are multiple recipe-A's  ;)12:32
T_UNIXthen B should provide and create some `-dev` package and `A` should `DEPEND` on `B` :)12:33
*** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto12:34
rburtonjofr: definitely no native involved12:35
rburtonjofr: its not convoluteld: you've a recipe that generates a header.  put it in $D$includedir.12:35
rburtonyou'll then also get a B-dev package for if you want to rebuild A on target for free12:36
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto12:37
*** bigMT1 <bigMT1!~mtijbout@83-87-64-60.cable.dynamic.v4.ziggo.nl> has joined #yocto12:37
yoctiNew news from stackoverflow: Yocto recipes not found <https://stackoverflow.com/questions/57233257/yocto-recipes-not-found>12:37
jofrNice. Thanks!12:38
jofrNow. A completely different problem.12:38
jofrWhich I do have a workaround for, but I think it's ugly has hell.12:38
jofrI have a recipe for a custom-package. But I would like to do that build as a part of our CI-system, and that includes building for pull-requests. I'm having some SRC_URI problems, because in that case, the "Git-path" isn't a normal branch (refs/head), but rather a pull-branch (refs/pull). Anyone solved that problem before?12:42
jofrThe branch-name (and commit-hash as well actually) is passed as an evironment variable (which I have whitelisted and all that is fine), and I have Python snippet that mangles the SRC_URI to conditionally add the "nobranch=1" if that branch-name starts with "refs/pull".12:44
jofrIsn't there a better solution?12:45
*** hpsy <hpsy!~hpsy@46.183.103.8> has joined #yocto12:45
bigMT1Hi All, I am new to this chat. Learning my way in to Yocto (and IRC)12:47
jofrHi, bigMT1 :)12:49
qschulzbigMT1: welcome!12:49
*** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC12:49
*** hpsy <hpsy!~hpsy@46.183.103.8> has quit IRC12:49
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto12:50
jofrrburton: One last question. Recipe B installs its stuff to ${D}${includedir}, but what is the full-path on the other-side, from recipe-A's perspective?12:53
jofr${D} isn't the same on both sides, is it?12:53
jofr(I wish those variables were populated in the -c devshell)12:54
rburtonD is Destination12:55
qschulzjofr: it's going to be in recipe-sysroot (or recipe-sysroot-native if native package)12:55
rburtonwhen installing, write to D12:55
rburtonthe include file will just be in the sysroot like every other include file12:56
jofrYes.. But if I have other files where I need to specify their full path?12:57
qschulzjofr: IRL example?12:57
qschulz(IIRC, a few tools get a --sysroot argument from yocto before executing any stuff on the source code of recipes)12:58
bigMT1A newbie question i suppose: I have build a default image for a raspberry pi. It boots, but my keyboard does not work. The screen shows messages that identifies the keyboard when I (re-plug) the keyboard in another port. Any suggestions?12:59
rburtonjofr: STAGING_DATADIR etc will be the absolute path into the sysroot13:01
qschulzbigMT1: missing driver is the kernel13:01
qschulzis/in13:01
rburtonjofr: note that not everything is in the sysroot by default, ie $datadir isn't included unless you tell it13:02
jofrYeah, I think I should just explain the whole thing. So what I'm messing with is the u-boot-environment. I have an environment specified in a file. Then I have a Python parser that parses that file and makes it nice for a header-file which is then #defined as CONFIG_EXTRA_ENV_SETTINGS in u-boot. So what I used to do was generate that header and then copy it into ${S}/include/configs where ${S} has been defined as the WORKDIR/git for the u13:05
jofr-boot recipes. This header file is used by u-boot, but also for u-boot-fw-utils.13:05
jofrNow I've added another dependency on such an output, that one is actually not using the same parser, because the output-format needs to be slightly different, but it mangles the same u-boot-environment to make it compatible for passing to (U-Boot) fw_setenv --script (this can happed at update-time if required). That part actually doesn't need to go anywhere in the sysroot, I can just "deploy" it to the image-folder (similar to some other13:05
jofrfinal-artifacts).13:05
jofrSo, In order not to change my u-boot build too much, I would really like to copy this header to ${S}/include/configs in U-boot..13:06
qschulzwhy don't you use bbappends for U-Boot directly?13:07
qschulzput your logic in an .inc shared by both u-boot and u-boot-fw-utils and add them in bbappends so you don't duplicate code. But I feel like I'm suggesting something you didn't want or that is not fixing your issue, what am I missing?13:09
*** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto13:11
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC13:15
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC13:16
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto13:17
*** anujm <anujm!~anujm@134.134.139.76> has joined #yocto13:23
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto13:28
jofrqschulz: That's what I had at first. So I just had a "files" folder and in my bbappend, I copied my files/<custom-board>_defconfig, my files/<custom-board>.h (the one I'm talking about here), etc. into the appropriate places within ${S}. But then me and other people found it so annoying to maintain the <custom-board>.h with the #define CONFIG_EXTRA_ENV_SETTINGS, making sure that the newline-escapes (the "string" \ ) were always ok, etc. S13:56
jofro I created this parser-thing that takes a nicer input, where the environment can be properly indented and so on and turns it into the string required by #define CONFIG_EXTRA_ENV_SETTINGS.13:56
jofrNow the update-system has gotten a little more complicated than it used to be. The update didn't update u-boot at all, and actually still doesn't, but it may require changes to the u-boot environment. So at build-time, the environment that gets compiled into the new u-boot as the default-environment, also gets output to a file that's compatible with "fw_setenv --script" so it can be used to update the u-boot-environment on the target. Tha13:56
jofrt required another parser, because now instead of doing the "<string>" \ business, it needs to remove newlines from each variable and so on. That environment-file/script then gets released with the update.13:56
jofrSo what I have now is a recipe called "u-boot-extra-env-settings(.bb)" and everything that it entails. Then u-boot and u-boot-fw-utils depend on this new recipe, and that's how it now gets its <custom-board>.h file. But, then there's the update system. That's a recipe that creates a "package", which is just a zip-file that consists for the artifacts, a JSON-manifest and a update-shellscript. That recipe required this other output from "u-14:01
jofrboot-extra-env-settings".14:01
jofrs/for the artifacts/of the artifacts/14:03
*** xtron <xtron!~xtron@110.93.212.98> has joined #yocto14:08
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC14:11
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto14:25
qschulzjofr: find a way for u-boot to take header files from the sysroot, don't copy it from your custom recipe's syrsroot to u-boot icnlude/configs.14:30
qschulzjofr: also, maybe you can use your u-boot-extra-env-settings binary as a native tool in your u-boot* recipes and create the header file directly in your u-boot* source code14:31
*** anujm <anujm!~anujm@134.134.139.76> has quit IRC14:34
*** camus <camus!~Instantbi@222.67.188.180> has joined #yocto14:41
*** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC14:42
*** camus is now known as kaspter14:42
*** junland <junland!~junland@142.93.201.46> has quit IRC14:43
*** junland <junland!~junland@142.93.201.46> has joined #yocto14:45
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC14:47
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto14:51
hyper_daveHey everyone, How can I manually trigger the build of a package?14:52
hyper_davestarting from do_fetch14:52
JPEWbitbake -C fetch <recipe>14:52
hyper_daveOkay, thanks14:53
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto14:56
rburtonjust bitbake [recipe] will work unless you want to force a rebuild15:02
rburtonin which case -C fetch is the trick15:03
rburtoni prefer -C unpack if you don't need to force a re-download15:03
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC15:05
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC15:21
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC15:30
*** armpit <armpit!~armpit@12.206.219.171> has quit IRC15:31
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:45
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC15:59
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto16:05
*** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto16:16
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto16:17
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC16:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:21
*** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has joined #yocto16:25
*** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has joined #yocto16:26
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC16:28
RParmpit: am I up to date with patch merging for the stable branches?16:29
armpitlet me check16:30
RParmpit: FWIW I want to get this hashequiv fix I'm working on into zeus16:31
armpitRP, you are up to date16:32
armpitk16:33
RParmpit: great, thanks16:33
RPadelcast: I was thinking more about the error handling in opkg - I think the "easy" fix may be to leave the collected error code but *also* print it at the time it happens?16:41
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC16:54
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC17:02
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC17:02
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto17:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:08
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC17:15
*** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has joined #yocto17:16
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto17:17
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC17:18
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto17:18
*** mcfrisk <mcfrisk!mcfrisk@91.232.154.11> has joined #yocto17:20
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC17:25
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC17:33
*** bradleyb is now known as radsquirrel17:49
*** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has quit IRC17:49
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto17:50
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto17:50
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto18:08
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto18:09
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC18:30
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto18:31
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-zxujeybqqwbxcbfk> has quit IRC18:31
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC18:31
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto18:43
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC19:09
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto19:11
*** bigMT150 <bigMT150!5357403c@83-87-64-60.cable.dynamic.v4.ziggo.nl> has joined #yocto19:27
fullstopI am trying to be a good citizen when it comes to shared library sonames.  Yocto is forcing me to do so, actually.19:29
fullstopIn my project I am using opkg.  Let's say that a project, bar, links to libfoo.1.2.so.  Can I upgrade libfoo to libfoo.1.3.so (which are ABI compatible) without updating all of the packages which depend on libfoo?19:30
fullstopWhat happens to libfoo.1.2.so when the package is upgraded?19:30
fullstopand, yes, I mean libfoo.so.1.2 etc.19:31
fullstopI see for things like libglib executables link to libglib-2.0.so.0 which is a symlink to a specific version.19:34
frayif it's compatible, then the new version needs to provide BOTH 1.3 and 1.2 sonames19:35
frayusual failure is someone releases 1.3, with a 1.2 compatible ABI, but never defines BOTH the 1.3 and 1.2 sonames19:36
fraythe YP build system inspects libraries, and if they're not defined right you will get dependency errors19:36
fullstopI will aim for that19:37
fullstopnot the usual failure case, multiple sonames19:37
fullstopdoes that mean multiple -Wl arguments to ld?19:38
fraysorry I don't have an example offhand19:39
fullstopdarn.  I'll dig through recipes I guess.19:39
frayusuaully not recipe specific, but buried in the upstream code..19:40
fraybut ya, it's multiple -Wl arguments, just don't remember the format offhand19:40
fraygcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...19:41
fraytry specifying -soname multiple times19:41
frayrecipe processing will automatically see this, and setup everything19:41
fullstopI have libraries which, for better or worse, are done in a Makefile.. so I'm the buried upstream code at the moment.  :-)19:41
fullstoproger19:41
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has quit IRC19:42
*** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto19:44
*** bigMT150 <bigMT150!5357403c@83-87-64-60.cable.dynamic.v4.ziggo.nl> has quit IRC19:50
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto19:53
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC19:54
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC20:07
yoctiNew news from stackoverflow: Yocto generated linux modules do not contain all the drivers selected in config <https://stackoverflow.com/questions/58941714/yocto-generated-linux-modules-do-not-contain-all-the-drivers-selected-in-config>20:08
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto20:14
*** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has joined #yocto20:20
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC20:25
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:33
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC20:35
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto20:35
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto20:40
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-yktwnucpoevgtygk> has quit IRC20:55
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC21:04
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC21:32
*** berton <berton!~berton@181.220.83.67> has quit IRC21:33
yoctiNew news from stackoverflow: Unable to add Kernel Module in the final image <https://stackoverflow.com/questions/58943148/unable-to-add-kernel-module-in-the-final-image>21:39
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto21:46
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC21:46
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.151.27> has joined #yocto21:48
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC21:50
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto21:51
*** anujm <anujm!anujm@nat/intel/x-waqubbveqihrcpqf> has joined #yocto21:56
RPJPEW: an interesting dilemma. How do we clean things out of the hash equiv database when we realise something is broken?21:57
JPEWRP: Ya, that is a interesting situation21:58
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.151.27> has quit IRC21:59
JPEWRP: Did you run into a problem with that?22:00
RPJPEW: we have zero size broken packages in the sstate cache :/22:01
RPI'm just not sure how to clean them out :(22:01
RPI guess if I remove them the hadhequiv entry is less of an issue than the broken sstate22:02
JPEWRP: I would expect so... only another broken package should (theortically) be detected as equivalent22:02
JPEWBump PR on the broken recipes?22:03
RPJPEW: I don't know exactly which broke :(22:04
JPEWRP: Ah, well, that won't work then22:04
JPEWAre they completely empty?22:04
RPJPEW: yes, I think so22:04
*** camus <camus!~Instantbi@222.67.188.168> has joined #yocto22:05
*** kaspter <kaspter!~Instantbi@222.67.188.180> has quit IRC22:05
*** camus is now known as kaspter22:05
RPJPEW: well, they're packages with no files so they have control data but no actual files22:05
bigMT1Hi, I am trying to build an image for my Raspberry Pi. Using straightforward the poky warrior, meta-raspberrypi and meta-openembedded. I managed to boot it, it recognizes my keyboard but does not work. It has been suggested to include keyboard drivers to the kernel. How do I do this? Any help appreciated for this newbie.22:06
RPbigMT1: sounds like you need to change the kernel defconfig and add in the pieces you need, then rebuild22:06
JPEWRP: Ah, I was thinking that they might all have the same outhash in the hashequiv database, but even if they were completely empty, it still wouldn't be the case because the outhash has a few recipes specific vars hashed in22:06
bigMT1RP: Do you have an example or a link at hand?22:07
RPbigMT1: I'm afraid not22:07
RPJPEW: right, its not a simple issue :/22:08
*** vam52 <vam52!~user@sgs-vb-128.vb.sgsnet.se> has joined #yocto22:08
JPEWRP: Anyway, I still think that the hashequiv part isn't a huge deal... it would only match in the event you re-created that same output anyway (which seems unlikely).22:08
vam52Hi all, does anyone know why attr depends on kernel?22:09
JPEWThe other option is to delete all hashequiv recipes for the broken recipes (assuming you can find which they are, which appears the be the bigger problem)22:09
vam52"attr.do_build" -> "linux-yocto.do_deploy"22:12
vam52it is not clear from the recipe =\22:12
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto22:13
RPJPEW: what is worrying me is how this problem persisted over some changes :/22:14
RPsomething isn't adding up22:14
JPEWRP: Was it undetected?22:14
RPJPEW: I added some tests to do_package so empty packages are detected. I'm assuming I fixed the hash equiv runqueue issue that generated them. I guess I should change it again to make it error, that should invalidate all hashes. I guess it means there is still a latent runqueue bug22:17
RPtoo many different issues at once :(22:17
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto22:18
JPEWRP: 59b7001767d ("bitbake: runqueue: Fix hash equivalence duplicate tasks running") ?22:20
JPEWI *think* that change won't cause the taskhashes to change, meaning the hashequivalence server won't know the hashes are equivalent.22:21
JPEW*aren't equivalent22:21
RPJPEW: That won't but the package.bbclass change in OE-Core will22:24
JPEWRP: Sorry, I have to go :( You might be able to find the taskhashes before and after than change in the database and validate that they do indeed have distinct outhashes?22:30
RPJPEW: np, thanks. I need to think further about what is going on I guess22:36
*** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC22:46
*** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto22:46
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC22:48
*** vineela <vineela!~vtummala@134.134.137.73> has quit IRC23:00
*** vineela <vineela!vtummala@nat/intel/x-omzjbgoaqjvrfvzi> has joined #yocto23:00
*** anujm <anujm!anujm@nat/intel/x-waqubbveqihrcpqf> has quit IRC23:07
*** vineela <vineela!vtummala@nat/intel/x-omzjbgoaqjvrfvzi> has quit IRC23:07
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC23:13
*** anujm <anujm!~anujm@134.134.137.75> has joined #yocto23:23
*** vam52 <vam52!~user@sgs-vb-128.vb.sgsnet.se> has quit IRC23:27
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC23:28
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto23:32
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC23:36
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC23:45

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!