Monday, 2021-09-13

*** sakoman <sakoman!~steve@> has quit IRC (Quit: Leaving.)00:30
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto01:14
*** camus <camus!~Instantbi@> has joined #yocto01:56
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 260 seconds)02:00
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)02:10
*** camus <camus!~Instantbi@> has joined #yocto02:10
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)02:51
*** zpfvo1 <zpfvo1!~fvo@> has joined #yocto02:56
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 245 seconds)02:58
*** Ad0 <Ad0!~Ad0@> has quit IRC (Ping timeout: 252 seconds)03:07
*** Ad0 <Ad0!~Ad0@> has joined #yocto03:13
*** wooosaiiii <wooosaiiii!> has quit IRC (Remote host closed the connection)04:01
*** wooosaiiii <wooosaiiii!> has joined #yocto04:01
*** user_123 <user_123!~user@> has quit IRC (*.net *.split)04:06
*** wyre <wyre!~wyre@user/wyre> has quit IRC (*.net *.split)04:06
*** fancer <fancer!> has quit IRC (*.net *.split)04:06
*** dl9pf <dl9pf!> has quit IRC (*.net *.split)04:06
*** elfenix|cloud <elfenix|cloud!> has quit IRC (*.net *.split)04:06
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has quit IRC (*.net *.split)04:06
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has quit IRC (*.net *.split)04:06
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (*.net *.split)04:06
*** xtopher_ <xtopher_!> has quit IRC (*.net *.split)04:06
*** rmmr <rmmr!> has quit IRC (*.net *.split)04:06
*** barath <barath!~barath@2001:470:69fc:105::21a> has quit IRC (*.net *.split)04:06
*** Ch^W <Ch^W!~mouser@> has quit IRC (*.net *.split)04:06
*** LocutusOfBorg <LocutusOfBorg!> has quit IRC (*.net *.split)04:06
*** mvlad <mvlad!~mvlad@2a05:d01c:f57:a700:7eb2:15b9:ec83:80cb> has quit IRC (*.net *.split)04:06
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto04:06
*** Ch^W <Ch^W!~mouser@> has joined #yocto04:06
*** user_123 <user_123!~user@> has joined #yocto04:06
*** fancer <fancer!fancer@2a03:5180:f::2:c200> has joined #yocto04:06
*** elfenix|cloud <elfenix|cloud!uid516192@2a03:5180:f:1::7:e060> has joined #yocto04:06
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto04:07
*** wyre <wyre!~wyre@user/wyre> has joined #yocto04:07
*** xtopher_ <xtopher_!> has joined #yocto04:07
*** dl9pf <dl9pf!> has joined #yocto04:07
*** rmmr <rmmr!> has joined #yocto04:07
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto04:08
*** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto04:11
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto04:13
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has quit IRC (*.net *.split)04:19
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (*.net *.split)04:19
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has quit IRC (*.net *.split)04:19
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has quit IRC (*.net *.split)04:19
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (*.net *.split)04:19
*** karl <karl!~Karlssel@2001:41d0:8:9a4b::1> has quit IRC (*.net *.split)04:19
*** warthog9 <warthog9!> has quit IRC (*.net *.split)04:19
*** kmaincent <kmaincent!> has quit IRC (*.net *.split)04:19
*** ndec <ndec!> has quit IRC (*.net *.split)04:19
*** karl <karl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto04:19
*** ndec_ <ndec_!> has joined #yocto04:19
*** ChanServ sets mode: +v ndec_04:19
*** kmaincent <kmaincent!~kmaincent@2001:41d0:305:1000::2a58> has joined #yocto04:19
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto04:21
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto04:23
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto04:27
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto04:30
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto04:30
*** warthog9 <warthog9!> has joined #yocto04:43
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:59
*** dev1990 <dev1990!~dev@> has joined #yocto06:15
JosefHolzmayr[m]yo dudX06:26
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)06:31
*** Guest58 <Guest58!> has joined #yocto06:37
*** zyga-mbp <zyga-mbp!> has joined #yocto06:44
*** wooosaiiii <wooosaiiii!> has quit IRC (Remote host closed the connection)06:46
*** wooosaiiii <wooosaiiii!> has joined #yocto06:46
*** Guest58 <Guest58!> has quit IRC (Quit: Client closed)06:47
*** ant__ <ant__!> has quit IRC (Quit: Leaving)06:53
*** rob_w <rob_w!> has joined #yocto06:58
*** rfuentess <rfuentess!> has joined #yocto07:00
*** frieder <frieder!> has joined #yocto07:05
*** gsalazar_ <gsalazar_!~gsalazar@> has joined #yocto07:08
*** gsalazar_ is now known as gsalazar07:09
*** mckoan|away is now known as mckoan07:10
mckoangood morning07:10
*** Johnsv <Johnsv!> has joined #yocto07:13
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)07:19
*** eduardas <eduardas!~eduardas@> has joined #yocto07:19
wCPOIs there any difference between RECIPE_SYSROOT and STAGING_DIR_HOST?07:21
JohnsvHi, is it possible to build with yocto a target image for x86 which includes a cross-toolchain for another architecture, e.g. ARM as well as inside this same target image an APT installation that allows to install -dev packages for this ARM arch, provided by a yocto package feed/repository?07:21
*** prabhakarlad <prabhakarlad!> has joined #yocto07:40
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:43
RPJohnsv: multiconfig would let you put an arm image inside an x86 one. We don't have the compiler setup like that out the box in OE-Core but I know it can be done as I've done it before a while ago08:00
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto08:04
JohnsvRP: thanks, I will have a look into multiconfig08:10
*** florian <florian!> has joined #yocto08:38
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:41
*** wooosaiiii <wooosaiiii!> has quit IRC (Remote host closed the connection)08:43
*** wooosaiiii <wooosaiiii!> has joined #yocto08:43
*** m4ho <m4ho!> has quit IRC (Ping timeout: 245 seconds)08:49
rburtonhm looks like recent gatesgarth commits just broke external-arm-toolchain08:49
*** m4ho <m4ho!> has joined #yocto08:50
*** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has quit IRC (Quit: You have been kicked for being idle)09:00
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has joined #yocto09:06
*** mckoan is now known as mckoan|away10:10
*** florian_kc <florian_kc!> has joined #yocto10:10
*** awafaa <awafaa!> has quit IRC ()10:24
*** awafaa <awafaa!> has joined #yocto10:24
*** GillesM <GillesM!> has joined #yocto10:48
RPrburton: that doesn't sound good :(10:50
rburtonnot sure how, nothing landed that would obviosly do that10:50
rburtonmaybe just a glitch in the CI10:50
*** ernstp <ernstp!> has joined #yocto10:53
*** rsalveti <rsalveti!> has quit IRC ()10:54
ernstpHmm I seem to get a new 80MB bb_cache.dat.123124124... for every build almost.10:54
*** rsalveti <rsalveti!> has joined #yocto10:54
ernstpthe one in build/tmp/cache/default-glibc/MACHINE/x86-64/10:55
*** jwillikers <jwillikers!> has joined #yocto10:56
rburtonthats the parsed recipe data10:57
rburtonthus the 'cache'10:57
ernstpI thought that was in build/cache/11:00
RPernstp: build/cache has the parsed metadata, top level cache has other caches which aren't as transient11:01
rburtonbah i was close11:01
ernstpso build/tmp/cache/ is supposed to be very transient?11:02
RPrburton: you were right I think, I'm just writing things that don't quite make sense :/11:02
RPernstp: as transient as "tmp" is11:02
RPbuild/tmp/cache has the parsed metadata, top level build/cache has other caches which aren't as transient11:03
RPis what I was trying to say and failing11:03
ernstptrying to optimize an automatic builder11:03
ernstptried to save some time by not nuking all of build/tmp/ between every build...11:04
rburtoninheriting rm_work makes the deletes happen during the build in the background, which saves a lot of time11:07
rburtonespecially if you have a long commit timeout on the filesystem, as you can delete stuff before it gets written11:07
*** NishanthMenon_ <NishanthMenon_!> has quit IRC ()11:15
*** NishanthMenon_ <NishanthMenon_!> has joined #yocto11:15
*** wwilly <wwilly!> has quit IRC (Ping timeout: 265 seconds)11:16
* RP hates rm_work11:16
*** Tyaku <Tyaku!> has joined #yocto11:20
*** Tyaku <Tyaku!> has quit IRC (Client Quit)11:20
*** Tyaku <Tyaku!> has joined #yocto11:21
TyakuHi, Did you know if it's possible to make a receipe to build "GN" based project ?11:21
qschulzTyaku: there are some recipes available to build chromium which is gn based11:26
ernstp@RP why do you hate rm_work... ? doesn't sound so promising.. :-)11:33
rburtonTyaku: best practise for GN apparently is that the project using it embeds its own copy of GN, which is obviously madness.11:33
rburtonTyaku: but is a WIP recipe I almost finished for a standalone gn recipe11:34
rburtondidn't get as far as writing a class, as i didn't see enough general behaviour to be useful11:35
rburtoncurious what else you've found that uses gn, i'm only aware of two pieces of software11:36
rburtonernstp: afaik, RP hates it because of how horribly it attaches itself to the task queue11:36
RPernstp: hard to implement/maintain and rather ugly from a code perspective. Just ignore me ;-)11:37
rburton<cough> bitbake should do it11:37
rburtonoh look its lunchtime RUNS AWAY11:37
RPit is hard to make rm_work do everything everyone thinks it should do11:37
TyakuI also find this: there are many commits, the last branch is this one:
Tyaku3 Months ago he said "This task is blocking on adding the GN capability in yocto which is being currently handled as task: OSTC/OHOS/meta-ohos#53 (closed). So, this task would be parked in backlog and would be taken up once GN is available as a part of yocto project."11:37
ernstphmm, enabling rm_work seems to have made a build error (correctly) surface that had been hidden forever... :-)11:38
rburtonTyaku: seems pretty similar to my recipe.  the class... i'm not convinced that's generalisable.11:39
Tyakurburton: My objective is to create a recipe to build the Matter (connectedhomeip) library and then to create a custom software that use this library.11:40
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::81de> has joined #yocto11:41
Tyakurburton: Do you think in the future, something "generic" will come as part of Yocto project to create receipe with GN based project ?11:43
rburtonTyaku: if there's a need, sure11:43
Tyakurburton: What does your recipe exactly ? It build the GN tool ?11:46
rburtonyour recipe then depends on gn-native and you write do_compile etc11:46
TyakuOh ok11:47
TyakuAnd what is the difference with the class method that i linked before ?11:47
rburtoni'm not 100% sure that the gn class in that layer works with all gn using projects11:48
rburtonmaybe it does, and you should use that11:48
*** wwilly <wwilly!> has joined #yocto11:50
Tyakurburton, using your method, do you have an exemple of a recipe for a project that depends on gn-native and define it's own do_compile etc ?11:53
rburtonwe use it in hafnium, but that ships with a makefile that does everything so it just calls make11:57
rburtonyou'll have to read the build instructions for what youre building11:57
*** creich <creich!> has quit IRC (Ping timeout: 245 seconds)12:09
*** xmn <xmn!> has quit IRC (Ping timeout: 252 seconds)12:11
*** otavio <otavio!> has quit IRC (Remote host closed the connection)12:13
*** dagmcr <dagmcr!> has quit IRC ()12:20
*** dagmcr <dagmcr!> has joined #yocto12:21
*** otavio <otavio!> has joined #yocto12:21
*** Guest1 <Guest1!> has joined #yocto13:13
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto13:23
*** ngoub <ngoub!~ngoub@> has joined #yocto13:24
ngoubI find the "root" cause of the VIRTUAL-RUNTIME_init_manager error13:25
ngoubI had in my local.conf : BBCLASSEXTEND = "native nativesdk"13:25
ngoubwhen I displayed DISTRO_FEATURES in packagegroup.class, I got something strange DISTRO_FEATURES= ipv6 opengl x11 xattr pulseaudio gobject-introspection-data ldconfig13:27
*** Guest1 <Guest1!> has quit IRC (Quit: Client closed)13:29
rburtonwhat did you expect to happen when you put BBCLASSEXTEND into local.conf?13:29
ngoubI don't know, may be it is the result of some testing13:39
ngoubMy mistake13:39
ngoubThank you for your help on Friday13:43
*** sakoman <sakoman!~steve@> has joined #yocto14:01
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:16
*** CosmicPenguin <CosmicPenguin!> has quit IRC ()14:19
*** CosmicPenguin <CosmicPenguin!> has joined #yocto14:19
*** pgowda <pgowda!> has joined #yocto14:26
*** Guest1124 <Guest1124!> has joined #yocto14:27
*** YogeshSiraswar_ <YogeshSiraswar_!> has quit IRC ()14:28
*** YogeshSiraswar_ <YogeshSiraswar_!> has joined #yocto14:28
*** armpit <armpit!> has quit IRC ()14:30
*** armpit <armpit!> has joined #yocto14:30
*** Guest56 <Guest56!~Guest56@> has quit IRC (Quit: Client closed)14:31
Guest1124I'm have a do_fetch failure I don't understand in Dunfell 3.1.7.  I'm getting the error: "ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure: Unable to find revision b4a58d95188dd092ae20072bac14cece0e67c388 in branch master even from upstream14:32
Guest1124ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'git://'. Unable to fetch URL from any source."14:32
Guest1124I went to the upstream and verified that b4a58d95188dd092ae20072bac14cece0e67c388 does exist on master.14:32
Guest1124I'm at a lost as to what to check next.14:33
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)14:34
Guest1124I've built this image many times, but just recently cleared my caches.14:36
TyakuGuest1124: I'm not "PRO" in yocto, but i already get this kind of errors. Sometimes it's because the fetch with GIT use SSH instead of HTTP. So if you don't have an account correctly configured on the GIT provider (ex: GitHub) then SSH fetch won't work.14:39
TyakuGuest1124: Again, Here this is an example where we specify the HTTP protocol in the recipe: "SRC_URI = "gitsm://;protocol=https;branch=main"" (it's a gitsm for submodules)14:42
Guest1124@Tyaku Yes except that I do have a github account and I was able to fetch many other components during the build.  This is the only one failing so far.  But, I'll try your suggestion.14:43
*** Little_rabbit <Little_rabbit!> has joined #yocto14:47
*** whuang0389 <whuang0389!> has joined #yocto14:48
Guest1124@Tyaku No luck.  I still get the do_fetch failure using the https.  ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure: Unable to find revision b4a58d95188dd092ae20072bac14cece0e67c388 in branch master even from upstream14:49
Guest1124ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'gitsm://;protocol=https;branch=master'. Unable to fetch URL from any source.14:49
whuang0389is there a way to check which recipe is brining in another recipe? I'm trying to remove busybox but doing it via image_install_remove doesnt seem to work, so Im thinking of bbappending the recipe that is bringing it in14:51
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)14:51
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:1e47:509e:73a7:3202> has joined #yocto14:52
TyakuGuest1124: So i don't know what happens, I can only confirm what you said: I try to clone the repository and checkout b4a58d95188dd092ae20072bac14cece0e67c388 and it works. The question is: What happens during the do_fetch(). Maybe a Yocto Pro will better help you14:53
JosefHolzmayr[m]whuang0389: bitbake -g your image, then inspect the resulting files. use a textviewer and/or grep14:54
Guest1124@Tyaku Thanks for the help!  Yes, I had done the same experiment - clone and checkout - and it succeeded for me also.14:54
Little_rabbitHey, is is possible to define a function within the local.conf file? I need to quick test something and was hoping to define a function in conf/local.conf and add in to ROOTFS_POSTINSTALL_COMMAND.14:55
Little_rabbitDon't hate me... :(14:55
zeddiiGuest1124: assuming you are getting go-systemd from meta-virt, and not somewhere else, the meta-virt branch you are building is out of date.14:55
Little_rabbitIt's just so convenient for quick validations...14:55
qschulzLittle_rabbit: just add it to the image recipe, directly in it or via a bbappend14:56
Little_rabbitqschulz: Fair. I guess then I risk commiting the change :). But thanks, makes sense14:57
qschulzGuest1124: I'd probably triple check what zeddii said, but I assume go-systemd just moved from master to main for the principal branch14:57
RPLittle_rabbit: you can add a class to classes/XXX and INHERIT it from local.conf14:57
qschulzLittle_rabbit: you can create a layer quickly with bitbake-layers create-layer and then bitbake-layers add-layer IIRC14:57
zeddiiit did, and we've update in meta-virt, with a backport to dunfell14:57
Guest1124@zeddii Yes, I am getting it from meta-virtualization.  However, the SRC_URI for go-systemd does seem to be valid.  It exists in github and the specific commit exists also.14:58
RPLittle_rabbit: bitbake will look at a classes directory alongside conf/14:58
qschulzGuest1124: it exists but not in the master branch14:58
qschulzsince the master branch is probably gone now14:58
Guest1124@zeddi Hmmm.  Okay.  Let me noodle with that.14:59
qschulzRP: though having an INHERIT like that will make all recipes being reparsed right? so anmy change to the class will result in long parsing time?14:59
*** splatch <splatch!~splatch@> has joined #yocto15:01
RPqschulz: that could be an issue, I was just answering the question15:02
Guest1124@zeddi and @qschulz Thanks.  My fetch is succeeding now.  I'm not sure how I missed the branch change.  I must have assumed the default was master.  Anyhow, thenks for setting me straight.15:04
qschulzGuest1124: alas go-systemd is not the only one having done that and some repos still change every now and then15:05
qschulzquite a pain15:05
qschulzespecially for people on old unmaintained branches15:05
qschulzbut nothing we can do for them as they're EOL :)15:05
Guest1124@qshulz for most of my work, I keep up to date with the latest Dunfell.  For this particular task, I had to duplicate a build from the past.15:06
qschulzGuest1124: Dunfell is maintained, so it was just a forgotten pull, but some branches (zeus, warrior, thud, rocko, etc) won't ever receive those patches to fix the master->main change15:09
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:09
Guest1124@qschulz Understood.  I need stability because I maintain many platforms.  I really appreciate the Dunfell LTS and I'll jump to the next one whenever Dunfell goes EOL.15:12
*** Guest1124 <Guest1124!> has quit IRC (Quit: Client closed)15:16
*** Guest1176 <Guest1176!> has joined #yocto15:16
*** splatch <splatch!~splatch@> has quit IRC (Remote host closed the connection)15:17
*** Guest1176 <Guest1176!> has quit IRC (Client Quit)15:17
*** eduardas <eduardas!~eduardas@> has quit IRC (Quit: Konversation terminated!)15:18
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)15:20
*** dev1990 <dev1990!~dev@> has joined #yocto15:22
*** mabnhdev <mabnhdev!> has joined #yocto15:26
*** mabnhdev <mabnhdev!> has quit IRC (Remote host closed the connection)15:26
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)15:29
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:1e47:509e:73a7:3202> has quit IRC (Quit: Konversation terminated!)15:34
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:9fbd:7ce9:723b:b352> has joined #yocto15:34
*** whuang0389 <whuang0389!> has quit IRC (Quit: Client closed)15:37
*** Little_rabbit <Little_rabbit!> has quit IRC (Quit: Client closed)15:41
*** whuang0389 <whuang0389!> has joined #yocto15:44
*** ngoub <ngoub!~ngoub@> has quit IRC (Remote host closed the connection)15:46
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:47
RPJPEW: I've just noticed something very strange. We may have reproducibility at the package level but our outhashes are varying an awful lot15:48
RPJPEW: an easy example is to add do_install += " " to the bash recipe and watch the outhash for do_package. I think its due to the time clamps used on the packages but not the sstate archives15:49
RPwe'd get way better hashequiv results if we fix that15:50
fraywould this be like some of the other variable sanitation we did a few years back that fixed a lot of hash mismatches?  (before has equivalency)15:50
RPfray: looks like a date stamp issue rather than anything else15:51
frayOhh ok, so different then, not variable contents (extra spaces and such, but other side effects)15:52
RPfray: yes, task output effects15:52
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:52
*** zyga-mbp <zyga-mbp!> has joined #yocto15:54
*** zyga-mbp <zyga-mbp!> has quit IRC (Client Quit)15:56
*** florian <florian!> has quit IRC (Quit: Ex-Chat)15:56
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 252 seconds)16:01
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)16:03
*** zyga-mbp <zyga-mbp!> has joined #yocto16:06
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)16:06
*** prabhakarlad <prabhakarlad!> has joined #yocto16:08
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)16:13
JPEWRP: We should clamp the mtime on the sstate archives and the outhash calculation (the two are independent IIRC)16:15
*** smurray <smurray!> has quit IRC ()16:17
*** zyga-mbp <zyga-mbp!> has joined #yocto16:17
*** smurray <smurray!> has joined #yocto16:17
*** yates <yates!> has joined #yocto16:22
yateswhen i run "bitake gcc-cross-csky", i find a Makefile, <build>/tmp/work/x86_64-linux/gcc-cross-csky/10.3.0-r0/gcc-10.3.0/build.x86_64-linux.csky-poky-linux/csky-poky-linux/libgcc/Makefile16:23
*** zpfvo1 <zpfvo1!~fvo@> has quit IRC (Remote host closed the connection)16:25
yatessince libgcc is a subdirectory of the gcc package, and there is no "gcc" folder inside build.x86_64-linux.csky-poky-linux, it must be copied from somewhere, right? where is this coming from?16:25
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:9fbd:7ce9:723b:b352> has quit IRC (Ping timeout: 268 seconds)16:27
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:244a:6628:297d:6a72> has joined #yocto16:27
rburtonthat's the build tree, not the source tree16:29
rburtongcc builds out-of-tree16:29
yatesmy goal is to find how crti.S is being compiled for the gcc-cross-csky16:32
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)16:33
yatescorrection: my true goal is to patch this build to get the proper definitions in16:33
yatesbut to patch i need to find which recipe is responsible for it16:33
yatesthe crti.o that is being used in csky-poky-linux-gcc is wrong - i need to find out where that is getting build and patch it16:36
rburtonthe gcc source is in tmp/work-shared16:36
*** zyga-mbp <zyga-mbp!> has quit IRC (Ping timeout: 265 seconds)16:37
*** zyga-mbp <zyga-mbp!> has joined #yocto16:39
yatesrburton: is it not true that yocto/oe builds gcc for the host machine (in my case x86_64) as well as the cross-gcc that runs on the host machine and generates files (executables) which will run on the target machine?16:41
yatesi do not understand where/how the compilation of the crti.S is done for the cross-gcc.16:43
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Ping timeout: 265 seconds)16:43
rburtonyates: yocto never builds a native compiler, it uses the host to build a cross16:44
yatesi still do not understand where/how the compilation of the crti.S is done for the cross-gcc.16:45
yatesthere is meta/recipes-devtools/gcc/gcc_{pv}.bb, and there is meta/recipes-devtools/gcc/gcc-cross_{pv}.bb. which one builds the cross compiler?16:46
RPJPEW: I'm wondering if we should just make do_package clamp the mtime16:47
yatesi also do not understand why there are separate recipes. isn't libgcc built as part of gcc?16:48
RPyates: we build one cross compiler for the architecture, we have to build a libgcc per tune16:50
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:51
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)16:59
*** whuang0389 <whuang0389!> has quit IRC (Quit: Client closed)17:03
* agherzan uploaded an image: (151KiB) < >17:13
agherzanPartner said I need to wash it first but it's just to cool17:13
*** angolini <angolini!> has joined #yocto17:21
*** florian_kc <florian_kc!> has joined #yocto17:24
marc1Has anyone ever had an issue when building a kernel (bitbake virtual/kernel) where for some reason only one CPU is used troughout the build? Looking at the logs, I see that '-j 20' is used with make, but for some reason a single gcc process is started. The other recipes do not seem to have this issue.17:32
rburtonmaybe its a custom kernel and someone broke the build?17:33
marc1It's a linux-yocto kernel if that makes any difference...17:34
rburtonagherzan: +1 to that17:36
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:244a:6628:297d:6a72> has quit IRC (Ping timeout: 268 seconds)17:39
RPagherzan: nice, I got a burgundy colour one (since I'm YP Compat!), been too warm to wear so far though17:44
*** arunss <arunss!> has joined #yocto17:50
ndec_agherzan: awesome ;)17:50
ndec_i have them in too many colors.. and it is indeed causing some troubles at home ;)17:51
khemmine got confiscated by my son17:51
agherzan@RP I wanted burgundy but it didn't pass the family vote.17:52
ndec_my sons has his too.. ;)17:52
*** roussinm <roussinm!> has joined #yocto17:52
agherzanSadly you don't do babies17:53
agherzanI mean baby sizes - to avoid confusion :)17:54
ndec_well, i could include babies stuff.. but it didn't feel appropriate..17:54
ndec_they make bodysuits and small t-shirt )17:55
JPEWRP: Hmm... that might be appliciable to any sstate task?17:57
JPEWof course... I don't think do_package is actually an sstate task is it17:58
agherzan@ndec_ cute17:58
*** ernstp <ernstp!> has quit IRC ()18:03
*** ernstp <ernstp!> has joined #yocto18:04
arunssI have a custom target with 64-bit kernel and 32-bit userspace using multilib. Target successfully builds, however SDK build fails trying to build userspace packages in 64-bit. Is there a way to determine why SDK builds 64-bit or set it to build only 32-bit packages?18:04
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)18:14
*** prabhakarlad <prabhakarlad!> has joined #yocto18:15
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC ()18:19
*** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto18:19
*** wwilly <wwilly!> has quit IRC (Ping timeout: 265 seconds)18:25
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto18:31
*** mattsm is now known as Guest403818:32
*** Guest4038 <Guest4038!> has quit IRC (Killed ( (Nickname regained by services)))18:32
*** mattsm <mattsm!> has joined #yocto18:33
*** mattsm <mattsm!> has quit IRC (Read error: Connection reset by peer)18:34
*** ldts <ldts!> has quit IRC ()18:35
*** mattsm <mattsm!> has joined #yocto18:35
*** paulbarker <paulbarker!> has quit IRC ()18:35
*** ldts <ldts!> has joined #yocto18:35
*** paulbarker <paulbarker!> has joined #yocto18:35
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)18:42
RPJPEW: yes, do_package is18:43
*** florian_kc <florian_kc!> has joined #yocto18:43
JPEWRP: Perhaps all sstate tasks should clamp the mtime in the input directory before creating the sstate archive? What could go wrong...18:44
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:678c:a720:1126:a377> has joined #yocto18:47
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)18:51
RPJPEW: I'm not sure I like that idea18:52
RPJPEW: although it does have a certain simplicity to it18:53
JPEWRP: Ya, I'm not sure either.... but I could certially see a future where we manually end up adding to every sstate task for better repro/hashequiv reasons18:53
JPEWRP: Seems fine to add it just to do_package for now maybe with a note that we may need to make it more generic in the future18:54
RPJPEW: adding just to do_package isn't straightforward and I think all sstate tasks will have this issue18:55
RPJPEW: I've been playing and it isn't simple18:55
*** zyga-mbp <zyga-mbp!> has joined #yocto18:57
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)19:02
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)19:15
*** zyga-mbp <zyga-mbp!> has joined #yocto19:21
*** splatch <splatch!~splatch@> has joined #yocto19:22
splatchhello, I ran into something unexpected and I am not quite sure what issue it really is. Is it host hardware or build issue: 'Creating filesystem with 2097152 4k blocks and 1048576 inodes' later on 'Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system'.19:23
*** zyga-mbp <zyga-mbp!> has quit IRC (Read error: Connection reset by peer)19:26
*** pgowda <pgowda!> has quit IRC (Quit: Connection closed for inactivity)19:45
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Remote host closed the connection)20:26
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto20:27
yatesrburton: you said the other day that gcc-cross*.bb builds the cross compiler. what id gcc*.bb for?20:32
yatesrburton: you stated today: "the gcc source is in tmp/work-shared". that is true - i can see that. so what of it? are you saying this is where i should patch files?20:37
RPyates: isn't crti.S compiled by glibc ?20:38
RPyates: grepping in tmp/sstate-control/* suggests the file is part of glibc20:38
yatesRP: since it is a part of the libgcc submake, i would think it is compiled in the libgcc build.20:38
yateswhat is tmp/sstate-control for?20:39
RPyates: it contains the manifests used by sstate to control which files get installed where in sysroots20:40
yatesthat paste is showing that the .S files are part of libgcc sub-"project"20:41
RPyates: In a normal oe build, I think it comes from glibc, at least in the glibc case. I can't see any reference to that in the libgcc build logs20:42
RPyates: I can see the glibc build logs compiling it, which was your question20:43
yatesRP: well that is a real paradigm shift for me.20:43
yatesis it the case that the crti.S file is provided by libgcc but not used? i.e. there is another one in glibc?20:44
*** splatch <splatch!~splatch@> has quit IRC (Remote host closed the connection)20:44
RPyates: looks like glibc has its own20:45
* yates face-palms20:45
yatesRP: from which bar may I buy you a beer?20:46
RPyates: Will be nice when we can finally do that! :)20:46
yatesRP: agreed!20:47
*** ant__ <ant__!> has joined #yocto20:53
yatesso the gcc recipe does not include glibc?20:54
yatesand yet the gcc driver will point the linker to glibc-compiled files (e.g., crti.o) when linking???20:54
ant__imaagine, what if you were using another libc, say musl?21:01
RPyates: correct, that shouldn't be too surprising21:07
ant__RP: hey, I was debugging today a strange samba rebuild and discovered SSTATE_MANMACH was pointing to MACHINE. Then I solved.21:15
ant__doing this I think I have spotted a double def:21:15
ant__and on line 13721:15
RPant__: those definitions aren't identical, I think it is intended21:17
RPJPEW: this is proving really hard to sort out :(21:18
ant__I first read about this var today, debugging a bogus e2fsprogs.bbappend machine-arch21:18
JPEWRP: Hmm, I guess my initial glance was deceiving21:19
JPEWWhats the difficulty?21:19
RPJPEW: the trouble is we need the on disk files to match what is in sstate else we'll get weird differences in "from sstate" and "not from sstate" builds21:19
ant__RP: on line 1321:20
* RP learnt long ago we don't want to go there even for simple dates21:20
*** stephano <stephano!~stephano@> has joined #yocto21:20
RPant__: right, I'd rather have the duplicate definitions than make the function half compelte though21:21
ant__for the sake of precision, while grepping for it I found references in toaster.bbclass21:22
ant__isn'it deprecated nowadays?21:22
JPEWThat's why we can't just clamp the sstate with tar when creating the archive, correct?21:23
JPEWClamp the mtime that is21:24
RPJPEW: yes, then the two paths differ21:24
RPJPEW: that way lies maddness21:24
JPEWI was thinking we clamp the mtime on the input directories before sstate_install... At least as a test21:25
RPJPEW: sstate_package() is where I think we need to do it, I have some code testing atm21:26
JPEWSounds reasonable. We can talk at the call tomorrow.21:27
RPJPEW: right, I'll continue to experiment21:29
RPJPEW: just letting you know what I'm finding21:29
RPI'm amazed how painful this is being21:29
*** otavio <otavio!> has quit IRC (Remote host closed the connection)21:38
*** xmn <xmn!> has joined #yocto21:39
*** otavio <otavio!> has joined #yocto21:39
RPJPEW: well, I fixed the timestamp issue. More worryingly, the content of bash's packages keeps changing21:40
RPoh, fun. bash increases a version every time you run make install on it21:42
* RP should find something else to test with then :/21:42
*** stephano <stephano!~stephano@> has quit IRC (Quit: Textual IRC Client:
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)22:42
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)22:47
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Quit: Konversation terminated!)22:50
JPEWRP: You just jogged my memory on that one. I found that a while ago when doing repro testing but forgot to log/fix it22:50
RPJPEW: I think  and should fix things22:57
*** pgowda <pgowda!> has joined #yocto22:57
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)22:59
* RP has far too much junk in his local tree now, this was all far too painful to figure out22:59
*** dev1990 <dev1990!~dev@> has joined #yocto22:59
* RP will continue tomorrow23:00
*** dev1990 <dev1990!~dev@> has quit IRC (Client Quit)23:01
*** sakoman <sakoman!~steve@> has joined #yocto23:03
*** florian_kc <florian_kc!> has joined #yocto23:13
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 268 seconds)23:24

Generated by 2.17.2 by Marius Gedminas - find it at!