Friday, 2021-02-12

*** oberstet <oberstet!~oberstet@> has quit IRC00:11
*** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC00:13
*** ahadi <ahadi!> has quit IRC00:26
*** ahadi <ahadi!> has joined #yocto00:26
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has joined #yocto00:35
*** linums <linums!~linums@> has joined #yocto00:46
*** B0ned1ger <B0ned1ger!> has quit IRC00:47
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto00:47
*** dvhart <dvhart!~dvhart@> has quit IRC00:58
*** dreyna__ <dreyna__!> has joined #yocto00:59
*** dreyna_ <dreyna_!> has quit IRC01:03
*** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto01:16
linumsHi guys01:23
linumsCan you help me how to rebuild after a distro feature addition?01:23
linumsIs there any way not to rebuild everything?01:23
*** kpo_ <kpo_!> has quit IRC01:36
*** kpo_ <kpo_!> has joined #yocto01:37
*** linums <linums!~linums@> has quit IRC01:44
*** linums <linums!~linums@> has joined #yocto01:44
*** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC01:48
*** Wouter01000 <Wouter01000!> has quit IRC01:53
*** Wouter01000 <Wouter01000!> has joined #yocto01:58
*** kiwi_29 <kiwi_29!> has joined #yocto02:46
*** kiwi_29 <kiwi_29!> has quit IRC02:51
*** goliath <goliath!> has quit IRC03:04
*** hpsy <hpsy!~hpsy@> has quit IRC03:08
*** imcleod <imcleod!> has joined #yocto03:11
*** ahadi <ahadi!> has quit IRC03:19
*** ahadi <ahadi!> has joined #yocto03:19
*** imcleod <imcleod!> has quit IRC03:26
*** aquijoule__ <aquijoule__!> has joined #yocto03:27
*** aquijoule_ <aquijoule_!> has quit IRC03:29
*** dreyna__ <dreyna__!> has quit IRC03:31
*** vineela <vineela!~vtummala@> has quit IRC03:37
*** JosephAntony <JosephAntony!a5e17a73@> has joined #yocto03:38
*** hpsy <hpsy!~hpsy@> has joined #yocto04:13
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has quit IRC04:14
*** B0ned1ger2 <B0ned1ger2!> has quit IRC04:47
*** B0ned1ger <B0ned1ger!> has joined #yocto04:47
*** bobo <bobo!> has joined #yocto04:48
*** dreyna__ <dreyna__!> has joined #yocto04:51
*** mattsm <mattsm!> has quit IRC05:02
*** vineela <vineela!vtummala@nat/intel/x-vpekvcdytyfenmek> has joined #yocto05:20
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:30
*** feddischson <feddischson!> has joined #yocto05:34
*** dreyna__ <dreyna__!> has quit IRC05:42
*** bobo <bobo!> has quit IRC05:46
*** vineela <vineela!vtummala@nat/intel/x-vpekvcdytyfenmek> has quit IRC05:49
*** cengiz_io <cengiz_io!~cengiz_io@> has quit IRC06:10
*** cengiz_io <cengiz_io!~cengiz_io@> has joined #yocto06:13
iceawayGood morning everyone06:20
*** jobroe <jobroe!> has joined #yocto06:21
iceawayYesterday I tried to set up my environment for fixing our kernel patches moving from Yocto 2.5->3.1. In 2.5 I used the devtool to work on the patches, but as I upgraded to 3.1 it said it was unable to find the defconfig, and I was advised to try the "traditional" approach as described in the manual. I'm stuck on the "yocto-kernel-cache" part, as I'm using the kernel from our SoC vendor, and they have no06:25
iceawaysuch repository. If I try skipping that step, devtool is unhappy. Is the kernel-cache stuff required?06:25
iceawayby devtool I mean bitbake in the second last sentence06:26
*** jobroe <jobroe!> has quit IRC06:31
*** jobroe <jobroe!> has joined #yocto06:31
*** AndersD <AndersD!> has joined #yocto06:31
*** AndersD_ <AndersD_!> has joined #yocto06:34
*** beneth <beneth!> has joined #yocto06:36
*** AndersD <AndersD!> has quit IRC06:36
*** bobo <bobo!> has joined #yocto06:36
*** gounaris <gounaris!~quassel@> has joined #yocto06:40
*** jobroe <jobroe!> has quit IRC06:40
*** jobroe <jobroe!> has joined #yocto06:41
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:53
*** oberstet <oberstet!~oberstet@> has joined #yocto06:55
*** AndersD_ <AndersD_!> has quit IRC07:00
*** AndersD_ <AndersD_!> has joined #yocto07:02
*** AndersD__ <AndersD__!> has joined #yocto07:04
*** AndersD_ <AndersD_!> has quit IRC07:07
*** minimaxwell <minimaxwell!> has joined #yocto07:10
*** bobo <bobo!> has quit IRC07:16
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:28
LetoThe2ndyo dudX07:28
*** w00die <w00die!~w00die@> has quit IRC07:28
*** w00die <w00die!~w00die@> has joined #yocto07:30
*** mckoan|away is now known as mckoan07:31
mckoanLetoThe2nd: good morning07:31
*** rcoote <rcoote!> has joined #yocto07:37
*** agust <agust!> has joined #yocto07:48
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:52
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has joined #yocto07:55
*** kiwi_29 <kiwi_29!> has joined #yocto07:56
*** kiwi_29 <kiwi_29!> has quit IRC08:00
*** JosephAntony <JosephAntony!a5e17a73@> has quit IRC08:14
*** Klox <Klox!> has quit IRC08:23
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has quit IRC08:25
*** flash27 <flash27!> has joined #yocto08:33
*** jkjaid349i <jkjaid349i!> has joined #yocto08:36
*** flash27 <flash27!> has quit IRC08:40
*** jkjaid349i <jkjaid349i!> has quit IRC08:41
*** flash27 <flash27!> has joined #yocto08:42
*** mbulut <mbulut!> has joined #yocto08:44
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:2413:85cb:bba4:fb22> has joined #yocto08:56
*** asteriusio <asteriusio!> has quit IRC09:00
*** asteriusio <asteriusio!> has joined #yocto09:00
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:08
*** ahadi <ahadi!> has quit IRC09:09
*** ahadi <ahadi!> has joined #yocto09:17
*** flash27 <flash27!> has quit IRC09:17
*** ahadi <ahadi!> has quit IRC09:18
*** kyanres <kyanres!> has quit IRC09:21
*** kpo_ <kpo_!> has quit IRC09:22
*** ahadi <ahadi!> has joined #yocto09:22
*** kpo_ <kpo_!> has joined #yocto09:22
kpo_Hello, I've got a quick question, because I can't find straightforward answer in docs: is it possible to tell gitsm fetcher to checkout to specific commit hash? As in tag, but using commit hash09:28
*** goliath <goliath!> has joined #yocto09:33
*** JungleBoy <JungleBoy!> has joined #yocto09:35
JungleBoyhi I'm JungleBoy09:35
LetoThe2ndkpo_: usually SRCREV does that, no idea if it applies to gitsm too. but thats the best guess.09:37
*** intera91 <intera91!> has joined #yocto09:41
intera91good morning09:42
intera91was wondering if anyone has built yocto for a ryzen platform and has met with the AMD graphics driver09:42
JungleBoyintera91 which board?09:44
intera91basically I have IMAGE_INSTALL_append = " mosquitto libavc1394 cairo zeromq imagemagick glfw libconfig libmosquitto1 ffmpeg strace gdb mosquitto-dev boost  gstream09:46
intera91er1.0-libav vulkan-cts vulkan-headers glm-dev glslang rinicom mesa mesa-demos" in my local.conf and trying to build a core-image-sato for a VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c6) (prog-if 00 [VGA controller])09:46
intera91still no radeonsi gets built and glxinfo states:09:47
LetoThe2ndintera91: that sounds like a totally flawed approach.09:47
intera91LetoThe2nd: am a newbie at that one09:48
LetoThe2ndintera91: 1) create a custom layer 2) create a custom image 3) make a somewhat sensible dependency chain that allows you to focus on one thing.09:48
intera91LetoThe2nd: am all ears at what would be the proper way to proceed09:48
LetoThe2nde.g., your image should INSTALL the application, and the application shall depend on the libs and whatever you need.09:48
LetoThe2nd4) get sato out of our head09:49
intera91feels like being so close yet so far09:50
LetoThe2nd5) accept the possibility that there is no real blueprint for the amd gpu setup you want and that you probably have to invest quite a bit of effort.09:50
intera91mmh I can see that, that's unfortunate09:51
intera91here is the problem: glxinfo | grep -i vendor09:51
intera91libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)09:51
intera91libGL error: failed to load driver: radeonsi09:51
intera91libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri)09:51
intera91libGL error: failed to load driver: radeonsi09:51
intera91server glx vendor string: SGI09:51
intera91client glx vendor string: Mesa Project and SGI09:51
intera91    Vendor: VMware, Inc. (0xffffffff)09:51
intera91OpenGL vendor string: VMware, Inc.09:51
LetoThe2ndintera91: use a pastebin next time, please.09:51
intera91sure sorry09:51
qschulzintera91: have you enabled the correct DISTRO_FEATURES and MACHINE_FEATURES for gpu/opengl support?09:52
kpo_@LetoThe2nd thanks, that's the thing :)09:52
intera91qschulz: not sure how to do that09:52
intera91is that in local.conf?09:53
LetoThe2ndintera91: probably you don't have a proper provider for virtual/gl or whatever it takes there. i'm no graphics guy, sorry, but really - stuffing everything into local.conf is a super bad practise and you should get rid of it before it forms a habit!09:53
LetoThe2ndintera91: i suggest watching the videos on creating a layer, a custom image, and the distro/machine/image one :)09:53
*** kyanres <kyanres!> has joined #yocto10:01
JungleBoyLetoThe2nd was searching for that video as well, do you know which # it was?10:06
LetoThe2nddistro/images/machine? not sure, 7, 8 or so.10:07
JungleBoyok will check it out, thanks10:07
*** ahadi <ahadi!> has joined #yocto10:12
*** ahadi <ahadi!> has quit IRC10:12
*** ahadi <ahadi!> has joined #yocto10:14
qschulzJungleBoy: it's in the title of the Youtube video IIRC10:18
*** NiniC0c0 <NiniC0c0!> has joined #yocto10:23
NiniC0c0hello, all I have 2 metas and both need a bbappend on device-tree part. if i put one inside meta-custom-bsp an one inside meta-custom-apps. Can I build an image from meta-custom-bsp without use the bbappend inside meta-custom-apps ? I'm not sure to be clear... sorry for that :)10:28
qschulzNiniC0c0: no10:30
qschulzor maybe with dynamic layers but I've no experience with that10:30
qschulzNiniC0c0: device tree is related to hw configuration, so it is related to your machine configuration file. You should therefore have two machines or two device trees at least.10:31
qschulzin case of two machines, you can have SRC_URI_append_<machine> in your bbappends10:32
NiniC0c0qschulz as always xD I have 2 meta folders (bsp and apps) with a device-tree_%.bbapend. When I build a bsp image i don't want to use the bbapend from apps folder. maybe BBFILE_PRIORITY is enough ?10:32
qschulzNiniC0c0: no, bbappend applies no matter what10:33
qschulzthe priority will just change the order in which they are applied10:33
NiniC0c0qschulz Ok. it's the same machine i need just to add a node inside10:33
qschulzNiniC0c0: what is this node for?10:33
NiniC0c0ho ok thx for the info10:33
NiniC0c0qschulz just to configure custom driver input10:34
qschulzNiniC0c0: you could always use device tree overlays10:36
LetoThe2ndNiniC0c0: tip: just because it is physically the same machine, it doesn't necessarily have to be the same machine configuration. or dt overlays. it "depends"10:37
qschulzapply the overlay in u-boot depending on a conf file that you'll set in your image recipe10:37
NiniC0c0qschulz LetoThe2nd I'm stupid overlays should do the trick:)  thank you for supporting my stupidity..10:38
LetoThe2ndNiniC0c0: you can always thank us with free beers!10:39
qschulzNiniC0c0: it's not stupidity, sometimes we just forget about things. Don't worry, happy to have helped, that's hthe most important part :)10:39
NiniC0c0it's a really good community guys<310:39
kayterinahello. What could be a good practice for I ran out of free space: should I 'clean' some temporary folder before I 'rsync' whole ~/poky to another drive? Does it keep any absolute path links?10:56
RobertBerger@NiniC0c0: If you want to solve this from a YP/OE point of view you could use dynamic layers, as qchulz pointed out. It's something like: if this layer exists than use that.11:02
RobertBergerOnly if the networking layer is in bblayers.conf apply the ntp bbappend:
NiniC0c0RobertBerger Thx I will alose take a look to dynamic layers11:03
LetoThe2ndkayterina: best practise is to get a disk thats big enough. second best practise is cleaning out sstate (even if only partially). moving the build does not work as easily as you might think, at least tmp has to be recreated from scratch, and probably most of the pathes in local.conf and bblayers.conf have to be checked.11:05
kayterinaso if tmp has to be recreated then I just as easily start over in the new disk11:06
LetoThe2ndkayterina: sstate can be moved. tmp cannot.11:07
qschulzkayterina: you can setup a SSTATE_MIRROR too, this way it's not entirely from scratch11:08
qschulzI think some people also have the sstate cache on an NFS?11:08
LetoThe2ndqschulz: NonFunctionalStorage?11:09
qschulzkayterina: i'm not really sure why you want to rsync whole poky?11:09
*** JungleBoy <JungleBoy!> has quit IRC11:09
kayterinaperhaps I have a wrong directory structure then. I hae my build in ~/poky/build and my layers in ~/mylayers/meta-blabla so I though I hae to move, so I move everything11:10
kayterinarsync is just what I use to move big files11:10
LetoThe2ndkayterina: s/perhaps/g11:10
qschulzkayterina: what exactly do you want to move and for which usecase?11:11
LetoThe2ndkayterina: instead of wasting time with copying, watch a couple of my videos where i explain how to lay out your project. especially the kas one essentially shows it step by step.11:11
LetoThe2ndqschulz: low disk space.11:11
kayterinaLetoThe2nd: link please?11:12
kayterinaI only found 3 on vimeo11:12
qschulzLetoThe2nd:  then INHERIT += "rm_work" and some cleanup of the sstate-cache with find -atime +30 -delete?11:12
LetoThe2ndkayterina: you're really not exactly a prime example of showing initiative and effort, i have to say.
kayterinaaouch. youtube..sorry leto11:13
LetoThe2ndqschulz: i don't like rm_work. cleaning out with a carefully chose atime can make sense, yes.11:13
LetoThe2ndkayterina: we've only been using youtube for one and a half years, so yes, it comes really surprising! ;-)11:14
qschulzLetoThe2nd: we use rm_work for years already :)11:18
LetoThe2ndqschulz: thats why i explicitly chose the wording "i don't like". not claiming my POV matches all others :)11:19
*** bps <bps!> has joined #yocto11:20
linumsDo I have to reboild everything after I add a new distro_feature, or can i just somehow rebuild the related packages11:38
rburtonbuild the image and it will rebuild what is needed11:40
LetoThe2nd"it's magic!"11:40
rburtonif you'd turned on hash equiv it will rebuild less11:40
*** vijay <vijay!a4a45f09@> has joined #yocto11:43
RPkanavin_home: I tried your patch on a -next build. Its interesting as we got numbers of 53, 53, 57, 58 as being different on the different distros11:46
linumsIt should also work with the distro_features addition?11:47
linumsThen I'm in trouble :D11:47
linumsBecause it thinks it has nothing to do11:48
LetoThe2ndlinums: *guess*: you added it in the image recipe.11:49
linumsI did11:49
linumsThroug an distro_features_append list11:49
qschulzlinums: distro feature is to be set in.... distro configruation file :)11:49
linumsYeah, I knew, that it is not the best idea, to add it from an image recipe :D11:50
qschulzlinums: well it's not that it's not the best idea, it's just that it won't work11:50
linumsWhatever does not work, sounds like a bad idea to me :D11:51
LetoThe2ndanybody, please sing along with yocto chant #1....11:51
qschulzI think we got some people interested for a Ubuntu meta-deb (meta-rpm like) on the mailing list :D11:54
*** vijay <vijay!a4a45f09@> has quit IRC12:10
LetoThe2ndqschulz: whenever i read the closing lines there, i really wonder if its the language barrier or it such folks really think its ok to just request/demand12:11
linumsHeey, it moving the distro_features to it's proper place worked! Thanks :)12:15
*** bps <bps!> has quit IRC12:20
*** cmg <cmg!> has joined #yocto12:20
LetoThe2nddoing something properly works? OMG!12:21
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:28
*** tgoodwin <tgoodwin!> has joined #yocto12:28
*** cmg <cmg!> has quit IRC12:29
*** iceaway <iceaway!~pelle@> has quit IRC12:33
*** pharaon2502 <pharaon2502!> has quit IRC12:37
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has joined #yocto12:39
*** intera91 <intera91!> has quit IRC12:39
*** jobroe <jobroe!> has quit IRC12:44
*** jobroe <jobroe!> has joined #yocto12:45
*** minimaxwell <minimaxwell!> has quit IRC12:51
LetoThe2ndrburton: the answer is: "i want an ubuntu but all i got from my hw vendor was this yocto bsp layer" :)12:52
*** minimaxwell <minimaxwell!> has joined #yocto12:53
*** linums <linums!~linums@> has quit IRC12:55
*** linums <linums!> has joined #yocto12:56
*** jobroe <jobroe!> has quit IRC12:57
*** jobroe <jobroe!> has joined #yocto12:58
*** iceaway <iceaway!~pelle@> has joined #yocto13:01
*** linums <linums!> has quit IRC13:04
*** linums <linums!~linums@> has joined #yocto13:05
*** jobroe <jobroe!> has quit IRC13:06
*** jobroe <jobroe!> has joined #yocto13:06
*** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/> has quit IRC13:07
iceawayI'm trying to build the extensible SDK, but I get some really strange error about do_prepare_recipe_sysroot failing with exit code 'setscene whitelist'. Any ideas? Google did not give me much.13:08
*** flash27 <flash27!> has joined #yocto13:08
*** kpo_ <kpo_!> has quit IRC13:22
*** kpo_ <kpo_!> has joined #yocto13:23
*** dev1990 <dev1990!> has quit IRC13:27
*** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto13:28
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:2413:85cb:bba4:fb22> has quit IRC13:34
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:53e8:7f49:1e5f:691> has joined #yocto13:35
*** flash27 <flash27!> has quit IRC13:41
*** ctlnwr__ <ctlnwr__!~catalin@> has quit IRC13:41
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:53e8:7f49:1e5f:691> has quit IRC13:42
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:fdee:4ba2:d966:c97a> has joined #yocto13:43
*** minimaxwell <minimaxwell!> has quit IRC13:46
*** minimaxwell <minimaxwell!> has joined #yocto13:50
RobertBerger@LetoThe2nd: and it's even worse if the one who asks is the BSP Layer vendor ;)13:52
LetoThe2ndRobertBerger: gosh didn't realize that.13:53
RobertBerger@iceaway: Which meta-layers did you include?13:53
RobertBerger@LetoThe2nd: I also commented on the mail ;)13:53
*** minimaxwell <minimaxwell!> has quit IRC13:57
*** minimaxwell <minimaxwell!> has joined #yocto14:02
*** flash27 <flash27!> has joined #yocto14:03
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto14:09
JPEWThe top level LICENSE for gnutls is "GPLv3 & LGPLv2.1+" because some parts are LGPL and some are GPLv3. However, some recent (dunfell?) change made this top level license the one that applies to generated -locale packages14:13
marexLetoThe2nd: the request thing is a language nuance, it is really meant as polite way of asking for help, not in the "demand" sense14:14
*** jobroe <jobroe!> has quit IRC14:14
marexLetoThe2nd: I only figured it out when watching startrek TNG :)14:14
JPEWThis makes my images fail because we don't allow GPLv3.... I'm fairly certain that the -locale files don't fall under the GPLv3, but I'm not sure how to tell bitbake that14:14
LetoThe2ndmarex: thanks!14:15
marexLetoThe2nd: I think Worf used it there a few times, to ask for a favor14:15
marexLetoThe2nd: when talking to Picard iirc14:15
*** linums <linums!~linums@> has quit IRC14:17
marexRobertBerger: cant you just build custom u-boot/kernel package for ubuntu ,create a ppa , apt install it and done ?14:17
marexthe later is I think make deb in linux sources, the former ... look at the debian package for u-boot and add a patch or somesuch14:18
*** linums <linums!~linums@> has joined #yocto14:19
yannactivating ccache globally in local.conf should not trigger rebuilds by itself, right ?  it does that to me in gatesgarth :(14:35
JPEWyann: It's missing some `BB_HASHBASE_WHITELIST` entries14:42
JPEWyann: Basically, since all of the CCACHE_* variables are `export` they will be include in every task hash, which is probably not what you want14:43
*** B0ned1ger <B0ned1ger!> has quit IRC14:47
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto14:48
RobertBerger@marex: I guess you could. Not sure if you can use it commercially after and/or call it Ubuntu. You might need to remove all the references to "Ubuntu".14:52
marexRobertBerger: you just dont distribute anything from the official images, just the PPA, that's not called ubuntu, but a custom repo15:00
RobertBerger@marex: We need to know the use case. Even if you don't distribute anything, someone eventually will.15:02
marexRobertBerger: so better do it the OE way, distribute the sources and let others compile them , hehe15:06
*** kpo_ <kpo_!> has quit IRC15:07
*** kpo_ <kpo_!> has joined #yocto15:07
RobertBerger@marex: Still the same problem once you ship the product. One of my customers actually wanted to compile Ubuntu sources with OE and asked Canonical. They did not allow it ;)15:07
marexRobertBerger: as in what apt source + dpkg-buildpackage does ? how can canonical stop you from doing so with inherently free or opensource software ?15:09
marexRobertBerger: are you sure it wasnt something something about branding ?15:10
marexRobertBerger: it sounds like the firefox/iceweasel situation in debian15:10
RobertBerger@marex: Trademark is for sure an issue.15:10
marexRobertBerger: if you are compiling linux kernel, what does canonical has to do with it ?15:12
marexRobertBerger: dtto for u-boot15:12
RobertBerger@marex: Nothing I would say.15:13
RobertBerger@marex: It's more about the rootfs and all the Ubuntu strings in there ;)15:13
sakomanJPEW: re: how to tell bitbake what license a package is for gnutls15:13
marexRobertBerger: wget it from ubuntu.com15:13
marexRobertBerger: there, no problem, canonical is distributing that part15:13
sakomanJPEW: LICENSE_${PN}-xx = "LGPLv2.1+"15:13
marexRobertBerger: you just installed packages from ppa into your debian-derivative distro, that's built into ubuntu, so shrug15:14
sakomanSee the gnutls recipe -- this is done for several packages15:14
marex(yes, it is a workaround, and the result would be poor, obviously)15:14
RobertBerger@marex: You mean your end customers know how to build and install packages? That's not how Embedded Systems are usually sold.15:15
yannJPEW: so all that's needed is to list them all in `BB_HASHBASE_WHITELIST`, right ?15:17
marexRobertBerger: we cannot assume that the original poster of that email thread plans to deliver a product15:17
RobertBerger@marex: Oh yes we can ;)15:18
marexRobertBerger: we can ? :)15:18
marexRobertBerger: it could be they are just preparing the building blocks for someone else15:18
RobertBerger@marex: Sure ;) For fun and non profit.15:19
RobertBerger@marex: "Internal use only"15:19
JPEWsakoman: That doesn't appear to work though15:23
JPEWsakoman: If that's supposed to apply to the -locale packages, it appears broken15:24
sakomanJPEW: Oh, no that specific line applies to the gnutls-xx package!15:24
sakomanYou would need to add similar -locales that you want changes15:25
sakomanI was just using that as an example :-)15:26
JPEWsakoman: Ah, right... I think the specific problem is that they packages are generated based on the configured locales, so we don't know all the names a priori15:27
sakomanI suspect that we really should be overriding the license on all of the locales15:28
sakomanSince as you say they are probably not intended to be gplv315:28
RPJPEW: we probably need some kind of locale license variable15:30
RPJPEW: but I do worry the locales are under GPLv315:30
RPor perhaps parts of them :/15:30
JPEWRP: Ya, I wasn't sure how that would work..... would they have the license of the source file they came from? Are they considered "data"?15:31
*** rcw <rcw!~rcwoolley@> has joined #yocto15:32
*** flash27 <flash27!> has quit IRC15:33
RPJPEW: does the source actually say?15:33
JPEWNot really:
*** eduardas <eduardas!> has joined #yocto15:35
*** bobo <bobo!> has joined #yocto15:36
RPJPEW:  in the source it has .po files with "This file is distributed under the same license as the gnutls package."15:38
JPEWRP: Yep, which is a little confusing since the source code has components under difference licenses:
RPJPEW: right :/15:40
RPJPEW: I think we may have to ask them15:40
JPEWRP: Will do15:42
yannwe can't use something like `INHERIT_append_pn-linux-vanilla = " ccache"` in local.conf, it *has* to be += in a .bbappend, right ?15:43
kergothyann: INHERIT is processed globally long beroe the recipes are parsed at all15:45
kergoth+= in a bbappend will do nothing either15:45
kergoth'inherit foo' in a bbappend will do fine15:45
yannyeah, looks better already, thx!15:47
yannof sstate as mentionned by JPEW , but that juste makes the task hashes unstable, can't see why15:48
*** mckoan is now known as mckoan|away15:48
JPEWRP: I asked on their ML. I think I'll also add a "nls" PACKAGECONFIG to disable the translations (I don't *really* care about having them)16:13
RPJPEW: fair enough. Its going to become an increasing problem :/16:14
RPJPEW: the point of splitting them into packages is so you can ignore them16:15
*** gounaris <gounaris!~quassel@> has quit IRC16:24
*** AndersD__ <AndersD__!> has quit IRC16:24
JPEWRP: Hmm, ya. Weirdly, if they weren't split into separate packages, I suspect they would have defaulted to the ${PN} package...16:30
JPEWWhich is LGPLv216:30
* JPEW verifies that assumption16:31
JPEWNope, I was wrong. There is a ${PN}-locale package16:32
JPEWBut, perhaps the split locale packages should pick their license from LICENSE_${PN}-locale (if set), that way you can at least set the license for all of them without having to know all the generated names first16:34
*** Wouter01000 <Wouter01000!> has quit IRC16:40
*** Wouter01000 <Wouter01000!> has joined #yocto16:40
weltlingis there a way to pull a dso from a foreign architecture? currently when including that, the build tries to strip it and to check symbol versions, etc., is there a way to skip it? I checked some steps and related "inhibit" variables but don't seem to find a good solution for that.16:41
weltlingsay pull an aarch64 dso into a x86 build, etc.16:41
JPEWweltling: Ya, you have to set a few variables to prevent it from doing those things, but it's possible16:42
*** bobo <bobo!> has quit IRC16:43
weltlingJPEW, could you help identify those please? my latest status i was setting INHIBIT_PACKAGE_STRIP_FILES, but then dnf tries to look into the symbol versions and obviously libc is a wrong one so it fails16:46
weltlingi was looking also at a wiki page about including binary artifacts into the build, that however concerns including artifacts of the same arch16:47
JPEWweltling: Hmm, Can you put the file somewhere other than a standard library search path?16:47
weltlingJPEW, it is in a subfolder of /usr/lib, but it wouldn't be found by default i think16:48
weltlingdfn finds it because it's listed explicitly in the spec, i think16:48
weltlinghmm, perhaps it could be put somewhere else, but i'll need to be available at the exact place then16:49
JPEWweltling: EXCLUDE_FROM_SHLIBS = "1" maybe?16:49
JPEWweltling: Reading through package.bbclass is helpful for these sorts of things16:49
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC16:50
weltlingJPEW, oh, reading teh doc, perhaps PRIVATE_LIBS could work, gonna try16:51
weltlingyeah, read the package.bbclass but obviously overseen these possibilities16:51
weltlingotherwise, it won't be possible to exclude all the dso at once, as the package produces also some libs that are from the same arch and are needed16:52
weltlingperhaps those of the foreign arch could be separated out, that might be an idea, too, then they could be excluded from shlibs16:53
JPEWweltling: You might try to split them apart if possible16:53
weltlingJPEW, thanks a lot for the help!16:53
JPEWweltling: np16:54
*** stephano <stephano!~stephano@> has joined #yocto17:00
diamondmanI am trying to make a recipe:task that will automatically run the do_test task on every recipe that inherits from a bbclass (the reason why I want this is at the bottom if anyone cares).17:05
diamondmanMy current idea is to have the bbclass add the do_test task and then add that do_test task as a dependency to company-tests:do_test. That way, you can run17:05
diamondmanbitbake company-tests -c do_test17:05
diamondmanand that automatically executes,, etc.17:05
diamondmanThis solution turns out to be pretty hard to do. I have been digging through the bitbake source code, and I can not find a way to add a dependency to a task from a different recipe. I am using an anonymous python function, so my code runs before tasks start being executed, but I have not figured out how to access the datastores of other tasks. Maybe there is no reliable way to do this since the recipes are not17:05
diamondmannecessarily parsed in any specific order.17:05
diamondmanI have several other less attractive ideas too, like in company-tests:do_test, scanning all parsed recipes to find ones that inherit from my bbclass and then dynamically those recipe''s do_test task to the scheduler (this would make the count of necessary tasks inaccurate, so I would love a better option).17:05
diamondmanDoes anyone have any ideas on how to achieve my goal? I am open to all alternatives. Thanks in advance.17:05
*** ahadi <ahadi!> has quit IRC17:06
*** dvhart <dvhart!~dvhart@> has joined #yocto17:07
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC17:10
*** mbulut <mbulut!> has quit IRC17:11
*** ahadi <ahadi!> has joined #yocto17:22
*** dvhart <dvhart!~dvhart@> has quit IRC17:24
*** linums <linums!~linums@> has quit IRC17:28
*** linums <linums!> has joined #yocto17:29
*** hpsy <hpsy!~hpsy@> has quit IRC17:37
*** hpsy <hpsy!~hpsy@> has joined #yocto17:41
yoctondiamondman: Do you know "bitbake-layers show-recipes -i <bbclass>" ?17:45
yocton(This is the bitbake way of getting all recipes inheriting a class)17:46
*** mprokos <mprokos!> has joined #yocto17:46
*** mprokos is now known as rabbit991117:46
rabbit9911Anyone seeing python3 core dumps with 3.1.5? Seems to only show up on our epyc server.17:47
diamondman@yocton I can look at how that code works and try to borrow it.17:48
yoctondiamondman: I would start from that, process a little then give it to bitbake -ctest ...17:48
diamondman@yocton are you recommending triggering a 2nd run of bitbake after determining which recipes need to be tested?17:48
*** manuel1985 <manuel1985!> has joined #yocto17:50
yocton"recommend" is a stong word ^^ For what I'm suggesting, you'll have one bitbake-layers run (getting the list of recipes) and one bitbake run (running the do_test task on all recipes)17:52
yoctonAlso, I wonder if "bitbake -c test world" would work17:55
*** vineela <vineela!vtummala@nat/intel/x-fdpgizmcjczzktft> has joined #yocto17:59
*** linums <linums!> has quit IRC18:00
*** linums <linums!~linums@> has joined #yocto18:00
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:03
*** zkrx <zkrx!> has quit IRC18:03
*** hpsy <hpsy!~hpsy@> has quit IRC18:04
*** zkrx <zkrx!> has joined #yocto18:07
kergothyocton: you'd probably need --runall=test if you want a task run on all the dependencies of the specified target, not just the target.18:10
* kergoth yawns18:10
kergoththat's only if the task exists everywhere, of course.18:10
*** feddischson <feddischson!> has quit IRC18:15
*** feddischson <feddischson!> has joined #yocto18:16
*** hpsy <hpsy!~hpsy@> has joined #yocto18:19
*** dreyna <dreyna!> has joined #yocto18:23
*** dreyna_ <dreyna_!> has joined #yocto18:24
*** zkrx <zkrx!> has quit IRC18:27
*** dreyna <dreyna!> has quit IRC18:27
*** zkrx <zkrx!> has joined #yocto18:34
*** kyanres <kyanres!> has quit IRC18:39
*** B0ned1ger2 <B0ned1ger2!> has quit IRC18:48
*** B0ned1ger <B0ned1ger!> has joined #yocto18:48
*** kpo_ <kpo_!> has quit IRC18:53
*** kpo_ <kpo_!> has joined #yocto18:54
*** zkrx <zkrx!> has quit IRC18:57
*** zkrx <zkrx!> has joined #yocto19:02
*** vdl <vdl!> has quit IRC19:04
*** sakoman <sakoman!~steve@> has quit IRC19:16
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto19:22
kanavin_homeRP: I'll send a better patch in a moment19:25
*** eduardas <eduardas!> has quit IRC19:26
kanavin_homethe one that directly prints:19:26
kanavin_home2021-02-12 00:54:44,402 - oe-selftest - INFO - Reproducibility summary for ipk: same=11252 different=0 different_excluded=71 missing=0 total=1132319:26
kanavin_homeunused_exclusions={'quilt-ptest', 'valgrind-ptest', 'vim', 'meson', 'kernel-devsrc', 'git', 'groff', 'watchdog', 'ruby', 'dtc'}19:26
*** sakoman <sakoman!~steve@> has joined #yocto19:31
*** w00die <w00die!~w00die@> has quit IRC19:35
*** sakoman <sakoman!~steve@> has quit IRC19:36
*** vineela <vineela!vtummala@nat/intel/x-fdpgizmcjczzktft> has quit IRC19:36
*** sakoman <sakoman!~steve@> has joined #yocto19:36
*** w00die <w00die!~w00die@> has joined #yocto19:37
*** zkrx <zkrx!> has quit IRC19:37
*** zkrx <zkrx!> has joined #yocto19:39
*** vdl <vdl!> has joined #yocto19:41
*** vmeson <vmeson!> has quit IRC19:44
*** vmeson <vmeson!> has joined #yocto19:44
*** vineela <vineela!~vtummala@> has joined #yocto20:04
rabbit9911It looks like python3-native is broken on 3.1.5 on epyc servers.. (still looking)20:04
*** hpsy <hpsy!~hpsy@> has quit IRC20:28
*** linums <linums!~linums@> has quit IRC20:31
*** linums <linums!> has joined #yocto20:32
*** linums <linums!~linums@> has joined #yocto20:34
*** dmoseley <dmoseley!~dmoseley@> has quit IRC20:42
*** B0ned1ger <B0ned1ger!> has quit IRC20:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto20:48
*** mcc_ <mcc_!> has quit IRC20:49
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto20:52
*** kiwi_29 <kiwi_29!> has joined #yocto21:14
*** kiwi_29 <kiwi_29!> has quit IRC21:33
*** kiwi_29 <kiwi_29!> has joined #yocto21:33
*** tgoodwin <tgoodwin!> has quit IRC21:35
*** kiwi_29 <kiwi_29!> has quit IRC21:39
*** linums <linums!~linums@> has quit IRC21:39
*** linums <linums!> has joined #yocto21:40
*** vineela <vineela!~vtummala@> has quit IRC21:43
*** feddischson <feddischson!> has quit IRC21:46
*** manuel1985 <manuel1985!> has quit IRC21:47
*** B0ned1ger2 <B0ned1ger2!> has quit IRC21:47
*** B0ned1ger <B0ned1ger!> has joined #yocto21:48
*** kiwi_29 <kiwi_29!> has joined #yocto21:49
*** kiwi_29 <kiwi_29!> has quit IRC21:58
*** linums <linums!> has quit IRC21:59
*** linums <linums!~linums@> has joined #yocto22:00
*** kiwi_29 <kiwi_29!> has joined #yocto22:06
*** bobo <bobo!> has joined #yocto22:09
*** kiwi_29 <kiwi_29!> has quit IRC22:12
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto22:13
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC22:14
vdlIt seems that setting VOLATILE_LOG_DIR = "no" recompiles everything :)22:17
*** adelcast <adelcast!> has joined #yocto22:22
vdlwhy though :/22:33
*** vineela <vineela!~vtummala@> has joined #yocto22:36
*** B0ned1ger <B0ned1ger!> has quit IRC22:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto22:48
moto-timoJPEW: we need to have a call some day about icecream in a tekton context. It seems to me that a commodity device cluster could be running _many_ iceccd nodes. Ideally that would be containers running on k8s nodes.22:50
moto-timoJPEW: that might also be the path to scaling in the cloud (since passing sstate around is somewhat meh).22:51
moto-timoJPEW: also, do you have a public repo for the Dockerfiles from your docker hub images?22:51
*** NiniC0c0 <NiniC0c0!> has quit IRC23:04
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:05
JPEWmoto-timo: Ya. Using icecream would heavily depend on your usecase... I think more parallel builds (even with meh sstate) is probably always going to beat icecream23:07
JPEWBut if you have a small number of mega builds that take forever, then it would make more sense23:07
JPEWI have not published my Dockerfiles... most of them are just modifications of the upstream ones (labgrid, crops); I've been a little tardy publishing them (and, I'm not sure if upstream can really take the changes anyway)23:09
JPEWOut of curosity, what's the meh part of sstate?23:10
RPkanavin_home: excellent, that sound great :)23:13
moto-timotrue cloud: e.g. s3 storage of sstate has been reported to be entirely too slow to be useful. Instead people recommend passing tarballs around.23:13
moto-timoJPEW: I have no actual experience yet.23:13
JPEWmoto-timo: I think S3 is the wrong backend to use. You want an NFS server backed with a reasonable disk23:14
JPEWI think you can get away with running an NFS server in a container backed by a persistentVolumeClaim23:15
JPEW(if you don't have access to a NFS server)23:15
moto-timoJPEW: I think NFS in the cloud starts to get us rapidly out of reasonably priced?23:15
moto-timoJPEW: I have two goals: local cluster (including a bunch of rpi4s, AWS/GCE/Azure/DigitalOcean/CloudDuJour23:16
JPEWIt depends on how you do it.... for example if you use the "hosted" NFS servers like AWS EFS (which is probably really fast) that can be expensive23:17
moto-timoJPEW: that is what I meant from my limited knowledge23:18
JPEWBut, if you just buy a e.g. 1TB block device and mount it as the backing to a container running an NFS server its pretty reasonable23:18
JPEWNot as cheap as S3, but not too bad23:18
RPI would love to actually set up an autobuilder in the cloud like that, have a set of the needed images ready on the shelf23:20
JPEWAlso depends on what you classify as "expensive"23:20
JPEWRP: You're going to love my talk :)23:21
neverpanicRecently ran across our colo bill. I think we could buy a reasonable chunk of cloud for that price, too.23:21
neverpanicBut yes, mounted NFS for download and sstate cache is what we use, works well.23:22
JPEWmoto-timo: I priced out a 1TB sstate cache on Azure at ~$2000/yr. If you're doing cloud builds, that a pitance compared to what you pay to actually *do* any meaningful amount of builds23:22
JPEWAnd, that's using their hosted NFS "files" instead of a block device + NFS in Kubernetes... suprisingly it comes out cheaper until you start to get to larger sstate sizes23:24
JPEWAnd, that price assumes that your using the full 1TB for a whole year, when it's really pay-for-what-you-use23:25
*** dvhart <dvhart!~dvhart@> has joined #yocto23:25
neverpanicI doubt you need a TB of sstate. We do "turn the last build's sstate cache into an sstate mirror for the next build, delete everything that's not used".23:26
moto-timomatt had some changes to the "s3" fetcher... I have not tried it23:26
neverpanicsstate is < 100G23:26
JPEWneverpanic: Ah, but see if you use an NFS server, you don't need to do that23:26
moto-timoneverpanic: my sstate is bigger than that... lots of layers and configurations and I don't flush it often?23:27
JPEWYour builds directly use NFS as the sstate cache. There is no "upstream mirror"23:27
neverpanicJPEW: you eventually do, unless you want your sstate to grow unbounded. we're running a couple thousand builds a month, so really don't want every single one of those one-off builds to end up in your sstate forever.23:27
moto-timowe need this tribal knowledge to get out of the minds of those that have done it. It is very confusing for folks new to the cloud.23:27
neverpanicsstate-mirror on the same nfs has the advantage of creating symlinks, so its a case of replacing those symlinks with hardlinks after the build, then deleting the old mirror23:28
moto-timo@RP: I agree, an AB in the cloud would be fantastic23:28
JPEWneverpanic: Ah, sure. But you can do that out-of-band of your actually builds23:28
RPneverpanic: I know the autobuilder runs sstate into multiple TBs but the autobuilder workload is unusual23:28
RPand we do run cleanup on that23:28
moto-timo@RP: the AB is more sstate than I normally run, but exactly my point ;)23:29
JPEWneverpanic: And in that cause, S3 makes a lot of sense as an upstream23:29
JPEWBut, you don't really want every build to have to figure out whats changed and upload it to S3... it's just slow. They should only read from it23:29
JPEWI know this because at $WORK we *don't* have NFS and have to rsync to a server at the end of every build. *sad trombone*23:30
RPJPEW: :(23:31
*** bobo <bobo!> has quit IRC23:32
JPEWRP: I'm working on it... it just take a while23:33
RPJPEW: I know how companies work :/23:34
moto-timo@RP or NOT23:34
neverpanic pages 4 and 7 have some numbers. apparently we're getting by with 30G of sstate cache.23:35
neverpanicbut yeah, the autobuilder isn't exactly our use-case.23:35
JPEWmoto-timo: I did a whole price breakdown a while ago for building in Azure, and you could get about 500,000 build-hours/year (with NFS sstate & hash equiv) for about $100,00023:36
neverpanicthat sonuds quite cheap, actually23:37
RPneverpanic: the autobuilder is different as it tests a ton of weird usecases nobody probably cares about as whole, only as some subset and we build all arches/libcs whereas anybody else probably again picks a subset23:37
JPEWneverpanic: Ya, it's not as bad as I though.... it really gives you drive to make builds as fast as possible to save costs. In that regard, NFS sstate pays for itself *really* quick23:38
RPJPEW: any idea how many build-hours we do on the autobuilder in a year?23:38
JPEWRP: I haven't the slightest idea23:38
RPJPEW: what is your definition of a build-hour ?23:38
JPEWOne CPU/hour of build time23:38
JPEWbuild-hours is a bad metric. SHould be CPU-hours23:39
RPJPEW: one virtual cpu core?23:39
JPEWRP: Correct23:39
RPhalstead: how many cpu cores do we have in typhoon, roughtly?23:40
*** agust <agust!> has quit IRC23:40
RPI could do with a decent illustration that the autobuilder is cost effective :)23:40
JPEWRP: Oh, ya I'm sure the AB is a lot cheaper than the cloud would be... this also doesn't factor in artifact storage which would also cost money23:41
RPJPEW: I'm sure it is too but I'm forever being asked why we do this when cloud is obviously the solution ;-)23:42
halsteadRP, On the controller? Just 2.23:42
RPhalstead: sorry, I mean overall in the workers as in the overall infrastructure23:43
halsteadRP, On the cluster... I can get that quickly.23:43
RPhalstead: 56*24 ish?23:44
moto-timohalstead: I know you did an assessment of bare-metal vs. cloud at some point and bare-metal still one (or so I recall RP saying :)23:45
halsteadRP, Yes. That's about how many hyperthreaded cores23:45
RPJPEW: so I think we have about 11million cpu-hours/year available23:45
RPhalstead: thanks, I was just curious on a rough number, its interesting to see the "price"23:46
RP($2,200,000 cloud cost)23:47
halsteadmoto-timo, Yes the colo plus three year hardware refresh was about 1/3 the price of similar capacity in a major cloud provider. Going with someone like Hetzner of OVH we could come close to price parity but there were network capability issues last time I looked.23:47
JPEWRP: Ya, if you were going to go that big you can do "Reserved capacity" where you basically rent a virtual instance permenatly which is usually about a 40% discount, but still23:47
halsteadJPEW, We do look at reserved pricing. And we factor in non-profit discounts as well.23:48
JPEWAh, ya23:48
RPJPEW: sorry, I didn't mean to derail your conversation. I was just curious how we compare with the numbers23:51
JPEWRP: Heh, it's ok. It's supper time anyway. Night all23:53
RPJPEW: 'night!23:53
halsteadGood night.23:54
*** dvhart <dvhart!~dvhart@> has quit IRC23:55
* RP should sleep too 23:56

Generated by 2.17.2 by Marius Gedminas - find it at!