Thursday, 2020-07-02

*** ericch <ericch!> has quit IRC00:14
*** nslu2-log <nslu2-log!> has joined #yocto00:16
*** dmoseley <dmoseley!~dmoseley@> has quit IRC00:17
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto00:19
champagnegkergoth: thx!00:27
*** dakhouya <dakhouya!> has quit IRC00:28
*** dakhouya <dakhouya!> has joined #yocto00:33
*** yann <yann!> has quit IRC00:45
*** nslu2-log <nslu2-log!> has quit IRC00:52
*** nslu2-log <nslu2-log!> has joined #yocto01:01
*** nameclash <nameclash!> has quit IRC01:10
*** nslu2-log <nslu2-log!> has quit IRC01:16
*** nslu2-log <nslu2-log!> has joined #yocto01:19
*** dmoseley_ <dmoseley_!~dmoseley@> has joined #yocto01:30
*** dmoseley <dmoseley!~dmoseley@> has quit IRC01:30
*** ssajal <ssajal!> has quit IRC01:48
*** dakhouya <dakhouya!> has quit IRC01:49
*** nslu2-log_ <nslu2-log_!> has joined #yocto02:01
*** ssajal <ssajal!> has joined #yocto02:04
*** nslu2-log <nslu2-log!> has quit IRC02:04
*** nslu2-log_ is now known as nslu2-log02:05
*** ssajal <ssajal!> has quit IRC02:13
*** ssajal <ssajal!> has joined #yocto02:37
*** nslu2-log_ <nslu2-log_!> has joined #yocto02:48
*** nslu2-log <nslu2-log!> has quit IRC02:51
*** nslu2-log_ is now known as nslu2-log02:51
*** nslu2-log_ <nslu2-log_!> has joined #yocto04:20
*** rewitt <rewitt!~rewitt@unaffiliated/rewitt> has quit IRC04:21
*** nslu2-log <nslu2-log!> has quit IRC04:21
*** nslu2-log_ is now known as nslu2-log04:22
*** nslu2-log_ <nslu2-log_!> has joined #yocto04:26
*** nslu2-log <nslu2-log!> has quit IRC04:29
*** nslu2-log_ is now known as nslu2-log04:30
*** rcoote <rcoote!> has joined #yocto04:53
*** dmoseley_ <dmoseley_!~dmoseley@> has quit IRC04:53
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto04:53
*** jobroe <jobroe!> has joined #yocto04:54
*** paulg <paulg!> has quit IRC04:57
*** nslu2-log_ <nslu2-log_!> has joined #yocto05:04
*** nslu2-log <nslu2-log!> has quit IRC05:06
*** nslu2-log_ is now known as nslu2-log05:06
*** pohly <pohly!> has joined #yocto05:15
*** beratiks <beratiks!52de0992@> has joined #yocto05:29
*** nslu2-log_ <nslu2-log_!> has joined #yocto05:32
*** AndersD <AndersD!> has joined #yocto05:34
*** nslu2-log <nslu2-log!> has quit IRC05:35
*** nslu2-log_ is now known as nslu2-log05:35
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC05:43
*** kroon <kroon!~kroon@> has joined #yocto05:44
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto05:44
*** kroon <kroon!~kroon@> has quit IRC05:47
*** kroon <kroon!~kroon@> has joined #yocto05:50
*** kroon <kroon!~kroon@> has quit IRC05:57
*** kroon <kroon!~kroon@> has joined #yocto05:59
*** agust <agust!> has joined #yocto06:08
*** sstiller <sstiller!> has joined #yocto06:30
*** lfa <lfa!> has joined #yocto06:32
*** frsc <frsc!> has joined #yocto06:33
*** nslu2-log <nslu2-log!> has quit IRC06:33
*** kroon <kroon!~kroon@> has quit IRC06:35
*** lfa <lfa!> has quit IRC06:37
*** kaspter <kaspter!~Instantbi@> has quit IRC06:38
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:38
*** kroon <kroon!~kroon@> has joined #yocto06:38
*** hpsy <hpsy!~hpsy@> has joined #yocto06:41
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:48
*** nslu2-log_ <nslu2-log_!> has joined #yocto06:52
*** eduardas <eduardas!~eduardas@> has joined #yocto06:55
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC06:55
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:55
*** nslu2-log_ is now known as nslu2-log06:55
*** mckoan|away is now known as mckoan06:56
*** nameclash <nameclash!> has joined #yocto06:57
*** NiksDev <NiksDev!~NiksDev@> has quit IRC06:58
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto06:59
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:59
*** AndersD <AndersD!> has quit IRC07:00
*** fl0v0 <fl0v0!~fvo@> has quit IRC07:00
*** gtristan_ <gtristan_!~tristanva@> has quit IRC07:01
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:01
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto07:04
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto07:05
*** Hauke <Hauke!> has quit IRC07:20
sstillerI have a .bbappend for a recipe (u-boot). I want to apply different patches depending on the built image. Is there a way to do it without using special local.conf files for different images?07:26
*** goliath <goliath!> has quit IRC07:27
kroonsstiller, not that I know of, packages are supposed to be independent of whatever image they are being installed to07:28
*** gtristan <gtristan!~tristanva@> has joined #yocto07:32
mihai-sstiller, you can use machine and distro overrides on SRC_URI, but image overriding is not possible afaik.07:38
*** Bunio_FH <Bunio_FH!> has joined #yocto07:40
*** Bunio_FH <Bunio_FH!> has quit IRC07:43
Letothe2ndsstiller: nope.07:44
Letothe2ndsstiller: applies07:45
Letothe2ndndec: so OSS+ELC+YPDD has been the final nudge for us to do an official slack now?07:47
RPLetothe2nd: we're doing an official slack?07:47
ndecLetothe2nd: it's official, not yet agreed/decided to make it long term.07:48
Letothe2ndRP: theyoctoprohect.slack.com07:48
ndecwe realized (late yesterday...) that many attendees for Dev Day wouldn't be able to use the LF/ELC slack, since they were not registered to ELC.07:48
ndecso we created this one as a backup for today's event.07:49
Letothe2ndndec: yeah the official was clar, jsut wondering if its ypdd-mostly/-only, or going to stay. on which i have somewhat mixed feelings.07:49
ndecit looks like the feedback is good about having a different (than IRC) communication channel. however there are concerns about using Slack (non free)07:50
ndecso maybe we will want to have another community channel, but maybe it won't be slack..07:50
RPndec: my concern is simpler, a fragmented community with people trying to handle two channels of communication07:50
RPits probably inevitable though07:51
ndecyes, this is a valid concern.. and we already have #yocto and #oe to some extends..07:51
*** nslu2-log <nslu2-log!> has quit IRC07:56
*** yann <yann!> has joined #yocto07:57
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:00
mihai-this seems like a new trend communities moving away from IRC, I don't get why thought, it's not like M$ bought freenode08:01
Letothe2ndmy pros: pretty comfortable, good user experience, high acceptance. my cons: fragmentation, non-free, one more channel to play.08:03
Letothe2ndlike i said, mixed feelings.08:03
kanavin_homedoes this slack require installing a closed source client?08:04
Letothe2ndkanavin_home: nope. closet source.08:05
Letothe2ndyou can also do with a web browser, though :)08:05
kanavin_homethen meh08:06
kanavin_homeopen source all the way or bust08:06
* Letothe2nd shrugs. pros and cons, as usual08:07
kroonis there any competition between different slack-clients ?08:08
Letothe2ndkanavin_home: chrome-crows vs. firefox-fanatics, mostly :)08:09
Letothe2ndkroon: ^^^^^08:09
Letothe2ndre: competition08:09
*** polaris- <polaris-!> has joined #yocto08:10
kroonyeah but why are you mentioning chrome and firefox ?08:10
Letothe2ndkroon: two browsers to run the slack client... (hint, i was not being *completely* serious)08:10
kroonok, so no competition at all then08:10
* kroon puts slack through the shredder08:11
Letothe2ndit all (R)DEPENDs on the criteria applied.08:13
RPThe trouble is there is a world of users out there who will never understand/use irc :/08:13
Letothe2ndRP: yup08:13
Letothe2ndactually i'm kind of leaning towards the reach/advocacy pov.08:14
qschulzkroon: weeslack :D ? (weechat plugin ^^)08:14
Letothe2ndqschulz: is that a thing?08:14
qschulzthere is such a plugin yes. Is that a thing? No idea, not using weechat yet :)08:16
Letothe2ndah, understood08:17
*** beratiks <beratiks!52de0992@> has quit IRC08:18
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC08:18
polaris-hi, "bitbake-layers show-appends" tells me that one of my recipes is "skipped". Is there a command/switch that could help me to figure out why it is skipped?08:22
Letothe2ndpolaris-: maybe because it doesn't append to anything? or it does have some COMPATIBLE set? (just guessing)08:23
qschulzLetothe2nd: you can't have a COMPATIBLE apply to only a bbappend IIRC08:25
Letothe2ndqschulz: i'm not sure also.08:25
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto08:26
polaris-Letothe2nd: It has an .bbappend which is also listed in the output of "show-appends". There is no COMPATIBLE set. The .bbappend is supposed to add a kernel option with a .cfg file.08:27
Letothe2ndpolaris-: can you put the bbappend on a pastebin?08:28
qschulzand probably the output of show-appends as well :)08:29
*** goliath <goliath!~goliath@> has joined #yocto08:29
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has quit IRC08:30
polaris-Letothe2nd: .bbappend:, show-appends:
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto08:30
polaris-Letothe2nd: the .bbappend used to work when I was using it with meta-raspberrypi. now I want to do the same in another context.08:33
Letothe2ndpolaris-: no idea right now, sorry.08:34
polaris-Letothe2nd: no problem, thanks for having a look!08:34
qschulzpolaris-: how are you specifying the kernel to build for your machine?08:40
qschulzDirectly giving linux-kp or using virtual/kernel and PREFFERRED_PROVIDER_virtual/kernel?08:41
polaris-qschulz: using PREFERRED_PROVIDER_virtual/kernel08:41
polaris-qschulz: in the BSP layer's machine directory.08:42
qschulzpolaris-: does this linux-kp actually support config fragemtns?08:43
qschulz(inherit yocto-kernel or linux-yocto or whatever it is called)08:43
*** Bunio_FH <Bunio_FH!> has joined #yocto08:45
polaris-qschulz: good questions ... the .bb file for linux-kp inherits kernel and includes linux-yocto.inc08:45
qschulzwait... that's actually useless info because the recipe is skipped08:45
qschulzso let's focus on that first08:45
polaris-qschulz: i was wondering already whether config fragments are supported when I use a defconfig file for the kernel.08:46
qschulzpolaris-: it depends (TM)08:46
*** ndec[m] <ndec[m]!ndecmatrix@gateway/shell/> has joined #yocto08:48
qschulzpolaris-: bitbake virtual/kernel -e | grep -e "^PREFERRED_PROVIDER_virtual/" ?08:48
polaris-qschulz: PREFERRED_PROVIDER_virtual/kernel="linux-kp"08:51
polaris-qschulz: I think there is a problem in my environment08:53
qschulzpolaris-: your environment shouldn't pollute your Yocto build by default... what is your thought process to say that? (may be true, just being curious)08:54
qschulzbitbake-layers show-recipes linux-kp? are there multiple ones?08:54
qschulzTry to build explicitly linux-kp (bitbake linux-kp) and Yocto will complain for what it thinks is a good reason I think08:55
polaris-qschulz: my thought process is that the recipe is not really skipped when I build the image, but show-appends thinks otherwise. there is only a single recipe.08:59
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:c862:e5c2:2a6c:5ccd> has quit IRC08:59
qschulzpolaris-: an image is built from a recipe and recipe data is local. So this shouldn't possibly happen (it was definitely not meant to if it does)09:04
qschulzpolaris-: bitbake linux-kp and let's see what happens (make sure you're using the correct machine and distro :) )09:05
*** xtron <xtron!~xtron@> has joined #yocto09:08
stacktrust_Learned yesterday about irccloud (paid not open), which has web/mobile client that unifies irc and slack09:09
*** yacar_ <yacar_!> has joined #yocto09:09
*** yacar_ <yacar_!> has joined #yocto09:10
polaris-qschulz: Not provided but now I understand my mistake. Lazy me provides the MACHINE directly (MACHINE=mymachine bitbake myimage) when running bitbake to build the image but I did not when running show-appends :(09:10
qschulzstacktrust_: if you're ok with companies owning your conversation logs.. :)09:10
qschulzpolaris-: hehehehe09:10
qschulza classic :) Everyone did that one at least once :)09:11
Letothe2ndqschulz: nope, me never.09:11
polaris-qschulz: at least I learned something :) thanks for helping!09:11
Letothe2ndi've done an awful lot of hilarious mistakes, but i've always believed in MACHIEN and DISTRO being set through local.conf09:11
* Letothe2nd feels mightily awesome now.09:12
Letothe2ndqschulz: well thats a bit of an unfair argument for most channels are publicly logged anyways.09:12
qschulzLetothe2nd: how do you swap between machines in automated builds? you just append to local.conf?09:12
Letothe2ndqschulz: separated builds altogether.09:13
qschulzLetothe2nd: not 1-to-1 :)09:13
Letothe2ndlike i said, "most channels" :)09:13
qschulz(and not private channels but yes, that was not totally fair of me)09:13
Letothe2ndeveil you!09:14
stacktrust_@qschulz I use Wire, so not generally ok with companies owning my conversation logs :)  But slack already owns all conversation logs on communities which insist on using slack AND the normal slack client prevents export of logs by non-admins, so I can't even have a copy of my conversations.  Irccloud lets users export their own messages, so I finally get access to my slack data, which can now be combined client-side09:15
stacktrust_with IRC data.09:15
Letothe2ndso as usual, it all depends (TM)09:17
qschulzstacktrust_: (I'll stop digressing from there but (and use Signal maybe :D ?))09:17
qschulz(I still use Whatsapp for some friends so me = none of the wiser)09:18
Letothe2ndwho needs wisdom if you can have a way to transport an endless stream of nonsense?09:23
stacktrust_@qschulz Historically, Signal required a copy of users contacts / social graph and a mobile phone number which is both mappable to national identity in many countries and real-time physical location via telco data brokers.  Wire requires only an email address and does not mandate contacts upload.  Different threat models.  More importantly, Wire is helping IETF development of MLS protocol (which will live alongside09:27
stacktrust_TLS) for E2E encryption of group messaging, currently the best candidate for everyone escaping chat silos with an open protocol that protects against modern threats.09:27
* Letothe2nd mentions Threema :)09:28
stacktrust_@Letothe2nd: all messaging companies should do this:
*** polaris- <polaris-!> has quit IRC09:49
*** polaris- <polaris-!> has joined #yocto09:51
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has quit IRC09:55
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto10:03
*** xtron <xtron!~xtron@> has quit IRC10:04
*** gtristan <gtristan!~tristanva@> has quit IRC10:18
*** kroon <kroon!~kroon@> has quit IRC10:26
*** kroon <kroon!~kroon@> has joined #yocto10:31
*** kroon <kroon!~kroon@> has quit IRC10:41
*** kroon <kroon!~kroon@> has joined #yocto10:45
*** gtristan <gtristan!~tristanva@> has joined #yocto10:58
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto11:03
*** NiksDev <NiksDev!~NiksDev@> has quit IRC11:12
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto11:13
*** xtron <xtron!~xtron@> has joined #yocto11:16
lukmaI do have a question regarding poky/meta/recipes-core/meta/buildtools-tarball.bb11:18
lukmaFrom my understanding it is for some machines, which cannot fulfill requirements for "supported" distros11:19
Letothe2ndlukma: bascially yes.11:19
lukmaand hence my question - why in this package there is only python3 installed ?11:19
lukmabut no python211:19
Letothe2ndlukma: because dunfell is py3 only?11:19
lukmaSo it is tuned for 3.1 ....11:20
lukmanot for _any_ (not anymore supported) version (like sumo for example) ?11:20
Letothe2ndwe know people love sumo, but see, its like... old... unsupported....11:20
lukmaYes...... but very often they love it because they have to :)11:21
lukmaKrogoth is also beloved one :)11:21
Letothe2ndso what do you expect now?11:22
lukmaNothing.... :)11:22
*** beratiks <beratiks!52de0992@> has joined #yocto11:22
Letothe2ndanother satisfied customer, next one!11:22
lukmaI was wondering why there was no python 211:22
lukmaLetothe2nd: But I'm satisfied11:22
Letothe2ndlukma: just what i said :)11:23
lukmaAnd I'm also _very_ happy that LTS version is planned11:23
qschulzlukma: even released ;)11:23
Letothe2nds/planned/in existence since Apr 2020/g11:24
lukmaThe time passes so fast :)11:24
*** xtron <xtron!~xtron@> has quit IRC11:28
*** xtron <xtron!~xtron@> has joined #yocto11:28
*** radsquirrel <radsquirrel!> has quit IRC11:35
*** radsquirrel <radsquirrel!> has joined #yocto11:36
*** rcoote <rcoote!> has quit IRC11:37
*** berton <berton!~berton@> has joined #yocto11:45
ndecLetothe2nd: lukma : buildtools-tarball has been with python3 since sumo! it has nothing to do with the switch from py2 to py3 in dunfell. it's the host (native) python, so it switched to python3 when bitbake switched to it.11:48
ndecsorry, since morty!11:49
*** rcoote <rcoote!> has joined #yocto11:49
Letothe2ndndec: ah interesting! thanks for the clarification. i thought dunfell was the first one to full by py3 for the host, but obviously i was wrong then.11:51
ndecin dunfell python2 recipes were removed from oe-core, and replace by python311:53
Letothe2ndndec: yup the last was clear11:54
Letothe2ndi thought this also was the time time when we finally got rid of py2 as host dependency11:55
*** dakhouya <dakhouya!d82e07b2@> has joined #yocto11:57
*** xtron1 <xtron1!~xtron@> has joined #yocto11:59
rburtonzeddii: can you lean on someone at xilinx to get added to the layer index12:00
*** xtron <xtron!~xtron@> has quit IRC12:01
lukmandec: Letothe2nd: On thud I do have a strange observation though - I do install hosttols: . /opt/poky/2.6.4/environment-setup-x86_64-pokysdk-linux , and then just setup envs for bitbake:12:02
lukma. ./poky/oe-init-build-env /work/yocto/centos/build/ and the strange thing is that PYTHONHOME is set to /opt/poky/2.6.4..../usr , which doesn't have python2 installed12:02
lukmaand of course python2 is installed on the host machine12:03
*** xtron1 <xtron1!~xtron@> has quit IRC12:04
*** paulg <paulg!> has joined #yocto12:05
*** xtron <xtron!~xtron@> has joined #yocto12:05
*** polaris- <polaris-!> has quit IRC12:15
Letothe2ndhalstead: i guess its no major problem if i just outright ignore the hands-on, right?12:17
*** xtron <xtron!~xtron@> has quit IRC12:18
halsteadLetothe2nd, No. But if you really won't follow along I can delete your server and save money for the project.12:18
Letothe2ndhalstead: please do so. need my conf number?12:18
halsteadLetothe2nd, No I know which is for you.12:19
Letothe2ndhalstead: awesome, thanks.12:19
Letothe2ndhalstead: (i'm just in for the social and "tradtition")12:19
halsteadThanks for letting me know.12:21
*** xtron <xtron!~xtron@> has joined #yocto12:31
*** dakhouya <dakhouya!d82e07b2@> has quit IRC12:37
zeddiirburton: I can do that. yes.12:45
*** maudat <maudat!> has joined #yocto12:45
*** AndersD <AndersD!> has joined #yocto12:50
*** beratiks <beratiks!52de0992@> has quit IRC12:51
rburtonzeddii: also is it dead?
zeddiiI'm checking that with the guys that hack on it.12:52
zeddiito see if they have another one somewhere else.12:52
zeddiiThe first line of my email: Is the meta-openamp layer here: Still active / the latest and greatest ?"12:52
rburtoninactive for nearly 18 months12:53
fullstopInteresting effect of going from 3.0 -> 3.1, my image shrank a few megabytes.  :-)12:53
zeddiiyah. that's the same amount of time I've been @ Xilinx, maybe I killed it ?12:53
rburtonzeddii: the curse of zedd12:53
zeddiibut they are still running / building / using it with OE, so I'm betting there is something hiding out. but anyway, I'll sort out what's what.12:54
rburtonnever heard of this before but a colleague was wondering how to make it work12:54
zeddiiIt can do some interesting things. The config side isn't trivial, but one of my non-yocto things I do is writing some tools to make it easier to configure it. If I raise the right people and you see sustained interest, we can put the right folks together.12:55
Letothe2ndrburton: "that" == openamp?12:56
Letothe2nduh huh12:57
*** ericch <ericch!> has joined #yocto13:08
*** sstiller <sstiller!> has quit IRC13:13
*** jobroe <jobroe!> has quit IRC13:21
*** kroon <kroon!~kroon@> has quit IRC13:25
*** rcw <rcw!> has joined #yocto13:31
yannI'm trying to understand spurious rebuilds, but I'm having trouble finding reference sigdata : when I'm building an image from sstate, the only sigdata files are those for the image tasks really run, and only do_rm_work.sigdata for all packages fetched from sstate13:36
yannhow can I understand why it wants to rebuild stuff, in this case ?13:37
*** dreyna <dreyna!> has joined #yocto13:37
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:42
JPEWHah, nevermind. Perl looks to be doing the right thing for cross compiling.... I just didn't understand what it was doing13:44
yannthe doc mentions that tasks from sstate should have a .siginfo file, but there are none13:46
*** AndersD <AndersD!> has quit IRC13:46
JPEWyann: Where are you looking?13:56
yannJPEW: in build/tmp/stamps/13:57
*** sgw <sgw!~sgw@> has joined #yocto13:57
qschulzI **think** they aren't recreated if the task isn't re-run (i.e. if you clean your tmpdir/builddir and then re-run from sstate, you won't get the sigdata/siginfo)... Definitely not sure but remember not having all sigdata when debugging once13:58
RPyann: the files may be in the sstate directory?13:59
*** gtristan <gtristan!~tristanva@> has quit IRC14:05
yannwouldn't it make sense to have them copied into stamps/ so diffsigs can find them ?14:07
yannespecially as the sstate can grow to have many of them, right ?14:07
RPyann: some do get copied but the ones for intermediate tasks may not be14:12
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto14:12
yannwouldn't it make sense to do so ?14:12
RPyann: well, which ones should XXX_do_package copy in? do_fetch? do_unpack? do_fetch of other tasks in DEPENDS?14:13
RPIts not such a simple thing14:13
RPThe tools are meant to look into the sstate cache to find things but they don't work so well :/14:14
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC14:14
yannI'd think it should copy all those that would have been created if the built did not use a sstate14:14
RPyann: That would be ideal, as I said, its not that simple sadly14:15
yannit works badly especially when we're trying to understand why they don't make use of the sstate :}14:15
RPyann: I know it does. I wish I could find time to make it better, makes me sad :/14:16
RPyann: A tip - run "bitbake X -S none" and it should generate all the sig files you need14:18
khemYP Dev day livestream if you are not registered can view the live proceedings14:18
yannRP: yeah, that was what I was after, I had run that for tests but did not realize it can get me those in the ref tree, thx much!14:20
qschulzkhem: <314:23
*** eduardas <eduardas!~eduardas@> has quit IRC14:34
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto14:34
*** goliath <goliath!~goliath@> has quit IRC14:34
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC14:37
*** ibinderwolf <ibinderwolf!> has quit IRC14:50
yannok, so I have do_configure sigdata apparently differing only by quilt/ - but diffsigs on those gives an empty output, what am I missing ?14:55
*** davidinux <davidinux!~davidinux@> has joined #yocto14:57
JPEWyann: quilt-native:do_configure ?14:58
JPEWyann: What version?15:00
yanndunfell 3.1.015:00
yannthere are some differences between the build tree generating the sstate and the build tree reusing it (one layer, but with nothing wicked, worked perfectly in sumo, possibly in warrior too though I did not test warrior much)15:01
*** Bunio_FH <Bunio_FH!> has quit IRC15:03
JPEWyann: Are you using poky?15:03
JPEWyann: Or better yet, do you have hash equivalence enabled?15:04
JPEWRP: Will "bitbake X -S none" take into account hash equiv ?15:04
yannnot directly poky, but I copied quite a bit of it into our distro (and updated the dunfell bits)15:05
yannand yes, I left hash equivalence enabled15:06
JPEWyann: OK, my suspicion is that bitbake -S none doesn't take into account equivalent hashes (the do_deploy_source_date_epoch are almost always marked as equivalent since they are just a timestamp file that almost never changes)15:07
RPJPEW: Its hard for bitbake to know what to do in some of these cases :/15:08
JPEWRP: Agreed15:08
JPEWyann: I *think* that the difference you're seeing isn't "real"15:08
JPEWe.g. bitbake-diffsigs reports it, but it might not actually re-execute?15:09
*** berton_ <berton_!~berton@> has joined #yocto15:09
JPEWbecause, the thing your diffing against didn't use equivalent hashes.... at least this is my theory15:09
*** NiksDev <NiksDev!~NiksDev@> has quit IRC15:10
RPyann: do these two builds your're compaing use the same sstate but different hash equiv server?15:10
*** mihai-- <mihai--!~mihai@unaffiliated/mihai> has joined #yocto15:11
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto15:11
*** davidinux <davidinux!~davidinux@> has quit IRC15:11
*** m1ster_r- <m1ster_r-!> has joined #yocto15:12
*** tgamblin_ <tgamblin_!> has joined #yocto15:12
*** georgem_ <georgem_!~georgem@> has joined #yocto15:12
*** camus1 <camus1!~Instantbi@> has joined #yocto15:13
*** weltling_ <weltling_!> has joined #yocto15:13
Letothe2nddl9pf: AGREED!15:13
*** Emantor_ <Emantor_!> has joined #yocto15:13
*** davidinux <davidinux!~davidinux@> has joined #yocto15:13
*** berton <berton!~berton@> has quit IRC15:14
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC15:14
*** weltling <weltling!> has quit IRC15:14
*** anoo1 <anoo1!~anoo1@> has quit IRC15:14
*** mattsm_ <mattsm_!> has joined #yocto15:14
*** mattsm <mattsm!> has quit IRC15:14
*** thaytan <thaytan!> has quit IRC15:14
*** m1ster_r0b0t <m1ster_r0b0t!> has quit IRC15:14
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC15:14
*** kaspter <kaspter!~Instantbi@> has quit IRC15:14
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC15:14
*** lukma <lukma!> has quit IRC15:14
*** Emantor <Emantor!> has quit IRC15:14
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto15:14
*** thaytan <thaytan!> has joined #yocto15:14
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC15:14
*** mrpelotazo <mrpelotazo!> has quit IRC15:14
*** tlwoerner <tlwoerner!~Trevor@> has joined #yocto15:14
*** JaMa <JaMa!~martin@> has quit IRC15:14
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC15:14
*** tlwoerner <tlwoerner!~Trevor@> has quit IRC15:14
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto15:14
*** camus1 is now known as kaspter15:14
*** sgw <sgw!~sgw@> has quit IRC15:14
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto15:14
*** tgamblin <tgamblin!> has quit IRC15:14
*** mattsm_ <mattsm_!> has quit IRC15:14
*** mrpelotazo <mrpelotazo!~mrpelotaz@> has joined #yocto15:15
*** georgem__ <georgem__!~georgem@> has quit IRC15:15
*** lukma <lukma!> has joined #yocto15:15
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto15:15
*** anoo1 <anoo1!~anoo1@> has joined #yocto15:15
*** sgw1 <sgw1!sgw@nat/intel/x-ozxhxlaxwlhgpjxy> has joined #yocto15:16
*** JaMa <JaMa!~martin@> has joined #yocto15:16
yannRP: I guess so, as they are running from their own separate build dirs15:18
yannwith auto-spawned hash equiv servers, I guess15:19
*** davidinux <davidinux!~davidinux@> has quit IRC15:19
RPyann: that will be the problem then15:19
RP(assuming I understand the issue correctly, I haven;t read all the scroll back)15:20
yannhm, but why would the hashequiv situation be worse than without hashequiv ?  shouldn't it only be able to improve on the latter ?15:22
JPEWyann: It's looking for sstate objects that don't exist15:22
JPEWyann: Or more correctly, hashequiv is telling it to use sstate objects that might not exist15:23
RPyann: the builds can't see what equivalences the other build picked, therefore they chose different hashes15:23
yannbut the 2nd build reuses the 1st sstate, where would those "that might not exit" live ?15:24
JPEWyann: Sorry I was wrong I think15:24
JPEWI was thinking of the other direction where you have two sstate and one hashequiv server15:24
JPEWHmm, I think there is a hole in archiver.bbclass... it handles recipes that are the source of shared source (e.g. gcc-source), but not the recipes that consume it... and for some reason now the recipes that consume it erase the shared source when then run do_unpack_and_patch15:30
yannhm, but quilt-native is not in that case, or is it ?15:31
RPJPEW: I worry your task dependency changes there break things somehow :/15:32
JPEWRP: Yes, I think they are the culprit for some reason.... Can't quite sort out *why* though15:33
RPyann: If build A decides hashes X and Y are equivalent, build B can't know. If will therefore try and build something rather than reuse from sstate15:33
yannbut on what would build A make a decision that build B would not be able to make itself ?15:34
RPyann: build A would have made two builds which it could compare the output of15:34
yannhm, that means that build A would have done an extra rebuild at one point, noticed the equivalence, nuked the extra build artifacts as a result - and that build B has to do the same extra build to make the same decision ?15:37
RPyann: yes15:37
yannso the question would be, why did it need to make a second build in the first place.  That's what diffsigs between the sstate version and the build B version ought to show, right ?15:39
JPEWyann: I *just* made a video of describing hash equiv basics:
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC15:39
RPyann: bottom line is that if you're trying to share sstate between two machines with hashequiv enabled, you need to have a common hashequiv server15:41
RPyann: if you don't, it will sometimes match, sometimes not depending on what eaxctly gets run on the different machines and whether the hash equiv database is preserved or not15:42
yannthat means any users of the sstate must have access to the hashequiv server, right ?15:42
RPyann: currently, yes. There is a proposed read only mode we'd like to add too15:43
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto15:46
*** hpsy <hpsy!~hpsy@> has quit IRC15:57
*** sgw2 <sgw2!> has joined #yocto16:00
*** gtristan <gtristan!~tristanva@> has joined #yocto16:01
*** sgw2 is now known as sgw_16:01
*** xtron <xtron!~xtron@> has quit IRC16:03
yannok, that sounds like I should disable it for now - but then let's be back to the reason of the rebuild that got recorded in build A: I should see it with diffsigs between the sstate version and the build B version, right ?16:03
*** stephano <stephano!> has joined #yocto16:04
*** xtron <xtron!~xtron@> has joined #yocto16:04
*** NiksDev <NiksDev!~NiksDev@> has quit IRC16:04
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto16:04
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:05
yannthe idea of read-only equiv database seems nice - I guess it would be nice to have it stored in the sstate tree, since they are so intricately linked.  Maybe used automatically from all SSTATE_MIRRORS ?16:05
RPyann: I'd start by disabling hashequiv and then seeing if you get the rebuilds you expect/don't expect and go from there16:08
RPyann: sharing a database over http isn't straightforward :/16:08
*** xtron <xtron!~xtron@> has quit IRC16:09
*** pharaon2502 <pharaon2502!> has quit IRC16:12
yannbasically, all this also means we have to maintain one hashequiv server for each and every sstate - that's still quite inconvenient.  Eg. I use a new sstate when updating the toolchain causes major archive rebuild (I understand hashequiv will help with some of these, but likely not all)16:12
yannthat's where it becomes impractical: using a separate sstate is trivial, adding a new hashequiv server is not that trivial, infrastructure-wise16:13
*** sgw_ <sgw_!> has left #yocto16:13
*** sgw2 <sgw2!> has joined #yocto16:14
*** sgw2 is now known as sgw_16:14
yannRP: it's likely that switching hashequiv off won't help understand why _past_ rebuilds were triggered16:16
JPEWyann: Yes, hashequiv needs some more work to cover some of these cases16:20
*** comptroller <comptroller!> has quit IRC16:20
*** comptroller <comptroller!> has joined #yocto16:21
*** fury <fury!uid193779@gateway/web/> has quit IRC16:22
*** mckoan is now known as mckoan|away16:22
yannWe also use separate sstates (nearly throwaway) for WIP branches, so we can still benefit from the CI, while not poluting the official shared ones16:24
JPEWRP: OK, so without my changes to archiver.bbclass the gcc recipes still erase the shares source... I think my change fixed the race, which exposed this problem16:26
JPEWyann: Ya, it sounds like you're in the (common) situation where CI populates sstate and your developers consume it read-only.... you want a read-only option for hash equiv in that case16:27
*** dmoseley <dmoseley!~dmoseley@> has quit IRC16:27
qschulzIf I could just add a +1 on that feature request (if that fixes the issue), because I was thinking of doing more or less the same (sstate-mirror via HTTP so RO for master branch only). I'm happy at least to discover now before deciding to upgrade Yocto and get the hashequiv feature16:29
yannJPEW: yes, and since the sstate can be reused offline, it would be good to get this RO hashequiv db to work offline too16:29
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto16:30
yannqschulz: so no, in my case RO HTTP would not be enough16:30
*** [Sno] <[Sno]!> has quit IRC16:30
yann(it's been long since I last worked in the train, but still)16:30
JPEWyann: Ya, I think maybe in that case you'd want some sort of multi-level server in that case where you'd have a local server that could (optionally) defer to the remote one16:30
RPyann: you can use different namespaces within a single hashequiv server for that same effect FWIW16:30
yannRP: ah, that's nice then16:31
yannbut then, when throwing away a given sstate, we need to throw away the matching namespace16:32
*** sno <sno!> has joined #yocto16:32
yannwhich advocates for colocation of the data16:32
RPyann: if you can show us how to make a performant database that works over a straight http mirror...16:33
RPyann: I don't know how to do that, the namespaces thing does at least get you close and extra names would just bloat the database a bit16:33
yannRP: I thought it was a problem ot have db entries refering to absent sstate entries ?16:34
RPyann: no, won't matter16:34
yannso if the equiv server says "take xxx it's equivalent" and "xxx" is part of a thrown away sstate, what's to happen ?16:35
RPit will add the xxx object to the sstate16:36
RP(build and add)16:36
yannsay I have worked in a throwaway sstate for sometime, and the final version built there is OK.  I nuke the sstate (to be reused, I dont use throwaway sstate names), push to master, get the official sstate populated with a rebuild.  Next dev iteration will not want to inherit the equiv db for the previous one, as it will match master to old removed sstates16:40
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:42
yannI fear it's bad idea not to bundle hashequivdb with sstate16:44
*** nslu2-log <nslu2-log!> has joined #yocto16:45
RPyann: why would it matter?16:45
RPit really doesn't matter which hash anything resolves to16:46
RPwith the namespacing it wouldn't even get seen/used if not selected16:46
RPand even with one namespace it doesn't matter16:46
RPIt was designed so this isn't an issue16:46
yannremote access to a RO db could be emulated by fetching the sqlite db using HTTP, and sync'd as necessary (it should not change too often, and is small, right ?  rsync would be better than http here, but hey)16:47
yannRP: maybe I misunderstood something then16:47
yannto not be seen it would require the namespace not being reused, which is the basic reason to throw it away in the first place to avoid accidents16:48
yannsee JPEW's slides at 00:13:24 : "sever should be maintained with sstate, otherwise could report hashes that do not exist" - relieved I did not invent it :)16:51
JPEWyann: Ya I probably should have been a little more specific... it works when that happens, it's just not optimal (since it will rebuild)16:52
JPEWThere are a few ways of acheiving that (namespacing, multiple servers, etc)16:52
RPyann: the YP hashequiv database on our autobuilder is about 6GB of sqlite.16:55
RPyann: what kind of accidents are you avoding though?16:55
RPyann: If the hash doesn't exist in the sstate it will be created. I don't see that as a problem?16:56
*** nslu2-log <nslu2-log!> has quit IRC16:56
*** Hauke <Hauke!> has joined #yocto16:59
*** Hauke <Hauke!> has quit IRC17:01
*** yann|work <yann|work!> has joined #yocto17:05
*** yann <yann!> has quit IRC17:06
*** hpsy <hpsy!~hpsy@> has joined #yocto17:13
*** hard2b <hard2b!~hard2btru@> has joined #yocto17:17
*** yann|work <yann|work!> has quit IRC17:19
*** yann|work <yann|work!> has joined #yocto17:19
*** yann|work is now known as yann17:19
*** berton_ <berton_!~berton@> has quit IRC17:25
*** matthewzmd <matthewzmd!> has joined #yocto17:29
*** dmoseley <dmoseley!~dmoseley@> has quit IRC17:33
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC17:35
*** frsc <frsc!> has quit IRC17:38
PaowZhi there ! Inheriting from core-image, what would be the packages to add in order to get an available X server ? No matchbox and stuff.. I read in users guide that should be packagegroup-core-x11-xserver, but no X process so far.. ?17:38
*** pharaon2502 <pharaon2502!> has joined #yocto17:41
*** dmoseley <dmoseley!~dmoseley@> has quit IRC17:44
*** Hauke <Hauke!> has joined #yocto17:46
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:49
*** nerdboy <nerdboy!~sarnold@> has joined #yocto17:55
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:55
*** stephano <stephano!> has quit IRC18:01
*** hpsy <hpsy!~hpsy@> has quit IRC18:02
*** hpsy <hpsy!~hpsy@> has joined #yocto18:02
zeddiiRP: I'm not sure how I missed the Module.symvers patch, but what we have in the tree doesn't look right.18:06
zeddiiand now, it seems to have gone back to dunfell as well.18:07
zeddiioh wait, not yet to dunfell18:07
RPzeddii: hmm, I thought you'd seen it :/18:07
zeddiiI followed up to the dunfell pull request and recommend against it.18:08
zeddiilooking into it more now.18:08
zeddiioh wow. and it's also in the Zeus pull request.18:09
RPzeddii: I was wondering how it gets to zeus without dunfell :/18:10
zeddiithat "fixes" the problem, by ignoring it.18:10
zeddiiseriously, they moved the generation of Module.symvers to the module build phase18:10
zeddiiwe copy it to the shared workdir before building modules18:10
zeddiithe "fix" is to test for the file and not copy it18:10
zeddiiwhich isn't really great if you *want* it in 5.8+18:10
zeddiiI'm working on linux-yocto-dev and the next ref kernel, so I'm only getting to see the issue now.18:11
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC18:11
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto18:12
*** hpsy <hpsy!~hpsy@> has quit IRC18:12
RPzeddii: it is in deunfell :(18:15
RPsakoman: looks like we have a problem...18:16
zeddiibugger. I'll revert the change, and move the task to after the module build. I don't see why we can't do the shared workdir after that, the module build doesn't need it, but will confirm after some tests.18:16
sakomanRP: yes, just read the list email18:17
*** wallthar <wallthar!> has joined #yocto18:19
zeddiiat some point fixing up newer kernel builds on the LTS falls into the category of supporting new distros, we'll know when the pain becomes to high :D18:20
zeddiiIf I hadn't been squashing some other issues, I would have gotten to 5.8 first and could have preempted it. oh well.18:21
sakomanI'm glad you caught it18:21
zeddiihmm. well, the module build does do a 2nd copy. so actually, we are probably ok.18:22
zeddiiI'll follow up, we are probably ok, but we should have had a comment there. so cancel the emergency this time. I'd say let it ride.18:22
zeddiiI mean, there's a really odd corner case if something is looking for the file and not building modules or in between the two tasks. but I'd react to that when I see it :P18:29
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto18:30
RPzeddii: ok, glad its not as bad as first thought18:32
RPzeddii: I have someone privately emailing me asking for a load more tweaks like that fwiw18:32
*** wallthar <wallthar!> has quit IRC18:32
zeddiiright. my first pass through the build didn't pickup the 2nd copy. I had forgotten about it.18:32
paulgalways loved the back channel requests for oddball shit.18:41
paulgmaybe if you are afraid to let your request see the sunshine of day, then that is a clue as to how appropriate/viable it is.....18:42
*** matthewzmd` <matthewzmd`!> has joined #yocto18:49
*** matthewzmd <matthewzmd!> has quit IRC18:50
*** matthewzmd` is now known as matthewzmd18:50
*** dmoseley <dmoseley!~dmoseley@> has quit IRC18:51
*** Ryan5 <Ryan5!345f0418@> has joined #yocto18:56
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:57
*** matthewzmd <matthewzmd!> has quit IRC19:01
*** matthewzmd <matthewzmd!> has joined #yocto19:02
RPpaulg: I've sent it to zeddii :)19:03
paulgRP, wise - that is what I always tried to do for the last 15+ years.   ;)19:03
*** sathish25071992 <sathish25071992!6ac6269f@> has joined #yocto19:06
sathish25071992Hi All. In a multiconfig, can there be a target recipe common between both the config? I have a multiconfig which has 2 armv5 based configs. Both shares same packages except for some. So when I build I get error saying "do_package_qa_setscene: Package already staged". What am I doing wrong? Thank you19:14
*** mihai-- is now known as mihai19:22
*** Ryan5 <Ryan5!345f0418@> has left #yocto19:24
*** matthewzmd <matthewzmd!> has left #yocto19:27
*** hipr_C <hipr_C!Thunderbir@gateway/vpn/nordvpn/hiprc/x-57922908> has quit IRC19:35
*** NiksDev <NiksDev!~NiksDev@> has quit IRC19:39
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto19:40
*** matthewzmd <matthewzmd!> has joined #yocto19:44
*** another_qwerty <another_qwerty!> has joined #yocto19:46
*** another_qwerty <another_qwerty!> has quit IRC19:52
*** pharaon2502 <pharaon2502!> has quit IRC19:55
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:00
*** rcoote <rcoote!> has quit IRC20:06
*** sathish25071992 <sathish25071992!6ac6269f@> has quit IRC20:08
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:12
*** stephano <stephano!> has joined #yocto20:22
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC20:23
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto20:23
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC20:26
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto20:27
* matthewzmd is trying to write an emacs recipe, but can't even get past do_configure20:49
smurrayemacs used to do some odd things in its build, that might be interesting20:51
*** matthewzmd <matthewzmd!> has quit IRC20:54
*** matthewzmd <matthewzmd!> has joined #yocto20:54
kergothugh, what the hell. screw it, i'm prototyping a new external toolchain implementation20:54
matthewzmdit generated a 6000-line config.log full of weird errors20:55
matthewzmdlooking at the 3-years-old demolished and don't help so much20:57
smurraymatthewzmd: I suspect that there isn't a current recipe for it suggests it's painful to keep working20:58
*** matthewzmd <matthewzmd!> has quit IRC21:02
*** matthewzmd <matthewzmd!> has joined #yocto21:02
smurraymatthewzmd: it's been a while since I tried vile, but the recipe for it was what one of my previous customers used to make emacs-users happy21:05
smurraymatthewzmd: sorry, zile, recipe is in meta-oe21:06
*** splatch <splatch!~splatch@> has joined #yocto21:07
splatchgood evening (for europeans!) :-)21:07
splatchI took the invite from tutorials seriously and come to say hello, thanks for awesome job and .. surprise something doesn't work21:08
*** fury <fury!uid193779@gateway/web/> has joined #yocto21:09
splatchso what I am stuck upon is quite basic, I've got BSP which is inteli7, however I do want to run image locally. I insisted on qemu as I have it on my PC, but I fail to build working setup. Part of problem is probably the partition layout (?) for swu, however I could not confirm that. I made a build via "MACHINE=qemux86-64 bitbake my-core-image" but it fails at do_image_wic due to missing grubenv file. How21:14
splatchdoes the machine change that?21:14
splatchI did not even reach the runqemu, cause image blew up21:15
*** pohly <pohly!> has quit IRC21:15
smurraysplatch: does it work with e.g. core-image-minimal?21:16
splatchthe build which produces intel-corei7-64 does, the stage I am is where I need to speed up test cycle to do more try-catch attempts21:18
splatchthe env I have is set up via kas-docker so I do not run poky on the host, but in the sandbox21:18
splatch[yocto 2.7.4/warrior]21:19
smurraysplatch: I assume you're using meta-intel, it's possible it's tweaking something that breaks that for qemux86-64.  Might be worth trying building for qemux86-64 w/o meta-intel in bblayers.conf to see if that's the case21:20
splatchall right, indeed I have it there and it takes ages to complete download of that part on my country side s** wifi21:20
*** maudat <maudat!> has quit IRC21:21
splatchsmurray: your advice resonates with me more than you think :)21:21
*** maudat <maudat!~moda@> has joined #yocto21:21
smurraysplatch: meta-intel is a reasonably well-behaved BSP layer, but anything's possible21:21
*** matthewzmd <matthewzmd!> has quit IRC21:26
*** matthewzmd <matthewzmd!> has joined #yocto21:26
splatchsmurray: all examples I've found so far with qemu are single partition, is it possible to get it running with second partition? [asking dump question as I'm not an qemu user]21:27
splatch[regular one]21:27
splatchI mean - runqemu itself, I guess with some gymnastics and two days of stackoverflow I would get qemu switches all in place21:28
smurraysplatch: it's definitely possible when running qemu by hand, I'm not sure with runqemu21:28
splatchok, will try getting qemu running first and then worry about /data :)21:29
smurraysplatch: there are some variables for adding options into the generated conf file used by runqemu, so that might be an option21:29
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto21:31
splatchfair enough, I got further - I have an override for linux-intel in my bsp. Is there a way to disable a recipe-xyx at some higher layer?21:32
JPEWsplatch: I run qemu with multiple partitions, the trick is to use wic to generate a complete disk image21:33
splatchI start to see that all these recipe-xyz names are not accidental cause they get processed somehow :)21:33
smurraysplatch: i.e. have the recipe not visible?  BBMASK is one option for that21:33
splatchJPEW: that's awesome news, I have wic images so all I need is to make the build pass :)21:33
splatchok, I've got build further.. so now its matter of time travel to get dependencies21:38
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto21:40
splatchI have one question which is more related to downloads - I do have very slow internet and sometimes for me it is faster to rsync files from ci/cd server, yet I see that these gets ignored even if I create ".done" file. I know that I probably tried to cheat the tool, but is there a better way for making it quick?21:42
splatchNot sure how the mirror logic works but I've got crazy ETAs for bigger dependencies counted in hours when rsync took me bit over 5 minutes21:43
smurrayhrm, I've done roughly that before, if the file is in the DL_DIR and matches the expected checksum I'd expect it to work21:45
smurraythe other option would be to rsync the things you need into a directory, then set that up as a local download mirror21:45
*** ykrons_ <ykrons_!~guillaume@> has quit IRC21:45
splatchok, I've seen one of the options in best practices21:46
splatchI'll check checksums cause I see ie yocto git mirror downloaded again21:46
smurraysplatch: see
*** matthewzmd <matthewzmd!> has left #yocto21:47
*** matthewzmd <matthewzmd!> has joined #yocto21:47
splatchI'm now on ci/cd where all downloads are, seems meta-intel is not to blame but something else in my bsp21:51
splatchso that's what blew up
*** maudat <maudat!~moda@> has quit IRC21:55
splatchJPEW: my bsp has the reipes-grub/grub/grub-efi, which bootloader/launch do you get with your qemu/wic?21:57
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC21:58
JPEWu-boot :)22:04
JPEWBut, I don't think you would have to do that22:05
splatchlooking at bsp files, I do have some patches messing around grubenv, I think that's the cause22:11
* splatch pretends to know what he is doing ;-)22:12
*** agust <agust!> has quit IRC22:12
splatchJPEW: so I got the build, it looks fine cause there is wic.bmap and wic.gz files, how do you plug these into qemu?22:15
*** dv|2 <dv|2!~dv@> has quit IRC22:17
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC22:17
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC22:20
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto22:24
* JPEW looks...22:32
JPEWsplatch: I think you want just the bare .wks file22:33
splatchif I find one, is that additional image output?22:33
JPEWsplatch: Not quite sure what you mean, it would be with the others22:34
JPEWi.e. core-image-minimal-qemux86.wks22:34
JPEWOh, wait sorry22:34
JPEWI'm wrong22:34
splatchJPEW: I was trying to get some other formats (ie virtualbox vmdk), but it didn't help. But I at least learned there are configurable image formats :)22:35
JPEWadd IMAGE_FSTYPES += "wic.qcow2"22:35
splatchok, doing test :)22:36
JPEWAnd also QB_DEFAULT_FSTYPE = "wic.qcow2"22:36
JPEWthen runqemu should do the correct thing by default... I think22:36
JPEWAnyway I have to go. Good luck!22:37
splatchJPEW: thanks for your time and insights, have fun!22:37
*** ericch <ericch!> has quit IRC23:07
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:14
*** weltling_ is now known as weltling23:20
*** dmoseley <dmoseley!~dmoseley@> has quit IRC23:24
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto23:26
*** yacar_ <yacar_!> has quit IRC23:30
*** stephano <stephano!> has quit IRC23:36
*** otavio <otavio!~otavio@> has joined #yocto23:44
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto23:44
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC23:45
*** JaMa <JaMa!~martin@> has quit IRC23:54

Generated by 2.17.2 by Marius Gedminas - find it at!