| RP | adelcast: I think I've perhaps done the best I can with this and it may be better to let you take a look from here | 00:01 |
|---|---|---|
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:01 | |
| RP | adelcast: 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 it | 00:01 |
| RP | adelcast: let me know if you need more info from me I guess or if I can help further | 00:02 |
| adelcast | thanks RP, I quickly looked at the ticket and I think I have everything I need to fix the particular bug | 00:03 |
| adelcast | after that, I'll try to get rid of the error buffering | 00:03 |
| adelcast | I agree, that buffering is just confusing | 00:03 |
| RP | adelcast: thanks, much appreciated! | 00:03 |
| adelcast | np, =) | 00:04 |
| RP | adelcast: I still haven;t figured out how reproducibile builds generate empty packages but I'm not sure I want to know ;-) | 00:04 |
| adelcast | hehe, 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 IRC | 00:06 | |
| RP | adelcast: yes, I'm guessing timestamps disappear from the tar file or something which makes it empty | 00:08 |
| RP | adelcast: and we probably only detect double free on some libcs | 00:08 |
| RP | hmm, locally it has module info in that package | 00:10 |
| RP | ok, a problem for tomorrow, should sleep! | 00:12 |
| *** likewise <likewise!~circuser-@145.132.74.106> has quit IRC | 00:12 | |
| RP | adelcast: 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 though | 00:13 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto | 00:30 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has quit IRC | 00:43 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 00:46 | |
| *** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has joined #yocto | 00:53 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC | 01:14 | |
| *** vdehors_ <vdehors_!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC | 01:16 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 01:26 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has joined #yocto | 01:30 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 01:36 | |
| *** kaspter <kaspter!~Instantbi@58.38.93.197> has joined #yocto | 01:43 | |
| *** dv_ <dv_!~dv@62.178.50.190> has quit IRC | 01:46 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 01:47 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 01:54 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC | 01:58 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 02:00 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has joined #yocto | 02:03 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 02:04 | |
| *** kaspter <kaspter!~Instantbi@58.38.93.197> has quit IRC | 02:13 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto | 02:14 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 02:29 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 02:29 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 02:59 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 03:00 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 03:09 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 03:18 | |
| *** rcw <rcw!~rcw@unknown-6-52.windriver.com> has quit IRC | 03:47 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 03:47 | |
| *** armpit <armpit!~armpit@12.206.219.171> has joined #yocto | 03:52 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 04:37 | |
| moto-timo | khem: 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 #yocto | 05:19 | |
| khem | moto-timo: EXTRA_IMAGE_FEATURES_append = " tools-sdk packagegroup-core-buildessential" | 05:24 |
| moto-timo | khem: right. thank you. must be tired | 05:25 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto | 05:47 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 06:00 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.131> has quit IRC | 06:28 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC | 07:01 | |
| *** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 07:06 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:07 | |
| *** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 07:11 | |
| *** hpsy <hpsy!~hpsy@85.203.15.122> has quit IRC | 07:24 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 07:25 | |
| *** johnnylintw <johnnylintw!~johnnylin@softbank126040025146.bbtec.net> has quit IRC | 07:26 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto | 07:37 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:39 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 07:42 | |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto | 07:46 | |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has quit IRC | 07:46 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:07 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 08:18 | |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto | 08:18 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 08:35 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 08:40 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 08:44 | |
| *** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto | 08:46 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 08:57 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:01 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-zxujeybqqwbxcbfk> has joined #yocto | 09:02 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:03 | |
| T_UNIX | hi | 09:25 |
| T_UNIX | is my understanding correct, that the mesa recipe packages a copy of the *same* file for every driver? | 09:27 |
| T_UNIX | i.e. a copy of the megadriver? | 09:28 |
| qschulz | bluelightning: 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 |
| qschulz | bluelightning: 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 it | 10:00 |
| bluelightning | qschulz: ok - if you could send your patch(es) I can apply them | 10:00 |
| qschulz | however, I saw this error only in some JavascriptCore JStubs file and nowhere else even though asm volatile is present in different files | 10:01 |
| qschulz | are 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 IRC | 10:02 | |
| bluelightning | qschulz: yep that's fine, if others become problematic they can be fixed as and when | 10:02 |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 10:03 | |
| qschulz | bluelightning: 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 #yocto | 10:07 | |
| *** florian_kc is now known as florian | 10:12 | |
| rburton | T_UNIX: no, it packages hardlinks | 10:16 |
| T_UNIX | ok | 10:17 |
| rburton | look like in the mesa i have, there are two real libraries and lots of hardlinks | 10:18 |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 10:25 | |
| *** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has quit IRC | 10:26 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:39 | |
| T_UNIX | yeah. My fault. Got mislead by `scp -r` instead of `rsync -rH` | 10:42 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:43 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:47 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 10:51 | |
| LetoThe2nd | when 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 |
| LetoThe2nd | any pointers? | 10:53 |
| LetoThe2nd | might the IAMGE_LINGUAS + GLIBS_GENERATE_LOCALES dance fix this? | 10:58 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 11:00 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto | 11:07 | |
| hyper_dave | Hey everyone, How do I download a file with SRC_URI with different name? | 11:13 |
| hyper_dave | I am using SRC_URI = "https://fonts.google.com/download?family=Roboto" and it is downloading a the file as download?familly=Roboto | 11:13 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 11:19 | |
| RP | hyper_dave: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher | 11:20 |
| RP | LetoThe2nd: does sound like you need a locale installed | 11:21 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 11:21 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 11:24 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 11:24 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 11:26 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:38 | |
| *** bradleyb <bradleyb!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 11:39 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 11:40 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:44 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:45 | |
| LetoThe2nd | RP: yeah something along those lines | 11:49 |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 11:51 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 11:54 | |
| jofr | If 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 |
| jofr | requires* | 11:59 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 12:02 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:02 | |
| T_UNIX | jofr: thats usually the difference betwenn `DEPENDS` and `RDEPENDS`. Where `R` is short for runtime. | 12:03 |
| T_UNIX | do `A.bb` would contain a line like `DEPENDS += "B"` | 12:04 |
| jofr | Yeah, 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_UNIX | did you read about `cross-canadian` in the context of compilation? | 12:05 |
| jofr | Yes yes. | 12:05 |
| jofr | So in my head, native recipes are for doing basically what I want. Provide stuff that should be used at compile-time | 12:06 |
| jofr | But what then is the difference between depending and rdepending on a native recipe? | 12:06 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 12:06 | |
| T_UNIX | usually you need the `-native` version only if you need to execute an architecture binary tool | 12:07 |
| jofr | (when I say native, I mean a recipe the classextends and is used with the -native suffix) | 12:07 |
| yocti | New news from stackoverflow: About the use of yocto toaster? <https://stackoverflow.com/questions/58933755/about-the-use-of-yocto-toaster> | 12:07 |
| T_UNIX | jofr: look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/psplash/psplash_git.bb | 12:11 |
| T_UNIX | as you can see it invokes http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh | 12:11 |
| T_UNIX | which, in turn, invokes `gdk-pixbuf-csource` | 12:12 |
| T_UNIX | so `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_UNIX | but 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_UNIX | which - in this very case - *might* be the same. | 12:16 |
| T_UNIX | jofr: 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 IRC | 12:22 | |
| rburton | jofr: 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 |
| jofr | rburton: Ok. I'll make up some paths then :) | 12:22 |
| jofr | But thanks both of you :) | 12:22 |
| rburton | jofr: rdepending on a native recipe makes no sense at all | 12:23 |
| jofr | rburton: I just found out.. QA gave me a warning | 12:23 |
| rburton | (unless you're a native recipe) | 12:23 |
| rburton | jofr: 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_UNIX | rburton: then, I assume, `-native` packages are depending on the corresponding `-native` version automagically? or are the handled in some parallel namespace? | 12:24 |
| rburton | not sure i understand, got a concrete example? | 12:25 |
| jofr | But for such an do_install section.. I think I might be too verbose: {D}${STAGING_DIR_NATIVE}${includedir}? | 12:25 |
| jofr | (missing $) | 12:25 |
| rburton | not STAGING_DIR_NATIVE | 12:25 |
| jofr | Aight. | 12:25 |
| rburton | install like normal, ${D}${includedir} | 12:25 |
| jofr | Thanks! | 12:25 |
| rburton | one 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 into | 12:26 |
| jofr | rburton: And recipe A should DEPENDS on B-native? | 12:29 |
| jofr | Or RDEPENDS on B? | 12:30 |
| T_UNIX | jofr: `-native` is not necessary if your data is not architecture specific to your build system :) | 12:30 |
| T_UNIX | jofr: do you need the data to be there, when you want to execute A on the target? | 12:30 |
| jofr | Nope. Recipe generates (among other things) a header-file that recipe A uses when building. | 12:31 |
| jofr | Nope. Recipe B generates (among other things) a header-file that recipe A uses when building. | 12:31 |
| jofr | It'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_UNIX | then 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 #yocto | 12:34 | |
| rburton | jofr: definitely no native involved | 12:35 |
| rburton | jofr: its not convoluteld: you've a recipe that generates a header. put it in $D$includedir. | 12:35 |
| rburton | you'll then also get a B-dev package for if you want to rebuild A on target for free | 12:36 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:37 | |
| *** bigMT1 <bigMT1!~mtijbout@83-87-64-60.cable.dynamic.v4.ziggo.nl> has joined #yocto | 12:37 | |
| yocti | New news from stackoverflow: Yocto recipes not found <https://stackoverflow.com/questions/57233257/yocto-recipes-not-found> | 12:37 |
| jofr | Nice. Thanks! | 12:38 |
| jofr | Now. A completely different problem. | 12:38 |
| jofr | Which I do have a workaround for, but I think it's ugly has hell. | 12:38 |
| jofr | I 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 |
| jofr | The 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 |
| jofr | Isn't there a better solution? | 12:45 |
| *** hpsy <hpsy!~hpsy@46.183.103.8> has joined #yocto | 12:45 | |
| bigMT1 | Hi All, I am new to this chat. Learning my way in to Yocto (and IRC) | 12:47 |
| jofr | Hi, bigMT1 :) | 12:49 |
| qschulz | bigMT1: welcome! | 12:49 |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 12:49 | |
| *** hpsy <hpsy!~hpsy@46.183.103.8> has quit IRC | 12:49 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 12:50 | |
| jofr | rburton: 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 |
| rburton | D is Destination | 12:55 |
| qschulz | jofr: it's going to be in recipe-sysroot (or recipe-sysroot-native if native package) | 12:55 |
| rburton | when installing, write to D | 12:55 |
| rburton | the include file will just be in the sysroot like every other include file | 12:56 |
| jofr | Yes.. But if I have other files where I need to specify their full path? | 12:57 |
| qschulz | jofr: 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 |
| bigMT1 | A 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 |
| rburton | jofr: STAGING_DATADIR etc will be the absolute path into the sysroot | 13:01 |
| qschulz | bigMT1: missing driver is the kernel | 13:01 |
| qschulz | is/in | 13:01 |
| rburton | jofr: note that not everything is in the sysroot by default, ie $datadir isn't included unless you tell it | 13:02 |
| jofr | Yeah, 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 u | 13:05 |
| jofr | -boot recipes. This header file is used by u-boot, but also for u-boot-fw-utils. | 13:05 |
| jofr | Now 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 other | 13:05 |
| jofr | final-artifacts). | 13:05 |
| jofr | So, 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 |
| qschulz | why don't you use bbappends for U-Boot directly? | 13:07 |
| qschulz | put 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 #yocto | 13:11 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 13:15 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 13:16 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 13:17 | |
| *** anujm <anujm!~anujm@134.134.139.76> has joined #yocto | 13:23 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 13:28 | |
| jofr | qschulz: 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. S | 13:56 |
| jofr | o 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 |
| jofr | Now 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. Tha | 13:56 |
| jofr | t 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 |
| jofr | So 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 |
| jofr | boot-extra-env-settings". | 14:01 |
| jofr | s/for the artifacts/of the artifacts/ | 14:03 |
| *** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 14:08 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 14:11 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 14:25 | |
| qschulz | jofr: 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 |
| qschulz | jofr: 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 code | 14:31 |
| *** anujm <anujm!~anujm@134.134.139.76> has quit IRC | 14:34 | |
| *** camus <camus!~Instantbi@222.67.188.180> has joined #yocto | 14:41 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 14:42 | |
| *** camus is now known as kaspter | 14:42 | |
| *** junland <junland!~junland@142.93.201.46> has quit IRC | 14:43 | |
| *** junland <junland!~junland@142.93.201.46> has joined #yocto | 14:45 | |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC | 14:47 | |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto | 14:51 | |
| hyper_dave | Hey everyone, How can I manually trigger the build of a package? | 14:52 |
| hyper_dave | starting from do_fetch | 14:52 |
| JPEW | bitbake -C fetch <recipe> | 14:52 |
| hyper_dave | Okay, thanks | 14:53 |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto | 14:56 | |
| rburton | just bitbake [recipe] will work unless you want to force a rebuild | 15:02 |
| rburton | in which case -C fetch is the trick | 15:03 |
| rburton | i prefer -C unpack if you don't need to force a re-download | 15:03 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 15:05 | |
| *** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 15:21 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 15:30 | |
| *** armpit <armpit!~armpit@12.206.219.171> has quit IRC | 15:31 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:45 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 15:59 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 16:05 | |
| *** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto | 16:16 | |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 16:17 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC | 16:21 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:21 | |
| *** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has joined #yocto | 16:25 | |
| *** Zajc <Zajc!~Zajc@89-212-111-208.static.t-2.net> has joined #yocto | 16:26 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 16:28 | |
| RP | armpit: am I up to date with patch merging for the stable branches? | 16:29 |
| armpit | let me check | 16:30 |
| RP | armpit: FWIW I want to get this hashequiv fix I'm working on into zeus | 16:31 |
| armpit | RP, you are up to date | 16:32 |
| armpit | k | 16:33 |
| RP | armpit: great, thanks | 16:33 |
| RP | adelcast: 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 IRC | 16:54 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 17:02 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 17:02 | |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 17:07 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:08 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 17:15 | |
| *** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has joined #yocto | 17:16 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 17:17 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 17:18 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 17:18 | |
| *** mcfrisk <mcfrisk!mcfrisk@91.232.154.11> has joined #yocto | 17:20 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 17:25 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 17:33 | |
| *** bradleyb is now known as radsquirrel | 17:49 | |
| *** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has quit IRC | 17:49 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 17:50 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 17:50 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 18:08 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:09 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 18:30 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 18:31 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-zxujeybqqwbxcbfk> has quit IRC | 18:31 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 18:31 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 18:43 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 19:09 | |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 19:11 | |
| *** bigMT150 <bigMT150!5357403c@83-87-64-60.cable.dynamic.v4.ziggo.nl> has joined #yocto | 19:27 | |
| fullstop | I am trying to be a good citizen when it comes to shared library sonames. Yocto is forcing me to do so, actually. | 19:29 |
| fullstop | In 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 |
| fullstop | What happens to libfoo.1.2.so when the package is upgraded? | 19:30 |
| fullstop | and, yes, I mean libfoo.so.1.2 etc. | 19:31 |
| fullstop | I see for things like libglib executables link to libglib-2.0.so.0 which is a symlink to a specific version. | 19:34 |
| fray | if it's compatible, then the new version needs to provide BOTH 1.3 and 1.2 sonames | 19:35 |
| fray | usual failure is someone releases 1.3, with a 1.2 compatible ABI, but never defines BOTH the 1.3 and 1.2 sonames | 19:36 |
| fray | the YP build system inspects libraries, and if they're not defined right you will get dependency errors | 19:36 |
| fullstop | I will aim for that | 19:37 |
| fullstop | not the usual failure case, multiple sonames | 19:37 |
| fullstop | does that mean multiple -Wl arguments to ld? | 19:38 |
| fray | sorry I don't have an example offhand | 19:39 |
| fullstop | darn. I'll dig through recipes I guess. | 19:39 |
| fray | usuaully not recipe specific, but buried in the upstream code.. | 19:40 |
| fray | but ya, it's multiple -Wl arguments, just don't remember the format offhand | 19:40 |
| fray | gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ... | 19:41 |
| fray | try specifying -soname multiple times | 19:41 |
| fray | recipe processing will automatically see this, and setup everything | 19:41 |
| fullstop | I have libraries which, for better or worse, are done in a Makefile.. so I'm the buried upstream code at the moment. :-) | 19:41 |
| fullstop | roger | 19:41 |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has quit IRC | 19:42 | |
| *** hyper_dave <hyper_dave!~dave@196.188.72.247> has joined #yocto | 19:44 | |
| *** bigMT150 <bigMT150!5357403c@83-87-64-60.cable.dynamic.v4.ziggo.nl> has quit IRC | 19:50 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 19:53 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 19:54 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 20:07 | |
| yocti | New 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 #yocto | 20:14 | |
| *** hpsy <hpsy!~hpsy@b2b-78-94-34-50.unitymedia.biz> has joined #yocto | 20:20 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 20:25 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:33 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 20:35 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 20:35 | |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 20:40 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-yktwnucpoevgtygk> has quit IRC | 20:55 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 21:04 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 21:32 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:33 | |
| yocti | New 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 #yocto | 21:46 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:46 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.151.27> has joined #yocto | 21:48 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 21:50 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 21:51 | |
| *** anujm <anujm!anujm@nat/intel/x-waqubbveqihrcpqf> has joined #yocto | 21:56 | |
| RP | JPEW: an interesting dilemma. How do we clean things out of the hash equiv database when we realise something is broken? | 21:57 |
| JPEW | RP: Ya, that is a interesting situation | 21:58 |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.151.27> has quit IRC | 21:59 | |
| JPEW | RP: Did you run into a problem with that? | 22:00 |
| RP | JPEW: we have zero size broken packages in the sstate cache :/ | 22:01 |
| RP | I'm just not sure how to clean them out :( | 22:01 |
| RP | I guess if I remove them the hadhequiv entry is less of an issue than the broken sstate | 22:02 |
| JPEW | RP: I would expect so... only another broken package should (theortically) be detected as equivalent | 22:02 |
| JPEW | Bump PR on the broken recipes? | 22:03 |
| RP | JPEW: I don't know exactly which broke :( | 22:04 |
| JPEW | RP: Ah, well, that won't work then | 22:04 |
| JPEW | Are they completely empty? | 22:04 |
| RP | JPEW: yes, I think so | 22:04 |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 22:05 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.180> has quit IRC | 22:05 | |
| *** camus is now known as kaspter | 22:05 | |
| RP | JPEW: well, they're packages with no files so they have control data but no actual files | 22:05 |
| bigMT1 | Hi, 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 |
| RP | bigMT1: sounds like you need to change the kernel defconfig and add in the pieces you need, then rebuild | 22:06 |
| JPEW | RP: 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 in | 22:06 |
| bigMT1 | RP: Do you have an example or a link at hand? | 22:07 |
| RP | bigMT1: I'm afraid not | 22:07 |
| RP | JPEW: right, its not a simple issue :/ | 22:08 |
| *** vam52 <vam52!~user@sgs-vb-128.vb.sgsnet.se> has joined #yocto | 22:08 | |
| JPEW | RP: 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 |
| vam52 | Hi all, does anyone know why attr depends on kernel? | 22:09 |
| JPEW | The 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 |
| vam52 | it is not clear from the recipe =\ | 22:12 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 22:13 | |
| RP | JPEW: what is worrying me is how this problem persisted over some changes :/ | 22:14 |
| RP | something isn't adding up | 22:14 |
| JPEW | RP: Was it undetected? | 22:14 |
| RP | JPEW: 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 bug | 22:17 |
| RP | too many different issues at once :( | 22:17 |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:18 | |
| JPEW | RP: 59b7001767d ("bitbake: runqueue: Fix hash equivalence duplicate tasks running") ? | 22:20 |
| JPEW | I *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 equivalent | 22:21 |
| RP | JPEW: That won't but the package.bbclass change in OE-Core will | 22:24 |
| JPEW | RP: 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 |
| RP | JPEW: np, thanks. I need to think further about what is going on I guess | 22:36 |
| *** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC | 22:46 | |
| *** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto | 22:46 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:48 | |
| *** vineela <vineela!~vtummala@134.134.137.73> has quit IRC | 23:00 | |
| *** vineela <vineela!vtummala@nat/intel/x-omzjbgoaqjvrfvzi> has joined #yocto | 23:00 | |
| *** anujm <anujm!anujm@nat/intel/x-waqubbveqihrcpqf> has quit IRC | 23:07 | |
| *** vineela <vineela!vtummala@nat/intel/x-omzjbgoaqjvrfvzi> has quit IRC | 23:07 | |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 23:13 | |
| *** anujm <anujm!~anujm@134.134.137.75> has joined #yocto | 23:23 | |
| *** vam52 <vam52!~user@sgs-vb-128.vb.sgsnet.se> has quit IRC | 23:27 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 23:28 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 23:32 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:36 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 23:45 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!