*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Quit: Leaving.) | 00:30 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 01:14 | |
*** camus <camus!~Instantbi@222.65.21.255> has joined #yocto | 01:56 | |
*** camus <camus!~Instantbi@222.65.21.255> has quit IRC (Ping timeout: 260 seconds) | 02:00 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 02:10 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:10 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 02:51 | |
*** zpfvo1 <zpfvo1!~fvo@88.130.218.196> has joined #yocto | 02:56 | |
*** zpfvo <zpfvo!~fvo@88.130.223.235> has quit IRC (Ping timeout: 245 seconds) | 02:58 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 252 seconds) | 03:07 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 03:13 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 04:01 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 04:01 | |
*** user_123 <user_123!~user@182.71.223.114> has quit IRC (*.net *.split) | 04:06 | |
*** wyre <wyre!~wyre@user/wyre> has quit IRC (*.net *.split) | 04:06 | |
*** fancer <fancer!fancer@id-180736.tinside.irccloud.com> has quit IRC (*.net *.split) | 04:06 | |
*** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has quit IRC (*.net *.split) | 04:06 | |
*** elfenix|cloud <elfenix|cloud!uid516192@id-516192.helmsley.irccloud.com> 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_!sid495823@id-495823.tinside.irccloud.com> has quit IRC (*.net *.split) | 04:06 | |
*** rmmr <rmmr!sid240755@id-240755.helmsley.irccloud.com> 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@209.147.121.179> has quit IRC (*.net *.split) | 04:06 | |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> 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!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 04:06 | |
*** Ch^W <Ch^W!~mouser@209.147.121.179> has joined #yocto | 04:06 | |
*** user_123 <user_123!~user@14.142.4.2> has joined #yocto | 04:06 | |
*** fancer <fancer!fancer@2a03:5180:f::2:c200> has joined #yocto | 04:06 | |
*** elfenix|cloud <elfenix|cloud!uid516192@2a03:5180:f:1::7:e060> has joined #yocto | 04:06 | |
*** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto | 04:07 | |
*** wyre <wyre!~wyre@user/wyre> has joined #yocto | 04:07 | |
*** xtopher_ <xtopher_!sid495823@id-495823.tinside.irccloud.com> has joined #yocto | 04:07 | |
*** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has joined #yocto | 04:07 | |
*** rmmr <rmmr!sid240755@id-240755.helmsley.irccloud.com> has joined #yocto | 04:07 | |
*** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto | 04:08 | |
*** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 04:11 | |
*** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 04: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!warthog9@proxy.monkeyblade.net> has quit IRC (*.net *.split) | 04:19 | |
*** kmaincent <kmaincent!~kmaincent@shells.bootlin.com> has quit IRC (*.net *.split) | 04:19 | |
*** ndec <ndec!sid219321@tinside.irccloud.com> has quit IRC (*.net *.split) | 04:19 | |
*** karl <karl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto | 04:19 | |
*** ndec_ <ndec_!sid219321@id-219321.tinside.irccloud.com> has joined #yocto | 04:19 | |
*** ChanServ sets mode: +v ndec_ | 04:19 | |
*** kmaincent <kmaincent!~kmaincent@2001:41d0:305:1000::2a58> has joined #yocto | 04:19 | |
*** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto | 04:21 | |
*** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 04:23 | |
*** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 04:27 | |
*** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto | 04:30 | |
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto | 04:30 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 04:43 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:59 | |
*** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto | 06:15 | |
JosefHolzmayr[m] | yo dudX | 06:26 |
---|---|---|
*** dev1990 <dev1990!~dev@78.10.71.240> has quit IRC (Quit: Konversation terminated!) | 06:31 | |
*** Guest58 <Guest58!~Guest58@87-49-45-150-mobile.dk.customer.tdc.net> has joined #yocto | 06:37 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 06:44 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 06:46 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 06:46 | |
*** Guest58 <Guest58!~Guest58@87-49-45-150-mobile.dk.customer.tdc.net> has quit IRC (Quit: Client closed) | 06:47 | |
*** ant__ <ant__!~ant@host-79-16-249-93.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 06:53 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:58 | |
*** rfuentess <rfuentess!~rfuentess@tmo-098-48.customers.d1-online.com> has joined #yocto | 07:00 | |
*** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> has joined #yocto | 07:05 | |
*** gsalazar_ <gsalazar_!~gsalazar@194.38.148.130> has joined #yocto | 07:08 | |
*** gsalazar_ is now known as gsalazar | 07:09 | |
*** mckoan|away is now known as mckoan | 07:10 | |
mckoan | good morning | 07:10 |
*** Johnsv <Johnsv!~Johnsv@d51a47c4a.access.telenet.be> has joined #yocto | 07:13 | |
erbo | morning! | 07:14 |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 07:19 | |
*** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 07:19 | |
wCPO | Is there any difference between RECIPE_SYSROOT and STAGING_DIR_HOST? | 07:21 |
Johnsv | Hi, 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!~prabhakar@pc.renesas.eu> has joined #yocto | 07:40 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:43 | |
RP | Johnsv: 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 ago | 08:00 |
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 08:04 | |
Johnsv | RP: thanks, I will have a look into multiconfig | 08:10 |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:38 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:41 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 08:43 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 08:43 | |
*** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds) | 08:49 | |
rburton | hm looks like recent gatesgarth commits just broke external-arm-toolchain | 08:49 |
*** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 08: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 #yocto | 09:06 | |
*** mckoan is now known as mckoan|away | 10:10 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:10 | |
*** awafaa <awafaa!sid716@highgate.irccloud.com> has quit IRC () | 10:24 | |
*** awafaa <awafaa!sid716@id-716.uxbridge.irccloud.com> has joined #yocto | 10:24 | |
*** GillesM <GillesM!~gilles@135.155.118.78.rev.sfr.net> has joined #yocto | 10:48 | |
RP | rburton: that doesn't sound good :( | 10:50 |
rburton | not sure how, nothing landed that would obviosly do that | 10:50 |
rburton | maybe just a glitch in the CI | 10:50 |
*** ernstp <ernstp!sid168075@stonehaven.irccloud.com> has joined #yocto | 10:53 | |
*** rsalveti <rsalveti!uid117878@highgate.irccloud.com> has quit IRC () | 10:54 | |
ernstp | Hmm I seem to get a new 80MB bb_cache.dat.123124124... for every build almost. | 10:54 |
*** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 10:54 | |
ernstp | the one in build/tmp/cache/default-glibc/MACHINE/x86-64/ | 10:55 |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 10:56 | |
rburton | thats the parsed recipe data | 10:57 |
rburton | thus the 'cache' | 10:57 |
ernstp | I thought that was in build/cache/ | 11:00 |
RP | ernstp: build/cache has the parsed metadata, top level cache has other caches which aren't as transient | 11:01 |
rburton | bah i was close | 11:01 |
ernstp | so build/tmp/cache/ is supposed to be very transient? | 11:02 |
RP | rburton: you were right I think, I'm just writing things that don't quite make sense :/ | 11:02 |
RP | ernstp: as transient as "tmp" is | 11:02 |
RP | build/tmp/cache has the parsed metadata, top level build/cache has other caches which aren't as transient | 11:03 |
RP | is what I was trying to say and failing | 11:03 |
ernstp | trying to optimize an automatic builder | 11:03 |
ernstp | tried to save some time by not nuking all of build/tmp/ between every build... | 11:04 |
rburton | inheriting rm_work makes the deletes happen during the build in the background, which saves a lot of time | 11:07 |
rburton | especially if you have a long commit timeout on the filesystem, as you can delete stuff before it gets written | 11:07 |
ernstp | interesting! | 11:09 |
*** NishanthMenon_ <NishanthMenon_!sid138049@highgate.irccloud.com> has quit IRC () | 11:15 | |
*** NishanthMenon_ <NishanthMenon_!sid138049@id-138049.uxbridge.irccloud.com> has joined #yocto | 11:15 | |
*** wwilly <wwilly!~wwilly@cpc92794-cmbg19-2-0-cust589.5-4.cable.virginm.net> has quit IRC (Ping timeout: 265 seconds) | 11:16 | |
* RP hates rm_work | 11:16 | |
*** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has joined #yocto | 11:20 | |
*** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has quit IRC (Client Quit) | 11:20 | |
*** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has joined #yocto | 11:21 | |
Tyaku | Hi, Did you know if it's possible to make a receipe to build "GN" based project ? | 11:21 |
qschulz | Tyaku: there are some recipes available to build chromium which is gn based | 11:26 |
qschulz | https://github.com/OSSystems/meta-browser/tree/master/meta-chromium/recipes-browser/chromium | 11:26 |
ernstp | @RP why do you hate rm_work... ? doesn't sound so promising.. :-) | 11:33 |
rburton | Tyaku: best practise for GN apparently is that the project using it embeds its own copy of GN, which is obviously madness. | 11:33 |
rburton | Tyaku: but https://gitlab.com/rossburton/meta-openembedded/-/commit/a28672fb73f81d40f3ea0f99ed0fe233d40d1c73 is a WIP recipe I almost finished for a standalone gn recipe | 11:34 |
rburton | didn't get as far as writing a class, as i didn't see enough general behaviour to be useful | 11:35 |
rburton | curious what else you've found that uses gn, i'm only aware of two pieces of software | 11:36 |
rburton | ernstp: afaik, RP hates it because of how horribly it attaches itself to the task queue | 11:36 |
RP | ernstp: hard to implement/maintain and rather ugly from a code perspective. Just ignore me ;-) | 11:37 |
rburton | <cough> bitbake should do it | 11:37 |
rburton | oh look its lunchtime RUNS AWAY | 11:37 |
RP | it is hard to make rm_work do everything everyone thinks it should do | 11:37 |
Tyaku | I also find this: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/53 there are many commits, the last branch is this one: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/merge_requests/196/diffs | 11:37 |
Tyaku | 3 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 |
ernstp | hmm, enabling rm_work seems to have made a build error (correctly) surface that had been hidden forever... :-) | 11:38 |
rburton | Tyaku: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/merge_requests/162/diffs?commit_id=cebbf8734ec78874471b45893eba424068f1c6df seems pretty similar to my recipe. the class... i'm not convinced that's generalisable. | 11:39 |
Tyaku | rburton: 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 #yocto | 11:41 | |
Tyaku | rburton: Do you think in the future, something "generic" will come as part of Yocto project to create receipe with GN based project ? | 11:43 |
rburton | Tyaku: if there's a need, sure | 11:43 |
Tyaku | rburton: What does your recipe exactly ? It build the GN tool ? | 11:46 |
rburton | yes | 11:46 |
rburton | your recipe then depends on gn-native and you write do_compile etc | 11:46 |
Tyaku | Oh ok | 11:47 |
Tyaku | And what is the difference with the class method that i linked before ? | 11:47 |
rburton | i'm not 100% sure that the gn class in that layer works with all gn using projects | 11:48 |
rburton | maybe it does, and you should use that | 11:48 |
*** wwilly <wwilly!~wwilly@fw-tnat-cam4.arm.com> has joined #yocto | 11:50 | |
Tyaku | rburton, 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 |
rburton | we use it in hafnium, but that ships with a makefile that does everything so it just calls make | 11:57 |
rburton | you'll have to read the build instructions for what youre building | 11:57 |
*** creich <creich!~creich@p200300f6af262d10000000000000039b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds) | 12:09 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds) | 12:11 | |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 12:13 | |
*** dagmcr <dagmcr!sid323878@highgate.irccloud.com> has quit IRC () | 12:20 | |
*** dagmcr <dagmcr!sid323878@id-323878.uxbridge.irccloud.com> has joined #yocto | 12:21 | |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 12:21 | |
*** Guest1 <Guest1!~Guest1@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 13:13 | |
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 13:23 | |
*** ngoub <ngoub!~ngoub@84.207.216.243> has joined #yocto | 13:24 | |
ngoub | Hello | 13:24 |
ngoub | I find the "root" cause of the VIRTUAL-RUNTIME_init_manager error | 13:25 |
ngoub | I had in my local.conf : BBCLASSEXTEND = "native nativesdk" | 13:25 |
ngoub | when I displayed DISTRO_FEATURES in packagegroup.class, I got something strange DISTRO_FEATURES= ipv6 opengl x11 xattr pulseaudio gobject-introspection-data ldconfig | 13:27 |
*** Guest1 <Guest1!~Guest1@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Quit: Client closed) | 13:29 | |
rburton | what did you expect to happen when you put BBCLASSEXTEND into local.conf? | 13:29 |
ngoub | I don't know, may be it is the result of some testing | 13:39 |
ngoub | My mistake | 13:39 |
ngoub | Thank you for your help on Friday | 13:43 |
JosefHolzmayr[m] | rburton: https://youtu.be/DSnOfF6-xZI?t=410 | 13:51 |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:01 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:16 | |
*** CosmicPenguin <CosmicPenguin!sid489106@highgate.irccloud.com> has quit IRC () | 14:19 | |
*** CosmicPenguin <CosmicPenguin!sid489106@id-489106.uxbridge.irccloud.com> has joined #yocto | 14:19 | |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 14:26 | |
*** Guest1124 <Guest1124!~Guest11@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has joined #yocto | 14:27 | |
*** YogeshSiraswar_ <YogeshSiraswar_!sid500596@highgate.irccloud.com> has quit IRC () | 14:28 | |
*** YogeshSiraswar_ <YogeshSiraswar_!sid500596@id-500596.uxbridge.irccloud.com> has joined #yocto | 14:28 | |
*** armpit <armpit!sid501830@highgate.irccloud.com> has quit IRC () | 14:30 | |
*** armpit <armpit!sid501830@id-501830.uxbridge.irccloud.com> has joined #yocto | 14:30 | |
*** Guest56 <Guest56!~Guest56@64.222.164.134> has quit IRC (Quit: Client closed) | 14:31 | |
Guest1124 | I'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 upstream | 14:32 |
Guest1124 | ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'git://github.com/coreos/go-systemd.git'. Unable to fetch URL from any source." | 14:32 |
Guest1124 | I went to the upstream and verified that b4a58d95188dd092ae20072bac14cece0e67c388 does exist on master. | 14:32 |
Guest1124 | I'm at a lost as to what to check next. | 14:33 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 14:34 | |
Guest1124 | I've built this image many times, but just recently cleared my caches. | 14:36 |
Tyaku | Guest1124: 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 |
Tyaku | Guest1124: Again, Here this is an example where we specify the HTTP protocol in the recipe: "SRC_URI = "gitsm://github.com/openthread/ot-br-posix.git;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!~Little_ra@2a02-a45a-88f0-1-787b-112e-f7bb-dc28.fixed6.kpn.net> has joined #yocto | 14:47 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 14: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 upstream | 14:49 |
Guest1124 | ERROR: go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure for URL: 'gitsm://github.com/coreos/go-systemd.git;protocol=https;branch=master'. Unable to fetch URL from any source. | 14:49 |
whuang0389 | is 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 in | 14:51 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 14:51 | |
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:1e47:509e:73a7:3202> has joined #yocto | 14:52 | |
Tyaku | Guest1124: 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 you | 14:53 |
JosefHolzmayr[m] | whuang0389: bitbake -g your image, then inspect the resulting depends.dot files. use a textviewer and/or grep | 14: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_rabbit | Hey, 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_rabbit | Don't hate me... :( | 14:55 |
zeddii | Guest1124: 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_rabbit | It's just so convenient for quick validations... | 14:55 |
qschulz | Little_rabbit: just add it to the image recipe, directly in it or via a bbappend | 14:56 |
Little_rabbit | qschulz: Fair. I guess then I risk commiting the change :). But thanks, makes sense | 14:57 |
qschulz | Guest1124: I'd probably triple check what zeddii said, but I assume go-systemd just moved from master to main for the principal branch | 14:57 |
RP | Little_rabbit: you can add a class to classes/XXX and INHERIT it from local.conf | 14:57 |
qschulz | Little_rabbit: you can create a layer quickly with bitbake-layers create-layer and then bitbake-layers add-layer IIRC | 14:57 |
zeddii | it did, and we've update in meta-virt, with a backport to dunfell | 14: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 |
RP | Little_rabbit: bitbake will look at a classes directory alongside conf/ | 14:58 |
qschulz | Guest1124: it exists but not in the master branch | 14:58 |
qschulz | since the master branch is probably gone now | 14:58 |
Guest1124 | @zeddi Hmmm. Okay. Let me noodle with that. | 14:59 |
zeddii | Guest1124: https://pastebin.com/1narBMHT | 14:59 |
qschulz | RP: 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@195.116.154.6> has joined #yocto | 15:01 | |
RP | qschulz: that could be an issue, I was just answering the question | 15: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 |
qschulz | Guest1124: alas go-systemd is not the only one having done that and some repos still change every now and then | 15:05 |
qschulz | quite a pain | 15:05 |
qschulz | especially for people on old unmaintained branches | 15:05 |
qschulz | but 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 |
qschulz | Guest1124: 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 change | 15:09 |
*** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> 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!~Guest11@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Quit: Client closed) | 15:16 | |
*** Guest1176 <Guest1176!~Guest11@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has joined #yocto | 15:16 | |
*** splatch <splatch!~splatch@195.116.154.6> has quit IRC (Remote host closed the connection) | 15:17 | |
*** Guest1176 <Guest1176!~Guest11@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Client Quit) | 15:17 | |
*** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 15:18 | |
*** Tyaku <Tyaku!~Tyaku@176-154-243-92.abo.bbox.fr> has quit IRC (Quit: Lost terminal) | 15:20 | |
*** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto | 15:22 | |
*** mabnhdev <mabnhdev!~mabnhdev@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has joined #yocto | 15:26 | |
*** mabnhdev <mabnhdev!~mabnhdev@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Remote host closed the connection) | 15:26 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> 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 #yocto | 15:34 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 15:37 | |
*** Little_rabbit <Little_rabbit!~Little_ra@2a02-a45a-88f0-1-787b-112e-f7bb-dc28.fixed6.kpn.net> has quit IRC (Quit: Client closed) | 15:41 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 15:44 | |
*** ngoub <ngoub!~ngoub@84.207.216.243> has quit IRC (Remote host closed the connection) | 15:46 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:47 | |
RP | JPEW: I've just noticed something very strange. We may have reproducibility at the package level but our outhashes are varying an awful lot | 15:48 |
RP | JPEW: 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 archives | 15:49 |
RP | we'd get way better hashequiv results if we fix that | 15:50 |
fray | would 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 |
RP | fray: looks like a date stamp issue rather than anything else | 15:51 |
fray | Ohh ok, so different then, not variable contents (extra spaces and such, but other side effects) | 15:52 |
RP | fray: yes, task output effects | 15:52 |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 15:52 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 15:54 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Client Quit) | 15:56 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 15:56 | |
*** amitk <amitk!~amit@103.208.69.43> has quit IRC (Ping timeout: 252 seconds) | 16:01 | |
*** rfuentess <rfuentess!~rfuentess@tmo-098-48.customers.d1-online.com> has quit IRC (Remote host closed the connection) | 16:03 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 16:06 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 16:06 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:08 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 16:13 | |
JPEW | RP: We should clamp the mtime on the sstate archives and the outhash calculation (the two are independent IIRC) | 16:15 |
JPEW | ? | 16:15 |
*** smurray <smurray!sid98062@id-98062.stonehaven.irccloud.com> has quit IRC () | 16:17 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 16:17 | |
*** smurray <smurray!sid98062@id-98062.hampstead.irccloud.com> has joined #yocto | 16:17 | |
*** yates <yates!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has joined #yocto | 16:22 | |
yates | when 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/Makefile | 16:23 |
*** zpfvo1 <zpfvo1!~fvo@88.130.218.196> has quit IRC (Remote host closed the connection) | 16:25 | |
yates | since 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 #yocto | 16:27 | |
rburton | that's the build tree, not the source tree | 16:29 |
rburton | gcc builds out-of-tree | 16:29 |
rburton | out-of-source-tree | 16:29 |
yates | ok. | 16:31 |
yates | my goal is to find how crti.S is being compiled for the gcc-cross-csky | 16:32 |
*** GillesM <GillesM!~gilles@135.155.118.78.rev.sfr.net> has quit IRC (Remote host closed the connection) | 16:33 | |
yates | correction: my true goal is to patch this build to get the proper definitions in | 16:33 |
yates | but to patch i need to find which recipe is responsible for it | 16:33 |
yates | the 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 it | 16:36 |
rburton | the gcc source is in tmp/work-shared | 16:36 |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Ping timeout: 265 seconds) | 16:37 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 16:39 | |
yates | rburton: 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 |
yates | i do not understand where/how the compilation of the crti.S is done for the cross-gcc. | 16:43 |
*** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Ping timeout: 265 seconds) | 16:43 | |
rburton | yates: yocto never builds a native compiler, it uses the host to build a cross | 16:44 |
yates | ok | 16:45 |
yates | i still do not understand where/how the compilation of the crti.S is done for the cross-gcc. | 16:45 |
yates | there 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 |
RP | JPEW: I'm wondering if we should just make do_package clamp the mtime | 16:47 |
yates | i also do not understand why there are separate ligcc-xyz.bb recipes. isn't libgcc built as part of gcc? | 16:48 |
RP | yates: we build one cross compiler for the architecture, we have to build a libgcc per tune | 16:50 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 16:51 | |
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving) | 16:59 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 17:03 | |
* agherzan uploaded an image: (151KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/zNrasIXBqoqybDRVIFNIiiuW/IMG_20210913_181314.jpg > | 17:13 | |
agherzan | Partner said I need to wash it first but it's just to cool | 17:13 |
*** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has joined #yocto | 17:21 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has joined #yocto | 17:24 | |
marc1 | Has 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 |
rburton | maybe its a custom kernel and someone broke the build? | 17:33 |
marc1 | It's a linux-yocto kernel if that makes any difference... | 17:34 |
rburton | agherzan: +1 to that | 17:36 |
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:244a:6628:297d:6a72> has quit IRC (Ping timeout: 268 seconds) | 17:39 | |
RP | agherzan: nice, I got a burgundy colour one (since I'm YP Compat!), been too warm to wear so far though | 17:44 |
*** arunss <arunss!~aruns@c-73-221-57-124.hsd1.wa.comcast.net> has joined #yocto | 17: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 |
khem | mine got confiscated by my son | 17: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!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 17:52 | |
agherzan | Sadly you don't do babies | 17:53 |
agherzan | I 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 |
JPEW | RP: Hmm... that might be appliciable to any sstate task? | 17:57 |
JPEW | of course... I don't think do_package is actually an sstate task is it | 17:58 |
agherzan | @ndec_ cute | 17:58 |
*** ernstp <ernstp!sid168075@stonehaven.irccloud.com> has quit IRC () | 18:03 | |
*** ernstp <ernstp!sid168075@id-168075.hampstead.irccloud.com> has joined #yocto | 18:04 | |
arunss | I 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!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 18:14 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 18:15 | |
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC () | 18:19 | |
*** darknighte <darknighte!sid214177@user/darknighte> has joined #yocto | 18:19 | |
*** wwilly <wwilly!~wwilly@fw-tnat-cam4.arm.com> has quit IRC (Ping timeout: 265 seconds) | 18:25 | |
*** mranostaj <mranostaj!~mranostaj@185.193.126.133> has joined #yocto | 18:31 | |
*** mattsm is now known as Guest4038 | 18:32 | |
*** Guest4038 <Guest4038!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Killed (iridium.libera.chat (Nickname regained by services))) | 18:32 | |
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 18:33 | |
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Read error: Connection reset by peer) | 18:34 | |
*** ldts <ldts!sid269548@id-269548.stonehaven.irccloud.com> has quit IRC () | 18:35 | |
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 18:35 | |
*** paulbarker <paulbarker!sid269702@id-269702.stonehaven.irccloud.com> has quit IRC () | 18:35 | |
*** ldts <ldts!sid269548@id-269548.hampstead.irccloud.com> has joined #yocto | 18:35 | |
*** paulbarker <paulbarker!sid269702@id-269702.hampstead.irccloud.com> has joined #yocto | 18:35 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 18:42 | |
RP | JPEW: yes, do_package is | 18:43 |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has joined #yocto | 18:43 | |
JPEW | RP: 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 #yocto | 18:47 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 18:51 | |
RP | JPEW: I'm not sure I like that idea | 18:52 |
RP | JPEW: although it does have a certain simplicity to it | 18:53 |
JPEW | RP: 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 reasons | 18:53 |
JPEW | RP: 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 future | 18:54 |
RP | JPEW: adding just to do_package isn't straightforward and I think all sstate tasks will have this issue | 18:55 |
RP | JPEW: I've been playing and it isn't simple | 18:55 |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 18:57 | |
*** zyga-mbp <zyga-mbp!~zyga@user-5-173-19-60.play-internet.pl> 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!~zyga@user-5-173-19-60.play-internet.pl> has joined #yocto | 19:21 | |
*** splatch <splatch!~splatch@195.116.154.6> has joined #yocto | 19:22 | |
splatch | hello, 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!~zyga@user-5-173-19-60.play-internet.pl> has quit IRC (Read error: Connection reset by peer) | 19:26 | |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 19:45 | |
*** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Remote host closed the connection) | 20:26 | |
*** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 20:27 | |
yates | rburton: you said the other day that gcc-cross*.bb builds the cross compiler. what id gcc*.bb for? | 20:32 |
yates | is | 20:33 |
yates | rburton: 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 |
RP | yates: isn't crti.S compiled by glibc ? | 20:38 |
RP | yates: grepping in tmp/sstate-control/* suggests the file is part of glibc | 20:38 |
yates | RP: since it is a part of the libgcc submake, i would think it is compiled in the libgcc build. | 20:38 |
yates | what is tmp/sstate-control for? | 20:39 |
RP | yates: it contains the manifests used by sstate to control which files get installed where in sysroots | 20:40 |
yates | http://paste.debian.net/1211628/ | 20:40 |
yates | that paste is showing that the .S files are part of libgcc sub-"project" | 20:41 |
RP | yates: 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 logs | 20:42 |
RP | yates: I can see the glibc build logs compiling it, which was your question | 20:43 |
yates | RP: well that is a real paradigm shift for me. | 20:43 |
yates | is 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@195.116.154.6> has quit IRC (Remote host closed the connection) | 20:44 | |
RP | yates: looks like glibc has its own | 20:45 |
* yates face-palms | 20:45 | |
yates | RP: from which bar may I buy you a beer? | 20:46 |
RP | yates: Will be nice when we can finally do that! :) | 20:46 |
yates | RP: agreed! | 20:47 |
*** ant__ <ant__!~ant@host-79-16-249-93.retail.telecomitalia.it> has joined #yocto | 20:53 | |
yates | so the gcc recipe does not include glibc? | 20:54 |
yates | and 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 |
RP | yates: correct, that shouldn't be too surprising | 21: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__ | https://git.openembedded.org/openembedded-core/tree/meta/classes/sstate.bbclass#n86 | 21:15 |
ant__ | and on line 137 | 21:15 |
RP | ant__: those definitions aren't identical, I think it is intended | 21:17 |
RP | JPEW: this is proving really hard to sort out :( | 21:18 |
ant__ | I first read about this var today, debugging a bogus e2fsprogs.bbappend machine-arch | 21:18 |
JPEW | RP: Hmm, I guess my initial glance was deceiving | 21:19 |
JPEW | Whats the difficulty? | 21:19 |
RP | JPEW: 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" builds | 21:19 |
ant__ | RP: on line 13 | 21:20 |
ant__ | SSTATE_PKGARCH = "${PACKAGE_ARCH}" | 21:20 |
* RP learnt long ago we don't want to go there even for simple dates | 21:20 | |
*** stephano <stephano!~stephano@73.240.0.134> has joined #yocto | 21:20 | |
RP | ant__: right, I'd rather have the duplicate definitions than make the function half compelte though | 21:21 |
ant__ | for the sake of precision, while grepping for it I found references in toaster.bbclass | 21:22 |
ant__ | isn'it deprecated nowadays? | 21:22 |
JPEW | That's why we can't just clamp the sstate with tar when creating the archive, correct? | 21:23 |
JPEW | Clamp the mtime that is | 21:24 |
RP | JPEW: yes, then the two paths differ | 21:24 |
RP | JPEW: that way lies maddness | 21:24 |
JPEW | Agrees | 21:24 |
JPEW | I was thinking we clamp the mtime on the input directories before sstate_install... At least as a test | 21:25 |
RP | JPEW: sstate_package() is where I think we need to do it, I have some code testing atm | 21:26 |
JPEW | Sounds reasonable. We can talk at the call tomorrow. | 21:27 |
RP | JPEW: right, I'll continue to experiment | 21:29 |
RP | JPEW: just letting you know what I'm finding | 21:29 |
RP | I'm amazed how painful this is being | 21:29 |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 21:38 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 21:39 | |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 21:39 | |
RP | JPEW: well, I fixed the timestamp issue. More worryingly, the content of bash's packages keeps changing | 21:40 |
RP | oh, fun. bash increases a version every time you run make install on it | 21:42 |
* RP should find something else to test with then :/ | 21:42 | |
*** stephano <stephano!~stephano@73.240.0.134> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 21:50 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 22:42 | |
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Read error: Connection reset by peer) | 22:47 | |
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Quit: Konversation terminated!) | 22:50 | |
JPEW | RP: You just jogged my memory on that one. I found that a while ago when doing repro testing but forgot to log/fix it | 22:50 |
RP | JPEW: I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=83f602ce25deb1c2d7cdfe65d7d54ca4cf50af06 and http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e657518afa7b216076fca7f84bd916427e34f67d should fix things | 22:57 |
*** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 22:57 | |
RP | JPEW: and http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=6fb926df4e5d08f2292e59649fe352a75df4501a | 22:58 |
*** dev1990 <dev1990!~dev@78.10.71.240> 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 out | 22:59 | |
*** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto | 22:59 | |
* RP will continue tomorrow | 23:00 | |
*** dev1990 <dev1990!~dev@78.10.71.240> has quit IRC (Client Quit) | 23:01 | |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 23:03 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has joined #yocto | 23:13 | |
*** florian_kc <florian_kc!~florian@dynamic-002-244-176-210.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 23:24 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!