locutusofborg has quit [Ping timeout: 245 seconds]
sakman has joined #yocto
sakman_ has joined #yocto
sakman has quit [Ping timeout: 276 seconds]
kpo has quit [Ping timeout: 256 seconds]
Chaser has joined #yocto
sakman_ is now known as sakman
sakman_ has joined #yocto
sakman has quit [Ping timeout: 255 seconds]
Danct12 has quit [Quit: WeeChat 4.1.1]
Danct12 has joined #yocto
zandrey has quit [Quit: Leaving]
bhstalel has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
zpfvo has joined #yocto
alessioigor has joined #yocto
alperak has joined #yocto
thomas_34 has joined #yocto
thomas_34 has quit [Client Quit]
thomas_34 has joined #yocto
<thomas_34>
Good morning guys: I have a recipe with that line: "DEPENDS_class-native += " swig-native"". Can someone explain that "_class-native" after DEPENDS? It seems, that the swig-dependency does not show up in recipe-sysroot-native directory. And all following dependencies, which are added via "DEPENDS += " some-native more-native deps-native"" do also
<yocton>
thomas_34: "_class-native" is the old syntax for the native override : it means that in case of a -native build, DEPENDS has " swig-native" appended to it.
goliath has joined #yocto
<yocton>
thomas_34: which Yocto branch are you using?
<yocton>
dunfell?
<thomas_34>
yocton I just check. Is it okay to check which branch I use at oe-core?
<thomas_34>
yocton, I am at dunfell. But in couple of weeks I will upgrade
zpfvo has quit [Ping timeout: 264 seconds]
<yocton>
dunfell still uses the old syntax so this part is fine
<thomas_34>
Ok. So when I build the recipe for the target, (not native), some-native, more-native and deps-native should show up in recipe-sysroot-native nevertheless, right?
sng has joined #yocto
tnovotny has joined #yocto
dmoseley has quit [Ping timeout: 255 seconds]
<kanavin_>
halstead, no problem, thanks
<yocton>
thomas_34: yes
zpfvo has joined #yocto
<thomas_34>
yocton, what can I do when this does not work? How can I track down the issue? https://pastebin.com/tjUkPgFY
<thomas_34>
The find command on line 6 should display 30 files or more, which consists of *dotnet* name. So there is nothing from dotnet-native in recipe-sysroot-native
<thomas_34>
But, when I comment the line in the recipe which sets this: DEPENDS_class-native=" cmaketools-native" (line 3), then dotnet-native and swig-native show up in recipe-sysroot-native
<mcfrisk_>
thomas_34: bitbake -e recipe-native ? Maybe that line is overwriting the full DEPENDS, and it should have been an append instead?
<yocton>
thomas_34: mcfrisk_+1 look at the operations leading to the final value of DEPENDS
<thomas_34>
Ok, how do I do that? Isnt that one line 2 what the final state of DEPENDS variable is?
<yocton>
"logginghubnative" as a recipename would not trigger a native build in case of a BBCLASSEXTEND = "native" but "logginghub-native" would
<yocton>
the dash is important
bhstalel has quit [Quit: Client closed]
<Rich_1234>
Does anyone know if the yocto beginner series talks from today's summit are going to be recorded?
<yocton>
thomas_34: if I'm not mistaken, DEPENDS_class-native is meant to overwrite DEPENDS (the target one). If your recipe inherit native then it is a native recipe and you should put every dependency in DEPENDS
<Saur_Home>
thomas_34: Do note that `DEPENDS_class-native` will override all of `DEPENDS` when building for native, not add to it. If you want to add, then it should be `DEPENDS_append_class-native`.
tct is now known as jbo
<Saur_Home>
Additionally, If `DEPENDS_class-native=" cmaketools-native"` is after `DEPENDS_class-native += " swig-native"`, the latter will be ignored as the former will set the value, ignoring any previous value.
<Saur_Home>
Typically, you want to set all dependencies that are needed for both target and native using `DEPENDS = "..."` and then add any extra dependencies using `DEPENDS_append_class-target = " ..."` and/or `DEPENDS_append_class-native = " ..."`
<alperak>
I'm going to create a patch for a recipe. Should I put my name in the "from" variable in the patch? Someone else made the fix but I'm going to create the patch. Or is it enough to just add "signed-off"?
<Saur_Home>
alperak: If you are submitting the patch on behalf of someone else, then just add your `Signed-off-by` line at the end.
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<alperak>
Saur_Home I'm not sending it on behalf of anyone, but in the end someone else wrote the code, not me. I will only add this patch to solve the build error.
<alperak>
It seems like it is enough to add signed-off.
luna has joined #yocto
pretec has joined #yocto
locutusofborg_ is now known as locutusofborg
locutusofborg has quit [Changing host]
locutusofborg has joined #yocto
locutusofborg is now known as LocutusOfBorg
alperak has quit [Quit: Client closed]
alperak has joined #yocto
KhazAkar has joined #yocto
<thomas_34>
yocton, "logginghubnative" as a recipename would not trigger a native build in case of a BBCLASSEXTEND = "native" but "logginghub-native" would":
<thomas_34>
Yes, I know that. logginghubnative does not provide anything for a native build. It only has some dependencies which are native. logginghubnative does not inherit native.
<RP>
JaMa: FWIW I'm leaning against unless there are people come forward and say they like it. I really haven;t had the time to sit and think about it properly though :(
<RP>
I just can't keep up with the flow of problems coming at me, I'm quite depressed about it
prabhakarlad has quit [Ping timeout: 250 seconds]
<RP>
JaMa: do yo happen to know which webos layers actually need the priority overrides ?
<JaMa>
RP: understood and I know it's not your fault, I was just asking if we really wait for someone else to confirm that this would be useful for them
<RP>
JaMa: my worry is that it is quite invasive and will break workflows for people with no way to keep the existing behaviour. That is the kind of change which generates a lot of friction
<JaMa>
RP: mcf (the tool which generates the bblayers.conf in LGE builds) does that automatically as weboslayers.py defines priority as a sorting order for BBLAYERS variable
<RP>
JaMa: my first thought when I saw this was to drop layer priority support ;-)
<JaMa>
it was needed for some layer 10+ years ago but fixed since then
<JaMa>
well it's still useful to define BBLAYERS order and priority to match :)
<RP>
JaMa: we probably need to revisit some of these things :/
<JaMa>
RP: the previous changes also broke the workflow (when it wasn't possible to prevent creating the links for kernel) which Paul reported (and even ended in release notes) and these changes at least fix that part
<RP>
JaMa: yes, it is tricky :/
<JaMa>
true, for the autobuilder build of OSE you shouldn't need to set the priorities for sure (it will be slightly different from our internal builds, but that's already true)
thomas_34 has quit [Quit: Client closed]
<RP>
JaMa: I was wondering about trying it without doing that. I can't bring myself to add code looking like that! ;-)
<RP>
JaMa: I'm not sure how to explain it to your colleagues though
thomas_34 has joined #yocto
_whitelogger has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
ptsneves has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
zpfvo has quit [Ping timeout: 276 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
Mike23 has joined #yocto
prabhakarlad has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<chep>
Hi, I'm trying to build something with my generated SDK but it lacks of libstdc++fs.a The same soft compiles fine with bitbake and libstdc++fs.a is added in its recipes-sysroot directory. What do I need to do to include it in SDK ?
<chep>
alperak: but I don't know what to add. I thought it was part of g++
<alperak>
@chep dont forget to check "SDKIMAGE_FEATURES" variable with "bitbake-getvar foo" or "bitbake -e | grep ^foo=". should contain "staticdev-pkgs"
<chep>
and it's strange that it is added in recipe-sysroot but not in SDK (my soft is a .so which is included in sdk)
<rburton>
chep: we don't build static libraries by default. do you really want the static library
<chep>
no dynamic is also ok
<chep>
but no one in sdk
<rburton>
how is your sdk built?
<chep>
bitbake -c populate_sdk my-image
<rburton>
does the sdk have the libstdc++.so files in?
Mike23 has quit [Quit: Client closed]
<chep>
yes
<rburton>
dynamically link then :)
starblue has joined #yocto
<rburton>
if you want static libraries then what alperak said is right: add SDKIMAGE_FEATURES:append = " staticdev-pkgs". the default is no static.
<rburton>
chep: ah there is no shared version of that library. you _need_ the static devs.
<rburton>
you could just add libstdc++-staticdev if you don't want to bloat the sdk too much (via TOOLCHAIN_TARGET_TASK)
<chep>
I'm trying with all staticdev. it may solve an other problem I got
<chep>
then I'll see
bhstalel has quit [Quit: Client closed]
<chep>
alperak rburton : it works, thanks a lot
bhstalel has joined #yocto
vladest has quit [Quit: vladest]
alperak has quit [Quit: Client closed]
alperak has joined #yocto
vladest has joined #yocto
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bhstalel has quit [Ping timeout: 250 seconds]
rber|res has joined #yocto
camus has quit [Quit: camus]
Mike23 has joined #yocto
camus1 has joined #yocto
Tom33 has joined #yocto
camus1 is now known as camus
khem has quit [Quit: Connection closed for inactivity]
pretec has quit [Remote host closed the connection]
<Tom33>
Hello! is it possible to set the priority of wic scripts? I have customized some wic scripts that are stored in my own layer - In another layer there are scripts with the same name. Currently the "wrong scripts" are used. I tried to set the layer priority but this seems not to work
<rburton>
do you mean the wks, or something else?
pretec has joined #yocto
<Tom33>
python scripts
<rburton>
no you can't just override pieces of wic from another layer, python doesn't work like that
lexano has joined #yocto
<Tom33>
(under the wic/plugins/source directory)
<Tom33>
ah ok, so the wic plugin dir is not "handled" by the bitbake layer priority
<Tom33>
Thank you for this info!
<rburton>
yeah wic is just a python program
<rburton>
layers mean nothing to dit
<rburton>
to it
GNUmoon has quit [Remote host closed the connection]
<jclsn>
Shouldn't it be enough to just inherit systemd, specify the SYSTEMD_SERVICE:${PN} = "hello.service" and add FILES_${PN} += "${systemd_unitdir}/system/hello.service" ?
<rburton>
iirc you don't need to do FILES but you're mixing override syntax there
<Tom33>
I have also another issue with my customized script - I'm calling a python script inside the wic plugin with arguments. This currently works only with an absolute path to the script. The script is also inside the pluging dir, but could not be found when relative path is being used. What i'm doing wrong / Is it possible to add an environment path
<Tom33>
for wic?
djs has joined #yocto
<rburton>
the cwd won't be the plugin directory, so that won't work
<rburton>
you could work out the path by using __file__
Rednak55 has joined #yocto
<Tom33>
Is it possible to add an directory path?
<rburton>
to sys.path? not directly. just work out the absolute path from __file__
<JPEW>
RP: Well... that setscene task dependency e-mail at least explains some things that I thought were strange when I did the SPDX class :)
<RP>
JPEW: I'm curious which things those were! :)
<Tom33>
Ok, I will try it - Thank you!
<JPEW>
I thought it was strange I couldn't rely on transitent sstate dependencies, but that makes sense now because they are squashed
* zeddii
wonders how JPEW is up already
<JPEW>
I figured from the behavior thats was the case, nice to get confirmation that is the intended way it works
<JPEW>
zeddii: Coffee.... a lot of coffee
* zeddii
goes to get one himself
Poppy has joined #yocto
<JPEW>
RP: contrib/jpew/hashserver-gc has garbage-collection/parallel query/sstate mirror skip on it.
<JPEW>
RP: There are a few caveats we'll need to figure out before we can merge it all though
gsalazar has joined #yocto
Poppy has quit [Ping timeout: 250 seconds]
Poppy has joined #yocto
<RP>
JPEW: looks promising at a quick glance, curious about the caveats. Nothing is ever simple :)
<JPEW>
RP: Main one is that the client breaks (hard) if the server isn't upgraded, so the servers have to be setup before the support can be enabled
<JPEW>
RP: I... made a perhaps poor choice initially that the servers are wholly responsible for compatability which is fine until you add _new_ API that a client wants to use
<JPEW>
We could make the clients aware of what API the servers support, but it would be a breaking protocol change
<RP>
JPEW: I guess we only have the one "live" server and we can arrange to upgrade that first
<JPEW>
Right
Chaser has quit [Ping timeout: 245 seconds]
<JPEW>
The second is that the siggen: Add parallel query API restructures the code to make it a lot cleaner, but that means OE-core needs to implement the changes in sstatesig in lock-step
<JPEW>
Integration is listed in the commit, and done in the next commit on the branch. It's simple, but important
Chaser has joined #yocto
wmills_ has joined #yocto
Kubu_work has joined #yocto
nico35 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bhstalel has joined #yocto
Danct12 has quit [Quit: WeeChat 4.1.1]
Tom33 has quit [Quit: Client closed]
g0hl1n has quit [Ping timeout: 250 seconds]
g0hl1n has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<kanavin_>
RP: I'm fully on board with linking shadow statically, thanks for the extended explanation
Estrella has joined #yocto
|Xagen has joined #yocto
koty0f has joined #yocto
koty0f has quit [Client Quit]
Xagen has quit [Ping timeout: 256 seconds]
|Xagen has quit [Ping timeout: 264 seconds]
perceval has quit [Remote host closed the connection]
perceval has joined #yocto
ajaya101 has joined #yocto
<ajaya101>
hello
<ajaya101>
I joined the yocto project summit late
<ajaya101>
ned to get my vm provisioned on digital ocean
<RP>
kanavin_: It may be we can fix the setscene dependencies but I think the static linking may be enough of a performance/efficiency gain it is worth the pain of maintaining it regardless
<RP>
JPEW: looking at that code in more detail, only caching those that exist may be problematic
<JPEW>
RP: why is that?
<RP>
JPEW: From memory, we hit some of these codepaths a lot and things assume the code caches for efficiency
<RP>
JPEW: we can put some other higher level cache inbetween siggen and runqueue but things are written assuming it does this iirc
<JPEW>
Ya... I was trying to balance caching and making sure we utilize the mirror as much as possible. I suppose we could assume nothing will be added to the mirror while we are running
<vmeson>
ajaya101: /msg your info to halstead - he's setting up these machines. Eg: /msg halstead Please setup : ssh ilab01@46NVSTZ-summit.yocto.io
<RP>
JPEW: The runqueue code won't really want to check again once it has looked and I think that cache was there to try and keep runqueue's view of the world consistent during a given build too? I'm a bit worried changing things from under it might break the state somehow too
<RP>
perhaps I'm worrying about nothing though
Tyaku has joined #yocto
<JPEW>
RP: I don't think it's changing anything in that regard. Once you get to this code, it (previously) would have gone and checked the HTTP server for sstate. This just add an extra step before that to ask the HE server to see if it thinks the hash exists first
florian__ has quit [Ping timeout: 264 seconds]
<Tyaku>
Hello, I come back about my dummies issues. So, I am using hardknott, I have many layers using hardknott, for example: meta-imx. In my project I create a systemd receive with 250 version (same as kirkstone) and set the prefered version to 250. At this point everything is good. *BUT* in meta-imx/meta-bsp/recipes-core/systemd they had the brillant idea to create a file systemd_%.bbappend with two patches. Of
<Tyaku>
courses, with systemd 250 these patches fails to apply. My question is simple: Without modifing meta-imx, is it possible to make sure the systemd_%.bbappend file is not used ?
<JPEW>
Tyaku: BBMASK out the bbappend I thinkj
<JPEW>
Tyaku: We've done that with a lot of poorly behaving BSPs in the past and it works alright
<Tyaku>
Wow I didn't know it was possible, so I'm going to search this on google.
<JPEW>
And by a lot I mean one really bad BSP :)
<Tyaku>
"poorly behaving BSPs" Thats what I was thinking about meta-imx. To much trashy things, like patches and stuff to add display, audio eveything by default. You don't imagine.
<rburton>
Tyaku: alternatively you can create another bbappend of your own and SRC_URI:remove the patches that the bsp adds
<Tyaku>
Thanks you!! I'm going to check the two options
<rburton>
Tyaku: i'm a strong believer that a _BSP_ should just enable the hardware and be entirely separate from the "example platform" which can enable all the stuff and show you how to glue things together. patching systemd is definitly the latter.
<JPEW>
rburton: That would be really nice
<rburton>
JPEW: we're trying to tease apart one of the arm bsps which has conflated "how to make the machine boot" with "reference distribution for testing and example" and it's fun
<JPEW>
Ya, I've found a lot of BSPs make their reference distribution layer mandatory to actually use the SoC in the real world though, even if the BSP layer proper is pretty good
<JPEW>
gstreamer patches always seem to be the hang up there
<wmills_>
Beginner slides say: "Do not try to share sstate-cache between hosts running different Linux distros even if they say it works". Is that advice just for the dir (no problem) or the mirror??
<rburton>
why do they say that
<rburton>
either there's a bug or there isn't
<wmills_>
Throw salt over your shoulder before launching bitbake
<Rich_1234>
shrodingers bug
Xagen has joined #yocto
<ente>
wmills_: thanks for the tip
<ente>
I should throw salt over the shoulder before engaging with computers
nico35 has quit [Quit: Client closed]
<RP>
wmills: I'd strongly disagree with that advice
<rburton>
pro-tip: the autobuilder does that
<RP>
rburton: indeed. it isn't like we just guess
<kanavin_>
wmills_, there's a surprising amount of FUD around sstate. Usually around being able to share it. Please ignore that FUD.
<wmills_>
RP, rburton : glad to hear that. Altought I assume "They" == you two and more :)
<rburton>
i've never considering myself one of Them before
<rburton>
do i get a badge? is there a secret cabal?
<kanavin_>
wmills_, ente people tend to blame sstate when they see build errors they can't explain, and sadly that makes its way into training material and the way builds are set up
<wmills_>
To play devils advocate, the AB always runs pretty well maintained layers. Is there anything a novice BB author can do to screw it up?
ajaya101 has quit [Quit: Client closed]
<kanavin_>
that could fill a whole conference talk
<wmills_>
kanavin: Yes I know. And some people have experience going back many years and they found a solution that worked for them and never changed
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
alessioigor has quit [Quit: alessioigor]
<wmills_>
rburton, I will make you a badge. You guys will need to work out the handshake
alessioigor has joined #yocto
<wmills_>
kanavin: "there's a surprising amount of FUD around sstate. Usually around being able to share it. Please ignore that FUD.". My point was it was in the YP summit beginner track slides. The project is spreading FUD against itself
<kanavin_>
wmills_, yes, that should absolutely be corrected. Can you raise the issue in #yocto-summit-2023.11 please?
<kanavin_>
ping presenter as well perhap
<kanavin_>
s
<wmills_>
OK will do. The slides are joint between Behan and Tom
prabhakarlad has joined #yocto
prabhakar has joined #yocto
Poppy has quit [Quit: Client closed]
Guest6 has joined #yocto
<Guest6>
here.
<Guest6>
Hi, I’m trying to understand the difference between devshell and devtool. It looks like they are the same thing. I need to modify device tree source in virtual/kernel then apply that as a patch. Seems like both tools can do that? Very confused the difference between them and which one I should use. Having a tough time understanding what to do
<rburton>
devshell is "drop me into a terminal in the work tree"
prabhakarlad has quit [Ping timeout: 250 seconds]
<rburton>
devtool has commands for upgrading recipes, modifying source trees and generating patches in recipes, etc
prabhakar has quit [Ping timeout: 252 seconds]
<rburton>
devshell is much lower level and really only useful if you're debugging a build failure by hand, as you're inside the build environment
<Guest6>
If I can modify source trees (which I assume is like modifying a device tree down in the kernel) with devtool then why use devshell? I guess that’s what I’m confused about.
<RP>
wmills: we have put tests in where we can to try and identify issues early. What puzzles me is whilst I hear these reports of issues, nobody ever puts them into bugzilla
<Guest6>
Ah ok … I kind of follow I think. So basically devtool is what I can start out with here.
g0hl1n has quit [Quit: Client closed]
<RP>
wmills: I do think we should ask that be removed from the slides
thomas_34 has quit [Ping timeout: 250 seconds]
Guest6 has quit [Quit: Client closed]
<rburton>
I take it YPTM is cancelled today?
<RP>
rburton: yes
<rburton>
RP: my calendar says the call after is still on but i have no memory of whether it was cancelled or not
<RP>
rburton: I don't control the calendar :(
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<LetoThe2nd>
Tyaku: lol i actually demoed BBMASK in the livecoding session today, masking so hard I broke the build ;-)
rber|res has quit [Quit: Leaving]
JerryM has quit [Quit: Konversation terminated!]
g0hl1n has joined #yocto
florian_kc has quit [Quit: Ex-Chat]
goliath has quit [Quit: SIGSEGV]
<Tyaku>
And I finally used it and it works
<Tyaku>
like a charm
Guest6 has joined #yocto
<LetoThe2nd>
Tyaku: yay!
<Guest6>
Is there anyways to rewatch some of the talks with this weeks seminar? Have to work and can’t attend so wanted to know if this was possible.
<rburton>
you can catch up on previous summits whilst you wait :)
Guest6 has quit [Client Quit]
jmd has joined #yocto
tnovotny has quit [Quit: Leaving]
kpo has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
goliath has joined #yocto
bhstalel has quit [Ping timeout: 250 seconds]
ptsneves has quit [Ping timeout: 276 seconds]
khem has joined #yocto
mbulut_ has quit [Ping timeout: 256 seconds]
ecdhe has quit [Read error: Connection reset by peer]
zpfvo has quit [Quit: Leaving.]
ecdhe has joined #yocto
goliath has quit [Quit: SIGSEGV]
<wmills_>
Now on master I get lots of "Error contacting Hash Equivalence Server". Is this new to master?
<khem>
chep: libstdc++fs is a static archive
<khem>
wmills_: hash equivalence is enabled but I wonder if its trying to contact a dead instance
djs has quit [Quit: Client closed]
ssweeny has joined #yocto
<khem>
default is to use a local instance unless you set BB_HASHSERVE_UPSTREAM
florian__ has joined #yocto
<wmills_>
khem: the hashserve.sock is open by the ultimate parent of the build that is running. The error message is pointing to the correct hashserver.sock
<wmills_>
WARNING: parted-native-3.6-r0 do_deploy_source_date_epoch: Error contacting Hash Equivalence Server unix:///media/big_scrap/bill/yp-generic-arm64/master/generic-arm64/build/hashserve.sock: Timed out waiting for data
<khem>
hmmm timeouts could be a bug
<khem>
maybe try to bisect bitbake I guess you had a prior instance of master working on the same host ?
<wmills_>
Not this same config but was doing a lot of builds leading up to nanbield tag w/o any issues.
<wmills_>
I can switch my old config to master tip and try that
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar has quit [Ping timeout: 276 seconds]
goliath has joined #yocto
<rburton>
fwiw i saw something similar earlier, i wonder if master has some changes to bitbake/hashserv which make it hang a bit
<RP>
wmills: that isn't python 3.12 is it?
<rburton>
i had the same with 3.10
<khem>
I have the ptest images working nicely for few weeks but now I am seeing ssh_test timing out randomly and if I run the same ptest image alone it works ok something in openssh perhaps, no idea, the images are use are systemd based unlike poky defaults
<khem>
I switched to dropbear and still see the failures but a bit less often
<khem>
its clear that its not able to get a response from ssh connection before timeout kicks in
<rburton>
khem: are you adding ssh-pregen-hostkeys to the images?