Vonter_ has quit [Read error: Connection reset by peer]
<wCPO>
Where can I find the error log for builds on autobuilder.yoctoproject.org? Ex: "The errors for this build are stored in /home/pokybuild/yocto-worker/no-x11/build/build/tmp/log/error-report/error_report_20210930203820.txt"?
alessioigor has quit [Remote host closed the connection]
mckoan|away is now known as mckoan
<mckoan>
good morning
tnovotny has joined #yocto
mckoan is now known as MarcoCavallini
MarcoCavallini is now known as mckoan
alessioigor has joined #yocto
<JosefHolzmayrThe>
yo dudX
alessioigor has quit [Client Quit]
TundraMan has joined #yocto
marka has quit [Ping timeout: 252 seconds]
vd81 has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
vd has quit [Ping timeout: 256 seconds]
roussinm has quit [Quit: WeeChat 3.3-dev]
mbuggem has joined #yocto
rob_w has joined #yocto
matthewcroughan_ has quit [Ping timeout: 252 seconds]
matthewcroughan has joined #yocto
ThomasD13 has quit [Ping timeout: 252 seconds]
* wCPO
found the error logs in the "Sending error reports" step
marex has quit [Ping timeout: 252 seconds]
matthewcroughan_ has joined #yocto
marex has joined #yocto
locutusofborg_ has joined #yocto
manuel_ has joined #yocto
alejandrohs has joined #yocto
troth1 has joined #yocto
rob_w_ has joined #yocto
derRicha1d has joined #yocto
troth has quit [Ping timeout: 252 seconds]
alejandr1 has quit [Ping timeout: 252 seconds]
rob_w has quit [Ping timeout: 252 seconds]
locutusofborg has quit [Ping timeout: 252 seconds]
matthewcroughan has quit [Quit: No Ping reply in 180 seconds.]
derRichard has quit [Ping timeout: 252 seconds]
zyga has quit [Ping timeout: 252 seconds]
manuel has quit [Ping timeout: 252 seconds]
alessioigor has joined #yocto
ant__ has quit [Ping timeout: 240 seconds]
u1106_ has joined #yocto
zyga-mbp has joined #yocto
mranostaj has quit [Quit: leaving]
rfs613 has joined #yocto
mranostaj has joined #yocto
woky has joined #yocto
u1106 has quit [Ping timeout: 252 seconds]
woky_ has quit [Ping timeout: 252 seconds]
rfs613_alt has quit [Read error: Connection reset by peer]
lexano[m]1 has joined #yocto
lexano[m] has quit [Ping timeout: 252 seconds]
FredO2 has joined #yocto
zyga has joined #yocto
shoragan[m] has quit [Ping timeout: 250 seconds]
fullstop has quit [Ping timeout: 250 seconds]
shoragan[m]1 has joined #yocto
leon-anavi has joined #yocto
ericson2314 has quit [Ping timeout: 250 seconds]
fullstop has joined #yocto
FredO has quit [Ping timeout: 250 seconds]
ericson23141 has joined #yocto
vd81 has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<qschulz_>
o/
<JosefHolzmayrThe>
stupid question, and slightly offtopic, but the #docker channel is giving me access headaches from #matrix. so: if i have an EXPORT directive in a dockerfile, whats the best practise to have it honoured? just add -P to docker run? the docs don't exactly enlighten me how those things interact.
qschulz_ is now known as qschulz
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
<qschulz>
JosefHolzmayrThe: EXPORT?
<qschulz>
JosefHolzmayrThe: isn't it supposed to be ENV ?
<JosefHolzmayrThe>
meh. EXPOSE.
<qschulz>
aaaaah, -P yes IIRC
<qschulz>
from the docs: "To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports."
<qschulz>
I've personally always used -p for each and every port mapping, at least it's then obvious what's open or not and to what they map
<JosefHolzmayrThe>
i read that too, but i wasn't sure if "to publish all exposed ports" means "all explicitly exposed ports" or "any port that the container exposes, e.g. opens up for incoming connections"
xmn has joined #yocto
<JosefHolzmayrThe>
so you'd say -P means "use the expose definition that the dockerfile gave for the container"?
<qschulz>
JosefHolzmayrThe: wouldn't make sense that it exposes all listening ports, that's a security issue. But wouldn't be the first time I'm surprised :)
<qschulz>
JosefHolzmayrThe: let's check what podman says :)
<frampy>
Hi all, is anyone able to advise on how to install a file to a different partition from the rootfs?
<frampy>
I'm trying to set up a r/w partition, as my rootfs is readonly.
<frampy>
Right now my r/w partition is set up as an empty filesystem in my wic, I'm wondering if I need to use a wic plugin to populate it?
<fleg>
frampy, the way I did it in a similar situation (not exactly yocto) was to create a systemd unit that was only executed at first boot, that extracted files to other partitions etc.
<fleg>
I wonder if there's a nicer way to handle it in Yocto
<frampy>
Hi fleg, yes I was considering that approach, I could set the service up so that wiping the r/w partition would result in it being re-populated with defaults, which would be a nice "factory reset" option
arlen has joined #yocto
arlen_ has quit [Ping timeout: 252 seconds]
<fleg>
yup, that's also an upside. The only issue I see is that you need to have the initial state of that partition somewhere on your r/o partition, that can cost some valuable flash space, but that's not always an concern. Also, if implemented correctly, that might handle the "multiple r/o partitions for firmware, one r/w partition for data" scenario
<JosefHolzmayrThe>
it depends quite a bit on the specific requirements, but generally a service early in the boot process who checks some kind of flag and then populates can be a pretty elegant solution.
<JosefHolzmayrThe>
you could even go for flags stored in bootloader space
RP has quit [Remote host closed the connection]
<frampy>
thanks guys I'll look into this method a bit more
<frampy>
it looks like Android does something similar
Guest95 has joined #yocto
Guest95 has quit [Client Quit]
frampy has quit [Ping timeout: 256 seconds]
RP has joined #yocto
derRicha1d is now known as derRichard
gwhiteley has quit [Quit: Client closed]
BCMM has joined #yocto
zyga_ has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
tnovotny has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w_ has quit [Remote host closed the connection]
locutusofborg_ is now known as locutusofborg
locutusofborg has joined #yocto
locutusofborg has quit [Changing host]
<RP>
The irony of fixing the reproducibility and reuse enough it breaks the testcases :/
alessioigor has quit [Quit: alessioigor]
prabhakarlad has joined #yocto
arlen has quit [Ping timeout: 252 seconds]
arlen_ has joined #yocto
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
<qschulz>
while at it, could the people changing the chan topic modify the YP links to use https :) ?
frampy has quit [Ping timeout: 256 seconds]
frampy has joined #yocto
zyga_ has joined #yocto
sstiller has joined #yocto
ex-bugsbunny has quit [Quit: Client closed]
thekappe has joined #yocto
<thekappe>
hello world !
grma has joined #yocto
<JPEW>
tlwoerner: Ars Technica used to have a section that was called "CPU Praxis and Theory" It went into the inner workings of the Pentium 1 through Pentium 4 (and I think the Pentium M also?)
<JPEW>
tlwoerner: It was almost 20 years ago, I can't seem to find all the articles anymore
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
kiran_ has joined #yocto
ex-bugsbunny has joined #yocto
sstiller has quit [Quit: Leaving]
ex-bugsbunny has quit [Client Quit]
tre has quit [Remote host closed the connection]
Flumpy33 has quit [Ping timeout: 268 seconds]
vd has joined #yocto
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
tnovotny has quit [Quit: Leaving]
<vd>
Can an image recipe set its PREFERRED_PROVIDERs? I think it can't, but wouldn't it make sense for an image to embed a different kernel or package version if it needs to?
<RP>
vd: it can't
<RP>
vd: I know you;d like to do that but bitbake can't have per image task graphs!
<qschulz>
vd: there's a possible hackish way for different package version by having a recipe with a slightly different name and include only the one you want int he image recipe
<qschulz>
obviously you need to repeat the hack for all recipes that depends on said package
<vd>
RP: I see, an image recipe is just a recipe after all
<qschulz>
exactly
<qschulz>
so the variable context applies only to that recipe
<vd>
graphics support is something you want to shred from the image if you're not using it but at the same time, it impacts the userspace, to this limitation makes sense...
vmeson has quit [Ping timeout: 252 seconds]
<vd>
so if I want both graphics and graphics-less images, I need to define two machines and build the images via multiconfig I suppose.
whuang0389 has quit [Quit: Client closed]
rfuentess__ has quit [Remote host closed the connection]
<RP>
JPEW: the comparison tests were so close. After modifying the file, we need to update the pyc files, gah :)
<RP>
JPEW: or probably exclude them in fact
<JPEW>
You probably don't want the pyc files in sstate anyway?
<JPEW>
Not sure about that
<RP>
JPEW: I think they should be ok but it is an interesting question
<RP>
JPEW: interestingly, with these patches applied, it looks like reproducibility of some other recipes breaks. I don't know if this is some kind of cache artefact of what happened :/
<RP>
JPEW: diffoscope going for a few hours with no output yet :(
<RP>
JPEW: font-alias is a timestamp mismatch, libnewt is removed pthread linkage
<RP>
libxml is pthread too. Now the question is why. I suspect this some kind of legacy cross linked hashes :/
jmiehe has joined #yocto
<khem>
vd: yes
<vd>
khem: thank you. Does the distro need the "opengl" feature to makes this all work?
<khem>
hmm you can use it over directfb too IIRC
<khem>
they have eglfs-kms and eglfs buffer
<vd>
khem: eglfs is what I want ultimately, to run qtwebengine on framebuffer directly. But meta-ti's um driver has DEPENDS += "wayland" at the moment...
leon-anavi has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
<vd>
ant__: I don't understand what you just said ^^
<vd>
ant__: my goal is to run qt-kiosk-browser on beaglebone (ideally with eglfs). Isn't it the way to configure this?
<ant__>
atm I am working on STB hardware, they provide closed-source drivers variously challenged
<ant__>
I'd exoect beaglebone to work flawlessy nowadays :)
<vd>
ant__ I meant in order to run qt-kiosk-browser (a qtwebengine application) on the beaglebone, is the local.conf section I've written in this http://ix.io/3Axg kas file the correct way to achieve it?
<ant__>
vd: I think some bogus line is asking for virtual/egl at runtime. Which recipe?
<ant__>
you should see the cull error
<ant__>
*full
<vd>
This is trying to build core-image-weston with INSTALL_IMAGE += qt-kiosk-browser
<ant__>
I mean around Nothing RPROVIDES 'virtual/egl'
<ant__>
what is the chain?
<vd>
Missing or unbuildable dependency chain was: ['core-image-base', 'virtual/egl']
<vd>
(I tried core-image-base instead of core-image-weston, but same error)
RP has quit [Remote host closed the connection]
florian has quit [Ping timeout: 252 seconds]
argonautx_ has joined #yocto
<ant__>
vd, I'd say the problem is in the IMAGE_INSTALL_APPEND
argonautx has quit [Ping timeout: 252 seconds]
<ant__>
IMAGE_INSTALL and RPROVIDES_${PN} use package-name
<vd>
ant__ you're not supposed to install the virtual/*gl* packages explicitly? What about virtual/gpudriver?
<vd>
or ti-sgx-ddk-km shouldn't PROVIDES = "virtual/gpudriver"
<vd>
ant__: if I set only IMAGE_INSTALL += "qt-kiosk-browser" (without the virtual/ packages), I got similar error but for virtual/libgl. I'm building core-image-base with IMAGE_FEATURES += "hwcodecs" and DISTRO_FEATURES += "wayland" and bitbake is now building
<vd>
hwcodecs doesn't seem useful, but it doesn't hurt
<ant__>
" the "virtual/" namespace is DEPENDS/PROVIDES only."
<ant__>
RP dixit
<vd>
ant__ I see, thank you
<vd>
hence my line PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km" is useless
goliath has quit [Quit: SIGSEGV]
yannd has quit [Ping timeout: 252 seconds]
<kergoth>
vd: that virtual is how you select what recipe to *build* not what reicpe to *install*. i don't see anything wrong with that PREFERRED_PROVIDER, but you'll have to install ti-sgx-ddk-km into an image, unless you also have an rprovider involved
<kergoth>
that is, can't use virtual/ in IMAGE_INSTALL
goliath has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
<vd>
kergoth: I see! Then meta-ti's RRECOMMENDS:${PN} += "ti-sgx-ddk-km" is correct to explicitly request this package
<kergoth>
yep
<vd>
paulbarker: I think you run into an issue with ti-sgx-ddk-km similar to "eurasiacon/build/linux2/toplevel.mk:230: eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or directory" in the past
leon-anavi has quit [Quit: Leaving]
RP has joined #yocto
<JPEW>
RP: OK, I've made some progress comparing sysroot contents... but there is a bit of a hang up and I'm not sure if it's because of a repro problem that actually needs fixed, or if it's some deeper problem: The core problem is that even in sysroot-components, there are still some host paths
florian has joined #yocto
<JPEW>
In particular, I was looking at curl, and sysroot-destdir/usr/bin/crossscripts/curl-config has host paths
<RP>
JPEW: right, hence my patch which filters out the pieces
<RP>
JPEW: there are quite a few of these
<RP>
JPEW: it is inevitable that there are some host paths in crossscripts so we just need to remove them for comparison purposes
amitk_ has joined #yocto
<RP>
JPEW: I did start working on a cleaner version of my patch but it was slow going
sakoman has joined #yocto
<JPEW>
RP: Fair. Can we assume that all scripts that have that sort of stuff will be in fixmepath ?
amitk has quit [Ping timeout: 252 seconds]
<RP>
JPEW: possibly, but that file is generated later than where I need that data
<RP>
JPEW: so it may work for you. We also have to filter out only the specific elements as there are other things in these files which need to influence the checksum. I got that wrong once already and it was rather messy :(
<JPEW>
Ya... for comparison we also have to know what that path actually is... I guess maybe we could just lop off TMPDIR anywhere we find it?
<JPEW>
heh
<RP>
JPEW: trouble is you have to do TMPDIR, COREBASE, SSTATE_DIR, TOPDIR and possibly others which may or may not overlap
<RP>
which is why I taught it about PATH and PSEUDO_IGNORE_PATHS
<moto-timo>
:/
<JPEW>
Ah
<moto-timo>
Yup
<JPEW>
... can we just throw the depsig file in the sstate archive? It would make my life a lot easier ;)
<RP>
JPEW: I did wonder about that
<RP>
JPEW: I wondered if we could just feed one of the sstate directories to the outhash function and get it regenerated
<JPEW>
For sysroot-components (at least) that would work
<JPEW>
Well.... except we don't know PATH and PSEUDO_IGNORE_PATHS from the time it was built
<RP>
true, that does only work for a subset :/
<RP>
JPEW: the way I'm currently masking those out, the actual value doesn't matter, was much easier that way
<RP>
but I do take the point about it being easier
<JPEW>
Sure... TBH it seems like including depsig in sstate is probably the most ideal; that is the actual data that we care about
<RP>
JPEW: I've long since tried to avoid doing this kind of thing :/
<JPEW>
RP: Why?
<RP>
JPEW: makes the files ugly to handle and I've had reproducibility concerns too
<RP>
I tried really hard to keep the sstate objects simple. We just keep bolting more and more complexity around them (and now into them)
<RP>
JPEW: do you remember why we need both zstd -T and pzstd ?
<JPEW>
RP: No. TBH I may have just not realized -T existed
<RP>
JPEW: you could wonder why I kept siginfo separately for example
<RP>
was that a good idea? I'm not sure anymore
<JPEW>
It makes comparison easier for sure
<JPEW>
(not having to extract it out of the sstate archive)
<RP>
JPEW: "it offers multithreaded decompression for files compressed by pzstd"
<RP>
JPEW: so if we use pzstd we can get parallel decompression
<RP>
is that important? good question
<JPEW>
RP: Hmm, I have (a possibly fabricated) memory that zstd in older hosts (18.04?) can't compress in parallel (only psztd can)
<RP>
JPEW: it looks like it is a recent option, not sure how recent
<JPEW>
OK, ya. That was why. I don't know how far back of hosts we support, but if you go back too far you need pzstd b/c zstd can't do parallel
<RP>
JPEW: 1804 has -T
<RP>
JPEW: versions on centos7+8 also do
<RP>
debian9 does not but uses buildtools
<JPEW>
OK, -T seems fine then
<JPEW>
I should probably update the bitbake compressor and drop pzstd from HOSTTOOLS
* JPEW
has to go eat
<RP>
JPEW: I'm not sure, I quite like the idea of parallel decompression
<vd>
There might be something to do with the beaglebone's TUNE_FEATURES and some check in ti-sgx-ddk-km, because I have a armel.mk not found while the recipe looks for armhf.mk, and I do have TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" currently set by the DEFAULT_TUNES ?= "armv7athf-neon"
<vd>
that seems wrong
kiran_ has quit [Ping timeout: 252 seconds]
argonautx_ has quit [Quit: Leaving]
<vd>
ls
* vd
changes window
jwillikers has quit [Remote host closed the connection]
Guest40 has joined #yocto
<Guest40>
If I am to try and build Linux for a board that doesn't is not supported. What are the things I should look out for?
<Guest40>
What will be the first things I would typically look for on the new board? Like Architecture etc
<vd>
Guest40: writing a "machine" configuration file for this board, describing its CPU, kernel, bootloader, device tree, etc.
angolini has quit [Quit: Connection closed for inactivity]
<Guest40>
@vd This just involves configuring the CPU and packages you need on the OS right? What if you didn't have bitbake?
<Guest40>
I haven't done yocto in a while although I remember imx6 was pretty smooth sailing with it
<khem>
so I wonder why its adding rdep on glib-2.0-dev then
<khem>
this use to work ok
<moto-timo>
khem: I was wondering the exact same thing
<vd>
guys I'm overriding TARGET_VENDOR or even ABIEXTENSION, but the value of TARGET_SYS is still the same, what am I doing wrong?
<kergoth>
use bitbake -e to make sure the variables you're setting have actually changed, to start with
<vd>
kergoth that's how I figured that TARGET_SYS wasn't changed
<kergoth>
i didn't say to check TARGET_SYS, but to check that TARGET_VENDOR is correct. but it will also show the history of the changes to TARGET_SYS and TARGET_VENDOR both so you can see what overrode your value.
<vd>
kergoth: I have this http://ix.io/3Ay7 and bitbake -e ti-sgx-ddk-km | grep ^ABIEXTENSION= shows eabi, not eabihf
<vd>
(that's a KAS configuration file, but it basically generates the local.conf file and call bitbake for you)