*** azcraft <azcraft!~AzCraft@195.214.252.213> has quit IRC (Remote host closed the connection) | 00:01 | |
*** florian <florian!~florian@dynamic-093-132-128-099.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 264 seconds) | 00:04 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 00:38 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 00:38 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 00:40 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 00:40 | |
*** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:11 | |
JaMa | RP: I had "fetch2: Add autorev warning when it is set too late" in my poky branch (from last rebase on master-next), I guess this explains the bbtests.BitbakeTests.test_git_unpack_nonetwork_fail failure I've seen | 01:21 |
---|---|---|
JaMa | after dropping it during rebase on today's master-next, it passes again: 2023-03-22 02:23:19,602 - oe-selftest - INFO - RESULTS - bbtests.BitbakeTests.test_git_unpack_nonetwork_fail: PASSED (38.50s) | 01:23 |
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 01:32 | |
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 01:35 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 260 seconds) | 01:38 | |
*** camus <camus!~Instantbi@116.236.93.172> has quit IRC (Quit: camus) | 02:01 | |
*** camus <camus!~Instantbi@116.236.93.172> has joined #yocto | 02:03 | |
*** davidinux <davidinux!~davidinux@81.22.36.210> has joined #yocto | 02:04 | |
*** starblue <starblue!~juergen@dslb-094-221-176-208.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 264 seconds) | 02:36 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 02:37 | |
*** starblue <starblue!~juergen@dslb-088-078-097-085.088.078.pools.vodafone-ip.de> has joined #yocto | 02:38 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 250 seconds) | 02:42 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #yocto | 02:43 | |
*** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has joined #yocto | 02:58 | |
*** zpfvo <zpfvo!~fvo@i59F5CFF6.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 03:05 | |
*** zpfvo <zpfvo!~fvo@i59F5CF39.versanet.de> has joined #yocto | 03:19 | |
*** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 268 seconds) | 03:28 | |
*** barometz <barometz!~dvanb@92-109-61-249.cable.dynamic.v4.ziggo.nl> has joined #yocto | 03:29 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6534:7900:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 248 seconds) | 03:38 | |
*** jclsn <jclsn!~jclsn@2a04:4540:6504:f500:2ce:39ff:fecf:efcd> has joined #yocto | 03:40 | |
*** zpfvo <zpfvo!~fvo@i59F5CF39.versanet.de> has quit IRC (Ping timeout: 240 seconds) | 04:03 | |
*** amitk <amitk!~amit@103.208.71.75> has joined #yocto | 04:13 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has joined #yocto | 04:18 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 248 seconds) | 05:04 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 05:04 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has quit IRC (Ping timeout: 240 seconds) | 05:06 | |
*** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 05:08 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 240 seconds) | 05:08 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 05:09 | |
*** zpfvo <zpfvo!~fvo@i59f5ce22.versanet.de> has joined #yocto | 05:19 | |
*** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:33 | |
*** amitk_ <amitk_!~amit@103.208.69.139> has joined #yocto | 05:46 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:14 | |
thomasd13 | Good morning guys. How do you deal with CMake-Projects which uses FetchContent/FindPackages to resolve their dependencies? Do you replicate these dependencies to the "recipe-level" or just run CMake-Project and let it do, what it wants to do? | 06:31 |
thomasd13 | And also, these CMake-Project establish a local cmake package cache at ~/.someDir. How would you deal with that? | 06:32 |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 06:40 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06:41 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 06:54 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 06:59 | |
*** pope <pope!~pope@46.140.99.106> has joined #yocto | 07:05 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:07 | |
pope | How can I recompile a kernel to support the earlyprintk option? | 07:10 |
mcfrisk | thomasd13: inherit cmake, then FindPackages should just work, though there are bugs like some recipes generate bad .cmake files with absolute paths which need to be fixed. dowloading dependencies needs to be disabled and instead recipe dependencies used. | 07:11 |
kanavin_ | thomasd13, those aren't common, but generally you need to unroll the dependencies either into their own recipes, or additional entries in SRC_URI | 07:11 |
pope | pope: Or how can I add it if no recompile is necessary...? | 07:18 |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:18 | |
thomasd13 | Thanks guys, I guess I just get started and see how it works. It sounds a bit weird to create recipes for each and every internal cmake-project dependency and supply them on recipe-level | 07:36 |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Quit: wooosaiiii) | 07:36 | |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 07:37 | |
mcfrisk | thomasd13: if the cmake modules are internal to the source tree then that can be kept as is, no need to create recipes for them | 07:38 |
mcfrisk | but I've had to separate a source tree build for target from the build host/native before. some cmake modules were code generators etc and used in a number of recipes/source trees | 07:39 |
thomasd13 | mcfrisk, ah okay, I think I get your point now. And how would you deal when the CMake-Project expects stuff on hardcoded location? Example the package cache at ~/.someDir ? Would that be isolated from other yocto recipes? | 07:42 |
mcfrisk | thomasd13: build output needs to be in the ${B} and recipe level dependencies in recipe specific sysroot. cmake.bbclass creates the toolchain file with paths into the sysroots so those must be used. | 07:44 |
mcfrisk | I know cmake stuff can become really annoying. downloading and using externals should be just disabled. everything must be used as recipe dependencies or via SRC_URI like kanavin_ said too. With SRC_URI, you can prepopulate a cache directory with downloaded externals | 07:45 |
kanavin_ | thomasd13, it's hard to give specific hints if you can't show the source tree you want to build | 07:46 |
kanavin_ | thomasd13, you can hire me to sort you out ;) | 07:46 |
kanavin_ | sales@linutronix.de | 07:46 |
*** frieder <frieder!~frieder@200116b824ef86810000000000001b2e.dip.versatel-1u1.de> has joined #yocto | 07:47 | |
mcfrisk | rust cargo stuff feels just as annoying as cmake code downloading random dependencies in various ways | 07:49 |
thomasd13 | mcfrisk, toolchains are another good point. I have to use some specific toolchains which are also not "available" in yocto | 07:51 |
JaMa | thomasd13: there are many recipes wich used FetchContent/ExternalProject_Add in meta-ros, you can find some examples there (but sometimes it's not simple) | 07:51 |
thomasd13 | Alright, thanks for the hint JaMa | 07:51 |
JaMa | thomasd13: sometimes it is enough just to let bitbake fetcher to fetch the right sources to right directory | 07:52 |
thomasd13 | kanavin_, i think I had contact to Linutronix at embedded world some years ago.. Maybe I'll get in touch if things get really worse ;) Do you have free capacity for new clients atm? | 07:53 |
JaMa | thomasd13: but then the cmake calls in ExternalProject_Add often don't pass the right params toolchain file to build the external dep correctly, so it was easier to build it in separate simple recipe and then modify CMakeLists.txt to accept this external dependency from "system" | 07:53 |
JaMa | until you get 2 projects which require the same external dependency, but different versions (for whatever reason), then it goes even worse | 07:54 |
mcfrisk | JaMa: oh yes, I have never seen a cmake externals using provided toolchain file correctly so that cross compilation would work :( | 07:55 |
thomasd13 | Well... I have a setup which builds same software for ARM R5, A72, DSP C6x and C7x targets, so thats working | 07:56 |
JaMa | you can pass the toolchain file parameter in ExternalProject_Add, but in all cases you have to patch the original CMakeLists.txt which is a bit annoying | 07:57 |
JaMa | I was also using these patch files to make sure that whenever requested version of ExternalProject_Add is changed, I get a conflict from this .patch (so that I notice that bitbake fetcher params need to be adjusted) | 07:58 |
RP | JaMa: I've tried with and without that patch. I still wonder if an older version corrupted the state of the builddir | 07:59 |
JaMa | and that was before network varflag, so to detect these ExternalProject_Add in meta-ros I was sometimes rebuilding from scratch (without sstate) with dns config intentionally crippled | 07:59 |
*** frwol <frwol!~frwol@user/frwol> has joined #yocto | 08:00 | |
JaMa | RP: I've let it run with most selftests over night and now I see more unexpected failures, but didn't investigate yet due to work | 08:01 |
JaMa | 2023-03-22 06:40:17,096 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=479, skipped=7, failures=8, errors=30) | 08:02 |
mcfrisk | I disabled networking from a build container and saw CMake code downloading custom python versions etc... | 08:03 |
*** mckoan|away is now known as mckoan | 08:06 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 08:08 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 268 seconds) | 08:34 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 08:37 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:46 | |
LetoThe2nd | yo dudX | 08:54 |
mcfrisk | how to update a crate in rust application recipe? If I update the version in SRC_URI, then build fails due to Cargo.lock having different version. Then in devshell I update the Cargo.lock including the checksum, but running run.do_compile still fails | 08:54 |
mckoan | hey LetoThe2nd | 08:59 |
mcfrisk | rust recipes seem to use these crates to download also sources, but how to update to pre-crate release or specific commit in git to test fixes? specifically how to update parsec-service from 1.1.0 from crate to 1.2.0-rc1 from git? 1.1.0 fails to compile due to some enum parsing issue | 09:09 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 09:16 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 09:19 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 09:20 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 255 seconds) | 09:25 | |
*** davidinux <davidinux!~davidinux@81.22.36.210> has quit IRC (Ping timeout: 276 seconds) | 09:30 | |
*** davidinux <davidinux!~davidinux@host-95-250-216-103.retail.telecomitalia.it> has joined #yocto | 09:31 | |
kanavin_ | thomasd13, I'm not sure about capacity - I'm not involved in staff allocation or project management :) | 09:33 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 09:34 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:34 | |
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 09:39 | |
RP | mcfrisk: I wonder why our normal network disabling didn't catch that. Was that with something in core? | 09:42 |
RP | JaMa: not good. I wonder what is going on :/ | 09:42 |
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 276 seconds) | 09:43 | |
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 09:44 | |
hnez | mcfrisk: maybe specify the git version of the crate you want to use in the Cargo.toml ( https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories ), run cargo update to generate a new Cargo.lock and cargo bitbake ( https://github.com/meta-rust/cargo-bitbake ) to generate a recipe with the updated sources? | 09:48 |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:53 | |
*** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:53 | |
mcfrisk | RP: an old issue, was using dunfell at the time so no support for bitbake network disable. btw that code was even using plain IP addresses to avoid DNS | 09:54 |
mcfrisk | hnez: I'm kind of a bitbake person so would like to do that in the recipe devshell but it seems that all these cargo updates are tricky there even if I manage to update Cargo.lock and Cargo.toml correctly. | 09:56 |
kanavin_ | mcfrisk, there is a oe-core class to update crate lists in recipes from what is declared in Cargo.lock | 09:59 |
RP | mcfrisk: lovely :( | 10:00 |
*** florian__ is now known as florian | 10:00 | |
JaMa | RP: me too, some of them seem to be caused by my pending runqemu changes (from the next batch), but I didn't really look yet (other than restarting the failed tests on background to see if the issues are reproducible) | 10:00 |
* mcfrisk goes down the rabbit hole of cyclic crate dependencies, aargh... | 10:04 | |
*** ptsneves <ptsneves!~Thunderbi@84.47.155.82> has joined #yocto | 10:07 | |
*** sgw <sgw!~swold@user/sgw> has quit IRC (Ping timeout: 268 seconds) | 10:07 | |
*** sgw <sgw!~swold@user/sgw> has joined #yocto | 10:09 | |
*** azcraft <azcraft!~AzCraft@195.214.252.213> has joined #yocto | 10:37 | |
jclsn | join #kitty | 10:54 |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 10:57 | |
mcfrisk | is there a way to use bitbake devshell to modify rust recipe and it's crate dependencies? "crate update" just sees packages downloaded in SRC_URI but I'd like to test changes so that I generate the new SRC_URI.. | 11:00 |
*** starblue <starblue!~juergen@dslb-088-078-097-085.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 276 seconds) | 11:03 | |
*** starblue <starblue!~juergen@dslb-088-078-097-085.088.078.pools.vodafone-ip.de> has joined #yocto | 11:04 | |
barath | when populating an ext4 image file using mkfs.ext4 image_types.bbclass sets -i 4096 by default. but this only makes sense if mkfs's blocksize, inode_size "match" with a bytes-per-inode value of 4096. the default blocksize, inode_size etc can differ between distros, as each distro may ship a different mke2fs.conf file | 11:05 |
barath | would it make sense to also set default values for those other mkfs parameters? I discovered this while debugging why image generation failed on one host, but not on another and the reason was that the two hosts had different mke2fs.conf files | 11:07 |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 11:27 | |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Quit: wooosaiiii) | 11:29 | |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 11:30 | |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Client Quit) | 11:30 | |
*** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 11:31 | |
rburton | barath: what release? i thought we fixed something like that already | 11:34 |
rburton | barath: ah i'm thinking about the inode size in small file systems. shouldn't mkfs be using the mke2fs.conf we install in e2fsprogs-native though, so you shouldn't get different behavious? | 11:37 |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 11:39 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 11:39 | |
barath | kirkstone, but looks like the default -i 4096 argument has been there a while | 11:40 |
barath | rburton: hm I'll double check whether it is/should be using the e2fsprogs-native conf file... it doesnt look like it is using that in my case | 11:41 |
*** amitk_ <amitk_!~amit@103.208.69.139> has quit IRC (Ping timeout: 268 seconds) | 11:59 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 12:25 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 12:25 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 12:28 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 12:32 | |
barath | thanks for the pointeres rburton! the e2fsprogs-native conf file from upstream is indeed used by default and everything is fine | 12:48 |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 13:20 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 13:20 | |
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 13:26 | |
*** Xagen <Xagen!~Xagen@4.14.206.69> has joined #yocto | 13:33 | |
*** zpfvo <zpfvo!~fvo@i59f5ce22.versanet.de> has quit IRC (Ping timeout: 255 seconds) | 13:37 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has joined #yocto | 13:39 | |
landgraf | I'm trying to clone linux-yocto (single branch v6.1/standard/bcm-2xxx-rpi) from git.yoctoproject.org to digitalocean machine (fast internet connection) and it works with --depth=1 but failed without it (fatal: fetch-pack: invalid index-pack output) . Is git.y.o overloaded? | 13:41 |
*** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has joined #yocto | 13:48 | |
*** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has joined #yocto | 13:50 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 13:53 | |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 13:54 | |
RP | JaMa: I merged some, dropped a couple and will ponder some a bit further :) | 13:54 |
RP | landgraf: I don't know. It is a bit early for our US based sysadmins too :/ | 13:57 |
RP | landgraf: you could email helpdesk@yoctoproject.org and report it ? | 13:58 |
landgraf | RP: I'll give it another try and report if failed. | 14:02 |
*** landgraf <landgraf!~landgraf@164.90.195.62> has quit IRC (Ping timeout: 255 seconds) | 14:08 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 14:09 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 14:09 | |
*** ilunev <ilunev!~koolkhel@95.174.114.26> has joined #yocto | 14:10 | |
*** landgraf <landgraf!~landgraf@164.90.195.62> has joined #yocto | 14:12 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 256 seconds) | 14:14 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 14:14 | |
*** Xagen <Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 14:27 | |
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 14:28 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 14:31 | |
*** |Xagen <|Xagen!~Xagen@4.14.206.69> has joined #yocto | 14:37 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 255 seconds) | 14:38 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 14:39 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 14:39 | |
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Ping timeout: 240 seconds) | 14:40 | |
rburton | barath: so what was breaking for you? | 14:40 |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 240 seconds) | 14:43 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 14:44 | |
*** tleb <tleb!6dbdd9ebc9@2604:bf00:561:2000::10cf> has quit IRC (Remote host closed the connection) | 14:48 | |
*** bryanb <bryanb!b5a314b1c0@2604:bf00:561:2000::106f> has quit IRC (Remote host closed the connection) | 14:48 | |
barath | rburton: I'm transitioning us from dunfell to kirkstone and we lost mklibs optimization. We were already close our the max rootf size and now we reached it. I got confused because running the same mkfs.ext4 on my host worked, whereas it failed in yocto which runs in a docker | 14:50 |
*** bryanb <bryanb!b5a314b1c0@2604:bf00:561:2000::106f> has joined #yocto | 14:50 | |
*** tleb <tleb!6dbdd9ebc9@2604:bf00:561:2000::10cf> has joined #yocto | 14:50 | |
barath | Turned out my host has a mke2fs.conf with a smaller default inode size (and block size) than the defaults used by poky / e2fsprogs defaults | 14:51 |
*** frieder <frieder!~frieder@200116b824ef86810000000000001b2e.dip.versatel-1u1.de> has quit IRC (Ping timeout: 240 seconds) | 14:51 | |
barath | *running the same mkfs.ext4 command | 14:52 |
barath | An inode size of 128 vs 256 made it work, though that's a bad workaround | 14:52 |
barath | For us | 14:52 |
rburton | barath: ah got it | 14:53 |
rburton | barath: i see mklibs has finally been ported to py3 upstream, so it shouldn't be difficult at all to resurrect it | 14:54 |
*** frieder <frieder!~frieder@i59F4B473.versanet.de> has joined #yocto | 15:04 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 15:04 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 15:04 | |
*** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Remote host closed the connection) | 15:06 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 240 seconds) | 15:09 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 15:09 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 15:12 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 15:12 | |
*** amelius <amelius!~quassel@147.161.165.84> has joined #yocto | 15:21 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving) | 15:22 | |
*** |Xagen <|Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 15:28 | |
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 15:29 | |
barath | rburton: ah cool, thanks for the heads up, I'll look into that :) | 15:31 |
*** |Xagen <|Xagen!~Xagen@4.14.206.69> has joined #yocto | 15:43 | |
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Ping timeout: 260 seconds) | 15:45 | |
JaMa | RP: thanks | 15:49 |
*** tleb <tleb!6dbdd9ebc9@2604:bf00:561:2000::10cf> has quit IRC (Remote host closed the connection) | 15:50 | |
*** bryanb <bryanb!b5a314b1c0@2604:bf00:561:2000::106f> has quit IRC (Remote host closed the connection) | 15:50 | |
*** vladest <vladest!~Thunderbi@6.174.199.178.dynamic.wline.res.cust.swisscom.ch> has quit IRC (Ping timeout: 246 seconds) | 15:51 | |
JaMa | RP: there was one more "safe" for meta-yocto if you want, but no rush | 15:51 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 15:53 | |
*** bryanb <bryanb!b5a314b1c0@2604:bf00:561:2000::106f> has joined #yocto | 15:56 | |
*** tleb <tleb!6dbdd9ebc9@2604:bf00:561:2000::10cf> has joined #yocto | 15:56 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:09 | |
*** thomasd13 <thomasd13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 276 seconds) | 16:10 | |
*** Net147_ <Net147_!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has quit IRC (Ping timeout: 256 seconds) | 16:10 | |
*** pope <pope!~pope@46.140.99.106> has quit IRC (Quit: Client closed) | 16:11 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has quit IRC (Ping timeout: 240 seconds) | 16:21 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has joined #yocto | 16:23 | |
*** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto | 16:24 | |
*** frwol <frwol!~frwol@user/frwol> has quit IRC (Quit: leaving) | 16:41 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 16:49 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 16:49 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 16:50 | |
rfs613 | just noticed that openssl 1.1.1 branch goes EOL this september. What will happen to dunfell at that time, no more SSL updates? I'm guessing updating to 3.1 is not under consideration? | 16:53 |
michaelo | Hi RP: thanks for the reply about "argp". I'll send a patch after 4.2 is out, right? | 16:54 |
rfs613 | to clarify, I mean openssl 3.1 or 3.0 (LTS) | 16:55 |
RP | michaelo: we can just do that now | 16:55 |
RP | rfs613: A major openssl version change would likely be painful on dunfell | 16:56 |
michaelo | RP: ok, great, thanks | 16:58 |
michaelo | RP: oops, my bad, I was checking the kirkstone branch, not master. It has already been removed. | 17:02 |
RP | michaelo: I wondered why I couldn't find it! | 17:07 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 17:15 | |
*** zpfvo <zpfvo!~fvo@i59F5CE22.versanet.de> has quit IRC (Quit: Leaving.) | 17:21 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 17:27 | |
*** ptsneves <ptsneves!~Thunderbi@84.47.155.82> has quit IRC (Ping timeout: 276 seconds) | 17:27 | |
*** amelius <amelius!~quassel@147.161.165.84> has quit IRC (Read error: Connection reset by peer) | 17:28 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:47 | |
*** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto | 17:48 | |
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has quit IRC (Ping timeout: 252 seconds) | 17:48 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 17:51 | |
*** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 17:55 | |
*** sgw <sgw!~swold@user/sgw> has joined #yocto | 17:56 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 18:06 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 18:06 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 18:21 | |
*** frieder <frieder!~frieder@i59F4B473.versanet.de> has quit IRC (Remote host closed the connection) | 18:34 | |
*** olani- <olani-!~olani@83-233-29-230.cust.bredband2.com> has quit IRC (Ping timeout: 265 seconds) | 18:35 | |
*** olani- <olani-!~olani@66.159.215.7> has joined #yocto | 18:35 | |
*** olani- <olani-!~olani@66.159.215.7> has quit IRC (Ping timeout: 265 seconds) | 18:40 | |
kanavin_ | rfs613, you can do local testing and propose a mixin layer, but it won't go into dunfell proper | 18:42 |
kanavin_ | rfs613, yocto LTS means there is a dedicated person reviewing, testing and publishing patches, but there is no promise to 'fix stuff' otherwise | 18:43 |
kanavin_ | project users need to take care of that part | 18:43 |
rfs613 | kanavin_: yup, sakoman and I are acquainted already ;-) I just wondered if for something as critical as SSL (or maybe glibc) there might be different policy. | 18:46 |
rfs613 | most users of course will see "Supported until Aug 2024" on the releases page, and will (probalby rightfully) assume everything is hunky dory until then. | 18:47 |
kanavin_ | rfs613, major updates like that are too disruptive, so they go into the 'overlay' layer: https://git.yoctoproject.org/meta-lts-mixins/ | 18:48 |
rfs613 | kanavin_: yup, understood, we talked about that for docker updates a while back | 18:49 |
kanavin_ | rfs613, there's no magic trick to go around the fact that we do not have people to staff a security team | 18:49 |
kanavin_ | rfs613, we produce CVE reports weekly, if entries in those are concerning, fixing them needs to be done by the project users | 18:50 |
rfs613 | indeed, and it is difficult to know when a given project will decide to stop supporting a certain version | 18:50 |
sakoman | rfs613: Dunfell support ends April 2024, so for the last 6 months of life we'll have to rely on patches to ssl 1.1.1 | 18:50 |
rfs613 | sakoman: if we can get them ;-) | 18:51 |
sakoman | rfs613: indeed, hopefully the community will step up if something serious arises | 18:51 |
kanavin_ | rfs613, you should move onto a newer yocto before that really | 18:51 |
kanavin_ | and generally think of your lifecycle management, and codify that as a policy | 18:52 |
rfs613 | this makes me wonder how many other existing packages in are in a similar position - upstream supported ended, and we are relying on backports done by volunteers, or not at all | 18:52 |
sakoman | rfs613: I'm sure there are many! | 18:52 |
rfs613 | having that info might help sell a version upgrade to management... | 18:52 |
kanavin_ | most upstreams do not support anything except the latest released version | 18:52 |
rfs613 | the folks i'm working with at least have plans to move to kirkstone... though I suspect there will be dunfell holdouts for quite a while yet... | 18:53 |
kanavin_ | rfs613, yes, security can be a major selling point to not stick with the old stack. Another is that falling far behind upstream means unpredictable effort when you do need to upgrade (e.g. not possible to estimate or plan). | 18:54 |
sakoman | rfs613: kirkstone support is also scheduled to end in April 2024 | 18:54 |
rfs613 | been on both ends of that stick, I can appreciate product owners being fearful of changing stuff | 18:54 |
sakoman | rfs613: dunfell support was extended two years as an experiment | 18:54 |
kanavin_ | I have an even more radical view: everyone should be doing product development on top of master, and branch off to LTS for shipping products | 18:55 |
rfs613 | kanavin_: and for folks with 10+ year product life cycles? | 18:55 |
*** florian_kc <florian_kc!~florian@dynamic-078-048-002-172.78.48.pool.telefonica.de> has joined #yocto | 18:56 | |
kanavin_ | rfs613, push software updates to deployed products that take them from one LTS to a newer LTS | 18:56 |
sakoman | rfs613: those folks should have developed a plan before committing to 10 years! | 18:56 |
fury | what am i supposed to see when core-image-sato finishes booting up? right now all i'm getting is a blank black screen after the boot progress bar goes to full | 18:56 |
sakoman | (and included the cost of that support in their plans!) | 18:56 |
rfs613 | and they also need a crystal ball to predict shutdown of 2G cell network, they need double or triple the flash space (because eveyrthing gets bigger over time), etc. | 18:57 |
kanavin_ | rfs613, 'product owners being fearful of changing stuff' == 'our testing sucks or is non-existent' | 18:57 |
rfs613 | those are do-able but at a cost.. not going to work in many situations | 18:57 |
sakoman | rfs613: In that case they shouldn't be committing to 10 years! | 18:58 |
rfs613 | hehe half the time it takes them 2 years just to develop the product... it's obsolete on launch day ;-) | 18:59 |
kanavin_ | sakoman, you should make a talk with your perspectives in a year's time | 19:00 |
sakoman | kanavin_: I suspect it would be a quite boring talk | 19:02 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 19:02 | |
kanavin_ | fury, you should be seeing something like this on the right https://blog.mbedded.ninja/programming/embedded-linux/yocto-project/yocto-running-qemu-after-building-default-linux-image.png | 19:02 |
kanavin_ | sakoman, then just an email :) | 19:02 |
fury | hmm. that's what i figured. wonder what i'm doing wrong | 19:02 |
rfs613 | fury: i only tried it under qemu a long time ago, but I recall there was some splash screen and then some kind of basic desktop | 19:02 |
*** florian_kc <florian_kc!~florian@dynamic-078-048-002-172.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 276 seconds) | 19:02 | |
fury | i started with plain ol' poky and added meta-raspberrypi so i could build for the raspberry pi zero w | 19:03 |
fury | i am on langdale | 19:03 |
*** Haxxa <Haxxa!~Haxxa@202.65.68.206> has quit IRC (Quit: Haxxa flies away.) | 19:15 | |
*** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 19:17 | |
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 264 seconds) | 19:22 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 19:40 | |
*** Wouter010067044 <Wouter010067044!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 19:40 | |
*** florian_kc <florian_kc!~florian@dynamic-078-048-002-172.78.48.pool.telefonica.de> has joined #yocto | 19:43 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 240 seconds) | 19:52 | |
kanavin_ | fury, I suggest you first build the same image for qemu and verify that graphics do indeed come up. | 19:53 |
kanavin_ | fury, then start looking for errors in logs on the actual hardware | 19:54 |
*** GillesM <GillesM!~gilles@126.88.69.37.rev.sfr.net> has joined #yocto | 20:13 | |
*** amitk <amitk!~amit@103.208.71.75> has quit IRC (Ping timeout: 255 seconds) | 20:16 | |
*** |Xagen <|Xagen!~Xagen@4.14.206.69> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 20:27 | |
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 20:43 | |
*** olani- <olani-!~olani@83-233-29-230.cust.bredband2.com> has joined #yocto | 20:48 | |
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 20:55 | |
*** florian_kc <florian_kc!~florian@dynamic-078-048-002-172.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 276 seconds) | 20:56 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 20:58 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 21:10 | |
*** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 21:10 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 21:15 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 21:18 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Client Quit) | 21:20 | |
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 240 seconds) | 21:22 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 21:26 | |
*** florian_kc <florian_kc!~florian@dynamic-078-048-002-172.78.48.pool.telefonica.de> has joined #yocto | 21:27 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 240 seconds) | 21:34 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 21:34 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 268 seconds) | 21:39 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 21:39 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 22:07 | |
*** seninha <seninha!~seninha@user/seninha> has joined #yocto | 22:07 | |
*** Guest18 <Guest18!~Guest18@2a01:c23:945c:4901:cdff:a522:7b21:79fa> has joined #yocto | 22:26 | |
RP | fury: if I remember rightly, meta-raspberrypi messes with the splash screen | 22:31 |
* RP doesn't know what else it does | 22:31 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 22:34 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 22:34 | |
*** Guest18 <Guest18!~Guest18@2a01:c23:945c:4901:cdff:a522:7b21:79fa> has quit IRC (Ping timeout: 260 seconds) | 22:36 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 240 seconds) | 22:39 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 22:39 | |
*** Guest18 <Guest18!~Guest18@2a01:c23:945c:4901:7dc1:8cc6:62b7:aaa8> has joined #yocto | 22:41 | |
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 255 seconds) | 22:54 | |
*** azcraft <azcraft!~AzCraft@195.214.252.213> has quit IRC (Remote host closed the connection) | 23:00 | |
*** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.) | 23:24 | |
*** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Ping timeout: 240 seconds) | 23:31 | |
*** Haxxa <Haxxa!~Haxxa@202.65.68.206> has joined #yocto | 23:32 | |
*** Guest18 <Guest18!~Guest18@2a01:c23:945c:4901:7dc1:8cc6:62b7:aaa8> has quit IRC (Ping timeout: 260 seconds) | 23:33 | |
*** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 255 seconds) | 23:38 | |
*** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 23:39 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds) | 23:40 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 23:41 | |
*** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 268 seconds) | 23:44 | |
*** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 23:44 | |
*** ardo <ardo!~ardo@host-79-49-38-54.retail.telecomitalia.it> has quit IRC (Ping timeout: 246 seconds) | 23:55 | |
*** ardo <ardo!~ardo@host-95-235-40-220.retail.telecomitalia.it> has joined #yocto | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!