Thursday, 2022-03-10

*** Tokamak <Tokamak!~Tokamak@> has joined #yocto00:03
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:13
*** wesm <wesm!> has joined #yocto00:14
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Write error: Connection reset by peer)00:18
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Ping timeout (120 seconds))00:18
*** neuberfran <neuberfran!~neuberfra@2804:14c:b385:848a:b717:56e5:8174:6c5> has quit IRC (Quit: Ping timeout (120 seconds))00:19
*** xmn <xmn!> has quit IRC (Ping timeout: 240 seconds)00:31
*** xmn <xmn!> has joined #yocto00:35
*** osama4 <osama4!> has quit IRC (Ping timeout: 272 seconds)00:41
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)00:49
*** prabhakarlad <prabhakarlad!> has joined #yocto00:53
*** otavio <otavio!> has quit IRC (Remote host closed the connection)00:57
*** sakoman <sakoman!> has joined #yocto01:03
*** yolo <yolo!> has joined #yocto01:27
yoloin the newest bitbake hello example, it runs 'bitbake' in a blank folder and saying some mistakes, I ran it, no errors, no warning about BBPATH unset, what am I missing01:28
yolothere is a bitbake-cookerdaemon.log generated, inside there is no warning or error either, is the newest doc out of date01:29
yoloyes the doc is unclear, BBPATH is not needed until you build out of topdir01:45
*** camus <camus!~Instantbi@> has joined #yocto01:49
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto02:07
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)02:18
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto02:21
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:31
*** starblue <starblue!> has joined #yocto02:33
vmesonyolo: can you provide more context? Are you using poky.git/master or jsut bitbake and what steps are required to encounter the error you see. Did things work before? Did you try to revert?02:36
yoloI did: git clone bitbake; set PATH for bitbake; mkdir hello; cd hello; bitbake; that's all, no errors reported, but the doc says it should report errors. I eventually got the bitbake hellworld working fine. BBPATH is optional(i.e. no error) as long as you stay inside the project02:38
vmesonyolo: ah, yes, I just scrolled back and saw that: 13:16] <yolo> git clone bitbake02:38
yolois devtool a standalone project or just part of poky or something?02:40
yoloplan to restudy bitbake, then oe-core, then openembedded, then poky/yocto before I got lost02:41
yoloalso is toaster mature enough for 'product use'? last time I used yocto toaster just came out :) so I never actually used it02:42
vmesonyolo: devtool is part of YP / oe-core02:43
vmesontoaster is having a mid-life crisis or something. ;-)   It's been around for a while, a few people use it. We were talking about it's future on this week's conference call.02:44
vmesonI think it was broken until RP pushed a bitbake fix: bf723f2c   2022-03-07   server/xmlrpcserver: Add missing xmlrpcclient import02:47
vmesonyolo:  if you see any problems with devtool or toaster or just have comments or questions, we're all ears. Doubly so for patches, in which casse we're all hands...02:48
yolothanks! it has been a while, does yocto/oe-core have a menuconfig like buildroot and the others02:48
vmesonyolo: cmdline, no there's no menuconfig.  Toaster is supposed to be a good way to discover features . I just read / search all the commits, code!02:49
yolothanks again, so the way to use it is unchanged over the years then.02:50
vmesonyolo:  there have been some recent syntax changes on overrides : _ -> :    and some inclusive language changes but yeah, it's basically the same.02:52
* vmeson wanders off for the night...02:53
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)03:27
*** jclsn78 <jclsn78!> has joined #yocto03:38
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto03:38
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 252 seconds)03:41
yolooe-core defaults to ipk(was it rpm?), qemu has no riscv support yet? and local.conf has no parallel build settings I assume bitbake will build in parallel on its own then?03:41
*** xmn <xmn!> has quit IRC (Ping timeout: 256 seconds)03:44
yolo seems broken for me: bitbake core-image-minimal, I got : ERROR: Variable PROVIDES_prepend contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.03:44
*** xmn <xmn!> has joined #yocto03:48
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)03:49
yoloswitched to 2021-10.2-honister branch "fixed" it, that doc is also out of date due to: I guess, old oe-core needs to go with older bitbake version03:56
*** amitk <amitk!~amit@> has joined #yocto04:18
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)04:39
*** camus <camus!~Instantbi@> has joined #yocto04:40
yolofound the riscv meta layer that hopefully contains qemu-riscv04:40
yoloquestion: is musl an officially supported lib in yocto? like what buildroot|opewnrt|alpine does, or it's just an add-on that "you're on your own"04:41
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has quit IRC (Quit: Quitting)05:09
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has joined #yocto05:10
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)05:26
*** Emantor <Emantor!> has quit IRC (Quit: ZNC -
*** Emantor <Emantor!> has joined #yocto05:51
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:52
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:55
*** kroon <kroon!> has joined #yocto05:56
*** michalkotyla <michalkotyla!> has joined #yocto06:08
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)06:17
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto06:36
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)07:05
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:06
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c075:7975:f5a2:1e76> has quit IRC (Remote host closed the connection)07:08
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c075:7975:f5a2:1e76> has joined #yocto07:09
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:30
*** olani <olani!~olani@2a02:aa1:1028:4b00:2b00:8c5e:8af5:6d33> has joined #yocto07:30
*** mckoan|away is now known as mckoan07:37
mckoangood morning07:37
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto07:39
*** rperier_ <rperier_!> has quit IRC (Quit: - Chat comfortably. Anywhere.)07:47
*** rperier <rperier!> has joined #yocto07:47
RPyolo: yes, musl support is there07:50
*** frieder <frieder!> has joined #yocto07:50
*** osama4 <osama4!> has joined #yocto07:55
*** osama <osama!> has joined #yocto07:56
*** osama4 <osama4!> has quit IRC (Ping timeout: 260 seconds)08:00
*** rfuentess <rfuentess!> has joined #yocto08:01
*** olani <olani!~olani@2a02:aa1:1028:4b00:2b00:8c5e:8af5:6d33> has quit IRC (Ping timeout: 268 seconds)08:02
jclsn78rburton: Yeah so I created a man page, but it is just one big file containing the information. Like this it is not of much use...08:08
*** dev1990 <dev1990!~dev@> has joined #yocto08:28
LetoThe2ndyo dudX!08:52
LetoThe2ndquick one - is there some part in the documentation that explains (and shows best practises) for custom commercial licenses? LICENSE="CLOSED" is the usual, but wrong way as we all know.08:53
mckoanLetoThe2nd: hey08:56
LetoThe2ndmckoan: howdy!08:59
*** florian_kc <florian_kc!> has joined #yocto09:06
*** goliath <goliath!~goliath@user/goliath> has joined #yocto09:09
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)09:14
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto09:20
*** risca <risca!> has quit IRC (Remote host closed the connection)09:20
*** risca <risca!> has joined #yocto09:22
*** xmn <xmn!> has quit IRC (Ping timeout: 240 seconds)09:25
rburtonLetoThe2nd: not sure if there's a section but i'd use NO_GENERIC_LICENSE to embed the correct license from the distribution, and LICENSE_FLAGS to mark it as opt-in.
LetoThe2ndrburton: thx!09:33
rburtongrep around for examples of NO_GENERIC_LICENSE, its basically saying 'this license isn't a standard one, use this file as the text'09:34
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 256 seconds)09:34
rburtonits not really documented, which should be fixed09:34
LetoThe2ndextra brownie points!09:35
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto09:36
*** florian <florian!> has joined #yocto09:37
*** lucaceresoli__ <lucaceresoli__!~lucaceres@> has joined #yocto09:38
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection)09:39
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC (Ping timeout: 256 seconds)09:41
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto09:41
qschulzLetoThe2nd: HOWEVER, if multiple of your pieces of software have the same license, it'd probably be better to add this license file to the list of valid licenses09:48
jclsn78qschulz: Thanks09:49
qschulzLetoThe2nd: + as an example of how I did it some time ago09:49
*** GillesM <GillesM!> has joined #yocto09:50
*** osama <osama!> has quit IRC (Quit: WeeChat 3.4)09:51
qschulzLetoThe2nd: you still need the LICENSE_FLAGS though (I didn't need it technically because it was a Proprietary | GPL-3.0 dual license)09:55
LetoThe2ndqschulz: thanks!09:56
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10:07
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit)10:07
RPjclsn78: how would you want it split up?10:11
*** mauro_anjo <mauro_anjo!~quassel@> has joined #yocto10:12
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto10:28
*** lucaceresoli__ <lucaceresoli__!~lucaceres@> has quit IRC (Ping timeout: 272 seconds)10:31
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:85a0:7214:95e:173a> has joined #yocto10:40
*** starblue <starblue!> has quit IRC (Ping timeout: 240 seconds)10:51
*** starblue <starblue!> has joined #yocto10:53
*** pgowda_ <pgowda_!> has joined #yocto11:06
*** JaMa <JaMa!> has quit IRC (Quit: off)11:18
*** mixfix41 <mixfix41!~homefame@user/mixfix41> has quit IRC (Ping timeout: 256 seconds)11:20
RPhmm, two ping failures for centos8-ty-2 :(11:25
*** JaMa <JaMa!> has joined #yocto11:26
*** tre <tre!> has joined #yocto11:54
jclsn78RP: By chapter I would say. On second thought that would only make sense if the chapters were tags to jump between the files I guess12:08
jclsn78The headlineas are also not bold. It is not nice to read12:09
rburtoni'm really curious how well the yocto docs would translate to man pages12:09
rburton(i suspect: not)12:09
rburtonyou can split per book, but then you have a few very large manpages12:09
jclsn78rburton: it is okay, just not structured12:10
rburtonor by chapter, but then you get manpages like yocto-ref-manual-tasks12:10
jclsn78Would be nice to search things like man yocto-layer12:10
jclsn78or man yocto-recipe12:10
jclsn78man yocto-bsp12:10
jclsn78You get the gist12:10
rburtonwhat bit of the docs would those be?12:11
jclsn78No idea12:11
rburtoni think that's the important point :)12:11
jclsn78I guess it would be too much work with a questionable outcome12:11
jclsn78Unless you write some skelton for sphinx to parse or somthing12:11
jclsn78I just had the idea while searching through the vim docs12:12
rburtonyou can generate a mega manpage now.  i'd hope it's not a huge amount of effort to get sphinx to split it into separate pages per book.  separate pages per chapter might be crazy.12:12
jclsn78You can write your plugin and just type :h something and it appears12:12
jclsn78So convenient12:12
jclsn78Yeah it is okay12:13
jclsn78Just weird that the table of contents is not there12:13
*** kroon <kroon!> has quit IRC (Quit: Leaving)12:17
jclsn[m]Does the order of the layers matter?... (full message at
jclsn78I just realized that mine are the other way around12:23
zyga[m]coldspark29[m]: yes, the order matters12:27
jclsn[m]zyga[m]:  So the hierarchy of the layers is determined by this order?12:28
zyga[m]coldspark29[m]: I don't know, I know layers have priority but I've seen cases where ordering does matter12:28
zyga[m]mind you I'm still a novice12:28
jclsn[m]qschulz: ? ^^12:28
qschulzjclsn[m]: properly written layers shouldn't impact the build depending on the order in which they are included12:29
jclsn[m]It is not described under variables12:29
jclsn[m]Alright thanks12:29
qschulzalas, they often aren't properly written :)12:29
jclsn[m]Wondering because it seems that meta-webkit influenced our graphics stack and Chromium12:29
qschulzI mean that's not real,y true what I just said12:29
jclsn[m]Without even having included cog or anything12:30
qschulzbasically, the order matters for layers with the same priority12:30
jclsn[m]So I guess this is bad... (full message at
jclsn[m]In kas they are the other way round actually12:31
qschulzjclsn78: I could see a manpage for the variable glossary, and optionally classes "glossary" too12:32
jclsn[m]Yes I missed that one actually. You need it very often12:33
qschulzjclsn[m]: I have no idea how I would be able to tell you if a specific ordering of layers would be "bad"12:33
qschulzjclsn[m]: as always, contributions welcome :)12:33
jclsn[m]Okay I just wondered12:33
jclsn[m]I will probably need to contribute to kas first, because we need a functionality to generate snapshots12:34
jclsn[m]Jan Kiszka is open for it, but he seems like he wants to plan it first12:34
RPIt seems somewhat perverse that the change to enable the datastore history tracking by default broke the display of history in the output :(12:35
*** tre <tre!> has quit IRC (Remote host closed the connection)12:43
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)13:03
*** davidinux <davidinux!> has joined #yocto13:05
*** hansihe <hansihe!~hansihe@2001:470:69fc:105::1:9dd> has joined #yocto13:16
*** lucaceresoli__ <lucaceresoli__!~lucaceres@> has joined #yocto13:17
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC (Ping timeout: 272 seconds)13:20
*** otavio <otavio!> has joined #yocto13:33
*** xmn <xmn!> has joined #yocto13:33
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto13:41
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** sakoman <sakoman!> has joined #yocto13:50
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto13:53
*** rando25892 <rando25892!~homefame@user/rando25892> has joined #yocto14:06
*** robertd[m] <robertd[m]!~robertdno@2001:470:69fc:105::1:ce51> has joined #yocto14:16
*** florian_kc <florian_kc!> has joined #yocto14:20
robertd[m]hey guys, I have a question regarding ptest14:21
robertd[m]is there a standard way to grab a file, like a test report, from the qemu target?14:22
robertd[m]I saw `copy_from` function in the oeqa, but it's not being used anywhere in ptest test suite context14:24
robertd[m]any hints?14:24
*** Guest81 <Guest81!> has joined #yocto14:25
Guest81Is yocto no longer allowing building under /usr/local/src? Seems PSEUDO_IGNORE_PATHS complains about overlapping paths. Is that intentional?14:26
yolo4 hours re-learn yocto, so far so good. build a glibc minimal and a musl one, now I need write 10 sample recipes to recall :)14:32
yolooelint-adv is pretty strict, is there a syntax-format utility for recipe? like clang-format for c|c++14:33
yoloor, if reciple looks very similar to some other formats I can leverage their formatter14:34
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)14:34
*** marc2 <marc2!> has quit IRC (Ping timeout: 268 seconds)14:52
*** marc2 <marc2!> has joined #yocto14:53
*** nsbdfl <nsbdfl!nsfbdl@user/nsbdfl> has quit IRC (Ping timeout: 250 seconds)15:18
*** opello <opello!~opello@about/csharp/opello> has quit IRC (Remote host closed the connection)15:19
*** opello <opello!~opello@about/csharp/opello> has joined #yocto15:19
*** nsbdfl <nsbdfl!nsfbdl@user/nsbdfl> has joined #yocto15:19
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)15:24
khemyolo: good progress 4hr .. not bad at all. We do not have an utility to rewrite formatted recipe you can take a look at meta-openembedded/contrib/oe-stylize.py15:26
*** sakoman <sakoman!> has joined #yocto15:27
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto15:39
yolocool. Thanks!15:49
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:1416:a546:ff88:20cd> has joined #yocto16:08
pasherringHey there, yoctoers! I've been trying to use dunfell for the past few days and I've been getting a lot of segmenation fault errors during the build... Is there something weird going on upstream, or is it just my setup that should be somehow plagued?16:10
pasherringI mean, the compiler is triggering the segfault16:11
rburtonrun memcheck16:15
rburtonyocto builds thrash your hardware, and bad ram can do that16:15
pasherringrburton, I see. I'll give it a go, thanks! One thing strikes me as strange is that on hardknott, it all builds fine, with no extra tunning required, like BB_NUMBER_THREADS or -l XX -j YY16:22
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:25
RPmoto-timo: just to add, I tried your test script and it worked for me with my patches16:30
moto-timoRP: that is excellent news... probably my guess at the failure mode was just wrong16:31
* moto-timo in a meeting but will check soon16:38
*** rando25892 <rando25892!~homefame@user/rando25892> has quit IRC (Ping timeout: 252 seconds)16:48
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:1416:a546:ff88:20cd> has quit IRC (Quit: Leaving)16:48
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:06
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 252 seconds)17:09
*** mckoan is now known as mckoan|away17:23
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)17:39
*** davidinux <davidinux!> has quit IRC (Ping timeout: 240 seconds)17:44
*** davidinux <davidinux!~davidinux@> has joined #yocto17:45
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:51
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)17:57
rfs613Am looking at CVE-2021-25219 in package bind... it seems this is fixed in various ways in all active branches, except for dunfell.18:06
rfs613dunfell has 9.11.35 currently, there is an update 9.11.36 which fixes the CVE. So we could either patch, or update to .36, is there a preference?18:07
rfs613also, the 9.11.x series is EOL right now (March 2022), so should dunfell move to 9.16.x? All other branches are on various 9.16.x it seems.18:08
khembumping major revision in dunfell is kind of risky18:08
sakomanrfs613: is 9.11.36 a security/bug fix release?  If no new features I would take a patch for that update.18:16
rfs613sakoman: yes, security fix and bugfix,
rfs613i've compiled and tested it locally... only change name of recipe and the sha256sum for the download, all existing OE patches apply. Want me to submit a patch for this?18:18
sakomanrfs613: Yes, I see I've done a number of those in the past.  If you could follow this format it would make me happy ;-)
sakomanrfs613: Thanks for helping with CVEs, I really appreciate it!18:19
rfs613sakoman: i have a few more in the pipe, but let me get this one sorted as first step.18:19
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)18:20
rfs613sakoman: I've been meaning to ask about the repos, as they seem confusing... the patch you linked is in openembedded-core-contrib, but when I look in poky the same commit has a different hash (with a link to OE-Core rev added)18:21
rfs613so how should I do my local workflow to generate patch against correct repo? or does it matter.18:21
sakomanrfs613: Submit patches to oe-core18:22
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)18:22
sakomanrfs613: poky is a constructed repo -- oe-core + bitbake + meta-yocto + yocto-docs18:22
sakomanrfs613: so patch submissions should be for the base component repo, not poky18:23
rfs613is there a guide to setting up local build using individual repos, rather than the poky constructed one?18:23
khemrfs613: generally patches done on top of poky are directly applicaple to oe-core unless you have local changes18:24
prabhakarladHi all, I have tmux package in my rfs, but when I run it I get "tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968". Any pointers on how to add UTF-8 support in yocto?18:25
khemyocto project consumes openembedded-core + bitbake and create poky repository along with few other layers fudged together18:25
sakomanrfs613: what khem said -- but when you submit, make sure you send the patch to the appropriate component repo mailing list18:25
rfs613sakoman: I sent the mail, but I missed the "Notes for ...", so i'll do a v2 in a moment.18:34
rfs613let me know if this looks okay otherwise18:36
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto18:36
*** konsgn <konsgn!~konsgn@user/Konsgn> has joined #yocto18:39
konsgnAlright, I've been banging my head against a wall for a bit now. I'm trying to get a pocket-beagle design to shutdown properly. Instead, the sysvinit tool halt grabs a system_transition_mutex lock and never lets go causing a stack dump after the umountfs init.d script successfully completes. How can I debug this?18:41
konsgnlooking at the uart output I see that umountfs script complete and the terminal drops back to displaying kernel messages, but I then get a warning that locks are still held by halt, followed by a stacktrace.18:42
rfs613prabhakarlad: not sure what version of yocto you're using, but try checking $LANG as a first step. Or perhaps check the output of "locale" command. I'm guessing you will see "C" rather than something ending in ".UTF-8"18:43
prabhakarladrfs613: $LANG is C18:44
khemkonsgn: I would test same setup on qemuarm and if it works there then its perhaps a beagle kernel issue18:44
rfs613prabhakarlad: so that's probably the reason, ANSI_X3.4-1968 is basically the same as C18:45
yolocan I list all recipes used for an image, e.g. core-image-minimal, bitbake -s seems just list everything possible18:45
khemkonsgn:  maybe there is some spurious unlock_system_sleep() call in kernel path18:45
*** chep` <chep`!> has joined #yocto18:45
prabhakarladrfs613: I see, how can I force it to UTF-8?18:46
rfs613prabhakarlad: well, as a quick test, just try "export LANG=en_US.UTF-8" and then run tmux... if that works, it's just your default locale that's the issue.18:47
khemyou might first check if you have locales included see IMAGE_LINGUAS  and what it is set to18:48
konsgnkhem, thanks for the pointers. specifically, I do have the beaglebone kernel 5.4 (as opposed to my dunfell at 5.9.16) shutting down gracefully, but it is running systemd as opposed to sysv. How could I check the kernel path?18:48
*** chep <chep!> has quit IRC (Ping timeout: 245 seconds)18:48
*** chep` is now known as chep18:48
prabhakarladrfs613: that didn't help "tmux: invalid LC_ALL, LC_CTYPE or LANG".18:48
rfs613prabhakarlad: ok, so probaly missing locale support, as khem just noted, check IMAGE_LINGUAS in your config18:49
khemkonsgn: perhap trace the halt path in kernel maybe with some kprintfs or something18:51
konsgnkhem: one more note, reboot works fine.18:51
khemyeah reboot and halt are different paths18:51
konsgnalright, will look into what you said, seeing power/main.c a focus point.18:52
prabhakarladrfs613: khem: reports its empty ( bitbake -e core-image-minimal | grep IMAGE_LINGUAS)18:54
Saur[m]jclsn: Yes, the order of the layers in `BBLAYERS` matters. You typically want layers with higher priority earlier in that list as this, e.g., will affect the order include/require finds files.18:54
rfs613prabhakarlad: so you can try setting it to IMAGE_LINGUAS="en-us" for example18:57
khemprabhakarlad: yeah minimal images are minimal add IMAGE_LINGUAS = "en-us" right18:58
rfs613prabhakarlad: for more info18:58
prabhakarladrfs613: khem: thanks for the pointer Ill give that a try now.19:00
sakomanrfs613: what you sent is fine19:04
rfs613sakoman: v2 is there with the extre line added, take your pick ;-)19:04
sakomanrfs613: I took the first version and I'm testing now.  Will try to get it into the 3.1.15 release.19:06
rfs613great thanks!19:06
khemyolo: you can do bitbake -g <your-image> which will generate a file called pn-buildlist which has the info you are seeking19:07
rfs613it seems the bitbake in dunfell branch has changed recently (last few days) to reject the old override syntax. I guess I missed the announcement? Or is this not intentional19:08
rfs613no, never mind, I was on the wrong poky branch.19:09
moto-timoRP: weird, still seeing the same behavior on Debian 11 (bullseye) which is Python 3.9.2 in stock config... I'll see if there is a backport of newer py319:09
*** florian_kc <florian_kc!> has joined #yocto19:10
prabhakarladrfs613: khem: looks like setting the IMAGE_LINGUAS = "en-us" in conf file is ignored when building minimal image.19:35
rfs613prabhakarlad: indeed, it is set to empty in poky/meta/recipes-core/images/core-image-minimal.bb19:38
rfs613you could comment out that line, or find another way to override it, I suppose19:38
prabhakarladouch, i see only option is to comment it, unless there is a graceful way to override it.19:40
rfs613in yocto, there is always a bigger hammer available :-)19:40
khemuse core-image-base19:41
rfs613sakoman: next on my list is CVE-2022-23308 in libxml2... it's new this week... got a few moments to discuss that one?19:43
sakomanrfs613: yes19:44
prabhakarladrfs613: khem: yep looks like I will have to go with core-image-base19:44
rfs613sakoman: so we have 2.9.12 in master branch, and there is a 2.9.13 release whcih fixes the CVE.19:45
rfs613sakoman: it also seems the project has moved from to, so "devtool upgrade" doesn't pick up on the new release.19:46
sakomanrfs613: are you looking to fix in master or in dunfell?19:46
rfs613sakoman: master first, as I know thats teh policy19:47
*** _wmills <_wmills!> has quit IRC (Ping timeout: 256 seconds)19:48
sakomanrfs613: if master, you might be able to sneak in the version upgrade if you work very fast, check with RP to see if he would still take that patch19:49
sakomanrfs613: it would also make sense to fix and broken paths in the recipe before the release19:50
sakomanrfs613: for dunfell it would need to be a CVE patch rather than version upgrade (unless there is a bug fix/security fix only release)19:51
moto-timoRP: confirmed with a toaster-container using master-next and Ubuntu 20.04 that the web UI can build quilt-native19:51
rfs613sakoman: yes, I'm messing with it now, though I will have to break to pickup car and kids soon, so may not have it soon enough for RP19:51
rfs613sakoman: I guess we can try to backport the CVE only to 2.9.10 in dunfell19:52
sakomanrfs613: If you can do it in the next few days it may be fine, but check with RP19:52
yolokhem: thanks that works. is there a command to list the recipes(and/or pkgs) that is only for the target, i.e. the rootfs? bitbake cares about all the recipes(host and target), sometimes I want to know what exactly went to the target rootfs19:52
sakomanrfs613: no time constraints on dunfell -- it will live for another couple of years :-)19:53
rfs613RP: ^^ i'm looking at updating libxml2 version (2.9.12 to 2.9.13) for CVE fix... but also the project download URLs changed (moved to
rfs613just a heads up ;-)19:53
rfs613Does it make sense to switch from download .tar.gz to using git instead? Finding non-javascript download links on gitlab seems to be challenging.19:56
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
yoloto answer my own question: enable buildhistory will give me the target pkg info20:11
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)20:12
jclsn[m]<Saur[m]> "jclsn: Yes, the order of the..." <- Alright thanks20:23
konsgnwell shiver me timbers, I'm hitting the omap_rtc_power_off(void) function just fine, it just doesn't trigger the pmic chip to shutdown somehow.....20:29
*** mauro_anjo <mauro_anjo!~quassel@> has quit IRC (Ping timeout: 252 seconds)20:39
khemyolo: right, you want to check output packages ( ipk/rpm/deb ) not recipes in that case20:44
khemlook under images/ directory in buildhistory20:45
khemit has quite a bit there20:45
khemkonsgn: might be interesting to you20:47
konsgnkhem: yea, that seems very related. Though In my case the bits are set the same btwn yocto's and beaglebones, at least it is the same as:
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:85a0:7214:95e:173a> has quit IRC (Remote host closed the connection)20:53
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto20:53
khemmaybe check if right PMIC options are enabled in .config20:54
konsgn.config controls those? interesting20:59
RPrfs613: I'd prefer to use release tarballs20:59
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)21:00
rfs613RP: good timing, as I finally found
konsgnkhem: Thank you!21:00
rfs613RP: although the 2.9 in the pathname is unforunate, not sure if there is a good way to handle that.21:01
*** florian_kc <florian_kc!> has joined #yocto21:01
RPrfs613: I'm sure we've dealt with this kind of thing before21:03
rburtonrfs613: gnomebase does that for you21:03
rfs613rburton: thanks, I am checking that out now!21:05
Saur[m]yolo: You do not need to enable buildhistory if all you want is a list of the packages that went into an image. E.g., if you build core-image-minimal for qemux86-64 then you should have an `tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.manifest` file that lists all the packages in the image.21:05
kergothHuh, how did I miss that license_image warns/errors about installing incompatible packages? I can drop an entire class from my layer that did that now. woo21:08
* kergoth rolls eyes at self21:08
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:11
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:13
rfs613rburton: gnomebase is good! However the original SRC_URL used name=libtar on the end, whereas gnomebase seems to call it "archive". Any idea if this matters?21:13
wesmI am using a different x11 wm than x11-base so I've made my own packagegroup that replaces the one selected by IMAGE_FEATURES. But rootfs-postcommands picks the systemd based only on finding 'x11-base' in IMAGE_FEATURES. What's the correct way to override that bbclass or otherwise set the myself?21:19
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)21:21
rburtonrfs613: not at all, just rename any instances, like the checksum21:26
khemhow can I extract some extra logs on a failing build on AB21:26
khemI need config.log file from pcp build
konsgn*facepalm .... Every 1.0s: cat /sys/class/rtc/rtc0/time  shows 00:00:00.... rtc clocks not running.21:28
konsgnmaybe setting up a seperate rtc threw it off21:29
khemcheck your DT21:29
RPkhem: you need ssh access so either someone with access grabs it or you get the access from halstead21:29
khemyeah if you can help grabbing this one wouild be goof21:30
khemI can work with halstead on ssh access21:30
khemI think I have access but I might have lost the instructions21:30
RPkhem: you don't have access on that worker that I can see21:31
khemthat failure is not reproducible on any of machines I have access to so kind of specific to that builder21:31
khemah thanks RP21:34
khem-I/usr/include/python3.10m -I/usr/include/python3.10  -I/usr/include/python3.10m -I/usr/include/python3.1021:34
khemsomehow its getting that poked21:35
halsteadkhem: Can I get you set up right now? I think you have an ssh account already.21:35
khemI sent my key21:35
Saur[m]Hmm, is it still appropriate to refer to the colon override syntax as "the new override syntax" in a commit message given that we have been using it for quite a while now. On the other hand, I had expected us to have smoked out all use of the old syntax from OE-Core by now, but alas I just found a case of the old syntax in `oe-pkgdata-util` (which resulted in incorrect output for `oe-pkgdata-util package-info`)...21:36
halsteadkhem: Shall I remove your previous keys?21:36
khemhalstead: they are still valid21:37
RPSaur[m]: "the override syntax" is less helpful21:37
fraymost people have been using the : syntax for less then a year.  I would still call it the 'new' syntax through at least the end of 202221:37
khemSaur: on universe time scale human civilization is still very new 🙂21:37
RPmoto-timo: I guess I should do an upgrade of my system, see if that reproduces :/21:38
halsteadkhem: Can you try now?21:40
Saur[m]RP: You can find the fix on the `pkj/oe-pkgdata-util` branch in poky-contrib, but I'll send it to the list tomorrow when I'm at the office.21:41
moto-timoRP: it might be something I have on top of master-next. I should try again in a clean environment.21:42
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)21:44
RPSaur[m]: thanks, I'll queue21:44
*** lucaceresoli__ <lucaceresoli__!~lucaceres@> has quit IRC (Quit: Leaving)21:44
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto21:45
khemhmm so pcp issue seems to be specific to fedora35 nodes21:45
RPkhem: the failed data is there, just renamed from build/build/ to build/build-renamed/21:46
RPmoto-timo: I tried on my 21.10 ubuntu and it shows exit code zero to your test script21:59
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)22:01
RPmoto-timo: and I can run builds ok there using the UI22:01
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)22:02
moto-timoRP: I think we call that bug closed. I must have something else happening.22:02
RPmoto-timo: did david see this issue too?22:03
moto-timoRP: I don’t know22:03
RPmoto-timo: try with a clean build dir with master-next and see where that gets us...22:05
* moto-timo reboots for the first time in a month22:07
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 240 seconds)22:08
moto-timoRP: yes, exactly. It should work. My container test proves it.22:08
RPmoto-timo: I missed that in the scrollback!22:12
RP(the container worked)22:12
moto-timoRP:  confirmed. It went away.22:17
* moto-timo goes to close a bug \o/22:17
RPmoto-timo: cool :)22:18
moto-timoRP: thank you so much for figuring this one out.22:19
RPnp, happy it is working22:20
tlwoernerRP: i like the new setscene/tasks info layout22:30
*** florian_kc <florian_kc!> has joined #yocto23:00
RPtlwoerner: cool :)23:07
tlwoerneralso, i don't have the root cause, but the build issue i've been seeing is related to BB_NUMBER_THREADS and PARALLEL_MAKE23:08
tlwoerneri've been able to reproduce it without having to use jenkins, and i've narrowed it down to those 2 variables23:09
RPtlwoerner: likely some kind of race then? :/23:11
tlwoernerRP: yes, i would assume, quilt complains that the patches are already applied. it *only* happens with recipes where the sources are in-layer23:11
RPtlwoerner: is it a task execution issue, i.e. is it running some task twice somehow?23:12
tlwoernerand it only started happening feb 25th (or thereabouts)23:12
RPare the patches really already applied?23:12
RPtlwoerner: was about then but is only for git application of patches23:13
RPtlwoerner: you don't have that configured I assume?23:14
tlwoerneryes, because there's really nothing to patch. the source files are in the layer and they're already in the work directory because they're "patches"23:14
tlwoernera fresh build doesn't show the issue23:14
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)23:15
tlwoernerbut if the layers update and a new build occurs, then it might happen. starting with layers a day or two old, building, deleting sstate, updating the layers, then building again will cause it23:15
tlwoernerlet me revert that patch and see...23:15
RPso it is some kind of build directory reuse issue23:16
RPtlwoerner: do you have git patch application configured?23:16
RPthat code shouldn't be involved otherwise23:16
tlwoerneri'm guessing "no", since i'm not sure what you're saying :-)23:16
RPtlwoerner: right, it defaults to not enabled23:17
tlwoerneranyway, i'll keep poking at it23:17
RPtlwoerner: ok. Just thought i'd mention in case you were using git patching instead of quilt23:17
* RP should sleep23:17
*** prabhakarlad <prabhakarlad!> has joined #yocto23:37
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto23:49

Generated by 2.17.2 by Marius Gedminas - find it at!