LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
demirok has quit [Quit: WeeChat 3.8]
demirok has joined #yocto
otavio has quit [Remote host closed the connection]
qschulz_ has quit [Remote host closed the connection]
qschulz has joined #yocto
sakoman has quit [Quit: Leaving.]
zelgomer has quit [Ping timeout: 240 seconds]
zelgomer has joined #yocto
marc1 has quit [Ping timeout: 272 seconds]
marc1 has joined #yocto
mason has quit [Quit: leaving]
mason has joined #yocto
starblue3 has quit [Ping timeout: 245 seconds]
starblue3 has joined #yocto
sakoman has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #yocto
_whitelogger has joined #yocto
Ablu__ has quit [Changing host]
Ablu__ has joined #yocto
Ablu has joined #yocto
sakoman has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
sakoman has quit [Ping timeout: 264 seconds]
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
npcomp has quit [Ping timeout: 255 seconds]
rob_w has joined #yocto
npcomp has joined #yocto
fray has quit [Remote host closed the connection]
frieder has joined #yocto
mckoan|away is now known as mckoan
Schlumpf has joined #yocto
goliath has joined #yocto
alessioigor has joined #yocto
rfuentess has joined #yocto
Yash84 has joined #yocto
Guest14 has joined #yocto
JerryM has joined #yocto
Kubu_work has joined #yocto
diamondman__ has quit [Ping timeout: 258 seconds]
diamondman__ has joined #yocto
zpfvo has joined #yocto
florian has joined #yocto
prabhakarlad has joined #yocto
florian has quit [Ping timeout: 252 seconds]
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
mvlad has joined #yocto
camus1 is now known as camus
gsalazar has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Guest14 has quit [Quit: Client closed]
florian_kc is now known as florian
zeddii has quit [Ping timeout: 240 seconds]
zeddii has joined #yocto
Yash84 has quit [Quit: Client closed]
leon-anavi has joined #yocto
Schlumpf has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Dracos-Carazza_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
<JerryM> I haven't tried it, but can sstate handle different versions? e.g. kirkstone and dunfell?
<rburton> yes
<rburton> the autobuilder builds 8 machines for four distros across three releases using the same sstate
<rburton> slide 4 or something of Why Is My Build So Slow: _always_ share sstate. There's no technical reason why you can't share sstate.
<JerryM> ah good, I do remember seeing that talk, but that part must've slipped my mind, so thanks for the remimder
prabhakarlad has quit [Quit: Client closed]
<KanjiMonster> while sstate can, tmpdir can't (you'll get a version complaint when trying to share between kirkstone and dunfell)
ptsneves has joined #yocto
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #yocto
GillesM has quit [Quit: Leaving]
GillesM has joined #yocto
GillesMM has joined #yocto
GillesMM has quit [Client Quit]
manuel1985 has joined #yocto
<manuel1985> Hi fellow Yoctonians! I'd like to add a recipe that provides a tool used to build another package. Is there something to take care of? Is the use of native.bbclass and '-native' suffix in the recipe customary or mandatory?
<TRO[m]> #AWS #CDK version of #buildbot for #Yocto #linux - might be interesting for more people.
<TRO[m]> We use it to test meta-aws with all supported releases and archs. (With shared SSTATE, polling changes of remote repos, kvm enabled testimage...)
destmaster84 has joined #yocto
<Ablu> manuel1985: If you only ever use it as build tool for other packages then yes. https://docs.yoctoproject.org/singleindex.html#native describes the two options. If the package may also make sense to install as a target then you can follow the second method.
<rburton> manuel1985: if you inherit native and don't call the recipe -native then you're just asking to confuse people
<rburton> you _need_ to inherit native to build native code
Kubu_work has quit [Quit: Leaving.]
Guest62 has joined #yocto
<Guest62> hello
<Guest62> was wondering if anyone knows if there is already an existing recipe for libtorchtrt and co somewhere  ...
<rburton> unless the recipe name would be different
<rburton> guess thats pytorch
<rburton> that's a "challenge" to build
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
Zaid has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
destmaster84 has quit [Quit: Client closed]
destmaster84 has joined #yocto
destmaster84 has quit [Client Quit]
zelgomer has quit [Ping timeout: 240 seconds]
zelgomer has joined #yocto
<mckoan> what could be a lightweight browser alternative to chromium to be used with Yocto ?
Guest82 has joined #yocto
<manuel1985> rburton: Thanks for the advice provided above
jetm has joined #yocto
<manuel1985> Ablu too
<RP> TRO[m]: We've often wondered what implementing an autobuilder on AWS infrastructure would look like but we don't have the money to be able to run such a thing!
philmd has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 245 seconds]
philmd has quit [Read error: Connection reset by peer]
jetm has quit [Read error: Connection reset by peer]
vladest has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<Guest82> Hello, I have a NodeJs project that I would like to include in my image. I am on Kirkstone and building linux-fslc-imx for an i.mx8 target.
<Guest82> I have used devtool to create the recipe for me.
<Guest82> Now I'm facing an issue where one of the dependency npm packages "leveldown" is failing in the do_package step, for example:
<Guest82> ERROR: backend-1.0.0+gitAUTOINC+b46ad989d4-r0 do_package: QA Issue: File '/usr/lib/node_modules/backend/node_modules/leveldown/prebuilds/android-arm/node.napi.armv7.node' from backend was already stripped, this will prevent future debugging! [already-stripped]
<Guest82> When i add "INSANE_SKIP:${PN} += "already-stripped" to the recipe i get:
<Guest82> do_package_qa: QA Issue: Architecture did not match (ARM, expected AArch64) in /usr/lib/node_modules/backend/node_modules/leveldown/prebuilds/android-arm/node.napi.armv7.node
<Guest82> It seems to me the prebuilt android-arm should not be used anyway in my case, so I should somehow set --build-from-source for leveldown? I have tried adding .npmrc with this command in the root but this did not help.
<Guest82> Looking at npm.bbclass I could not figure out if I should tell it to do something specific.
<Guest82> Would any of you know where to start debugging this?
philmd has joined #yocto
Guest62 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 272 seconds]
philmd has quit [Client Quit]
nemik has joined #yocto
jetm has joined #yocto
vladest has quit [Ping timeout: 240 seconds]
philmd has joined #yocto
vladest has joined #yocto
jetm has quit [Quit: ZNC 1.7.2 - https://znc.in]
philmd has quit [Quit: ZNC 1.7.2 - https://znc.in]
zpfvo has quit [Ping timeout: 250 seconds]
<TRO[m]> <RP> "TRO: We've often wondered what..." <- I mean setting up a build cluster in a few minutes is great. The running costs should be low, just the builder (on demand) instance type should be considered carefully...
<RP> TRO[m]: we have around ~65 different "builders" active on any give test run and they use a fair bit of resources to run the builds so I suspect it would be expensive
<RP> TRO[m]: it would be interesting to see what "oe-selftest -r reproducible" would 'cost' or "oe-selftest -a --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirroring.test_yocto_source_mirror reproducible -T machine -T toolchain-user -T toolchain-system -j 15"
<RP> we run the latter four times on centos, debian, fedora and ubuntu
zpfvo has joined #yocto
<RP> smurray, dl9pf: https://autobuilder.yoctoproject.org/typhoon/#/builders/120/builds/3054/steps/13/logs/stdio - we updated ptest-runner again and there is a patch issue
<TRO[m]> <RP> "we run the latter four times..." <- I guess it will not be cheap, but I'm not a pricing model expert ;)
<RP> TRO[m]: this is why we have our own servers :/
<RP> " ninja: error: manifest 'build.ninja' still dirty after 100 tries, perhaps system time is not set"
<dl9pf> RP: ok will take a look (smurray is on vacation)
<RP> dl9pf: thanks
<TRO[m]> RP: We can have this discussion offline ;)
Tyaku has joined #yocto
psi34 has joined #yocto
<RP> TRO[m]: I've just had a lot of people tell me things about this over the years and in general people don't appreciate the scale of our servers/tests
rber|res has joined #yocto
<psi34> Hi! I think I've found a bug with externalsrc and dependency handling. When I call clean on an externalsrc recipe then call prepare_recipe_sysroot for a recipe that depends on it, I get the following "The sstate manifest for task 'dummy_cleaned_task:populate_sysroot' (multilib variant '') could not be found.". If I build the dummy_cleaned_task
<psi34> fully it works fine, also works fine when I convert the recipe to not use externalsrc. I think the "if task.endswith("_setscene"): bb.build.deltask(task, d)" causes the problem somehow or breaks an assumption elsewhere because if I disable this it also works. Has anybody encountered something similar?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP> psi34: it is probably worth filing a bug for that
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Zaid has quit [Quit: Client closed]
<JerryM> if I (r)dpend on a package with a certain PACKAGECONFIG is it possible to check this?
Minvera has joined #yocto
<tgamblin> Do we have a style/formatting guide for our Python scripts?
xmn has joined #yocto
rob_w has quit [Remote host closed the connection]
<rburton> tgamblin: personally, what black says
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
psi34 has quit [Quit: Client closed]
<tgamblin> rburton: thanks!
<rburton> (nobody has ran it over the existing code)
Xagen has joined #yocto
<tgamblin> rburton: One of the other BL devs was asking but I didn't have an answer other than maybe pylint. I've suggested they look at black
Xagen has quit [Client Quit]
<rburton> black is super-opinionated but there's a lot of zen from that
Xagen has joined #yocto
<RP> zeddii: FWIW other builds all worked even on that worker
sakoman has joined #yocto
<zeddii> RP: that is definitely strange. ninja just went insane.
<LetoThe2nd> zeddii: i want the above quote out of context.
* zeddii will have to avoid japan if the quote gets out
<RP> zeddii: I doubt it is meta-virt related :/
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
StephanKlatt[m] has joined #yocto
amitk has joined #yocto
fray has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<manuel_> Does the devtool shall have userspace qemu enabled?
<manuel_> Today a collegue of mine was adding a recipe for a tool he wants to include in the docker build
<manuel_> It's a native recipe but he failed to mark it as -native and choose the wrong architecture as well
<manuel_> (the arch of the target, not of the build host)
<manuel_> to my surprise, he could execute that binary in the devtool shell. That was really puzzling me.
<rburton> nope
<rburton> it probably just used your native compiler
<rburton> did you check the binary was actually the wrong arch?
<manuel_> jepp, did so. I checked with `file`.
<manuel_> The file (pandoc) was precompiled. It's written in Haskell from what I know.
<manuel_> He took the wrong file from here: https://github.com/jgm/pandoc/releases/tag/3.1.5
<rburton> some distributions enable the qemu-user thing if you install qemu
<rburton> so that probably happened, outside of yocto
<RP> yes, binfmt-misc is probably at play
<manuel_> That explains it. The collegue is using Ubuntu. I guess Ubuntu is very likely to enable that by default because it's so targeted at novices.
kscherer has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #yocto
Xagen has joined #yocto
manuel_ has quit [Ping timeout: 272 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
yannd has quit [Ping timeout: 240 seconds]
Tyaku has quit [Quit: Lost terminal]
yannd has joined #yocto
rfuentess has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
amitk has quit [Ping timeout: 246 seconds]
ptsneves has quit [Ping timeout: 250 seconds]
frieder has quit [Remote host closed the connection]
<RP> JPEW: ptest-runner changes seemed to work in testing, thanks
<JPEW> RP: Good
jkorsnes[m] has quit [Remote host closed the connection]
dmoseley_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
dmoseley has joined #yocto
zpfvo has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 240 seconds]
<tlwoerner> is there an example of a BSP layer that handles add-on boards?
<tlwoerner> e.g. MACHINE = "the-base-board"
<tlwoerner> SOME_SETTING = "with-this-add-on-board"
<tlwoerner> perhaps use MACHINE names for each combo?
DvorkinDmitry has joined #yocto
<DvorkinDmitry> I need to overwrite the file, generated by another recipe. can't use .bbappend. What can I do?
<rburton> why can't you use a bbappend? that's what they're for.
Guest82 has quit [Quit: Client closed]
<vvn> tlwoerner: isn't what SOME_SETTING:the-base-board provides you?
<vvn> RP: I like ${TOPDIR}/tmp-${DISTRO} because it keeps the same directory depth. Also deploy dir already splits per-machine artifacts, so I think it'd be convenient to explicit the distro in the build path too as a saner default setup.
sudip has quit [Quit: ZNC - http://znc.in]
sudip_ has joined #yocto
Wenqing has quit [Read error: Connection reset by peer]
Wenqing has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
<DvorkinDmitry> rburton, case I need to keep configs and files for this image in one recipe. I just need to overwrite the file that installed previously by OE
<JPEW> DvorkinDmitry: One way would be to bbappend the OE recipe to make it `rm` the file in do_install:append. Then your new recipe wouldn't conflict
<JPEW> DvorkinDmitry: But.... you might want to consider why your new recipe _has_ to be the one to install the file; it's probably not best practice to do that
<DvorkinDmitry> JPEW, I see. I have two images for the same machine: first image has normal nginx, another has nginx + custom htmls + custom php config + custom nginx. all I need is just to add myrecipe (with this files) into image B. Seems it is not possible?
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
<JPEW> DvorkinDmitry: Is that 2 different nginx's or is the "custom nginx" the config?
<DvorkinDmitry> JPEW, in the first image I have to keep default nginx config (from OE), in another image I need to replace the default nginx config with customer's. Nginx binaries in both images are identical.
<JPEW> ah. We override the base nginx to use drop files, then you can easily add in other config fragments from other recipes as necessary
goliath has joined #yocto
florian_kc has joined #yocto
<DvorkinDmitry> JPEW, ok. I have a recipe that installs several php files into /var/www/localhost/html/ but index.html and the directory /var/www/localhost/html conflicts with the files installed by nginx*.bb. If I'll place it into another dir I have to change default nginx.conf to point to another dir anyway. right?
<JPEW> ya
<DvorkinDmitry> JPEW, and I run into conflict again...
<DvorkinDmitry> I can't even replace the nginx setup in my .bbappend, case it is image-specific, not machine specific
<JPEW> Ya, then I'd just remove it completely in a bbappend and make new recipe(s) to provide it
<DvorkinDmitry> JPEW, probably it is the best idea I can imagine too. was thinking about it, but hoped there are some magical key exists for such a situation in OE
<JPEW> DvorkinDmitry: Ya, that one is a little tricky
<Ablu> DvorkinDmitry: Can you maybe do your config in a file under "/etc/nginx/conf.d/*.conf" or "/etc/nginx/sites-enabled/*"? /etc/nginx/nginx.conf includes those.
<DvorkinDmitry> Ablu, I can. but I can't override default webserver settings for localhost,_default and * servernames then
<Ablu> DvorkinDmitry: You could overwrite parts of it, but yeah, doing a clean cut may be better in some situations.
florian_kc has quit [Ping timeout: 272 seconds]
pbsds has quit [Ping timeout: 252 seconds]
pbsds has joined #yocto
<rburton> sounds like patches welcome for the nginx recipe to package the configuration separately as a recommendation
<rburton> so you can provide your own
<rburton> easy
<rburton> something like package daemon recommends daemon-config and has a subpackage daemon-default-config which rprovides daemon-config
<rburton> then you can write your own package and install it explicitly, so the default config doesn't get pulled in
Kubu_work has joined #yocto
mvlad has quit [Remote host closed the connection]
<tlwoerner> vvn: but i don't want SOME_SETTING:the-base-board, i want SOME_SETTING:a-specific-add-on-board
<tlwoerner> maybe i just need to add my add-on boards to OVERRIDES or something
florian_kc has joined #yocto
<vvn> tlwoerner: yep, either inherit a new machine config from the base board, or extend MACHINEOVERRIDES and update your recipes with a few :a-specific-add-on-board
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 246 seconds]
Piraty has quit [Quit: -]
Piraty has joined #yocto
alessioigor has quit [Remote host closed the connection]
tin_ has joined #yocto
leon-anavi has quit [Quit: Leaving]
vladest has quit [Ping timeout: 272 seconds]
Kubu_work has quit [Quit: Leaving.]
<RP> tlwoerner: MACHINEOVERRIDES may help
|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #yocto
goliath has quit [Quit: SIGSEGV]
<zelgomer> what does this mean? "foo-1.0-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'bar:populate_sysroot' (multilib variant '') could not be found."
<zelgomer> i sometimes get workspaces into this state, i don't know how, and i don't know how to recover from it except to delete and recreate
florian_kc has quit [Ping timeout: 272 seconds]
<abelloni> JPEW: are you planning to merge meta-mingw master-next in master?
<JPEW> abelloni: Ya, does it fix the problem?
<abelloni> yes
<abelloni> I started a build with master and I got the problem
<JPEW> Done
<abelloni> I then remembered I did my other builds with master-next :)
kscherer has quit [Quit: Konversation terminated!]
Xagen has joined #yocto