| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 00:07 | |
| JaMa | what might be adding "/dev/sda1 /boot vfat defaults 0 0" to the /etc/fstab after rootfs was created? I'm seeing it e.g. in core-image-sato-sdk-qemux86-64.rootfs.ext4, but it's not in WORKDIR/rootfs/etc/fstab for me it breaks the boot with systemd as there is no /dev/sda1 and boot waits forever for that (noticed when trying to debug -c testimage getting stuck until it timeouts waiting | 00:13 |
|---|---|---|
| JaMa | for login | 00:13 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:16 | |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto | 00:19 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 00:24 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 00:24 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 00:31 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 00:31 | |
| *** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has quit IRC | 00:37 | |
| *** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has joined #yocto | 00:39 | |
| khem | JaMa: are you using wic ? | 00:49 |
| JaMa | khem: not really intentionally, but there was IMAGE_FSTYPES="wic.vmdk ext4 wic wic.bmap" | 00:50 |
| JaMa | wasn't the issue with wic modifying it for other image types already fixed? let me find the commit | 00:51 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 00:53 | |
| JaMa | http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html | 00:53 |
| JaMa | ah it looks like it never made it pass Ross | 00:54 |
| khem | yep | 00:54 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 00:55 | |
| JaMa | so it's either openembedded-core/scripts/lib/wic/canned-wks/common.wks.inc expecting /boot partition which doesn't exist, or the /dev/vda image used by runqemu should actually use different disk which had separate /boot partition | 00:57 |
| JaMa | it was happening only for -sdk images, so I was looking in wrong direction :/ | 00:58 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 00:58 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 01:01 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 01:01 | |
| *** camus is now known as kaspter | 01:01 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 01:13 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 01:17 | |
| *** la_croix <la_croix!~la_croix@82.11.161.99> has joined #yocto | 01:23 | |
| *** camus <camus!~Instantbi@222.67.189.189> has joined #yocto | 01:24 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 01:25 | |
| *** camus is now known as kaspter | 01:25 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 01:37 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 01:41 | |
| *** mischief <mischief!~mischief@216.126.196.60> has joined #yocto | 01:43 | |
| mischief | is it normal that 'oe-pkgdata-util find-path' can't find directories? | 01:44 |
| *** sgw <sgw!~sgw@134.134.137.77> has quit IRC | 01:50 | |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-phyargejysojxzap> has quit IRC | 01:53 | |
| khem | mischief: whats your full cmd ? | 02:31 |
| khem | and have you built an image ? | 02:31 |
| zeddii | RP: if all goes well, I'll have 5.4 ready by the end of this week + the new libc-headers. I fixed a few more issues today, but I have -rt, aufs, yaffs2, etc, all ported now and am running glibc tests. will do musl tomorrow and the AB after that. | 02:35 |
| mischief | khem: oe-pkgdata-util find-path /var | 02:44 |
| mischief | or /var/tmp, or /var/log, so on | 02:44 |
| mischief | if i inspect the built base-files package, of course it has /var, so thats what i expected this to print. | 02:45 |
| mischief | and yes, i have an image. | 02:45 |
| *** sgw <sgw!~sgw@192.55.54.42> has joined #yocto | 02:54 | |
| khem | mischief: it works on filenames | 02:55 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 03:37 | |
| *** agust <agust!~agust@p508B64CC.dip0.t-ipconnect.de> has joined #yocto | 05:44 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 05:50 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 06:24 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 06:26 | |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 06:28 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 06:28 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:37 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:44 | |
| yocti | New news from stackoverflow: How to enter in root on sama5d27-som1-ek board <https://stackoverflow.com/questions/59728514/how-to-enter-in-root-on-sama5d27-som1-ek-board> | 06:49 |
| *** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has joined #yocto | 07:17 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:29a6:db2c:eaaf:35ef> has joined #yocto | 07:27 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:32 | |
| LetoThe2nd | angelo__: no, its the other way round. sumo is old, u-boot is new. so you you either need to roll back to an old u-boot, or forward to a new yocto release. | 07:34 |
| *** meow <meow!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto | 07:37 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:46 | |
| *** meow <meow!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has quit IRC | 07:47 | |
| *** jww <jww!~magnet@lfbn-mon-1-581-143.w2-4.abo.wanadoo.fr> has joined #yocto | 07:49 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:52 | |
| angelo__ | LetoThe2nd, thanks | 07:53 |
| *** mckoan|away is now known as mckoan | 08:01 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:02 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 08:07 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 08:08 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 08:09 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 08:11 | |
| stuom1 | how do I say to "devtool add" from what branch it should fetch? | 08:17 |
| LetoThe2nd | stuom1: devtool add --help :) | 08:18 |
| stuom1 | I'm trying "--srcbranch" but it still complaind that unable to resolve master | 08:18 |
| stuom1 | i dont have master branch and i dont want to fetch from master | 08:18 |
| LetoThe2nd | well if master doesn't even exist, that might be a problem then. | 08:19 |
| stuom1 | why master has to exist? | 08:19 |
| yocti | New news from stackoverflow: Yocto Linux for Banan Pi? <https://stackoverflow.com/questions/59729452/yocto-linux-for-banan-pi> | 08:19 |
| stuom1 | My "master" branch is called develop, and "--scrbranch develop" says " Fetcher failure: Unable to resolve 'master' in upstream git repository" | 08:20 |
| LetoThe2nd | stuom1: its possible that the devtool code takes this as canonical state of a repo. if --srcbranch doesnt work for you, then you're probably either up to manual creation of the recipe or digging devtool source. | 08:20 |
| LetoThe2nd | or reporting a bug, or trying with recipetool | 08:21 |
| stuom1 | if I would have branch called master, would it then fetch from correct srcbranch, or quietly fetch from master in that case? | 08:22 |
| LetoThe2nd | it would probably fetch master and then checkout. | 08:23 |
| LetoThe2nd | but thats guessing, please check the sources if you need to know for sure. | 08:23 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:24 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:28 | |
| stuom1 | using srcrev instead works luckily | 08:29 |
| LetoThe2nd | stuom1: care to file a bug report, anyways? the worst thing that cna happen is a "won't fix because wroks like intented, reason is XYZ" | 08:30 |
| stuom1 | i can look into it, if it doesnt take a workday to learn how to do it ;) | 08:31 |
| LetoThe2nd | stuom1: https://bugzilla.yoctoproject.org/enter_bug.cgi | 08:32 |
| stuom1 | thanks, now where did i put by bugzilla credentials... | 08:33 |
| *** likewise <likewise!~leon@145.130.96.189> has joined #yocto | 08:36 | |
| qschulz | bluelightning: hello :) Asking you since you are one of the committers of meta/lib/oe/patch.py :) | 08:37 |
| qschulz | is patchdir *officially* supported for applying patches on top of files coming from FILEPATH? (e.g. meta-a/recipes-a/a/files/myfile and a patch meta-b/recipes-a/a/files/patch-for-myfile.patch) | 08:37 |
| qschulz | more specifically, what I'm describing is supported but breaks devtool modify because the relative path to the files is then incorrect when running extract_files to prepare the workspace. I could try to dig into that but if we already know it's not gonna make it upstream, i'd rather not waste time :) | 08:38 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 08:40 | |
| khem | RP: sato-sdk/mips issue is due to prelink, if we disable prelinking it works | 08:47 |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:50 | |
| RP | khem: that sounds like fun to debug, good to nannow it down though! | 08:57 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 09:05 | |
| *** MeanEngi <MeanEngi!5fa87c99@95.168.124.153> has joined #yocto | 09:19 | |
| angelo__ | just updated "PREFERRED_VERSION_u-boot = "2016.03"" but bitbake still build the previous version. How can i refresh the version ? | 09:27 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 09:29 | |
| RP | angelo__: did you change the u-boot recipe? | 09:29 |
| paulbarker | angelo__: Do any of your layers have a recipe for that version of u-boot? it's a little old | 09:29 |
| angelo__ | no, that above in in machine conf, u-boot recipe was always there | 09:30 |
| angelo__ | yes i have | 09:30 |
| paulbarker | You might need to use "2016.03%" if there is anything appended to that version string in the recipe | 09:30 |
| angelo__ | mm ihave -rw-rw-r-- 1 ge ge 264 Jan 14 09:16 u-boot_2016.03.bb | 09:30 |
| qschulz | angelo__: bitbake-layers show-recipes u-boot? | 09:31 |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:31 | |
| qschulz | you'll see if your recipe is parsed by bitbake and thus available to you | 09:31 |
| angelo__ | qschulz, thanks | 09:32 |
| angelo__ | i see | 09:32 |
| angelo__ | u-boot: | 09:32 |
| angelo__ | meta 1:2018.07 | 09:32 |
| angelo__ | meta-xxx-layer v2016.03+gitAUTOINC+df61a74e68 | 09:32 |
| paulbarker | angelo__: PREFERRED_VERSION needs to match what's in PV in the recipe, in this case I'd guess to use "v2016.03%" | 09:33 |
| angelo__ | paulbarker qschulz RP, thanks, it works now | 09:35 |
| stuom1 | LetoThe2nd I think I found the bug in recipetool, I tried fix locally and it works. Is it easier to make a pull request somewhere or file a bug and write my findings there? | 09:37 |
| LetoThe2nd | stuom1: if you've already got a fix, then then best way is to send a patch to the ML | 09:38 |
| *** sgw <sgw!~sgw@192.55.54.42> has quit IRC | 09:45 | |
| qschulz | BTW, I was thinking, a good tool we could add to bitbake-layers or something would be something that parses SRC_URI and FILEPATHS and tells you which files in which paths could be a match and which one is used for that particular line in SRC_URI, making it way easier to help people debug weird defconfigs or so | 09:45 |
| qschulz | the use-case is bbappends with same files but different layer priorities | 09:46 |
| qschulz | and/or OVERRIDES in paths | 09:46 |
| qschulz | (and the order in FILEPATHS) | 09:47 |
| qschulz | (i.e. PN-PV, then PN, then files) | 09:47 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 10:01 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 10:06 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 10:09 | |
| stuom1 | LetoThe2nd I did my best to send a patch, let's see how it went, heh | 10:56 |
| stacktrust | for interactive dev/debug, when many changes are taking place (recipes, local patches, remote repos), it is sometimes necessary to issue "-c cleanall" for one or more recipes. Question 1: can cleanall+build be combined in a single bitbake invocation? Question 2: could bitbake theoretically be modified (may not be suitable for upstream) to retry failed tasks with cleanall? | 10:57 |
| LetoThe2nd | stuom1: thanks! | 10:57 |
| LetoThe2nd | stacktrust: 0) thou shalt use clean, not cleanall. 1) not my knowledge 2) anything is possible, its only software. but you're probably better off just using some wrapper then (also applies to 1) | 10:58 |
| stuom1 | I also use cleanall when I want to clean something, is it bad? | 11:00 |
| qschulz | stuom1: the question is, what makes you use -c clean/cleanall/cleansstate? If it's just for cleaning purposes, then I'd say fine. But if it is because it's not behaving as it should or there is an error. NOT fine, you're "fixing" the consequence, not the cause. All of that = IMO | 11:02 |
| LetoThe2nd | it was explained lately why clean, not cleanall (by RP). it made sense, i just totally forgot again. | 11:03 |
| LetoThe2nd | anybody please dig up the logs, or poke him again :P | 11:03 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 11:05 | |
| stacktrust | LetoThe2nd: thanks :) Wrapper works for target that has a few dependencies. For a target with a large number of tasks, it would be too slow (hours) to rebuild after clean/all, hence it would be good if bb can internally re-queue the small subset of tasks which are failing (e.g. recipe edits have invalidated existing sysroots, causing FileExistsError for copy to sysroot-providers). | 11:05 |
| paulbarker | LetoThe2nd: `cleanall` throws away downloads, sstate and the work dir. `clean` only throws away the work dir | 11:08 |
| stacktrust | Earlier in the logs it was mentioned that bb is only aware of recipe edits, not source changes. It was also mentioned that PN/PV increments are the accepted way to force a rebuild. What do you do when PN/PV are already used by a recipe (e.g. dbus) and not suitable for modification in a bbappend? In that scenario, -c clean or -c force_rebuild (with warning message about tainted do_compile) can help. | 11:08 |
| stacktrust | Speaking as a relatively new user of bb, the learning curve is so steep, and clean fixes so many indecipherable error messages, that -c clean is much closer to the default way of using bb. | 11:11 |
| *** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has joined #yocto | 11:16 | |
| stacktrust | The other issue with a wrapper is that each invocation of the wrapper loses time to reparse recipes. Memory-resident bitbake is good if recipes are not changing, e.g. only making changes to source code. | 11:18 |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC | 11:19 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 11:19 | |
| paulbarker | stacktrust: That doesn't sound like my experience with bitbake. | 11:20 |
| paulbarker | What do you mean by "source changes"? Are you using the externalsrc bbclass or `SRCREV = "${AUTOREV}"`? | 11:21 |
| stacktrust | mostly autorev. | 11:21 |
| paulbarker | Or are you placing source files in your layer and using `file://` URLs? | 11:21 |
| paulbarker | autorev should pick up new commits to a recipe without you needing to mess with PN/PV | 11:22 |
| paulbarker | If it isn't doing then that's a bug not a feature | 11:22 |
| paulbarker | `-c cleanall` should only be needed if there's something wrong with your downloads directory, `-c cleansstate` only if there's an issue in sstate (which is almost always a bug to report upstream as sstate shouldn't ever be reused incorrectly), `-c clean` when you just need to re-build a recipe from scratch | 11:24 |
| stacktrust | there are some patches in the layer with file:// URLs | 11:24 |
| paulbarker | patches in the layer and a few small source files are fine. Changes to these should be detected by bitbake and it will re-run the tasks from do_unpack for that recipe | 11:25 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 11:25 | |
| likewise | Running into a devshell gives me this error: bash: /dev/fd/62: No such file or directory (which is the probable cause for subsequent problems). What could cause this? | 11:26 |
| stacktrust | paulbarker: -c clean also needed when sysroot changes are caused by recipe edit, e.g. separating one package into two packages (e.g decoupling header file from library builds). Before: 60 packages depended on P1. After: 30 packages depend on P1a. The other 30 depend on P1b (which depends on P1a). | 11:30 |
| *** likewise <likewise!~leon@145.130.96.189> has quit IRC | 11:31 | |
| paulbarker | That shouldn't be needed, the dependency graph should rebuild the appropriate recipes. Which version of bitbake and the core layers are you using? | 11:32 |
| stacktrust | pyro | 11:32 |
| stacktrust | (migration to zeus in progress) | 11:33 |
| paulbarker | pyro shouldn't be too bad. | 11:34 |
| paulbarker | When you say you split P1 into P1a & P1b, are they separate recipes? Or packages in the same recipe? | 11:34 |
| stacktrust | Separate recipes. Packages in the same recipe would have a common dependency on P2, which we want to break by separating P1 into P1a/P1b. | 11:35 |
| stacktrust | After the split, only P1b depends on P2. | 11:36 |
| paulbarker | So then did you change DEPENDS in the 60 other recipes you mentioned? | 11:36 |
| stuom1 | is it a bad idea to copy a recipe from newer branch of meta-oe than I use? I cannot update the whole meta-oe and I'm stuck with a very old nodejs :| | 11:37 |
| rburton | feel free to backport it | 11:37 |
| rburton | just be aware that some things might need changing | 11:38 |
| rburton | RP: so a-full does meta-intel builds now right | 11:38 |
| * Crofton|road New Year resolution is to reduce the amount of work he does for old versions :) | 11:38 | |
| stacktrust | paulbarker: it was more like 30 packages depended on P3, which depended on P1. After the split, DEPENDS on P3 was changed to P1a. The other 30 packages remain dependent on P1==P1b. | 11:41 |
| JaMa | rburton: was this dropped intentionally based on your review comment? It seems still needed http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html | 11:41 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:41 | |
| rburton | JaMa: right, i was expecting a reply | 11:42 |
| paulbarker | stacktrust: Dependency resolution in bitbake should figure out what to rebuild in that case, P3 will be rebuilt as DEPENDS changed then everything which DEPENDS on P3 will be rebuilt. If that's not happening it's a bug worth reporting | 11:42 |
| JaMa | I wanted to bump that thread, but no longer have it in the maildir | 11:42 |
| stacktrust | Ok, should be easy (albeit slow) to repro. Will do that after the refactoring is done. With OpenXT moving to zeus, our bug reports will be more useful. | 11:45 |
| stacktrust | Thanks for the analysis. | 11:45 |
| stacktrust | Everything which DEPENDS on P3 *was* rebuilt, but they each failed with FileExistsError in staging_copyfile os.link(c, dest), e.g. copying from /build/tmp-glibc/sysroots-components/all/P1a/sysroot-providers/P1a -> /build/tmp-glibc/work/core2-64-oe-linux/libgknome-keyring/2.32.0-r3/recipe-sysroot/sysroot-providers/P1a | 11:50 |
| *** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has joined #yocto | 11:50 | |
| stacktrust | (excuse typos from manual copy) | 11:51 |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 11:53 | |
| *** likewise <likewise!~leon@145.130.96.189> has joined #yocto | 11:53 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 11:53 | |
| paulbarker | Unless you're manually copying things into weird recipe sysroots that sounds like a bug. If libgnome-keyring is rebuilt as one of its dependencies changed, the recipe sysroot should be rebuilt | 11:55 |
| *** MeanEngi <MeanEngi!5fa87c99@95.168.124.153> has quit IRC | 12:03 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 12:03 | |
| LetoThe2nd | likewise: is this a real hw build host? running which distro? | 12:10 |
| *** nacknick <nacknick!b9b8f483@185.184.244.131> has joined #yocto | 12:33 | |
| nacknick | Hi. I added the line * USERADD_PARAM_pn-systemd += "--system systemd-network" * to local.conf - and can't use root to login, why? | 12:35 |
| LetoThe2nd | nacknick: are you trying to replicate this? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n353 | 12:37 |
| nacknick | LetoThe2nd: no. It's just a local.conf someone passed to me and I don't know how to login | 12:37 |
| LetoThe2nd | nacknick: then what the line there for anyways? if you can't tell, get rid of it. | 12:38 |
| nacknick | I need to configure the environment as he did | 12:38 |
| LetoThe2nd | even if its wrong? | 12:38 |
| nacknick | why wrong? | 12:39 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 12:39 | |
| nacknick | If there is no other choice, I will delete that line. Just wanted to make sure there is no way to login | 12:39 |
| LetoThe2nd | because let me rephrase your question. "i want to add this line to my local.conf. i have no idea why, just copying random stuff from somebody else. now something breaks. help me!" | 12:40 |
| nacknick | exactly | 12:40 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 12:40 | |
| RP | rburton: right | 12:43 |
| *** blauskaerm <blauskaerm!Fever@gateway/vpn/mullvad/blauskaerm> has joined #yocto | 12:49 | |
| blauskaerm | I have a function in my image recipe like: do_myfuntion(). Is it possible to include if-statements like in bash? | 12:50 |
| blauskaerm | I want to execute some commands if an environment variable is set | 12:50 |
| LetoThe2nd | blauskaerm: sure. lots of examples here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n218 | 12:51 |
| qschulz | blauskaerm: tasks and functions are running in a shell (I don't exactly how to turn that sentence so that might be *technically* wrong but whatever is inside should be shell valid | 12:51 |
| qschulz | blauskaerm: now the question is... what exactly are you trying to achieve | 12:52 |
| LetoThe2nd | blauskaerm: only remember the yocto chant: "recipe data is local, conf data is global". so if you want to set stuff in one recipe and use in another, then - nope, sorry. not a syntactical, but architectural problem that you have | 12:53 |
| rburton | blauskaerm: environment variables get purged so you can't just do "FOO=bar bitbake recipe" | 12:53 |
| LetoThe2nd | rburton: was just about to add that | 12:53 |
| rburton | a shell function is literally ran by /bin/sh though so any sh works | 12:54 |
| LetoThe2nd | while that can be hacked with EXTRAWHITE | 12:54 |
| rburton | shush | 12:54 |
| qschulz | LetoThe2nd: SHUSH | 12:55 |
| rburton | proper solution is to just use a variable in local.conf etc :) | 12:55 |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto | 12:55 | |
| qschulz | well it depends what they want to achieve | 12:55 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 12:55 | |
| LetoThe2nd | qschulz: i'm proud, you're getting the spirit. | 12:55 |
| qschulz | rburton: BTW, this is kinda weird to have /bin/sh because if I'm correct, the result of the task could be different depending on which shell is the one used on the building machine right? | 12:56 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:56 | |
| LetoThe2nd | qschulz: (it ALWAYS depends :) ) | 12:56 |
| rburton | qschulz: docs say assume posix sh | 12:56 |
| rburton | if you use bash code then yes expect breakage if you don't get bash | 12:56 |
| qschulz | LetoThe2nd: I was talking about the variables which shouldn't be named. But the local/global thing one day will be burnt in my brain | 12:56 |
| *** tprrt <tprrt!~tprrt@139.28.219.86> has joined #yocto | 12:57 | |
| PinkSnake | hello guys! Little trouble with this recipe : http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/tree/recipes-common/ssh-keys/ssh-keys_0.1.bb?h=master, I have simply added this recipe to my Yocto env (branch zeus) I got this error but I don't understand what's appened (log: https://pastebin.com/pm61RXzF) any idea ? Thanks | 12:57 |
| qschulz | rburton: yup. not great, no checks are enforced at review time I think here. Is there any magic thing one of you uses to detect non-posix instructions? | 12:57 |
| qschulz | here = where I work eh | 12:58 |
| rburton | qschulz: there's a tool to verify that you're not doing bashisms, scripts/verify-bashisms | 13:00 |
| stacktrust | shfmt claims to check posix shell validity: https://github.com/mvdan/sh | 13:00 |
| qschulz | rburton: that's nice! thanks! | 13:02 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 13:06 | |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 13:09 | |
| blauskaerm | LetoThe2nd qschulz rburton: Thank you all for your replies :) | 13:12 |
| blauskaerm | Im developing agenst a iMX6 board and want to controll when yocto hands over our kernel binaries to our crypto server for signing | 13:13 |
| blauskaerm | And environment variable is not required, it just something I came up with | 13:13 |
| blauskaerm | If I could pass something else to bitbake and check if that is set in my function would be much better but I have not found anything like that? | 13:14 |
| qschulz | blauskaerm: I'm not entirely sure you want to automate that actually. | 13:14 |
| qschulz | I mean from security PoV | 13:14 |
| qschulz | signing whatever is output by Yocto without human validation... | 13:14 |
| blauskaerm | We have two sets of boards. One for lab and one for production | 13:14 |
| blauskaerm | Production keys will be handled differently but we want to sign software for lab in yocto | 13:15 |
| blauskaerm | But regardless if it sound very dump, is it possible to pass "arbitrary" variables to bitbake what I can read in the function? | 13:17 |
| qschulz | blauskaerm: out of my head, maybe not ideal=> two recipes PROVIDES (that's the var name) the same "crypto-keys". One for lab, one for production. Then you pick the recipe with PREFERRED_PROVIDER_crypto-keys = "crypto-lab" in conf/local.conf for example? | 13:17 |
| qschulz | blauskaerm: sometimes when you want things to be controlled within a recipe from outside, what you want are different recipes, images, distros, machines or some lines in local.conf. | 13:18 |
| blauskaerm | That could work. Will discuss it with my colleague :) | 13:21 |
| blauskaerm | 13:21 | |
| blauskaerm | Thanks for your time | 13:21 |
| *** kovalevsky <kovalevsky!~kovalevsk@fedora/kovalevsky> has quit IRC | 13:26 | |
| qschulz | blauskaerm: we use some post script in the image recipe here. So you could have two different images (slightly, just one line changed or something) and build the correct image (lab/prod) when needed. It depends on how complex the signing process is and how late it should happen | 13:28 |
| silviof | I am involved in a single-source project, which also includes customization of several third party components. Now the sources are checked out x times. Is there a way around this and can the sources only be downloaded once? I assume that this is done via "work-shared", but I don't know how to do it. Does anyone have a manual for? | 13:47 |
| qschulz | silviof: I do not really understand the "includes customization of several third party components" part | 13:48 |
| silviof | qschulz: We make changes in systemfiles, for example from "/etc/network/interfaces", but we do not track these changes in yocto but in another repository. | 13:50 |
| Yatekii | onto my first receipe! | 13:53 |
| stuom1 | is it possible to skip sysroot_strip function? | 13:53 |
| Yatekii | hmm how would i source my sdk env from my receipe? should i just source the env file or is there a vetter way (does it do this by default?)? | 13:54 |
| qschulz | Yatekii: no no, Yocto passes a few variables to the build system of your software. If the build system (make, cmake, autotools, meson...) does not use the variables correctly, you patch the sources. If it does not have the variables you're interested in, you add them to passed variables (CFLAGS, EXTRA_OEMAKE, EXTRA_OECONF, etc...) | 13:56 |
| Yatekii | qschulz: ok, thx, i'll try | 13:59 |
| *** florian_kc is now known as florian | 14:01 | |
| Yatekii | how hard can it be i mean xD | 14:02 |
| qschulz | Yatekii: good luck. Try as much as you can but if it feels too hacky or you rely a bit too much on Google, maybe ask a question or two here :) | 14:02 |
| qschulz | Yatekii: take this https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html. It's dangerous to go alone/ | 14:02 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 14:03 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 14:03 | |
| Yatekii | :D | 14:05 |
| Yatekii | yeah I googled a lot butr most of it seems outdated (see conversationm yesterday) or just half-knowledge | 14:05 |
| Yatekii | many irc channels are more like "google yourself, noob" | 14:06 |
| Yatekii | :D | 14:06 |
| Yatekii | so thanks :) | 14:06 |
| qschulz | Yatekii: well we know most YP stuff is very specific to one's case | 14:07 |
| *** sgw <sgw!sgw@nat/intel/x-yxqwtcrfhrhidppp> has joined #yocto | 14:07 | |
| qschulz | and the mega-manual being so mega is both a blessing and a curse. So much information. But... SO MUCH INFORMATION | 14:07 |
| qschulz | anyway, I should work some time :) | 14:08 |
| Yatekii | have fun :) | 14:08 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 14:19 | |
| yocti | New news from stackoverflow: Raspberry Pi 4 yocto, rpi-basic-image.bb: Unable to determine endianness for architecture 'INVALID' <https://stackoverflow.com/questions/59735965/raspberry-pi-4-yocto-rpi-basic-image-bb-unable-to-determine-endianness-for-arc> | 14:51 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:55 | |
| rburton | silviof: downloads will be done once, cached in DL_DIR | 14:57 |
| silviof | rburton: Ah thanks. probably the unpacking will take ages, because this is what takes time then. Can I use an already unpacked source tree then? | 14:58 |
| rburton | work-shared isn't a built-in feature but rather something the kernel does itself | 14:58 |
| rburton | its full of pain, you'll be best living with slow unpacks | 14:58 |
| rburton | remember if you have two builds for different recipes inthe same source tree you *need* to be *sure* that they won't stamp on each other | 14:59 |
| rburton | maybe some tricks like only unpacking the bits you need | 15:00 |
| rburton | if eg you have a 1gb tarball but only need one directory, just unpack those bits | 15:01 |
| silviof | rburton: Ah okay. Thanks you helped a lot. | 15:02 |
| rburton | i'm presuming its a giant tarball as you said slow unpack | 15:02 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:05 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 15:05 | |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-utkoeprpuhmnusyb> has quit IRC | 15:13 | |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-fkqexphgaprygwas> has joined #yocto | 15:18 | |
| kanavin | RP: fix for gstreamer meson conversion on the way | 15:19 |
| kanavin | (just so you don't drop the patches from master-next) | 15:19 |
| RP | kanavin: thanks! :) | 15:19 |
| RP | kanavin: there is a -next build underway with your patches in | 15:19 |
| kanavin | RP: right :) btw, I will be employed by Daimler directly starting Feb 1st, which means changing equipment, setting up access, etc., so upstream work will be delayed until I'm settled | 15:21 |
| LetoThe2nd | kanavin: hooray! | 15:21 |
| kanavin | I will keep my build machine most likely, but making it work in Daimler environment may be tricky | 15:21 |
| kanavin | I will also try to convince them to buy me the 64 core threadripper :) | 15:22 |
| RP | kanavin: thanks for the headsup, I know what the disruption can be like! | 15:24 |
| nacknick | how to reset root password of yocto? I tried raspberry pi technique (init=/bin/sh) with no success | 15:24 |
| LetoThe2nd | nacknick: rebuild image, with settings accordingly: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-extrausers | 15:29 |
| LetoThe2nd | nacknick: or IMAGE_FEATURES += "DEBUG_TWEAKS" | 15:29 |
| mcfrisk | hi, want's the deal with nspr triggering compile of glibc on zeus. can't see the dependency.. | 15:40 |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:41 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 15:43 | |
| qschulz | mcfrisk: bitbake-diffsigs on glibc might be helpful? | 15:45 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:46 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 15:47 | |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-fkqexphgaprygwas> has quit IRC | 15:48 | |
| mcfrisk | qschulz: blah, I trigger fingered rm -rf tmp... I'll remember that if this reproduces | 15:48 |
| angelo__ | is it possible to set a more recent gcc version to build all (and i.e. u-boot ?) | 15:49 |
| LetoThe2nd | angelo__: you can try and copypasta in recipes from a newer release, but be ready for some pain | 15:50 |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 15:50 | |
| LetoThe2nd | angelo__: (roughly the same amount as outright upgrading the release) | 15:50 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:50 | |
| angelo__ | aaaargh :( | 15:50 |
| LetoThe2nd | theres a reason why there are releases which offer a consistent state :) | 15:51 |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-xeugvhvbxzdauoez> has joined #yocto | 15:52 | |
| armpit | YPTM: Armin in on | 15:55 |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC | 15:56 | |
| qschulz | mcfrisk: if you have your sstate-cache elsewhere it's still fine | 15:56 |
| angelo__ | LetoThe2nd, have the following issue. I am in a sumo stuff, and cannot upgrade. If i build u-boot 2018, i get error that gcc must be > 6.0.0 (linaro-5.3 now), if i use an older 2016.03 u-boot i get the error "error: conflicting types for 'fdt64_t'" | 15:59 |
| mcfrisk | qschulz: yea, I did hit the bug again. have a bbappend for nspr which adds a test and that seems to be triggering this, and recompile of gcc-cross. diffsigs didn't know how to display this though.. | 16:00 |
| LetoThe2nd | angelo__: well then, either happy u-boot-patching, or happy upgrading. | 16:00 |
| LetoThe2nd | angelo__: hint: you can look at the u-boot logs to try and identify the commit that fixes your problem, then backport it. | 16:02 |
| angelo__ | LetoThe2nd, well, will try. Thanks for now, i'll stay happy btw :) | 16:02 |
| qschulz | mcfrisk: interesting, it usually at least gives you one task which is the trigger | 16:03 |
| kergoth | JPEW: what are the requirements pyrex has for the docker image? if i wanted to change the base image, what would i have to add to it to be able to use pyrex with it? Is everything in the dockerfile mandatory, or is there a specific list of requirements? | 16:05 |
| tlwoerner | yptm: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit | 16:06 |
| Yatekii | hmm I am trying to use the receipe in this example: https://github.com/rust-embedded/meta-rust-bin | 16:08 |
| kergoth | JPEW: another quick question, when using non-standard oe setup scripts, can we manually set things lke BITBAKEDIR before sourcing pyrex-init-build-env? | 16:09 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 16:10 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 16:11 | |
| LetoThe2nd | Yatekii: "and then...§ | 16:14 |
| Yatekii | ? | 16:15 |
| LetoThe2nd | Yatekii: "i am trying to use this recipe". well if you got no further questions or remarks? | 16:15 |
| Yatekii | well it says it cannot copy the license etc | 16:17 |
| Yatekii | and when I ignore it it complains about a missing manifest | 16:18 |
| Yatekii | and when I check the git dir it is empty | 16:18 |
| Yatekii | so I wonder how I get a populated git dir | 16:18 |
| LetoThe2nd | the git dir? | 16:20 |
| Yatekii | manifest path `/home/yatekii/repos/ecarup/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/1.0-r0/git/Cargo.toml` does not exist | 16:20 |
| Yatekii | the Cargo.toml is missing | 16:20 |
| Yatekii | but the dir it is supposed to be in is the git dir the receipe should clone from | 16:20 |
| Yatekii | (the one in the readme) | 16:21 |
| LetoThe2nd | so you have a recipe that is called "raichu-core_git.bb, but which should build the gpio-utils? or what? | 16:22 |
| Yatekii | I have a receipe that is called raichu_core.bb | 16:23 |
| Yatekii | raichu-core.bb | 16:23 |
| Yatekii | yes it builds the gpio-utils | 16:23 |
| LetoThe2nd | see, thats the problem. | 16:23 |
| Yatekii | hmm? | 16:23 |
| LetoThe2nd | ${PN} and ${PV} are derived from your recipe name, unless tated otherwise. with that name, PV is unset, therefore the checkout braks. | 16:24 |
| LetoThe2nd | suggestion: raichu-core_0.3.0.bb :) | 16:24 |
| Yatekii | ohhh thank you :) | 16:25 |
| Yatekii | hmm what do I have to do so it now checks out? | 16:26 |
| Yatekii | it's still empty (I added the tag and the PV variable requirement all together | 16:26 |
| LetoThe2nd | (hint: next time you just post a pointless information without context or qeustion, i'll silently ignore instead of trying and pulling it all out of nose) | 16:26 |
| LetoThe2nd | ? | 16:27 |
| qschulz | Yatekii: what did you do exactly? | 16:27 |
| LetoThe2nd | can't you just put the recipe as is in a pastebin? including the real file name? | 16:27 |
| Yatekii | LetoThe2nd: sorry, got distracted debugging ^^I actually intended to pose a quetsion ... :/ | 16:27 |
| Yatekii | LetoThe2nd: https://gist.github.com/Yatekii/45cd029ca2f6690fddcbd00aa9a4120c | 16:30 |
| Yatekii | here you gho :) | 16:30 |
| Yatekii | qschulz: ^ | 16:30 |
| LetoThe2nd | "i do not listen to what LetoThe2nd write: [X]" | 16:30 |
| Yatekii | LetoThe2nd: I thought when I remove the PV requiremet that works | 16:30 |
| Yatekii | ? | 16:31 |
| LetoThe2nd | stop thinking. start reading. this might sound like an insult, which it is not. its just the truth. | 16:31 |
| Yatekii | LetoThe2nd: well I thought it's optional because my mate here in the office did his receipe without it | 16:32 |
| Yatekii | so this was confusing | 16:32 |
| Yatekii | but I now found some statements in his receipe | 16:32 |
| LetoThe2nd | SRC_URI[md5sum] on a git checkout is pointless too, imho | 16:32 |
| LetoThe2nd | -> SRCREV | 16:32 |
| Yatekii | yes, this is what he did | 16:32 |
| Yatekii | also added this: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" | 16:33 |
| qschulz | Yatekii: basically, what you did there is asking yocto to checkout master | 16:33 |
| LetoThe2nd | tell your "mate" that PV belongs into the recipe name. and if its a moving target, then it shall be _git | 16:33 |
| qschulz | Yatekii: stop stop stop. Start with small things :) | 16:33 |
| LetoThe2nd | *sighs* | 16:33 |
| LetoThe2nd | qschulz: have fun. i'm off. | 16:33 |
| qschulz | Yatekii: you have an example, make the example work | 16:33 |
| qschulz | LetoThe2nd: o/ | 16:33 |
| qschulz | Yatekii: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#git-fetcher | 16:34 |
| Yatekii | well I have another example from a mate which works, so it's har dto tell which one is correct. especially since his seemed to work whilst the other didn't (not saying any of those means anything, but it's just confusing) | 16:34 |
| Yatekii | thx LetoThe2nd :) | 16:34 |
| qschulz | Yatekii: your mate might not know what he's doing :) | 16:34 |
| qschulz | (and I say *might* because I don't know them and I haven't seen the code and I have no authority over who's doing something right or wrong :) | 16:35 |
| Yatekii | qschulz: that's 100% the case :D | 16:35 |
| qschulz | Yatekii: so have a look at the link | 16:35 |
| qschulz | this gives all the default | 16:35 |
| Yatekii | yup :) | 16:35 |
| Yatekii | thx | 16:35 |
| qschulz | for the git fetcher | 16:35 |
| qschulz | mmmm | 16:36 |
| qschulz | it's actually not that good, it's missing the requirement on SRCREV | 16:36 |
| qschulz | anyway | 16:36 |
| Yatekii | well it tells the args I can put into the url | 16:36 |
| Yatekii | but not much more :/ | 16:36 |
| qschulz | TL;DR, either you use tag=mytag and you're good (except some network consequences as mentioned) | 16:37 |
| qschulz | or you need to pass a commit hash to SRCREV, because Yocto won't know which commit to take | 16:37 |
| qschulz | Remember, yocto is meant to build ina reproducible manner | 16:37 |
| Yatekii | hmm what if I always want the newest hash? | 16:37 |
| qschulz | so, tag is ok because tag are meant to be fixed hashes | 16:37 |
| Yatekii | because I am developping and not in the mood to always change it | 16:37 |
| qschulz | Yatekii: we'll see later | 16:37 |
| qschulz | let me finish that first | 16:38 |
| Yatekii | kk :) | 16:38 |
| qschulz | so, either tag=something after the URL, or SRCREV | 16:38 |
| qschulz | the thing is, the hash in SRCREV is a hash that has to be in master | 16:38 |
| qschulz | or, if you add branch=mybranch, in mybranch | 16:39 |
| qschulz | (add to the URL) | 16:39 |
| qschulz | (because branch=master by default) | 16:39 |
| qschulz | so that's one thing | 16:39 |
| qschulz | so when you remove tag=${PV} | 16:39 |
| qschulz | It tries to get a undefined commit hash in master.. I'm actually surprised bitbake does not complain | 16:40 |
| qschulz | so you need either a tag or a branch + a commit hash | 16:40 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:40 | |
| qschulz | now I hope the name of the recipe (${PN}) won't matter anywhere in the cargo class or elsewhere :) | 16:41 |
| qschulz | so, to answer your "but I want to develop and not update the SRCREV" => https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV | 16:42 |
| qschulz | and READ IT CAREFULLY, because the first line is not enough :) (bitbake will not complain but you'll have issues later on) | 16:42 |
| kergoth | JPEW: nevermind, just used a wrapper script to set them | 16:43 |
| qschulz | FILESEXTRAPATHS_prepend is for bbappends, you don't need that in a recipe (moreover, what your mate did, if they did it in a bb recipe and not in a bbappend, is actually already done, in another way, but it's done already so it's a no-op) | 16:43 |
| qschulz | Yatekii: also, best practice, always name your recipes my-recipe_version.bb | 16:44 |
| qschulz | NO underscores in my-recipe, NO uppercase letter or fancy character | 16:44 |
| qschulz | version can be a number, have letters or be `git` | 16:44 |
| qschulz | with that, PN in the recipe will be `my-recipe` and PV will be `version` | 16:45 |
| qschulz | ok, afk til tmrw. You can write I'll answer tomorrow if nobody's answered til then | 16:45 |
| qschulz | Yatekii: https://www.youtube.com/user/TheYoctoProject | 16:46 |
| Yatekii | okii, thx :) | 16:46 |
| Yatekii | thx so much! | 16:46 |
| Yatekii | I will try some around, already read the sectioon you linked but not sure I fully understand | 16:47 |
| Yatekii | have a nice evening! | 16:47 |
| armpit | YPTM: is over | 16:47 |
| qschulz | Yatekii: i'm plugging my previous company's training (open access to materials) https://bootlin.com/training/yocto/ you can read the slides. It's a very wide introduction but not deep. Should be good for you. | 16:47 |
| qschulz | Yatekii: don't blindly copy paste. If you think you need to add something to your recipe or someone tell you to do it, have a look at the mega-manual and try to see if ithe variable to be modified makes sense | 16:48 |
| qschulz | Yatekii: btw, your personal website is returning 403 ;) | 16:49 |
| JPEW | kergoth: Ah, sorry missed your questions | 16:49 |
| Yatekii | qschulz: I never blindly copy paste, I'll always try and understand the process behind it. but that does not mean it's the best way to do something ;) | 16:49 |
| Yatekii | WPF (thank god I don't have to use it anymore) is a good example. the entire internet suggests to use it like winforms. when in fact you are not supposed to. | 16:50 |
| Yatekii | and even tho you can understand the code and it kinda makes sense, you can't know there's a better version ;) | 16:50 |
| qschulz | JPEW: sorry for vomitting on the channel :) | 16:50 |
| JPEW | kergoth: It should be possible to set BITBAKEDIR before sourcing the environment script. We just need to make sure that BITBAKEDIR is one of the variables passed during capture | 16:51 |
| Yatekii | qschulz: yeah, I know :/ I cba to fix it ... only had my resume, my PGP key and my email :D should fix it ... thx for the hint :) | 16:51 |
| qschulz | Yatekii: that was more meant for the FILESEXTRAPATH thing :) | 16:51 |
| JPEW | qschultz: no problem | 16:51 |
| qschulz | JPEW: you didn't use autocompletion for my nickname didn't you :p | 16:51 |
| Yatekii | qschulz: yeah, that was just telling you guys what my mate used :) I didn't actually use that (lucky me :D) | 16:52 |
| Yatekii | qschulz: https://github.com/yatekii this is more of a webpage for what I do :D | 16:52 |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 16:52 | |
| JPEW | qschulz: Hah, I didn't even know my client *had* autocomplete until I just tried it | 16:52 |
| Yatekii | ok imma catch the train and continue work tomorrorw. but i'l be online on the cell to chug in all that info you gave me! | 16:52 |
| qschulz | Yatekii: invest your time in reading materials before coding otherwise you'll just be left with frustration. It is especially true with Yocto :) GL | 16:54 |
| JPEW | kergoth: I think adding "BITBAKEDIR" to run:envvars in pyrex.ini will do what you want | 16:55 |
| JPEW | kergoth: If you want to give that a try to make sure it works, I'll add it as the default | 16:56 |
| JPEW | kergoth: As far as the images are concerned, the absolute minimum requirement are the "*-base" images. From those, you could theoretically build up images for OE, Android, whatever | 16:58 |
| khem | JPEW: I think getting devtool to work would make pyrex useful for me | 16:58 |
| khem | and also running runqemu seemlessly | 16:58 |
| JPEW | I think those both work now | 16:59 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 16:59 | |
| JPEW | khem: On the "next" branch at least | 16:59 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:59 | |
| JPEW | runqemu works as long as you use uninative, since technically you are building qemu on a different system than you are running it :) | 17:00 |
| JPEW | khem: I don't use devtool extensively, but when I have used it, it's worked | 17:01 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:04 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 17:06 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:08 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 17:10 | |
| Yatekii | qschulz: yeah :) I am reading through the material you gave me :) thx! | 17:15 |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:29a6:db2c:eaaf:35ef> has quit IRC | 17:19 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 17:23 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 17:25 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 17:43 | |
| *** tprrt <tprrt!~tprrt@139.28.219.86> has quit IRC | 17:48 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 17:53 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 17:53 | |
| *** sveinse <sveinse!~sveinse@7.92-221-150.customer.lyse.net> has joined #yocto | 17:59 | |
| sveinse | I used to be able to run bitbake -c fetchall core-image-minimal, in zeus it complains Task do_fetchall does not exist for target core-image-minimal. How can I download the sources? | 18:01 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-yzjpehayamasiyzu> has quit IRC | 18:03 | |
| paulbarker | sveinse: That was changed | 18:03 |
| paulbarker | https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.5-bitbake-changes | 18:03 |
| sveinse | thanks | 18:04 |
| khem | RP: I have a potential patch for prelink | 18:04 |
| khem | i think it needs more work but hopefully can eke it out | 18:06 |
| *** mckoan is now known as mckoan|away | 18:11 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 18:12 | |
| RP | khem: very cool :) | 18:19 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:23 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 18:25 | |
| Crofton|road | Can you linkedin people do me a favour and share this page ? | 18:29 |
| Crofton|road | https://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ | 18:29 |
| tgamblin | Done | 18:31 |
| JaMa | RP: I have one case of reproducible 'getpwuid(): uid not found: 1001' issue, but it happens only on one builder and works on other, anything you want me try there? | 18:36 |
| JaMa | RP: what I've found sofar is that it's triggered on all files which is unpacked from tarball in do_install() and it's not related to existing sstate-cache as I can still reproduce it on that builder after cleansstate and removing all SSTATE_MIRRORS | 18:38 |
| RP | JaMa: I was literally just looking at the python3 issue which also seems to only happen sometimes. I just replied on list about what I found there (not much) :/ | 18:38 |
| RP | JaMa: Is the ownership of those files from the tarball ever set? | 18:39 |
| JaMa | RP: as chown in the do_install, then not, it's this recipe: https://github.com/webOS-ports/meta-webos-ports/blob/zeus/meta-luneos/recipes-webos/luna-init/luna-init.bb#L24 | 18:41 |
| RP | JaMa: is pseudo up to date with master in that build? | 18:41 |
| JaMa | yes, it's oe-core b6d4150f9c74f25a4022a3fa0bd489a8e85deb77 | 18:41 |
| RP | JaMa: I think with that do_install you're at the mercy of tar and the ownership of the files is not consistent | 18:42 |
| JaMa | I'm logging the paths with bb.warn in "except KeyError as e" and it looks like every unpacked file triggers it (actually twice, once in package and once in packages-split directory) | 18:43 |
| RP | JaMa: there are basically two things that may happen here. Either tar never sets the ownership "correctly" or it makes a syscall pseudo doesn't capture | 18:43 |
| JaMa | is it using tar from host? | 18:44 |
| RP | JaMa: yes | 18:44 |
| RP | JaMa: I guess a quick cheap test is to try a different older tar binary? | 18:44 |
| JaMa | ok, can compare 2 builders, the failing one is tar-1.29 from Ubuntu 18.04, the other one tar-1.30 from Ubuntu 19.10 | 18:45 |
| RP | JaMa: I'd have expected the older one to work and the newer one to fail :( | 18:46 |
| RP | JaMa: still worth comparing. Are the uids of the build user different or the same? | 18:47 |
| JaMa | different, 3001 on failing one, 1000 on the ok, one and the error is about 1001: WARNING: luna-init-2.0.1-10+gitAUTOINC+9f0d2b6e31-r0 do_package: Cannot update hash with getpwuid or getgrgid for path ./packages-split/luna-init-fonts/usr/share/fonts/Prelude-Bold.ttf: 'getpwuid(): uid not found: 1001' | 18:48 |
| yocti | New news from stackoverflow: My other imx7d pico android things start kit died, again <https://stackoverflow.com/questions/58982265/my-other-imx7d-pico-android-things-start-kit-died-again> | 18:52 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ciwnunpypgelrabk> has joined #yocto | 18:54 | |
| RP | JaMa: in the tarball what is the ownership of the files? | 18:56 |
| JaMa | RP: "select * from files where path like '%Prelude-Bold.ttf%'" | 18:59 |
| JaMa | on both builders look the same (1001 uid and gid) | 18:59 |
| RP | JaMa: I guess that is good and it means the python lookup isn't deterministic :/ | 19:00 |
| khem | RP: the gnu hash stuff is complicated, and musl does not support it either, so I think its best course for us to stay as it is | 19:00 |
| RP | JaMa: they'll be different python versions? | 19:01 |
| RP | host python | 19:01 |
| RP | khem: ok, fair enough | 19:01 |
| RP | khem: its a good one to watch/consider | 19:01 |
| khem | RP: I want to do some measurements before enabling it | 19:01 |
| RP | khem: sounds sensible | 19:01 |
| khem | since it can cause some maintainence burden, and lets not take it if its not worth it | 19:01 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-qlwsyfyluamvfhzp> has joined #yocto | 19:02 | |
| *** thannoy_ <thannoy_!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 19:04 | |
| JaMa | RP: 3.6.9 on failing, 3.7.5 working fine | 19:07 |
| JaMa | RP: roger/roger in the tarball which is 1001/1001 with --numeric-owner | 19:08 |
| RP | JaMa: Both should error, I don't know why they behave differently :/ | 19:09 |
| JaMa | trying with explicit chown on the failing one now | 19:10 |
| RP | JaMa: could you add debug to sstatesig.py to see that the return values of the pwd.getpwuid() call are and the input values | 19:11 |
| RP | being py it shouldn't change sigs and rebuild | 19:11 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:3849:7200:d754:59fc> has quit IRC | 19:12 | |
| RP | python docs say it shouldn't be version specific | 19:12 |
| JaMa | with chown -R root:root.. it works fine, pseudo db showing 0:0 now | 19:13 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-dgnptywhtlmzxvek> has joined #yocto | 19:20 | |
| *** beratiks <beratiks!b0283dda@176.40.61.218> has joined #yocto | 19:20 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hgypzpqdskxhcmqe> has joined #yocto | 19:28 | |
| Crofton|road | https://twitter.com/YoctoThe/status/1217166071519744000?s=20 | 19:31 |
| JaMa | RP: is it possible that it doesn't have include_owners set on the working one? I've added bunch of bb.warns (like I did on the failing builder) and nothing is shown, let me add it before the include_owners case | 19:34 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 19:36 | |
| JaMa | damn, sorry, it might be that this build directory on the failing one doesn't have hashserv enabled at all :/ | 19:36 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-xvsuireibjifcxbx> has joined #yocto | 19:44 | |
| JaMa | RP: now it's failing the same on both builders, I'm sorry for wasting your time | 19:46 |
| RP | JaMa: no problem, I know who hard these things can be to figure out | 19:48 |
| JaMa | RP: we might still improve the error message in these cases | 19:48 |
| RP | JaMa: yes, I quite like what I managed locally to improve the python 3.8 error failure | 19:49 |
| JaMa | I've checked last zeus build and the .ipk file really contains the files owned 1001:1001 and package-qa was fine with it (because it wasn't the same as builder's UID to trigger user-host-contamination) | 19:49 |
| RP | try: <xxx> except Exception: bb.warn(str(path)) raise | 19:49 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 19:50 | |
| RP | JaMa: we really need to improve the package-qa check to check "all unknown users" | 19:50 |
| JaMa | I was using https://paste.ubuntu.com/p/t2hMCZH977/ | 19:50 |
| RP | JaMa: might be worth a bug | 19:50 |
| RP | JaMa: With mine the benefit is it doesn't change behaviour, just shows more warning | 19:51 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-icfmwaskxccctbov> has joined #yocto | 19:51 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 19:51 | |
| LetoThe2nd | RP: https://twitter.com/YoctoThe/status/1217168511845519361 | 19:51 |
| yocti | New news from stackoverflow: Trouble building u-boot for gumstix overo on yocto "thud" release <https://stackoverflow.com/questions/59093849/trouble-building-u-boot-for-gumstix-overo-on-yocto-thud-release> | 19:52 |
| JaMa | Yes, that would be good, because now this error is triggered only with OEOuthashBasic and it might lead people to assume it's related to that | 19:52 |
| JaMa | I'll check the code in package-qa as I obviously have good test case for that | 19:53 |
| RP | JaMa: the hard part would be knowing which user ids are "bad". Current build user is easy, anything else is harder | 19:56 |
| RP | JaMa: I guess "exists in passwd in sysroot" is the right test? | 19:57 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-sezuirtplpeidujr> has joined #yocto | 19:58 | |
| JPEW | `getent passwd | cut -f1 -d: | grep -q $USER` ? | 19:59 |
| RP | JPEW: sounds like a performance nightmare | 19:59 |
| JPEW | RP: Ya, I could see that | 19:59 |
| * RP is only half joking | 19:59 | |
| *** berton_ <berton_!~berton@189.103.49.163> has joined #yocto | 20:01 | |
| *** davisr <davisr!~davisr@cpe-184-58-235-7.wi.res.rr.com> has joined #yocto | 20:02 | |
| JPEW | rburton, RP: regarding YOCTO #13733, I've noticed that sometimes the non-reproducbility is in parts of ELF files that get discarded, but this changes (only) the NT_GNU_BUILD_ID. | 20:03 |
| JPEW | Best solution I've found is to disable stripping of ELF files in the reproducible build test so that you ca debug it | 20:04 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 20:04 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hwzrmewrnprffogp> has joined #yocto | 20:05 | |
| khem | RP: interestingly, GNU_HASH/without-prelink boots faster than sysv_has/with-prelink almost 15% | 20:06 |
| fray | Hey we just ran into an sstate failure (zeus) where the filename was too long. I know this has been seen before.. has zeus been patched for this (and my zeus is just too old?) | 20:08 |
| fray | GNU_HASH w/ prelink is what I test. I'm not even sure sysv_hash + prelink actually works | 20:08 |
| khem | it works on mips | 20:10 |
| khem | filename too long is host system problem | 20:11 |
| khem | are you using something like ecryptfs | 20:11 |
| fray | no.. the sstate filename is -really- long.. | 20:11 |
| fray | it's the arch part that seems to have made it too long.. | 20:12 |
| fray | I was looking in the oe-core archives, and I see some recent patches to address it, but havn't seen if they went in (yet) | 20:12 |
| khem | longer than 255 ? | 20:12 |
| fray | yes | 20:12 |
| fray | 257 | 20:13 |
| *** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 20:13 | |
| *** fullstop <fullstop!~fullstop@162.243.42.48> has quit IRC | 20:13 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 20:14 | |
| *** aidanh_ is now known as aidanh | 20:14 | |
| khem | perhaps we should check for NAME_MAX and bail out | 20:14 |
| fray | RP's patch fro 1/5 looks like it will fix it.. | 20:15 |
| fray | [OE-core] [PATCH 4/4] sstate: Handle sstate filenames longer than 255 characters | 20:15 |
| dev1990 | if project have custom license, is it ok to use it like this LICENSE="${PN}" ? | 20:15 |
| fray | No, you need to define the license with a specific name. 'proprietary' is one such name you can use | 20:16 |
| *** fullstop <fullstop!~fullstop@162.243.42.48> has joined #yocto | 20:16 | |
| dev1990 | I have bunch of projects with custom licenses to deal with, they have custom licenses but they are all non-commercial | 20:17 |
| dev1990 | example: https://github.com/libretro/fmsx-libretro/blob/master/LICENSE | 20:18 |
| LetoThe2nd | dev1990: proprietary != commercial | 20:18 |
| LetoThe2nd | so fray++ | 20:18 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-eehyaiqdtllqgykl> has joined #yocto | 20:19 | |
| *** berton__ <berton__!~berton@189.103.49.163> has joined #yocto | 20:20 | |
| khem | fray: perhaps that patch could try to deduce the limits at runtime using getconf NAME_MAX $SSTATE_DIR | 20:22 |
| fray | There is a section in the manual on settin the license field and including the license in your layer(s) | 20:23 |
| *** berton_ <berton_!~berton@189.103.49.163> has quit IRC | 20:23 | |
| fray | http://lists.openembedded.org/pipermail/openembedded-core/2020-January/290956.html | 20:23 |
| fray | + limit = 254 | 20:23 |
| fray | + fn = spec + hash + "_" + taskname + extension | 20:24 |
| fray | + if len(fn) > limit: | 20:24 |
| fray | + avail = (254 - len(hash + "_" + taskname + extension) - len(components[0]) - len(components[1]) - len(components[5]) - len(components[6]) - 7) / 3 | 20:24 |
| fray | then max for fields 2/3/4 are 'avail' | 20:24 |
| fray | that should ensure it stays comfortably at or under 254 | 20:24 |
| fray | I'll spend some time to check that on Zeus in a bit | 20:27 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-bcxdpfmjetkixgcz> has joined #yocto | 20:27 | |
| denix | is there a bash-completion script available for opkg? | 20:31 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 20:31 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-wubjxxexfucabpjv> has joined #yocto | 20:34 | |
| sveinse | bitbake is evaluating the entire dependency tree up front right? Are there any options to alter the behaviour of the sequencing of tasks, such as early as possible vs late as possible? | 20:34 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-phahabciwrimlarg> has joined #yocto | 20:41 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 20:42 | |
| *** fullstop <fullstop!~fullstop@162.243.42.48> has quit IRC | 20:44 | |
| angelo__ | need to produce u-boot.bin and u-boot-spl , on deploy images i find only the main u-boot, how can i produce also the spl ? | 20:44 |
| LetoThe2nd | angelo__: adjust u-boot configuration accordingly | 20:45 |
| *** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has quit IRC | 20:45 | |
| LetoThe2nd | u-boot will build whatever its config it says. | 20:45 |
| *** fullstop <fullstop!~fullstop@162.243.42.48> has joined #yocto | 20:45 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-bfhjxmoikdotohzz> has joined #yocto | 20:47 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 20:47 | |
| angelo__ | LetoThe2nd, mm i have CONFIG_SPL in my config, but seems only one binary is generated | 20:51 |
| LetoThe2nd | angelo__: and if you build the config manually then it gets built? | 20:51 |
| angelo__ | i build out of the tree with same config, it get built | 20:52 |
| angelo__ | but i see now that the single u-boot produced is u-boot.imx | 20:53 |
| angelo__ | so, there seems to b an issue with the make target | 20:53 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ucewoupobbwzjuha> has joined #yocto | 20:53 | |
| LetoThe2nd | angelo__: time to inspect the logs, then. | 20:53 |
| angelo__ | maybe is this | 20:54 |
| angelo__ | UBOOT_MAKE_TARGET ?= "u-boot.imx" | 20:54 |
| LetoThe2nd | maybe. | 20:56 |
| angelo__ | LetoThe2nd, there will be any Yocto stand at fosdem ? | 20:57 |
| LetoThe2nd | angelo__: OpenEmbedded is there | 20:57 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 20:57 | |
| LetoThe2nd | see also https://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ | 20:57 |
| denix | angelo__: define SPL_BINARY | 20:58 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 21:05 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ehqcuwmwprmosvww> has joined #yocto | 21:08 | |
| angelo__ | LetoThe2nd, cool, will probably buy a ticket | 21:08 |
| angelo__ | LetoThe2nd, you will be there ? | 21:08 |
| angelo__ | denix, thanks, trying | 21:08 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 21:10 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 21:10 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-wclsdrbxoybmzxyy> has joined #yocto | 21:14 | |
| *** Linus_SWE <Linus_SWE!d58e1c30@h213-142-28-48.cust.a3fiber.se> has joined #yocto | 21:14 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:16 | |
| Linus_SWE | Hi! Im trying to find out how to remove busybox and replace it with coreutils on my build but Im failing miserably. Any hints? :) | 21:22 |
| yocti | New news from stackoverflow: How do you properly build gpiod applications from Yocto? <https://stackoverflow.com/questions/59741817/how-do-you-properly-build-gpiod-applications-from-yocto> | 21:22 |
| RP | sveinse: you can change bitbake's scheduler, its plugable | 21:25 |
| RP | sveinse: rmwork enabled a different one for example | 21:25 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-tjdgaayaqxcuiqla> has joined #yocto | 21:26 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 21:29 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 21:30 | |
| roussinm | autoconf-archive fails to the configuration step, because it finds python through my pyenv configuration... that is weird. | 21:33 |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 21:36 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 21:37 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-tsirfhsgmggpzryt> has joined #yocto | 21:40 | |
| *** Linus_SWE <Linus_SWE!d58e1c30@h213-142-28-48.cust.a3fiber.se> has quit IRC | 21:44 | |
| *** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto | 21:49 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-pbzajjfrcufmwqdj> has joined #yocto | 21:51 | |
| RP | JPEW: Are your slides from the San Diego devday somewhere I can link to? | 21:52 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:53 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-detceyyvfyvbmjto> has joined #yocto | 22:03 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:07 | |
| JPEW | Rp: https://docs.google.com/presentation/d/1IzFlI8n8B49HkHiQClO6OoE_mugvK52Zoarx9BRimiY/edit?usp=sharing | 22:08 |
| RP | JPEW: can I put that on the wiki? | 22:09 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-irxmlnasxcrvazze> has joined #yocto | 22:09 | |
| JPEW | Please do | 22:09 |
| RP | JPEW: thanks | 22:09 |
| dev1990 | I found funny thing, please look at this | 22:09 |
| dev1990 | https://github.com/RetroPie/RetroPie-Setup/tree/master/scriptmodules/libretrocores | 22:09 |
| dev1990 | seems familiar? | 22:10 |
| RP | dev1990: not to me... | 22:12 |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 22:13 | |
| dev1990 | I don't get it, they are working so hard on something that could be a Yocto from the beginning | 22:14 |
| dev1990 | Yocto layer I mean | 22:15 |
| RP | dev1990: oh, I see. I've seen that happen before :/ | 22:16 |
| khem | RP: is there space for running another glibc run ? | 22:16 |
| RP | khem: its busy doing a build from scratch but there probably is overnight | 22:17 |
| khem | I have a fix for prelink, which I want to see if is working | 22:17 |
| RP | khem: does it only affect mips? | 22:17 |
| RP | khem: I could just run the failing mips builds if so | 22:18 |
| khem | RP: the fix is mips specific but applies to common srcs | 22:18 |
| khem | of prelink | 22:18 |
| RP | khem: so we should build everything? or just need to test mips atm ? | 22:18 |
| khem | GNU hash is pretty fast | 22:18 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 22:18 | |
| khem | I think mips will benefit from it, I will disable it for musl/mips and enable it for glibc/mips | 22:19 |
| RP | khem: ok | 22:19 |
| RP | khem: do you have a poky branch with the change in? If so we can just run it on the AB and queue after the current build | 22:19 |
| RP | I can point it at your branch | 22:19 |
| khem | musl will eventually get it done too but they are not happy with glib's approach, so it might be a while | 22:19 |
| khem | RP: I will push this into kraj/glibc-2.31 | 22:20 |
| khem | let me do that | 22:20 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-hslhzdxojcsvanej> has joined #yocto | 22:22 | |
| *** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 22:25 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ttcvsxuvvbplpwks> has joined #yocto | 22:28 | |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 22:33 | |
| *** beratiks <beratiks!b0283dda@176.40.61.218> has quit IRC | 22:33 | |
| khem | RP: try https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/glibc-2.31 | 22:34 |
| khem | RP: perhaps just run mips/core-image-sato-sdk for starts | 22:35 |
| * zeddii calls it a day of boot testing on 5.4. sato and kernel-dev tomorrow. then I'm pretty well covered | 22:35 | |
| RP | zeddii: btw, I think there are fixes for meta-intel which will stop the autobuilder throwing warnings | 22:36 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-gvivtrrjkdhvwhwq> has joined #yocto | 22:36 | |
| *** hpsy <hpsy!~hpsy@85.203.15.14> has joined #yocto | 22:37 | |
| RP | khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1447 https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/206 https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1445 | 22:37 |
| zeddii | yah. I have most of them queued here, but they are on top of other 5.4 changes that I have, so I need to test a bit more. | 22:37 |
| RP | zeddii: ok, cool. Just keen to get rid of one of the last warnings on the AB | 22:38 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 22:40 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 22:42 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ulkfftatrolnmkxp> has joined #yocto | 22:43 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:46 | |
| khem | RP: cool, I opened them in browser lets hope for green | 22:47 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ozodbkxluzjtcxnr> has joined #yocto | 22:48 | |
| khem | RP: I think we need https://patchwork.openembedded.org/patch/168929/ along with rest gst/meson conversion patch | 22:49 |
| khem | there are several layers which have to adopt to meson changes for gst as well | 22:49 |
| RP | khem: right, will add in the next round of testing | 22:49 |
| khem | ok | 22:49 |
| *** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 22:52 | |
| khem | RP: nfsroot with qemu is quite helpful in debugging the low level stuff like ldso | 22:52 |
| RP | khem: needs better documentation! :) | 22:52 |
| khem | RP: I think when you have prelinked rootfs and want to unprelink just one file and rootfs is not booting | 22:54 |
| khem | such situations while not common are very hard to debug otherwise | 22:54 |
| RP | khem: yes, early init can be fun... | 22:55 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-ujpqfwlzmxzzypnl> has joined #yocto | 22:55 | |
| khem | especially a borked ldso :) | 22:55 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 23:02 | |
| fray | ya, broken ldso sucks.. REALLY a pain to debug | 23:02 |
| fray | what bugs me is the error is usually "No such file or directory".. but it doesn't tell you it's the ldso (or what the ldso was trying to load).. just a completely nebulous error. | 23:03 |
| *** agust <agust!~agust@p508B64CC.dip0.t-ipconnect.de> has quit IRC | 23:06 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-jmqgtmuxquautynt> has joined #yocto | 23:07 | |
| *** nacknick <nacknick!b9b8f483@185.184.244.131> has quit IRC | 23:14 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 23:16 | |
| *** florian_kc is now known as florian | 23:19 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-kuyuzongdxqgjvkt> has joined #yocto | 23:20 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 23:20 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-fueusutovoluxukr> has joined #yocto | 23:27 | |
| khem | Kernighan law rightly states - debugging is twice as hard as writing the code in the first place | 23:32 |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-yklffwjnzdicmdqg> has joined #yocto | 23:32 | |
| RP | khem: unless its bitbake hashequiv :) | 23:38 |
| khem | hmm heh | 23:38 |
| khem | RP: core-image-sato-sdk is booting here fine on qemumips now | 23:39 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 23:39 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 23:40 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-lakuidaajunudyzu> has joined #yocto | 23:46 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 23:52 | |
| *** net_wayfarer <net_wayfarer!net_wayfar@gateway/shell/ircnow/x-azwphkpsqiemruhy> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!