Wednesday, 2021-08-11

*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto00:34
*** felixi <felixi!~felixi@cable-hki-50dc2c-3.dhcp.inet.fi> has quit IRC (Ping timeout: 272 seconds)00:46
*** felixi <felixi!~felixi@cable-hki-50dc2c-3.dhcp.inet.fi> has joined #yocto00:48
halsteadAnyone with devtool experience willing to help me with some AB test issues?00:54
*** wing0 <wing0!~wing0@2804:431:c7ed:41c:20ad:47f:325f:7c35> has quit IRC (Quit: WeeChat 3.1)01:02
*** hpsy1 <hpsy1!~hpsy@85.203.15.67> has quit IRC (Ping timeout: 272 seconds)02:04
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection)02:20
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 252 seconds)02:32
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto02:37
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Quit: Leaving.)02:40
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)03:03
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection)03:07
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto03:08
*** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto03:33
*** amitk <amitk!~amit@103.208.69.187> has joined #yocto03:52
*** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 248 seconds)03:55
*** Tokamak <Tokamak!~Tokamak@107.117.203.145> has quit IRC (Ping timeout: 258 seconds)03:56
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has joined #yocto04:11
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev)04:26
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection)04:32
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto04:32
*** camus1 is now known as camus04:34
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)04:37
*** mihai- <mihai-!~mihai@user/mihai> has joined #yocto04:47
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Ping timeout: 248 seconds)04:50
*** Guest68 <Guest68!~Guest68@2001:420:c0c8:1001::834> has joined #yocto05:04
*** Guest68 <Guest68!~Guest68@2001:420:c0c8:1001::834> has quit IRC (Client Quit)05:06
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:50
*** fray <fray!~fray@kernel.crashing.org> has quit IRC (Ping timeout: 240 seconds)05:50
*** fray <fray!~fray@kernel.crashing.org> has joined #yocto05:51
*** mihai- is now known as mihai05:56
*** wing0 <wing0!~wing0@179.113.134.50> has joined #yocto06:05
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:10
mihaiyo06:12
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto06:24
*** davidinux <davidinux!~davidinux@217.138.219.36> has quit IRC (Quit: WeeChat 2.8)06:26
*** davidinux <davidinux!~davidinux@217.138.219.36> has joined #yocto06:31
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** frieder <frieder!~frieder@41-68-142-46.pool.kielnet.net> has joined #yocto06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:40
*** frieder_ <frieder_!~frieder@41-68-142-46.pool.kielnet.net> has joined #yocto06:41
*** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto06:41
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)06:52
*** frieder_ <frieder_!~frieder@41-68-142-46.pool.kielnet.net> has quit IRC (Quit: Leaving)06:52
*** zpfvo <zpfvo!~fvo@i59F44E98.versanet.de> has joined #yocto06:55
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 248 seconds)06:56
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto06:56
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto06:56
LetoThe2ndyo dudX06:56
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:cc0:9aba:43d0:8fe8> has joined #yocto06:58
*** wing0 <wing0!~wing0@179.113.134.50> has quit IRC (Quit: WeeChat 3.1)07:00
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)07:03
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds)07:17
mihaiif I'm using file://* in SRC_URI, should pseudo aborts surprise me? :)07:26
LetoThe2ndmihai: actually it should, yes.07:27
LetoThe2ndmihai: AIUI the pseudo aborts are mostly caused by, lets call it "unwanted/unexpected things" happening to sstate/tmp. SRC_URI should be completely unproblematic07:28
mihaiI've been getting some in the last couple of days, but figured it's because of my SRC_URIs07:28
LetoThe2ndmihai: and what is so special about that SRC_URI?07:29
LetoThe2ndsounds like those are... "tricky".07:29
mihaiwell I vaguely remember something about staying away from it07:30
mihaibut I can't remember the reason07:30
LetoThe2nda hardcoded, constant file:// SRC_URI should be perfectly unproblematic. those must be used in thousands in oe-core alone. however, if you tried to do something "clever" there, things might be different.07:32
mihainot helping with "constant" :)07:33
mihaiI did mention: file://*07:33
LetoThe2nd?07:33
LetoThe2ndah that "*" was not a placeholder? you actually did use globbing in there?07:33
mihaiyes :D07:34
LetoThe2ndgo away.07:34
mihai:)))07:34
LetoThe2ndyup, thats gonna give you headaches.07:34
mihaicool07:35
manuel_Talking about file:// SRC_URIs, I'm thinking about storing the source tree of some packages directly in the meta-layer. Has anyone any hints on that?07:36
manuel_Little helper packages with just a few LOC07:36
LetoThe2ndmanuel_: it can have advantages for really, really small things, like a small helper script or such, yes.07:36
manuel_I think it would make sense to tell Bitbake not to do any package versioning on them but just build them. Build doesn't take more than a few seconds anyway.07:37
LetoThe2ndmanuel_: for anything that extends beyond one source file, i personally suggest to do otherwise.07:37
manuel_LetoThe2nd: Agree.07:37
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto07:38
manuel_How do I tell bitbake that the package needs to be rebuilt?07:38
LetoThe2ndmanuel_: and bitbake always does version your stuff. you can force rebuilds every time per recipe, but thats definitively discouraged.07:38
LetoThe2ndbitbake -c clean :)07:38
manuel_So should I bump the version part of the recipe filename everytime I change something in my source tree? Or set {PV} in the recipe?07:39
LetoThe2ndgood question. however i think thats more of a philosophical question - do you really expect that script to change that often?07:40
manuel_Or can I have bitbake check the time stamp of the files in the files/ subdir next to recipe?07:41
LetoThe2ndnope, that makes the build non-deterministic. not all VCS keep timestamps.07:41
manuel_Ok I see07:41
manuel_VCS interaction is still a bit unclear to me07:42
manuel_When my recipe follows a git branch, does bitbake poke the remote repo at every build for new commits?07:42
manuel_Things like that07:43
LetoThe2ndnope. it checks if it already has the version that you have set in SRCREV. if it has, it builds. if it doesn't have, it gets that version, then builds.07:43
manuel_I see. And what if SRCREV=${AUTOREV}?07:44
LetoThe2ndfor the script recipe, it *think* setting do_build as nostamp might do the trick. its not exactly pretty, but if it works well enough for the given case, then so be it.07:44
qschulzmihai: globbing does not work in SRC_URI07:44
qschulzyou think it does, but it does not. do not use it07:44
LetoThe2ndAUTOREV makes it poke the repo on each build. and completely breaks determinism, as well as builds from download cache. avaoid.07:45
qschulzgive a full directory to it or list every file you want to include07:45
mihaiqschulz: exactly, I think it does :) ok, I'll stay away from it07:45
qschulzgo for the latter if there's a chance one of the files can be overridden07:46
manuel_LetoThe2nd: Super, thanks for your insight.07:46
qschulzso... go for the latter :p07:46
LetoThe2ndmanuel_: have fun07:46
qschulzmihai: basically, the most obvious issue is that file changes aren't watched, so any change to your files won't trigger a rebuild07:46
manuel_qschulz: Didn't know Bitbake does that07:47
qschulzmichaelo: I just need to create commits for yocto-docs override change and I will send them07:47
LetoThe2ndmanuel_: it bakes bits. isn't that obvious?!?07:48
qschulzfound a thing or two to fix meanwhile (at least those I noted :) )07:48
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto07:48
qschulzRP: is there a place to note all variables that looks like they're using overrides but aren't?07:49
qschulzA wiki page maybe or something?07:49
manuel_LetoThe2nd: But doesn't what qschulz contradict you?07:49
*** bps <bps!~bps@27-reverse.bang-olufsen.dk> has joined #yocto07:49
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 248 seconds)07:49
*** camus1 is now known as camus07:49
qschulzI found a few more occurrences yesterday while going through the doc07:49
manuel_He said file changes are not gonna watched if SRC_URI=file://*07:49
manuel_and you said checking the timestamp of the files in files/ subdir would make the build non-deterministic07:49
qschulzmanuel_:  also breaks file overrides in other layers and do not fetch newer files IIRC07:50
LetoThe2ndmanuel_: why would it contradict?07:50
* mihai feels sorry about mentioning file globbing 07:50
manuel_Arent you talking about the same set of files here?07:50
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 258 seconds)07:51
LetoThe2ndmanuel_: i think thats different aspects here.07:51
manuel_recipes-test/test_1.0.0.bb and then recipes-test/files/THIS-FILES-HERE07:51
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:51
LetoThe2ndbut granted, its not one of the things i use on a regular basis07:51
LetoThe2ndi mean, timestamp != file content.07:53
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:cc0:9aba:43d0:8fe8> has quit IRC (Ping timeout: 258 seconds)07:54
LetoThe2ndqschulz: this is where my knowledge gets shaky. are files that are directly referenced in SRC_URI checked for modifications? i actually don't think so, just that SRC_URI goes into the dig.07:54
LetoThe2nds/dig/sig/07:54
qschulzLetoThe2nd: they are checked07:55
qschulzyou can check with bitbake-dumpsig of the fetch task07:55
qschulzyou can see a checksum per included file07:55
LetoThe2ndqschulz: they are? interesing.07:55
LetoThe2ndmanuel_: in that case, please mentally eradicate my mention of nostamp quickly!07:55
LetoThe2ndqschulz: i don't look at dumpsig usually07:56
qschulzLetoThe2nd: well... it's usually what you have a look at when something should be rebuilt and isn't or the opposite07:57
manuel_Super, now it all makes sense. Thanks qschulz and LetoThe2nd!07:57
qschulzand since I had a few issues like that in my previous company, I unfortunately had to deal with it07:57
qschulzand that's how I discovered the SRC_URI globbing thing being brokenb07:57
LetoThe2ndqschulz: interesting technique. when i see something build or not build, i usually jsut start over, find me a beer and find everything done when i've finished drinking.07:58
*** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 248 seconds)08:04
*** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto08:06
mihaiLetoThe2nd: your technique sounds better :D08:12
LetoThe2ndi know. thats why i employ it.08:13
RPqschulz: we probably should start something08:15
LetoThe2ndRP: like, drinking?08:18
LetoThe2ndbut on a more serious note. couldn't a glob in SRC_URI trigger a QA note?08:18
LetoThe2ndthen, if somebody really really wants to use it, they would at least have to willingly skip the check and therefore be notified that it is problematic.08:19
qschulzLetoThe2nd: I think something's been done in more recent releases08:21
qschulzLetoThe2nd: https://docs.yoctoproject.org/migration-guides/migration-3.2.html#globbing-no-longer-supported-in-file-entries-in-src-uri08:22
michaeloqschulz: great, thanks :)08:23
LetoThe2ndqschulz: ah yeah, thats a good step. but i'm thinking of going beyond that, so the build actually doesn't run until you really for it to. or what happens when i put a * into there in gatesgarth?08:24
qschulzLetoThe2nd: I haven't checked but I assume no file will be fetched08:25
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:25
LetoThe2ndi want it to go boom!08:26
qschulzLetoThe2nd: https://cgit.openembedded.org/bitbake/commit/?id=0c9302d950c6f37bfcc4256b41001d63f668bdf708:27
LetoThe2ndsweeeeeet!08:28
qschulzLetoThe2nd: "and error to the user if they have"08:28
qschulzsuch urls.08:28
qschulzso... mihai... update to 3.2+ release :p08:28
qschulzand you would know this is bad :p08:28
LetoThe2ndyep08:29
mihaior backport to dunfell? :D08:29
LetoThe2ndmihai: that would be the obivous thing, but actually would break the "somewhat working" state, and such contradicts the LTS thinking.08:30
mihairight08:31
mihaitrue08:31
RPLetoThe2nd: doesn't it error on that now?08:41
RPah, yes. Thought we made it do that08:41
qschulzRP: just not cherry-picked in bitbake used on Dunfell I guess08:43
RPqschulz: probably too invasive for an LTS08:44
LetoThe2ndRP: way too invasive.08:44
qschulzyeah I'm torn... it's "fixing" something that does not work08:45
qschulzbut eh, if Dunfell is EOL soon, might not have to care that much about it :p08:46
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto08:55
prabhakarladHi all, I am seeing the below issues when I try and build wic image08:55
prabhakarlad("The artifact that couldn't be found was %s:\n  %s", 'rootfs-dir', '/builds/0/meta-rzg2/build-scripts/build/build/tmp/work/smarc_rzg2l-poky-linux/core-image-minimal/1.0-r0/rootfs')08:55
prabhakarladany pointers for the above ? bitbake core-image-minimal works as expected.08:56
Guest48Can you post what you setup in you local.conf ?09:01
prabhakarlad# Enable multilib to support 32-bits applications.09:32
prabhakarladrequire conf/multilib.conf09:32
prabhakarladMULTILIBS = "multilib:lib32"09:32
prabhakarladDEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf-neon"09:32
prabhakarladIMAGE_INSTALL_append = " lib32-htop"09:32
prabhakarlad# Create wic image for easy flashing09:32
prabhakarladIMAGE_INSTALL_append = " kernel-devicetree"09:32
prabhakarladIMAGE_FSTYPES_append = " wic.gz"09:32
prabhakarladWKS_FILE = "rootfs.wks"09:32
prabhakarladIMAGE_INSTALL_append = " kernel-image kernel-devicetree"09:32
lukmaRP: Maybe a bit strange question - is it also required (after bitbake override syntax) to also convert idioms like: "RDEPENDS_${PN}-devel" to "RDEPENDS:${PN}-devel" ?10:09
qschulzlukma: yes10:09
lukmaqschulz: Ok thanks for the info ....10:14
lukmaBTW: What was the rationale for this change? To use the C++ scope ':' operator to make the code looking more clean?10:15
lukmaOr it was clumsy to use the '_' as it would look like the part of the variable name ?10:16
rburtonthe latter10:18
qschulzespecially since some overrides could have _ in their name too10:19
rburtonand overrides are arbitrary, so you might call a variable foo_bar but then bar becomes an override in a new BSP10:19
qschulzit could probably bring parsing speed improvement too, since it'll probably be a "dumb" split on : instead of trying to figure out if the _ is part of the variable/override or if it's the override separator10:19
qschulzrburton: hence why variables should be uppercase :p10:20
LetoThe2ndwe should just get rid of variables altogether and rewrite everything functional style. and i'm not talking haskell, thats way too real life. maybe lisp10:24
LetoThe2ndor for the sh*** and giggles, lets go for f#, procedural extensions in cobol.10:25
*** davidinux <davidinux!~davidinux@217.138.219.36> has quit IRC (Ping timeout: 248 seconds)10:33
rburtonLetoThe2nd: sounds like you want to use guix10:35
LetoThe2ndrburton: but only with hurd. otherwise its way too real life.10:36
*** davidinux <davidinux!~davidinux@217.138.219.36> has joined #yocto10:38
lukma:-)10:39
lukmaI would opt for having everything in python ....10:40
lukmaif not - then +1 for Lisp10:40
lukmaEmacs cannot be wrong .... :D10:40
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving)10:42
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed)10:58
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has joined #yocto10:58
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)11:10
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed)11:25
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has joined #yocto11:26
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto11:36
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto11:40
*** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto12:25
michaeloHey. With the latest (master) Poky, BitBake refuses to run: ERROR: Variable PACKAGECONFIG_append_pn-qemu-system-native contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.12:50
marexmichaelo: PACKAGECONFIG:append:pn-......12:50
marexmichaelo: s@_@:@g12:50
michaeloAny tips for finding the code that needs fixing?12:50
michaelomarex: yes, I know, but struggling to find the bad code12:51
marexgit grep ?12:51
michaelomarex: already tried, but didn't find "PACKAGECONFIG_append_pn-qemu-system-native", and even looking for "PACKAGECONFIG_append" doesn't help12:52
qschulzmichaelo: local.conf or sample conf file somewhere12:55
lukmamichaelo: There was some kind of script, which was supposed to facilitate the conversion ....12:55
qschulzit was discussed yesterday on this channel12:55
*** Chep <Chep!~chep@88.168.197.200> has joined #yocto12:56
michaeloGood idea to check my local.conf12:56
michaeloqschulz: good catch, it was a line that was left unchanged in local.conf. That's why I couldn't find it with git grep :)12:57
michaeloqschulz: thanks!12:58
michaelolukma, marex: thanks too12:58
ChepHi, I need some python code to fetch some sources. As I need it in several recipes, I want to create a tool for the host and use it in do_fetch functions. I tried to create a recipe mytool-native.bb and add DEPENDS_${PN} = "mytool-native" in my recipe but in do_fetch, I can't import my python code and I can't find the source code in package's sysroot or any other folder. How can I do that?12:59
marexqschulz: you beat me to it, I was also about to suggest to check bitbake -e output12:59
marexmichaelo: ^12:59
qschulzmarex: probably won't work since I assume this error happens during parsing, so it'll fail before bitbake -e can output anything13:01
qschulzChep: DEPENDS = "mytool-native"13:01
*** otavio_ <otavio_!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto13:03
Chepqschulz: that only works when I use my tool in do_build function13:04
Chepit seems like the dependencies are not available when fetching13:04
qschulzChep: my bad, misread. Why do you want it in the do_fetch? What are you going to do with this tool?13:05
*** nerdboy_ <nerdboy_!~nerdboy@47.143.129.193> has joined #yocto13:05
michaelomarex: right, "bitbake -e" was failing too for the same reaons13:05
Chepqschulz: I need to fetch data from an artifactory server13:07
Chepand use its api13:07
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 258 seconds)13:07
LetoThe2ndChep: sounds more like you want to write a custom fetcher for it.13:08
ChepLetoThe2nd: exactly13:10
LetoThe2ndChep: but then you're on the wrong track. custom fetchers are not supposed to be implemented in the recipes per so, but to be triggered by the SRC_URI. something like "artifactory://xxxxx"13:11
qschulzChep: lib/bb/fetch2 in bitbake git repo to check how fetchers are done :)13:12
LetoThe2ndChep: i think you can look at examples for custom fetchers in layers that bring language support, like rust or scala13:12
Chepthanks13:12
Chepthat sounds great13:12
ChepAnd can I tell bitbake that the fetcher is in my layer?13:13
LetoThe2ndChep: like i said, take a look at such a layer13:15
LetoThe2ndChep: here's the one for rust: https://github.com/meta-rust/meta-rust/blob/master/lib/crate.py13:20
Chepthanks13:20
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto13:43
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)13:55
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto13:58
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)14:00
*** xmn <xmn!~xmn@p200300c37f2e99003d43672b48a82607.dip0.t-ipconnect.de> has joined #yocto14:04
*** flynn378 <flynn378!sid63564@id-63564.charlton.irccloud.com> has joined #yocto14:19
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto14:28
*** xmn <xmn!~xmn@p200300c37f2e99003d43672b48a82607.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 276 seconds)14:31
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto14:33
*** Fulgo <Fulgo!~Fulgo@239.red-81-34-255.dynamicip.rima-tde.net> has joined #yocto14:35
FulgoHello everyone. I am working on a minimal YOCTO image. This image is basically the core-image-minimal. The point here is that after analyzing the build history, I am noticing that udev-hwdb is pretty big (6664 KiB). I am doing some research and I found out I can disable it by using BAD_RECOMMENDATIONS += "udev-hwdb", but I did not found any14:39
Fulgoresource explaining if I can reduce its size without removing it or what impact can cause if it is removed. Thanks in advance.14:39
FulgoAll the resources I found speaks about how to update the hwdb, that it is a key value database and that it is used by udev, but I have no clue about if it is interesing to have it, if it impacts on the performance.... :/14:40
qschulzFulgo: FWIW, my previous company removed it and the product was working just fine14:41
JPEWFulgo: IIRC it might affect what tags udev adds to a device and thus might prevent something like and input device from being handled properly14:42
FulgoI have seen how other people use it for key remapping14:43
JPEWFulgo: Ya it probably can do that too. If you have a closed set of devices you need it to support and you've validated they all work, it's probably optional.14:43
FulgoThe problem is that compared to the other packages this is pretty big, and for sure most part of the hwdb is not being used. So, I was wondering if it is possible to reduce it (how to do it could be a secret :/ ) or just to disable it14:44
JPEWbut, if you need to for example, "support any USB input device the user might plug in" than you want it14:44
rfs613https://www.freedesktop.org/software/systemd/man/hwdb.html14:44
rfs613you can take the text version, strip out what you don't want/need, and generate a much smaller binary version14:45
rfs613knowing which fields you need, that is the tricky part ;-)14:45
Fulgorfs613 yes, that is what I read but... there is nothing about apart from what it is. I mean, why is all that stuff in it14:45
FulgoAnd I guess I should createa a bbappend to modify how it is created, but I have not found yet where these hwdbs are populated :/14:46
rfs613just assorted property values... which udev matches as new devices appear (eg. during boot, or when you plug in a new device like USB)14:46
rburtonthe source is https://github.com/systemd/systemd/tree/main/hwdb.d14:46
rburtonyou can likely delete chunks if you know you'll never need them14:47
* rfs613 nods14:47
rburtonlike all the mouse/touchpad stuff  if you know you're not going to plug in input devices14:48
FulgoYes, I see somethin in  /sources/poky/meta/recipes-core/systemd/systemd_244.3.bb14:48
FulgoSo, it is not recommended that I remove it XD14:48
rburtondepends on your use case really14:49
JPEWJust depends on the requirements you have. I would not remove it if the user is allowed to plug in arbitrary USB devices and have them "work"14:49
JPEWOr any device (not just USB) for that matter14:49
FulgoOk. The requirements are minimal, so I should not require any of this. But what really worries me is that there should be a way of managing what should be in the database14:52
qschulzor devices that are already on the system but whose drivers are modules and can be probed later for example14:52
*** xmn <xmn!~xmn@p200300c37f2e99003d43672b48a82607.dip0.t-ipconnect.de> has joined #yocto14:53
FulgoOk... But nobody knows if it is possible to customize those databases as the image is created or how this is usually handled14:54
rburtoni believe its not usually customised14:55
FulgoAt least there is no info about it14:56
rfs613Fulgo: well, take the 70-mouse.hwdb for example... primarily it contains the DPI settings for a few hundred different mice, identified by their vid/pid numeric codes. Would you want to manually enable/disable each one of these, just to reduce the database size a bit? On most desktop systems where this gets used, the driver is gigabytes, so the database is insignificant.14:56
FulgoIt is just commented that it is a database but nothing elase14:56
rfs613s/driver/disk drive/14:56
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Read error: Connection reset by peer)14:57
Fulgorfs613 yes, that is true. I know they are about 7MB, but when you need a minimal rootfs... every byte counts. Obviosly, if the effort required is insane, I discard the idea14:57
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto14:58
rfs613on an embedded system where storage space is much more constrained, you usually don't have anywhere as wide of a range of devices that might be plugged in, so you can just skip the database entirely in most cases. For mouse it will just mean the sensitivity (DPI) may be wrong.14:58
FulgoBut it could be something like the kernel: enable/disable for example the suppor for the mouses, and that is all XD14:58
LetoThe2ndFulgo: send patches :)14:59
rfs613There's a similar problem for kernel device drivers... do you fine-tune the configuration to have just the drivers you need, or do you build them all (or most of them) and accept the extra space it takes up? These days most people seem to take the 2nd option.15:00
FulgoFor a desktop image ok, but for an embedded one... It should be the smaller the better15:02
LetoThe2ndFulgo: you're essentially doing the learning stage "anybody can build a raspi image with 500MB to run some script. but to make a real, productizable thing, it requires knowledge and effort"15:03
FulgoObviosly, after analyzing this, the next step will be.... attacking the kernel XD15:03
LetoThe2ndand most of us have been there some time too15:03
FulgoI agree with you LetoThe2nd. But normally, people learns from documentation or others work, to invent something new is pretty hard, that is why I am asking15:04
FulgoI am just trying to learn and only after doing some research I ask :(15:05
FulgoBut if the official documentation says that it is a database and no much more... It does not even say about what happend if the udev-hwdb is disabled.15:06
LetoThe2ndFulgo: those are areas where most people do not easily ahre with outsiders anymore, as it is often considered internal knowhow, i'm sorry.15:06
FulgoUnderstood :(  sorry for asking then15:06
*** fury <fury!uid193779@id-193779.brockwell.irccloud.com> has left #yocto15:07
LetoThe2ndno need to be sorry, its good to ask. just explaining why documentation is rare then. if more people would *really* care about it, they could become YP members, invest money and say "hey, this is what we want and care about".15:07
LetoThe2ndas long as that doesn't happen... it will stay the way it is.15:08
FulgoOk15:08
FulgoIt is matter of money then XD15:09
qschulzAlso, size and boot time reduction heavily depends on your platform, the devices that are connected to it, your rootfs, the app you're running on it, etc...15:10
qschulzthere's no "one size fit all"15:11
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)15:11
FulgoYes. If the product has those constraints, they are hard to handle also, qschulz15:11
FulgoBut nothing about this in the Mastering embedded  Linux programming 3rd edition book XD15:12
FulgoBut LetoThe2nd just to know if  it is possible or not, or if it makes sense... the udev-hwdb should be reduced or disabled? I guess this is not an answer with copyright :P15:15
FulgoI do not want to take part in the Infinite Wars :/15:15
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto15:17
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-30-222.mycingular.net> has joined #yocto15:20
rfs613Fulgo: the title of that book is misleading... I've been doing embedded linux for at least 25 years, and I'm still nowhere near "mastering" it ;-)15:24
FulgoHahaha, I am jokin meeen XD15:24
rfs613Me too (but I really have been using Linux that long, mostly embedded...)15:25
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds)15:25
rfs613the point is you can never master it, there's just too much, and it all keeps changing...15:25
FulgoI am more focused on bare metal or using RTOS, but with YOCTO I am suffering a bit XD15:25
FulgoYes, I agree15:25
FulgoI think I understand how to do it anyway. Easy peasy lemon squeezy15:26
FulgoAnd there are not so much things to remove. It is just to decide what to put from the sources downloaded. That is all. If you do not need usb keyboards... OUT XD. That is all15:27
rfs613btw have you looked at how big all the systemd stuff is? If your needs are modest, and you want a smaller image, I'd suggest trying good old sysvinit instead.15:27
FulgoYes, but the list of mice for example, it is all gathered in one file. If you are not going to connect a mouse, do not include 70-mouse.hwdb and that is all15:28
rfs613exactly!15:29
FulgoYou can do it with a bbappend of the recipe that is on charge of doing that15:29
FulgoNothing else15:29
FulgoEasier than I thought15:29
*** ant__ <ant__!~ant@host-87-0-28-96.retail.telecomitalia.it> has joined #yocto15:33
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-30-222.mycingular.net> has quit IRC (Ping timeout: 258 seconds)15:39
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-30-222.mycingular.net> has joined #yocto15:41
qschulzalso, might want to use mdev if your size constraint is extreme. and yes, sysv vs systemd is a good choice when size's involved15:46
*** xmn <xmn!~xmn@p200300c37f2e99003d43672b48a82607.dip0.t-ipconnect.de> has quit IRC (Quit: ZZZzzz…)15:48
*** aleblanc <aleblanc!~aleblanc@192-222-183-114.qc.cable.ebox.net> has joined #yocto15:48
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has joined #yocto15:57
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Read error: Connection reset by peer)15:58
*** zpfvo <zpfvo!~fvo@i59F44E98.versanet.de> has quit IRC (Remote host closed the connection)16:00
* paulg idly wonders how we'd ever know if anyone is using yaffs2 in Yocto vs. an "in mainline" fs solution...16:00
paulgwas basically a decade ago when it tried but never managed to go mainline...   https://lwn.net/Articles/529121/16:00
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-30-222.mycingular.net> has quit IRC (Ping timeout: 268 seconds)16:01
paulghttps://yaffs.net/documents/faq     <----- dated 2012.16:02
*** Tokamak <Tokamak!~Tokamak@107.117.203.145> has joined #yocto16:05
ant__ "a choice between mainlining it and not continuing to make a living"16:08
ant__project dead :/16:08
ant__see, for these legacy linux devices ubifs was already a gigantc leap16:09
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto16:15
paulgI kinda was finding myself thinking in the same direction, but I'm always one to lean towards cutting bait and moving on ; even on crap I've written myself.16:18
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:25
*** Fulgo <Fulgo!~Fulgo@239.red-81-34-255.dynamicip.rima-tde.net> has quit IRC (Quit: Client closed)16:26
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)16:31
marexpaulg: yaffs is yet another forgotten file system ?16:31
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:34
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has joined #yocto16:39
ant__marex: nasty16:40
ant__marex: you are still guilty, you should have ported u-boot to pxa Z at least16:43
ant__I had to spend 10yrs on kexecboot to circumvent your lazyness :)16:44
ant__..but I learned a lot about MTD, thanks !16:45
*** frieder <frieder!~frieder@41-68-142-46.pool.kielnet.net> has quit IRC (Remote host closed the connection)16:46
*** aleblanc <aleblanc!~aleblanc@192-222-183-114.qc.cable.ebox.net> has quit IRC (Ping timeout: 268 seconds)16:56
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:01
*** Tokamak <Tokamak!~Tokamak@107.117.203.145> has quit IRC (Ping timeout: 258 seconds)17:01
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto17:15
*** rcw <rcw!~rcwoolley@45.72.203.103> has joined #yocto17:16
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds)17:21
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto17:23
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has joined #yocto17:23
paulglooks like sgw kicked its surrounding infrastructure  to the curb a decade ago: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7aabd71d0a84c689f747eab95a4e8370ff35889f17:26
paulgI'll suggest to zeddii he can consider doing the same for the kernel portion for spring 2022.17:27
*** Tokamak <Tokamak!~Tokamak@107.117.203.161> has joined #yocto17:33
*** aleblanc <aleblanc!~aleblanc@192-222-183-114.qc.cable.ebox.net> has joined #yocto17:34
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)17:37
JPEWsgw. rburton : I just pushed all my SBoM stuff to poky-contrib: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/sbom17:39
sgwpaulg: what am I being blamed for now?  goodness I hope ;-)17:45
paulgsgw, anybody nuking old cruft is doing goodness by my standards.   :-)17:46
paulgnow if I could only get the powerpc guys to pay attention for similar...  https://lore.kernel.org/lkml/20210709124822.GA56045@windriver.com/17:48
*** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto17:54
overridels17:54
overridels17:54
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto17:56
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:02
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)18:04
*** kranzo <kranzo!~kranzo@p2e539df3.dip0.t-ipconnect.de> has joined #yocto18:05
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto18:05
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection)18:05
*** camus1 is now known as camus18:05
*** Tokamak <Tokamak!~Tokamak@107.117.203.161> has quit IRC (Ping timeout: 258 seconds)18:24
*** Tokamak <Tokamak!~Tokamak@2600:381:1529:c93d:f422:662d:52eb:6d43> has joined #yocto18:30
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto18:48
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)18:53
RPrburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/2372/steps/11/logs/stdio ;-)19:10
paulgI'd eye any unqualified context free autobuilder link with suspicion.   Smells like work.19:12
* paulg had no idea we had a connection cache.19:14
RPpaulg: rburton has broken the build with patches19:23
*** nerdboy_ is now known as nerdboy19:24
paulgRP, see?   I knew it smelled like a to-do work item.19:25
paulgCheck-in and run is a time honoured tradition.19:25
RPpaulg: patches aren't merged, I can just reject ;-)19:27
*** perdmann <perdmann!~patrick@nostromo.0x47.net> has quit IRC (Quit: leaving)19:29
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto19:33
RPrburton: I have a fix on the branch for it19:42
tlwoerneris there a wiki page or blog post on how to integrate the sanitizers into a yocto build? i'm guessing there's a simple flag we can enable in a recipe file or local.conf?19:43
RPtlwoerner: I think you may get to write it!19:45
tlwoernerw00t!19:46
LetoThe2ndhand sanitizers?19:49
*** amitk <amitk!~amit@103.208.69.187> has quit IRC (Ping timeout: 248 seconds)19:49
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)19:55
paulgtlwoerner, be careful -  RP will draw you in and *then* tell you they have to be alcohol-free.19:59
tlwoernerhe just wants what's best for the project, so if that means alcohol-free sanitizers, then so be it!20:04
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)20:10
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto20:17
Xagen_i'm really at the end of my investigative path with this error i'm seeing in Toaster20:20
Xagen_https://pastebin.com/V5FYFUg420:20
Xagen_the packages that it's complaining about at the end are built20:20
Xagen_but it doesn't find them20:20
Xagen_i can't seem to figure out how to fix this20:20
*** Xagen_ is now known as Xagen20:21
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:cc0:9aba:43d0:8fe8> has joined #yocto20:23
rburtonRP: damnit!20:24
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds)20:33
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto20:40
*** Tokamak <Tokamak!~Tokamak@2600:381:1529:c93d:f422:662d:52eb:6d43> has quit IRC (Remote host closed the connection)20:45
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds)20:49
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto20:50
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:07
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto21:09
*** bps <bps!~bps@62.44.138.228> has joined #yocto21:09
*** bps <bps!~bps@user/bps> has quit IRC (Read error: Connection reset by peer)21:12
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:cc0:9aba:43d0:8fe8> has quit IRC (Ping timeout: 272 seconds)21:13
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)21:32
*** Tokamak <Tokamak!~Tokamak@107.117.203.209> has joined #yocto21:33
vmesonXagen: what branch / commit-id is that? Can you reproduce it with poky ? How about outside of toaster ?21:38
RPpaulg: its nearly as if you're thinking of some past trauma? :)21:39
vmesonXagen:  I'm going to break for dinner but will likely check later. We're short on people to fix YP bugs but if you open a defect in the YP bugzilla, someone might look at it.21:40
paulgwell, trying to hack on the fetcher is pretty traumatic ; I don't care who you are.21:40
vmesonXagen: https://wiki.yoctoproject.org/wiki/Bug_reporting_and_Information_levels21:41
RPpaulg: it is, I know that all too well :(21:41
RPpaulg: guess what rburton broke earlier? :)21:42
* paulg giggles21:42
paulgI was pretty sure the wget connect cache wasn't in do_package21:43
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has joined #yocto21:44
paulgthen again with all the millenials clamouring for rust and JIT and what have you, it might just come from do_compile.   :-P21:44
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)21:45
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)21:58
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)22:10
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)22:27
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving)22:31
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)22:34
*** florian_kc <florian_kc!~florian@dynamic-002-244-000-242.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds)22:36
*** Guest48 <Guest48!~Guest48@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed)22:46
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection)22:48
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has joined #yocto23:08
*** xmn <xmn!~xmn@p200300c37f2e9900d8320fb6eca4a095.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)23:13
*** kranzo <kranzo!~kranzo@p2e539df3.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)23:15
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:32
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:cc0:9aba:43d0:8fe8> has joined #yocto23:44

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