Thursday, 2023-08-31

*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 255 seconds)00:05
JaMaDvorkinDmitry: if you just want modules-load.d file then look at KERNEL_MODULE_AUTOLOAD in meta/classes-recipe/kernel-module-split.bbclass00:07
DvorkinDmitryJaMa, oh, thank you!00:08
JaMaFILES variable doesn't do anything unless you meant FILES:${PACKAGE_NAME}00:08
DvorkinDmitryJaMa, yes, I know. FILES:${PN} += meanless in kernel module recipe00:08
JaMait's not meaningless as long as you have correct packagename there, but for modules-load.d it's not needed as there is better mechanism for that00:10
CroftonBuild success00:20
Croftonwacking everything and trying again00:20
JaMawhack that spinning rust at least to 15K RPM00:26
*** SK <SK!~SK@> has joined #yocto00:27
SKHello, I'm all of the sudden start seeing following errors in my build process, when running `repo sync`. "error: Server does not allow request for unadvertised object" Does anyone saw similar problems? I don't have any changes on my end, it just started happening today. (it runs via github runner, in AWS)00:28
*** jbo <jbo!~tct@user/tct> has quit IRC (Ping timeout: 245 seconds)00:35
*** tct <tct!~tct@user/tct> has joined #yocto00:36
SKdoes yocto git repo ( has some sort of rate limiting implemented?00:41
*** SK <SK!~SK@> has quit IRC (Quit: Client closed)00:52
*** belgianguy <belgianguy!> has quit IRC (Ping timeout: 246 seconds)01:01
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 240 seconds)01:03
*** davidinux <davidinux!> has joined #yocto01:06
*** SK <SK!~SK@> has joined #yocto01:15
*** SK <SK!~SK@> has quit IRC (Quit: Client closed)01:22
*** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 255 seconds)01:34
*** OnkelUll_ <OnkelUll_!> has joined #yocto01:36
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 246 seconds)01:37
*** OnkelUlla <OnkelUlla!> has quit IRC (Read error: Connection reset by peer)01:37
*** Ablu <Ablu!> has joined #yocto01:37
*** jclsn <jclsn!~jclsn@2a04:4540:6534:9f00:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 245 seconds)02:24
*** jclsn <jclsn!~jclsn@2a04:4540:6533:6700:2ce:39ff:fecf:efcd> has joined #yocto02:26
*** old_boy <old_boy!~old_boy@> has quit IRC (Quit: Client closed)02:34
*** Marian64 <Marian64!> has joined #yocto02:50
Marian64I'm trying to build a .wic image and I have the following wks.ini file02:55
Marian64part /boot --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --ondisk sda --label msdos --active --align 102402:55
Marian64part swap --ondisk sda --size 1G --label swap1 --fstype=swap02:55
Marian64part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 --use-uuid02:55
Marian64bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"02:55
Marian64The problem is that the swap partition is not 1G is 44M:02:55
Marian64wic ls test-image-genericx86-64.wic02:55
Marian64Num     Start        End          Size      Fstype02:55
Marian64 1       1048576     28428287     27379712  fat1602:55
Marian64 2      28428288     74565631     46137344  linux-swap(v1)02:55
Marian64 3      75497472   1159546879   1084049408  ext402:55
Marian64Any input on this?02:55
*** kpo <kpo!> has quit IRC (Ping timeout: 255 seconds)02:59
*** rfs613 <rfs613!~rfs613@> has quit IRC (Remote host closed the connection)03:16
*** prabhakar <prabhakar!> has quit IRC (Quit: Ping timeout (120 seconds))03:17
*** rfs613 <rfs613!> has joined #yocto03:18
*** Marian67 <Marian67!> has quit IRC (Quit: Client closed)03:30
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto03:32
*** wooosaiiii <wooosaiiii!> has quit IRC (Ping timeout: 246 seconds)03:38
*** wooosaiiii <wooosaiiii!> has joined #yocto03:39
*** wak <wak!~wkenningt@2001:19f0:ac01:40f:5400:4ff:fe7c:68e6> has joined #yocto03:45
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto03:46
*** Marian64 <Marian64!> has quit IRC (Quit: Client closed)04:23
*** SK <SK!~SK@> has joined #yocto04:33
*** SK <SK!~SK@> has quit IRC (Client Quit)04:33
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)05:02
*** amitk <amitk!~amit@> has joined #yocto05:05
*** kpo <kpo!> has joined #yocto05:20
*** davidinux <davidinux!> has quit IRC (Ping timeout: 246 seconds)05:33
*** davidinux <davidinux!~davidinux@> has joined #yocto05:33
*** kayterina <kayterina!~kayterina@> has joined #yocto05:39
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:55
*** OnkelUll_ is now known as OnkelUlla06:19
*** rob_w <rob_w!> has joined #yocto06:24
*** rfuentess <rfuentess!> has joined #yocto06:32
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto06:38
*** varjag <varjag!~user@> has joined #yocto06:41
*** mckoan|away is now known as mckoan06:51
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:55
*** Guest39 <Guest39!~Guest39@> has joined #yocto07:00
Guest39khem Yes, it was always reproducible07:00
Guest39JaMa Yes, it fails all the time. I am able to reproduce now07:01
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 246 seconds)07:01
*** mckoan <mckoan!> has quit IRC (Ping timeout: 246 seconds)07:03
*** olani_ <olani_!> has quit IRC (Ping timeout: 246 seconds)07:03
*** olani <olani!> has quit IRC (Ping timeout: 246 seconds)07:03
*** kayterina <kayterina!~kayterina@> has quit IRC (Quit: Client closed)07:03
*** olani <olani!~olani@> has joined #yocto07:04
*** olani_ <olani_!~olani@> has joined #yocto07:04
*** mckoan <mckoan!> has joined #yocto07:07
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:15
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:16
*** kpo <kpo!> has quit IRC (Quit: Konversation terminated!)07:28
*** prabhakarlad <prabhakarlad!> has joined #yocto07:32
*** rob_w <rob_w!> has quit IRC (Ping timeout: 246 seconds)07:48
*** vladest <vladest!> has quit IRC (Ping timeout: 245 seconds)07:50
*** rob_w <rob_w!> has joined #yocto08:01
*** belsirk <belsirk!> has joined #yocto08:04
*** rfuentess <rfuentess!> has quit IRC (Ping timeout: 246 seconds)08:05
*** Guest61 <Guest61!> has joined #yocto08:10
*** ptsneves <ptsneves!> has joined #yocto08:15
*** mvlad <mvlad!~mvlad@2a02:2f08:4c00:5d00:7656:3cff:fe3f:7ce9> has joined #yocto08:23
*** Guest62 <Guest62!> has joined #yocto08:28
Guest62has someone got the irc chat web interface url for nvidia development boards ?08:29
*** Guest61 <Guest61!> has quit IRC (Quit: Client closed)08:33
*** lars_ <lars_!> has joined #yocto08:37
lars_Hello. I tried making my image recipes cleaner by moving common IMAGE_INSTALL stuff into a packagegroup, which makes my layer much tidier. But I get an error for some packages: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (fuse-dev to libfuse-dev)08:38
RPlars_: don't make your packagegroup allarch ?08:39
*** Kubu_work <Kubu_work!> has joined #yocto08:39
RPis your packagegroup recipe setting PACKAGE_ARCH ?08:40
lars_I just made a packagegroup, I did not explicitly say anything about allarch. Also those packages actually are machine type specific inside my packagegroup, like this: RDEPENDS:mypackagegroup:genericx8608:41
RPso set PACKAGE_ARCH = "${MACHINE_ARCH}" ?08:42
lars_But I share this packagegroup between both arm and x86 targets08:42
lars_Can I set it for just parts of the packagegroup?08:43
RPlars_: packagegroup.bbclass defaults to allarch FWIW, that is where it is coming from08:43
RPduplicating per arch is really minor, don't worry about that would be my advice08:43
lars_Ah, my whole point of making this packagroup was to minimize duplication to make maintainability easier and to always keep all targets in sync and up to date08:44
RPwell, you can mark some bits as machine specific but the net result will be it has to be built once per arch08:45
RPsplit the machine specific bits to a separate recipe ?08:45
lars_Yeah, that will probably be good08:46
lars_When I set PACKAGE_ARCH for the packagegroup, then this will automatically handle compatibility? So if I add this packagegroup to my image, then it will only be installed for the compatible machines? Or do I have to add it like this: IMAGE_INSTALL:genericx86 ?08:48
RPIt can't know about compatibility08:49
lars_Well, probably wrong word to use. Architecture might be better word08:50
*** vladest <vladest!~Thunderbi@> has joined #yocto08:50
RPIn that case, probably, if I understand the question08:53
*** tnovotny <tnovotny!> has joined #yocto09:01
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:04
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:04
*** rfuentess <rfuentess!~rfuentess@> has joined #yocto09:05
*** belsirk <belsirk!> has quit IRC (Ping timeout: 246 seconds)09:07
*** Guest61 <Guest61!> has joined #yocto09:29
dvergatalRP: for something completely different, we have a fix for this one
dvergatalRP: my team mate who is the author of it will soon join us here and wants to discuss his proposal regardig the fix09:31
*** Guest32 <Guest32!> has joined #yocto09:32
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:2c48:2c2f:7902:cd27> has joined #yocto09:37
*** Guest32 <Guest32!> has quit IRC (Client Quit)09:37
*** rfuentess <rfuentess!~rfuentess@> has quit IRC (Ping timeout: 246 seconds)09:38
*** Guest39 <Guest39!~Guest39@> has quit IRC (Ping timeout: 246 seconds)09:42
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:49
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:50
rburtonRP: can you share a link for that qemu patch breaking on mips?09:51
*** mbulut <mbulut!> has joined #yocto09:53
dvergatalbtw., we would be grateful if any of you have already taken a look at this patch and shared your thoughts, because it is still a draft09:57
RPsadly fortify source doesn't change the qemuppc issue09:57
RPdvergatal: I did just glance at the patch and I can kind of see what you're doing but the lack of any commit message and explanation doesn't help. I did wonder if it would make sense to split it into pieces09:59
dvergatalthere is a comment in bugzilla10:00
dvergatalthe last message10:00
dvergatalRP: shortly in this bug the problem we have discovered is because posinst scripts are being run in alphabetical order and when user is being added with some dependecies with different order than alphabetical the problem occurs10:04
RPdvergatal: That is not really enough. It only says what the patch does, it doesn't say what the issue being fixed is, why it matters or how the changes fix the issue10:05
RPdvergatal: I guessed that but I should be guessing :)10:05
dvergatalas i said this is just a draft10:05
dvergataland we wanted to discuss the approach in here10:06
dvergatalif it is correct10:06
dvergatalRP: you shouldn't :P10:06
*** rfuentess <rfuentess!> has joined #yocto10:07
RPdvergatal: I'm just giving feedback on your draft ;-)10:08
dvergatalRP: ok Jan is eating his launch so he will join us in couple of minutes10:09
* RP feels like a bisection of glibc coming on10:16
dvergatalare you scared?:P10:18
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)10:20
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:20
RPdvergatal: weary10:20
dvergatalaahhh i see10:21
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:23
dvergatalbtw. i still need to taken care of the issue reported by khem but i'm still configuring my gentoo in parallel with other fixes like the one above because our CI stopped to be usable because of it10:25
*** slimak <slimak!> has joined #yocto10:30
*** frieder <frieder!> has joined #yocto10:30
dvergatalslimak: finally you joined us10:30
slimak@dvergatal last time I used IRC was about 20 years ago... lots changed since then10:31
dvergatalok :D10:31
JaMamatching name :)10:32
dvergatalJaMa: yeah indeed:P10:32
dvergatalRP: slimak: OK i think we can start10:34
dvergatalslimak: I think you can reveal the details of the patch and the approach10:35
varjagwhen stripping of target binaries happen in Yocto?10:37
varjagwhich stage10:37
slimakThe issue we had was, than addition of users groups and group memberships was done with postinst scripts run in non-deterministic order --- when there were multi level dependencies it could happen that this order was causing error10:39
RPslimak: I was saying to dvergatal earlier, the patch really needs more explanation. I see you added sort() calls which would make it deterministic but I guess that wasn't enough to ensure everything ran as needed10:40
slimakMy approach is to split each useradd postinst script into 3 parts, one for groups, second for users third for group memberships10:40
slimakbasepasswd script is already executing useradd scripts in alphabetical order, so I gave names to the scripts to run them correctly10:41
slimakand sorted() was needed for ordering in python part10:42
RPI think it does make sense but I don't really like the reuse of user_group_groupmems_add_sysroot for the other two, I think that is confusing10:43
dvergatalRP: yeah this is what we wanted to discuss10:44
slimakmy question is if you generally agree with the idea --- this patch is just proof of concept --- the final should look closer at avoiding generated code duplication for sure10:44
RPI'd probably split the patches into two, one for the sort and one splitting useradd10:44
RPThe principle looks fine to me10:44
dvergatalRP: ok so we all agree on the approach10:44
dvergatalcool :D10:44
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has quit IRC (Remote host closed the connection)11:05
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:15
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:15
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has joined #yocto11:16
shoragandid anyone hear about
shoraganor is going to attend?11:20
RPshoragan: not heard of it, kind of sad OE/Yocto aren't mentioned11:25
shoraganRP, yes. there's a lot of existing work in the embedded community which seems to be overlooked :/11:26
shoraganI'll see if I can fit it into my schedule..11:27
RPshoragan: it would certainly be good to raise awareness11:29
shoraganhmm, registrations closed11:29
KanjiMonsterit also says invitation only11:33
kanavinit seems like a microsoft-oriented thing aimed primarily at azure/cloud use cases11:46
kanavinI would go if I were invited, as I happen to be in Berlin, but :shrug:11:49
RPDo we know anyone going or any of the organisers?11:49
kanavinRP: Organizers: Linux Systems Group at Microsoft - Christian Brauner, Lennart Poettering, Luca Boccassi11:51
RPAh. I guess we could ask Luca11:51
RPthey are at least aware of YP11:51
*** arisut_ is now known as arisut12:00
*** gsalazar <gsalazar!> has joined #yocto12:06
RPof course not all glibc commits actually work :(12:07
neverpanicSurprised they also haven't reached out to other industry players, considering quite a bit of the agenda seems to be on over-the-air updates. I'm sure there are plenty of people in the automotive space with experience on that.12:08
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 260 seconds)12:09
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:10
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)12:14
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:14
manuel1985What is the path of a file? Just the dirname, or dirname+basename?12:16
manuel1985What's the common lingo?12:16
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Quit: Leaving)12:17
ptsnevesshoragan: the font of that document's titles is something special12:24
alessioigorI would like submit a little patch for meta-openembedded. I'm reading  but I don't understand if I should sent it to poky mailing-list or openembedded-devel  mailing-list?12:26
alessioigorI guess the second one...12:26
alessioigorCould someone confirm it, please?12:26
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto12:28
*** florian_kc <florian_kc!> has joined #yocto12:30
*** xmn <xmn!> has joined #yocto12:31
ptsnevesmeta-openembedded is a layer on it's own and I think has its own maintenance forum. openembedded-devel is project12:32
JaMaopenembedded-devel is also a ML where to send the changes, see
JaMaalessioigor: ^12:44
KanjiMonsterthere's also the third option of creating a PR at - not necessarily the fastest though12:44
RPPlease use the mailing list, pull requests are not the preferred method12:45
RPalessioigor: is there anything you'd suggest to make the docs clearer?12:45
landgrafRP: it should be in the thus all visitors of GH page see this12:46
landgrafin the README of the project, not layer I mean12:47
*** Guest39 <Guest39!~Guest39@> has joined #yocto12:47
RPlandgraf: which README is that though? :/12:49
RPrburton: any luck with that mips failure?12:50
landgrafRP: this )12:51
landgrafjust level up12:51
RPlandgraf: ah, right, yes. Someone should send a patch! :)12:51
KanjiMonsteryou can also land easily at the not quite so helpful yocto contrib guidelines if you google for e.g. "meta-openembedded submit patch", then the first hit (at least for me) is
dvergatallandgraf: it is quite well documented in here
dvergatalso I don't understand your issues12:54
dvergatalKanjiMonster: yeah I see that it has been updated :D but still the previous version was just fine12:55
alessioigorRP: The docs ( say "“meta-*” trees: These trees contain Metadata. Use the poky mailing list." and "For changes to other layers hosted in the OpenEmbedded source repositories (i.e., use the openembedded-devel mailing list"12:57
alessioigorFollow the docs meta-openembedded merts both requirements.12:57
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has quit IRC (Ping timeout: 246 seconds)12:57
alessioigorI'll send my patch to openembedde-devel. Thanks to all!12:58
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 245 seconds)13:04
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto13:06
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has joined #yocto13:18
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)13:21
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)13:21
vvnsite.conf.sample has been removed from the template files, right?13:22
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto13:23
vvnWhat is the expected way to deploy a site.conf file? Manually on first build?13:24
* vvn is just confused by the upstream site.conf.sample13:33
*** Xagen <Xagen!> has joined #yocto13:36
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto13:38
vvnRP: in addition to TEMPLATECONF, what do you think about adding support for a SCONF_FILE environment variable in oe-setup-builddir in order to copy a site.conf file on first build?13:40
*** varjag <varjag!~user@> has quit IRC (Quit: ERC (IRC client for Emacs 27.1))13:41
vvnor do we prefer that the user copy their site.conf file manually after sourcing oe-init-build-env?13:42
RPvvn: It is meant to be site provided, not from our code13:45
vvnsure, because it is site provided, I guess it's okay to blindy copy the site.conf file in <builddir>/conf/ on first build or even before every builds.13:51
RPalessioigor: thanks, we should tweak that meta-* piece13:59
vvnis uninative likely a site-wide configuration?14:08
vvnor is it a distro thing?14:09
rburtonRP: had lunch, left machine building14:13
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:20
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:21
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)14:23
*** mckoan is now known as mckoan|away14:32
*** vladest <vladest!~Thunderbi@> has quit IRC (Ping timeout: 246 seconds)14:37
*** hrberg <hrberg!> has quit IRC (Quit: - Chat comfortably. Anywhere.)14:50
*** hrberg <hrberg!> has joined #yocto14:50
*** vladest <vladest!> has joined #yocto14:58
*** Guest39 <Guest39!~Guest39@> has quit IRC (Quit: Client closed)15:00
*** vladest <vladest!> has quit IRC (Read error: Connection reset by peer)15:00
*** vladest <vladest!> has joined #yocto15:01
kergoth_vvn: site could very well live outside the build directory entirely, also, if your default BBLAYERS includes an external path. lots of ways to do it. makes sense to have a copy option though15:02
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:04
vvnyeah I'm using TEMPLATECONF to provide a base configuration for bblayers.conf and local.conf (without versionning them) but I wanted a way to make sure the site.conf is deployed as well15:07
vvnOtherwise I know that at some point I will rm -rf build/ ; . oe-init-build-env and that'll re-create the download and sstate caches15:08
vvnso so far I'm using a wrapper script which cp /etc/site.conf $BDIR/conf after sourcing oe-init-build-env...15:09
RPvvn: ideally you'd point at a standard location for site.conf e.g. somewhere in $HOME rather than copying it around all the time15:09
vvnRP: you mean require/include /etc/site.conf?15:10
RPvvn: there are various options15:10
kergoth_alter your bblayers.conf to set the default BBLAYERS to ${HOME}/.oe, put site.conf in ~/.oe, as one example. as always with yocto, multiple approaches are available :)15:11
vvnhaving a "site" layer is an option, but it seems weird to append BBLAYERS to alter the build in that way15:11
kergoth_I actually don't do it that way myself, since I use a product that has a templateconf and i didn't want to override it, or have that path in customer files, so i just have my workspace scripts symlink it into place instead15:11
kergoth_the whole point of site is to be specific to your network and host, set PREMIRRORS, etc, which doesn't make sense to be a part of build, which is more specific than that, or your main layers, which are less15:12
* kergoth_ shrugs15:12
vvnyep indeed, I'd set SSTATE_DIR, DL_DIR, maybe DEPLOY_DIR (with "/${DISTRO}" appended) and maybe INHERIT += "buildhistory" in my site.conf15:15
vvnin other words, site.conf is a site-wide static configuration, while auto.conf is a site-wide dynamic configuration (build tag name, image links, ...)15:16
vvnbut yeah I think that it'll be convenient if oe-setup-builddir could provide the user a way to check for these configs too15:17
vvnin the meantime, a wrapper to oe-init-build-env it is :-)15:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 245 seconds)15:24
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:24
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 245 seconds)15:29
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:30
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)15:39
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto15:47
*** dvergatal <dvergatal!~dvergatal@> has quit IRC (Quit: leaving)15:49
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:59
*** florian <florian!> has quit IRC (Quit: Ex-Chat)15:59
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:01
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 248 seconds)16:01
JaMakhem: quick q about meta-clang should clang always find corresponding gcc installation or do you remember some cases where default GCC_INSTALL_PREFIX didn't work and you had to explicitly pass --gcc-install-dir? in some strange mulilib setup I'm seeing gcc install in /usr/lib32 but clang seems to search only in lib32-recipe-sysroot/lib/../lib16:03
*** slimak <slimak!> has quit IRC (Ping timeout: 245 seconds)16:03
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 255 seconds)16:04
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto16:08
*** mbulut <mbulut!> has quit IRC (Ping timeout: 246 seconds)16:09
khemJaMa: to be honest I have not tested it much with multilib setup I remember someone did work on it few years ago and made it work on x86 in meta-clang16:10
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)16:11
khemOE's installs are not defaults of gcc and so we might have to teach clang that16:12
JaMaok, I'm cooking patch for that16:18
*** amitk_ <amitk_!~amit@> has joined #yocto16:18
*** amitk_ <amitk_!~amit@> has quit IRC (Client Quit)16:19
JaMaseems simple enough as it searches /lib and /lib64, adding /lib32 as well might fix the issue I'm seeing16:19
*** amitk_ <amitk_!~amit@> has joined #yocto16:24
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 246 seconds)16:33
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 246 seconds)16:34
*** Guest62 <Guest62!> has quit IRC (Quit: Client closed)16:45
*** ptsneves <ptsneves!> has joined #yocto16:48
*** pabigot <pabigot!> has quit IRC (Ping timeout: 246 seconds)16:50
*** Guest11 <Guest11!~Guest11@2601:280:cb05:1334:7ad1:6a7:f222:b531> has joined #yocto16:51
RPkhem: I've been trying to bisect glibc to track down which commit causes qemu to fail for ppc. It is looking like 2c6b4b272e6b4d07303af25709051c3e96288f2d works and b40f5f84c41bc484d4792531a693d7583cecae0a fails. Continuing to work through it. Each test takes around 30 mins16:51
Guest11is there any way to get data from a recipe in a packagegroup from that packagegroup? I'd like to, effectively, iterate over each recipe RDEPEND'ed in a packagegroup and get the SRCREV for them16:51
*** Guest61 <Guest61!> has quit IRC (Quit: Client closed)16:51
RPkhem: it doesn't make such sense so I wonder if one of my tests was a false result :/16:52
ptsnevesGuest11: with tinfoil you can16:53
ptsnevesor jsut processing packagedata16:54
Guest11packagedata doesnt have SRCREV, unfortunately16:55
Guest11and hwo can I do that with tinfoil?16:55
Guest11I was trying to, but couldnt figure out how16:55
rburtonright, packagedata is _target metadata_ so if the SRCREV doesn't end up in the version then it's lost16:56
rburtonyou can iterate packagedata to get the recipes and then look up srcrev in tinfoil16:56
ptsnevesGuest11: tinfoil.parse_recipe16:57
khemRP: interesting looked through this here -
khemonly this one seems could be affecting all arches
*** lars_ <lars_!> has quit IRC (Quit: Lost terminal)16:58
khemothers are not looking relevant16:58
RPkhem: right, they don't seem obvious candidates :/16:59
RPkhem: I'll keep going, see where things end up17:00
*** Guest72 <Guest72!~Guest11@2601:280:cb05:1334:7ad1:6a7:f222:b531> has joined #yocto17:00
Guest72ptsneves it killed my session, still me; can I do this from a job in a recipe/bbclass or no?17:01
ptsnevesGuest72: ah no.17:02
ptsnevesThen what you should do is augment the packagedata task to also put the SRCREV in the pkgdata. Then you can access it in another recipe's task after depending on the task that added the SRCREV data17:03
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)17:03
*** Guest11 <Guest11!~Guest11@2601:280:cb05:1334:7ad1:6a7:f222:b531> has quit IRC (Ping timeout: 246 seconds)17:04
Guest72there's no way to attach to the running server?17:04
*** pabigot <pabigot!> has joined #yocto17:04
ptsnevesGuest72: you mean arbitrarily query for the data cache of another recipe?17:05
ptsnevesif you want that, then I do not think you can17:06
Guest72I was just hoping to make a BOM (or at least a packagegroup-specific BOM) that also had the SRCURI and SRCREV17:07
ptsnevesGuest72: so to achieve that you have the 2 options provided17:09
rburtonGuest72: personally i'd write a script to resolve the packagegroup to a list of packages using pkgdata, and then use tinfoil to look up SRC_URI/SRCREV for those recipes17:10
Guest72something akin to, I assume?17:10
ptsnevesGuest72: what is cool about the script is that you can do the post processing without constrains on bitbake way of doing things. You can also juggle datastores from multiple recipes which you can never have inside a recipe.17:16
RPkhem: 2d472b48610f6a298d28035b683ab13e9afac4cb is broken does lead to that commit. Continuing to bisect...17:25
*** Guest72 <Guest72!~Guest11@2601:280:cb05:1334:7ad1:6a7:f222:b531> has quit IRC (Quit: Client closed)17:31
*** dvergatal <dvergatal!~dvergatal@> has joined #yocto17:37
*** ptsneves1 <ptsneves1!~Thunderbi@> has joined #yocto17:39
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 246 seconds)17:40
*** ptsneves1 is now known as ptsneves17:40
khemyeah resolvers can be hog17:42
*** florian_kc <florian_kc!> has joined #yocto17:53
*** ptsneves <ptsneves!~Thunderbi@> has quit IRC (Ping timeout: 246 seconds)17:59
*** ptsneves <ptsneves!> has joined #yocto18:01
*** ptsneves <ptsneves!> has quit IRC (Client Quit)18:04
RPkhem: bb9a4fc02841cf58a112a44b259477547893838b breaks so there is something wrong with the bisect :(18:08
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)18:09
*** mvlad <mvlad!~mvlad@2a02:2f08:4c00:5d00:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection)18:19
*** ptsneves1 <ptsneves1!> has joined #yocto18:27
*** ptsneves1 is now known as ptsneves18:30
*** speeder__ <speeder__!~speeder__@> has joined #yocto18:30
*** speeder__ <speeder__!~speeder__@> has quit IRC (Remote host closed the connection)18:39
RPkhem: confirmed that 0567edf1b2def04840e38e3610452c51a3f440a3 is broken so it is something further back. The joys of intermittent failures :/18:40
*** florian_kc <florian_kc!> has joined #yocto18:43
yates_worksuggestion: in the subsections of, e.g., "Normal Recipe Build Tasks," list the task subsubsections in normal or typical order they occur, or provide a diagram of their order.18:44
yates_workotherwise, that section of the manual is quite excellent18:46
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)18:52
*** Kubu_work <Kubu_work!> has joined #yocto18:55
yates_workdoes the do_package task happen when building a single executable application recipe? i.e., something like a command-line utility written in C and generating a single executable output?18:57
yates_workor does it only happen when builing images?18:57
rburtonit always happens for 'normal' recipes19:02
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)19:03
rburtoneven a single C binary recipe has the main package, the debug package, and the source package19:03
*** Kubu_work <Kubu_work!> has joined #yocto19:08
yates_workaha. good.19:10
yates_workand i see the local.conf specifies the package format (e.g., rpm). i was getting confused on whether this was specified by the image recipe or elsewhere. there's my answer.19:11
rburtonremember every recipe is effectively isolated19:13
rburtonan image recipe can't tell your libc recipe to generate rpms or ipkgs19:13
rburtonthe distro can, because that's global state before each recipe is parsed19:13
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto19:14
JaMakhem: only partial success with lib32, I'm collecting the info in Draft PR once I have something usable, will change it to regular PR19:31
khemJaMa: yeah it seems to be going in right direction AFAICT19:45
khemRP: yeah that list looked light to me19:47
yates_workrburton: ack. thanks for the guidance.19:47
RPkhem: I have 0567edf1b2def04840e38e3610452c51a3f440a3 breaking and 6f962278e24bdf5cb5f310c5a17add41da95407c working19:48
RPkhem: obviously the working may be another false positive, but I'll try and bisect it, see what that gives19:48
RPkhem: the strerr fflush there looks interesting19:48
khemRP: that has some interesting commits lets see19:49
khemRP: do we have a build host with glibc 2.38 ?19:50
khem* af130d2709 Always do locking when accessing streams (bug 15142, bug 14697)19:50
RPkhem: not yet19:51
RPkhem: I tried with fortification turned off btw, it didn't help19:51
khem* 64d9580cdf Allow glibc to be built with _FORTIFY_SOURCE19:51
vvnwould you have a preferred way between TEMPLATECONF=foo . oe-init-build-env and export TEMPLATECONF=foo ; . oe-init-build-env?19:55
vvnis there a rationale for that or is it purely a preference?19:58
Saurvvn; With the former, the TEMPLATECONF variable is only set while the command is running, in the other case it becomes part of the environment.19:59
vvnyep this I know. Put differently, is it unwanted to have it part of the environment?20:00
RPthat variable name is too vague to be part of a general environment20:01
vvnok so it is more meant to be a variable for a single given script, thus not having it in the environment is better20:02
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 246 seconds)20:36
*** davidinux <davidinux!~davidinux@> has joined #yocto20:37
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Quit: Leaving)20:41
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto20:52
*** amitk_ <amitk_!~amit@> has quit IRC (Remote host closed the connection)20:55
*** Thorn_ <Thorn_!> has quit IRC (Quit: Depression is merely anger without enthusiasm)20:59
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)21:20
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)21:24
*** ptsneves <ptsneves!> has quit IRC (Read error: Connection reset by peer)22:05
*** Xagen <Xagen!> has quit IRC (Ping timeout: 246 seconds)22:32
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 245 seconds)23:15
*** Xagen <Xagen!> has joined #yocto23:41
*** Xagen <Xagen!> has quit IRC (Client Quit)23:44

Generated by 2.17.2 by Marius Gedminas - find it at!