<Lihis>
I have tried to test out my image with "runqemu qemux86-64 slirp nographic ovmf <my-image-name> wic" but only get error "IMAGE_LINK_NAME wasn't set to find corresponding .qemuboot.conf file". Reference manual says that "default value is derived using the IMAGE_BASENAME and IMAGE_MACHINE_SUFFIX variables". I haven't override the value so how come it is not set? I'm on master branch if that matters
<rburton>
the arg to 'ovmf' is the firmware to use, not your image
<rburton>
"runqemu qemux86-64 slirp nographic " should just work
<Lihis>
the 'ovmf' is needed to boot with UEFI?
LocutusOfBorg has quit [Ping timeout: 264 seconds]
<rburton>
ah its an optional arg. the AB exercises this with just 'runqemu nographic serial wic ovmf', so maybe remove your image name and let runqemu find it? runqemu argument parsing can be a little fiddly...
jmiehe has quit [Remote host closed the connection]
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
jmiehe1 has joined #yocto
lexano has joined #yocto
jmiehe1 is now known as jmiehe
<Lihis>
thanks rburton, it works! looks like only thing needed was to drop the image name from the command
<Lihis>
somehow I got the impression that the image name would have been required but I was wrong
jmiehe has quit [Client Quit]
LocutusOfBorg has joined #yocto
<rburton>
Lihis: it should have used the name as a hint but as i said, the parsing is a bit complex as its so flexible
MrCryo_ has joined #yocto
MrCryo has quit [Ping timeout: 255 seconds]
MrCryo_ is now known as MrCryo
ehussain has quit [Quit: ehussain]
MrCryo has quit [Ping timeout: 268 seconds]
alessioigor has joined #yocto
Chaser has quit [Ping timeout: 240 seconds]
alessioigor82 has joined #yocto
alessioigor82 has quit [Client Quit]
alessioigor has quit [Ping timeout: 250 seconds]
MrCryo has joined #yocto
Xagen has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
manuel1985 has quit [Quit: Leaving]
rob_w has quit [Remote host closed the connection]
<vvn>
hi there -- DEPLOY_DIR can be safely shared between multiple distro/machine/releases, right?
<vvn>
hum, not distro, one DEPLOY_DIR per distro, but multiple releases and machines
florian has quit [Quit: Ex-Chat]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gmask>
Hi community! buildpath warnings show up in scarthgap for projects using gcov (-fprofile-arcs --coverage). Seems that absolute `gcda` paths are injected into object files. The new -fprofile-prefix-map has been implemented, but is not working as expected (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063). Any idea what to do about this?
<rburton>
gmask: sounds like this is a gcc bug so i'm not sure what you expect us to do?
<vvn>
is it safe to use BBMASK with distro/machines overrides?
<gmask>
rburton: this new `-fprofile-prefix-map` is not in `DEBUG_FLAGS` or anywhere in `bitbake.conf`, so I wonder if this is intentional or none had found this problem before? In the former case, maybe you've found another set of flags to work around this
ray-san has quit [Ping timeout: 240 seconds]
<rburton>
gmask: add it and see if it fixes your problem, if it does send a patch
Esben has quit [Remote host closed the connection]
<gmask>
It doesn't, although it should. That's why I was asking herer
<rburton>
sounds like a gcc bug then
Guest62 has joined #yocto
Guest62 has quit [Client Quit]
mjm has joined #yocto
florian_kc has joined #yocto
<gmask>
rburton: yes, and it seems like none has even attempted to use the flag, since it's nowhere in the code, which is strange, since it will be required for reproducible builds (if using gcov)
<rburton>
obviously nobody has wanted reprod builds with coverage enabled
<gmask>
why obviously?
<rburton>
because it doesn't work :)
<rburton>
if the flag doesn't work then its a gcc bug, so ask gcc
leon-anavi has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
<gmask>
The flag works partially, and there are other flags associated with profiling that some people seem to have used, hence my question here. But ok, I'll go ask Mr gcc
florian_kc has quit [Ping timeout: 260 seconds]
<kilobyte_ch>
Hello, I'm using chromium in kiosk mode on yocto with matchbox-wm. Now I would like to display a video windows (borderless window) on top of chromium. For this I use libSDL. I can set the libSDL window Borderless. But in matchbox-wm it is always fullscreen. Can I somehow convince matchbox-wm to not make this window fullscreen?
<rburton>
kilobyte_ch: make it a dialog window
<rburton>
normal windows are fullscreen in matchbox, you can't avoid that
<kilobyte_ch>
rburton: do you know how that would work with a chromium window and then a SDL window on top of it as "dialog window"? Is there an SDL flag for that?
linfax has quit [Ping timeout: 264 seconds]
jmd has joined #yocto
<rburton>
i won't ask why you can't play the video in chromium...
<kilobyte_ch>
rburton: ok, thanks. Window type is a good thing to dig deeper. Even though I don't see yet how to implement this with SDL.
<kilobyte_ch>
rburton: oh, there is SDL_WINDOW_POPUP_MENU. With that it works, very nice!
pasherring has joined #yocto
<pasherring>
Hey there =) Regarding packages-split (which I am still learning about, so, please correct me if I say something stupid =), I understand that the files are selected to populate the package from left to right, according to the FILES_ match. What if I wish the same file is installed in multiple packages, is it possible?
<rburton>
no
<rburton>
you can put files in a common package and then have other packages depend on that common package
<pasherring>
rburton, Nice, thanks! Do you have an example to share regarding this usage (maybe some recipe you know by heart that does this)?
<rburton>
its nothing clever
<rburton>
PACKAGES = PN-foo PN-bar PN-common
<rburton>
put into common the files that you want present if either foo or bar are installed
<rburton>
then add RDEPENDS from foo and bar to common
<vvn>
PN-common would usually be simply PN
<vvn>
and PN-foo depends on PN
<rburton>
sure, maybe
Xagen has joined #yocto
<pasherring>
Ok, got it... I did something here, but the packages-split folder doesn't seem what I was expecting. So, the file was added to PN-common indeed, but the file is absent under the PN-foo. Is this expected?
<rburton>
yes, because it will be in one package
<rburton>
remember you're digging around the build tree, not looking at what gets installed in an image
<rburton>
you make pn-foo rdepend on pn-common, then installing pn-foo will also install pn-common, and the file you want exists
<pasherring>
vvn, got it, makes sense! The file in question is the lib's pkg-config file (libfoo.pc). In this specific case, I don't want it to go into the PN.
<pasherring>
rburton, got it, many thanks for the explanation and suggestion!
<rburton>
.pc files should be in the -dev package
zpfvo has quit [Remote host closed the connection]
<pasherring>
Yeah, this specific recipe is a vendor provided, faulty one that was packing it into -dbg. I wanted to move it into -dev (it was not being added to the sdk because of that), but I wish also to keep things as is not to break the vendor's assumptions
<vvn>
If I build the same distro (but different OE releases) for various machines, can I safely share DEPLOY_DIR between builds to serve a single artifacts location during development?
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
geoffhp has joined #yocto
pasherring has quit [Remote host closed the connection]
<rburton>
no, builds will go and clean "old" files from it
<vvn>
ha
<vvn>
same for DEPLOY_DIR_* (such as DEPLOY_DIR_IPK)
<vvn>
?
<rburton>
yes
<vvn>
should artifacts be necessarily merged manually? How do you guys usually centralize artifacts for e.g. factory images or development .ipk?
<rburton>
i can't answer that, but i can ask why you want to merge different releases into a single artifact
yudjinn has quit [Ping timeout: 255 seconds]
<vvn>
rburton: I have several machines supported by my distro, some of them build against kirkstone, some of them build again mickledore, and so on.
<vvn>
I guess I'll have no choice but to have deploy dirs per machine then
<JaMa>
vvn: do those builds with kirkstone and mickledore share anything other than DL_DIR? I share TOPDIR for multiple MACHINEs but not for different releases
<vvn>
JaMa: DL_DIR, SSTATE_DIR, and I thought about DEPLOY_DIR, but this is likely a bad idea
<JaMa>
but why not share DL_DIR, SSTATE_DIR from 2 different TOPDIRs?
<vvn>
that's what I'll do, yes
<vvn>
but in the end I want the .ipk for internal development and the *.wic* as well, I thought I was being smart by sharing DEPLOY_DIR_IPK and DEPLOY_DIR_IMAGES from my distro
<JaMa>
technically you can share SSTATE_DIR across all possible combinations, but I don't think you'll actually reuse much from kirkstone in mickledore build, so I keep SSTATE_DIR separate per release as well (which makes it easier to delete/prune it when some major change is merged and all older sstate is invalidated)
<JaMa>
maybe I'm missing something, but sharing e.g. bash .ipk from mickledore in package-feed for kirkstone (if some of your MACHINEs share common TUNE_PKGARCH) sound like terrible not smart idea :)
<vvn>
if it doesn't hurt to share, I think it'd be better to share sstate with all releases, then eventually sometimes clear it in the CI
<vvn>
JaMa: I figured :)
<vvn>
and relying on "releases" isn't the best too, because different BSPs will require different revision of some layers within the mickledore or kirkstone timeline
<JaMa>
it works but in my experience isn't particulary useful and this "sometimes clear" is different for each release (e.g. master builds need prunning much more often as they grow faster compared to e.g. mickledore which isn't getting many changes and doesn't grow and can stay valid for months - prunning it would cause unnecesary rebuilds)
<JaMa>
ah evil BSPs :)
<vvn>
so beside DL_DIR and SSTATE_DIR, sharing sounds nice but is likely a bad idea... one build dir per machine (including its DEPLOY_DIR) then a post build script to serve artifacts from various locations
<JaMa>
ask BSP vendor to get some sense, with more people complaining they will more likely understand that it's not ideal
<vvn>
ho I do that too, do not worry
<vvn>
but in the meantime, I have to deal with it
<vvn>
(an example is the NXP based boards from various manufacturers, you may be able to share meta-freescale for mickledore between them, or not)
<vvn>
with all bbappend for fixed versions (including minor numbers) it becomes a nightmare
<vvn>
or some soc overrides trick they may do
florian_kc has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
enok has joined #yocto
MrCryo has quit [Remote host closed the connection]
<kilobyte_ch>
Maybe a dumb question, is there something like Electron for Embedded/Yocto? Or is QT still the "only" good way to go for a proper embedded GUI?
frieder has quit [Remote host closed the connection]
<rburton>
and meta-browser has chromium etc already
<rburton>
there's also meta-flutter if you like that sort of thing. or gtk4.
<JaMa>
or lvgl and many other things, depends on what you need
<kilobyte_ch>
rburton: thanks, I have searched multiple times for yocto and electron, but never found that meta layer. That's a very valuable starting point!
<rburton>
literally the top hit for 'yocto electron' :)
<kilobyte_ch>
Flutter is pretty great, I use it for mobile, but for embedded it doesn't really feel ready (yet). Tried it some years ago. Maybe its already better.
<rburton>
if you like flutter then meta-flutter is actively maintained
<JaMa>
I don't use it myself but some other project use it with some issues (like the fetcher is far from ideal - similarly to npm and cargo and all these fancy new things)
mbulut_ has quit [Remote host closed the connection]
mbulut_ has joined #yocto
ajfriesen1 has joined #yocto
Bardon_ has joined #yocto
gmask has quit [Remote host closed the connection]
denix has quit [Ping timeout: 246 seconds]
Bardon has quit [Ping timeout: 268 seconds]
tleb has quit [Read error: Connection reset by peer]
ajfriesen has quit [Ping timeout: 246 seconds]
ajfriesen1 is now known as ajfriesen
trochotron_ has joined #yocto
armpit_ has joined #yocto
dl9pf_ has joined #yocto
patersonc_ has joined #yocto
rsalveti_ has joined #yocto
dl9pf has quit [Ping timeout: 256 seconds]
dl9pf_ is now known as dl9pf
patersonc has quit [Read error: Connection reset by peer]
rsalveti has quit [Read error: Connection reset by peer]
patersonc_ is now known as patersonc
JaMa has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
rsalveti_ is now known as rsalveti
JaMa has joined #yocto
shoragan_ has joined #yocto
shoragan has quit [Ping timeout: 256 seconds]
denix has joined #yocto
armpit has quit [Ping timeout: 246 seconds]
rburton has quit [Ping timeout: 246 seconds]
armpit_ is now known as armpit
gmorell has quit [Ping timeout: 268 seconds]
gmorell_ has joined #yocto
drkhsh has quit [Ping timeout: 268 seconds]
rburton_ has joined #yocto
trochotron has quit [Ping timeout: 268 seconds]
olof has quit [Ping timeout: 268 seconds]
trochotron_ is now known as trochotron
olof has joined #yocto
schtobia has quit [Remote host closed the connection]
tleb has joined #yocto
_lore_ has quit [Ping timeout: 264 seconds]
drkhsh has joined #yocto
schtobia has joined #yocto
trochotron has quit [Changing host]
trochotron has joined #yocto
_lore_ has joined #yocto
pbiel has quit [Ping timeout: 252 seconds]
<khem>
lvgl anytime
enok has quit [Quit: enok]
_lore_ has quit [Ping timeout: 256 seconds]
_lore_ has joined #yocto
<JaMa>
at least it doesn't take ages to build like chromium :)
<JaMa>
and not every embedded device needs full-blown html rendering (that's why I've mentioned it) on the other hand 97 inch oled from LGE has also OS built with OpenEmbeded and try to "embed" this to average living room :)
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Jookia>
kilobyte_ch: there's wpewebkit. xogium and i have had mixed results with it
<Jookia>
unfortunately if you need something accessible you will need a full desktop environment basically
gmask has joined #yocto
Kubu_work has quit [Quit: Leaving.]
amitk has quit [Ping timeout: 268 seconds]
Guest60 has joined #yocto
Guest60 has quit [Client Quit]
Xagen has joined #yocto
snowurm has quit [Ping timeout: 255 seconds]
Xagen has quit [Ping timeout: 255 seconds]
<smurray>
JaMa: there's some ongoing discussion on coming up with a scheme for Dart/Flutter similar to what's being done for Rust crates (i.e. modules recorded into SRC_URI for reproducibility)
<smurray>
JaMa: hopefully that'll materialize within the next couple of months, a few people are working on it
Xagen has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
<JaMa>
smurray: cool, thanks for info, this has some fetcher for dh, but still enables the network in configure/compile, I haven't looked further
<smurray>
JaMa: the goal is to get to where Rust support currently is, and maybe further wrt license info
<smurray>
JaMa: there are multiple companies with people keen on it from the sounds of it, so I'm hopeful. I expect we'll be helping test it in AGL