<LetoThe2nd>
abelloni: i'm kinda disappointed we didn't make it through all of the bottle. almost there, i think there's only like 5-10 shots left in it.
manuel1985 has joined #yocto
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
tnovotny has joined #yocto
alessioigor has quit [Quit: alessioigor]
behanw has quit [Quit: Connection closed for inactivity]
<abelloni>
LetoThe2nd: didn(t you get a refill at Teeling ? :)
<LetoThe2nd>
abelloni: i just refilled myself.
<abelloni>
Did you try poitín?
<LetoThe2nd>
abelloni: no, at least not consciously. i tried the three at teeling, bought kilbeggan single pot and single grain (and handed out those two), and had a classic bushmills black at the airport to wrap things up.
<abelloni>
we stayed a bit behind during the distillery tour and we chatted with one of the workers there
<abelloni>
he said we could ask for poitín at the bar
<abelloni>
this was 72% of alcohol
<LetoThe2nd>
hmm but thats no fun to drink straight.
<LetoThe2nd>
the internets say teeling poitin is 52.5%, that sounds more reasonable.
<abelloni>
the bottled one, yes
<LetoThe2nd>
heh so they gave you a cask ;-)
zpfvo has quit [Ping timeout: 264 seconds]
<abelloni>
well, it was in a bottle but not a commercial one
<abelloni>
it is a part they sample before mixing
zpfvo has joined #yocto
<LetoThe2nd>
ah cool
<LetoThe2nd>
i got pulled into "things" towards the end of the teeling party with the cisco and comcast people.
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
tnovotny has quit [Quit: Leaving]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
d-s-e has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<mcfrisk>
is there a variable which points to a specific meta layer path? I'd use it for 'git describe'
davidinux has quit [Ping timeout: 244 seconds]
<mcfrisk>
not sure if using TOPDIR is a good idea..
<qschulz>
mcfrisk: LAYERDIR?
davidinux has joined #yocto
<mcfrisk>
LAYERDIR: "When used inside the layer.conf configuration file, this variable provides the path of the current layer." But I'm looking for this outside of layer conf..
<mcfrisk>
I can use the same path which is in bblayers.conf since that is generated, a bit of a hack but could do
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
<qschulz>
mcfrisk: set a unique variable with LAYERDIR in it?
kriive has quit [Remote host closed the connection]
kriive has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<fabatera[m]>
Would anyone confirm whether the following should work:
<fabatera[m]>
Running bitbake -c devshell virtual/kernel from a docker container running inside a screen session.
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #yocto
seninha has joined #yocto
mckoan is now known as mckoan|away
<rburton>
mcfrisk: what do you actually want to do? bitbake has functions to give you the layer/version breakdown you see when the build starts. if you want to save the layer path then just do an immediate assignment in layer.conf, ie MY_LAYER:= "${LAYERDIR}"
<mcfrisk>
rburton: I want to create a BUILD_ID for a layer which uses kas to setup all needed layers. Then use that for os-release, image file and SDK versioning.
* RP
has wondered about having a better API for layers in this area
<RP>
it is also risky though as far too easy to hardcode layer paths into sstate sigs
alessioigor has joined #yocto
<rburton>
RP: mcfrisk there is poky-contrib:ross/layerpath...
<mcfrisk>
I think I'll contibute a simple git-describe.bbclass which can be used for such, I'll document examples there.
<rburton>
mcfrisk: have you seen image-buildinfo.bbclass?
<rburton>
extending buildcfg.py to have a describe function would make sense
zpfvo has quit [Ping timeout: 252 seconds]
zkrx has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zkrx has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
seninha has quit [Quit: Leaving]
<RobertBerger>
@fabatera[m]: yes this works, I use it from byobu on top of the screen session ;)
seninha has joined #yocto
prabhakarlad has quit [Quit: Client closed]
kevinrowland has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<qschulz>
mcfrisk: if you want to change SDK_VERSIOn/DISTRO_VERSION/MAINTAINER< why not just define a new distro which includes poky.conf?
<qschulz>
and change them there?
<rburton>
or just write your own distro, don't use poky for production!
zkrx has quit [Ping timeout: 264 seconds]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
goliath has joined #yocto
goliath has quit [Remote host closed the connection]
goliath has joined #yocto
rob_w has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
rburton: the other bug we really need to fix is this systemd one with the postinst issue that keep affecting avahi
* RP
suspects that may be our most frequently occurring now
<fabatera[m]>
<RobertBerger> "@fabatera[m]: yes this works..." <- Thank you! Something is missing here then. I get only a blank new line after running bitbake -c devshell ...
tre has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 268 seconds]
<mcfrisk>
qschulz, rburton: yea but my 'product' is just an intermediate meta layer with some features added on top of poky, meta-oe etc. When testing the binaries I still want to know what versions are on target. It's all based on poky and with as few changes as possible. I can host the bbclass also elsewhere, it's that tiny..
davidinux has joined #yocto
vladest has quit [Quit: vladest]
<JPEW>
RP: Can we just use `bc` instead of postinstall scripts maybe
vladest has joined #yocto
<qschulz>
mcfrisk: I think we are more challenging the = => ?= change in poky.conf
<qschulz>
mcfrisk: I would very much not have this, because I already foresee users coming to us with logs where the distro says poky but the version is like 100.5.18-gdecaf and this will make it a bit harder to get the proper information quickly
<qschulz>
(it's often important to know which version of poky git repo the user is using, this does it pretty well if they're using poky)
davidinux has quit [Ping timeout: 252 seconds]
vermaete has joined #yocto
sakoman has joined #yocto
<vermaete>
Could it be that 'touchscreen' is still in the documentation, but not anymore in the code as MACHINE_FEATURE.
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<rburton>
using run-postinsts in the dnf.py tests does seem overkill. thats got invasive and non-trivial postinsts
<JPEW>
rburton: Ya, that what I was thinking also
vermaete has quit [Quit: Client closed]
seninha has quit [Quit: Leaving]
<rburton>
RP JPEW i can poke at this now
thomasd13 has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
ecdhe has joined #yocto
<RP>
JPEW: I was thinking a bit more. We know dnf will be installed to run these tests so I suspect we can use some dependency of dnf :)
<RP>
rburton: ^^^
<RP>
maybe some dbg package?
<JPEW>
Oh, ya a -dbg package would probably work well. A "normal" package would probably break dnf when it's uninstalled though
<RP>
I wonder if we should create a test package somewhere specifically for this
seninha has joined #yocto
davidinux has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
seninha has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
jmiehe has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Tokamak has joined #yocto
seninha has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
kscherer has joined #yocto
Guest634 has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Minvera has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
zpfvo has quit [Quit: Leaving.]
<zwelch>
i find myself spec'ing a microcontroller to offload some CPU tasks: gpio, rs232, i2c, and a few low-level timing-critical tasks. I can find a part to satisfy my requirements easily enough (leaning toward something with a Cortex M), but good silicon is not enough. The question I have here today is along the lines of "who is the least evil vendor?" when it comes to uC tools, such that I can build my firmware in Yocto from source using out-of-th
<zwelch>
e-box support.
<fray>
Cortex M (or R) doesn't build directly from YP in most cases. You'll need something like Zephyr or other custom (non-Linux) OS or baremetal config..
<zwelch>
For more context, I want the binary firmware to be bundled into the RFS, such that the CPU can update the uC as needed.
<fray>
with that said there are some vendors who do have baremetal compilation support as part of the Yocto Project.. but it's pretty spotty (to the best of my knowledge)
<zwelch>
Right, the uC firmware will be a non-OS.
alessioigor has quit [Quit: alessioigor]
<fray>
I'm not familiar with most of the current semis for ARM based systems that include M/R functionaity on the same chip. (I work for AMD/Xilinx, I'm really only familiar with our stuff)
<zwelch>
IIRC, doesn't the BBMULTICONFIG stuff enable this kind of scenario?
<fray>
yes it can. Where I am, we're JUST startign to use multiconfig to do that kind of thing. For instance out ZynqMP FPGA SoC contains Cortex-A, Cortex-R and Microblaze CPUs (in addition to the FPGA logic which could say be turned into a risc-v).. We've got code [reccently released as EA] that uses multiconfig to build all of the parts and pieces from source for their respective ISAs..
<fray>
but multiconfig really is (IMHO) the right way to do it. This way developers who only care abou tthe baremetal can do "single" builds for their work.. but a system integrator can do a master build of everything
<rburton>
zwelch: meta-arm has plenty of examples of using the prebuilt arm gcc for M to build eg TF-M. I want to move that to multiconfig as fray says, but this way works...
prabhakarlad has quit [Quit: Client closed]
<zwelch>
fray: Yup, i"m wearing both hats. I get to write the firmware and then integrate the image into the RFS, just as soon as I spec the part and have our EE integrate it with the next rev of the board. The BBMULTICONFIG support seems a natural fit, and it sounds like the `meta-arm` bits that rburton just mentioned would let me build this firmware. Seems possible, at least.
<zwelch>
Thanks for the leads. :)
alessioigor has joined #yocto
<rburton>
zwelch: the short version is that meta-arm-toolchain ships recipes for the binary releases of the arm toolchains for R and M cores, so your firmware recipe can just depend on them and use them to build
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
manuel__ has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
manuel1985 has quit [Ping timeout: 264 seconds]
manuel__ has quit [Ping timeout: 265 seconds]
PhoenixMage has quit [Ping timeout: 244 seconds]
PhoenixMage has joined #yocto
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
seninha has quit [Ping timeout: 244 seconds]
seninha has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
jmiehe has quit [Ping timeout: 264 seconds]
Tokamak has joined #yocto
sakoman has quit [Quit: Leaving.]
frosteyes1 has quit [Quit: WeeChat 2.8]
frosteyes has joined #yocto
<mischief>
for some reason my kernel recipe fails in do_kernel_configme. it seems that it fails because ccache is not in $PATH. my recipe for the kernel uses inherit ccache, but i don't see ccache in recipe-sysroot-native/usr/bin/. any idea what i can do about that?
otavio has quit [Ping timeout: 252 seconds]
mvlad has quit [Remote host closed the connection]
zkrx has joined #yocto
ferlzc has joined #yocto
<ferlzc>
Hi, i`m trying to use libssh2 recipe as a dependency to compile a custom recipe that needs it to compile. The problem is that I'm not figuring out which is the correct way to pass to gcc the path o libssh2 provided by yocto.
<ferlzc>
I'm trying to use EXTRA_OECONF += "lib=${STAGING_LIBDIR}/libssh2"
<ferlzc>
if I check via devshell, the recipe-sysroot/lib/libssh2 exists but the folder is empty
<ferlzc>
and I'm unable to find the libssh2.so
<ferlzc>
any direction on where I should look?
<mischief>
ferlzc: did you add it to DEPENDS? you probably want to use pkgconfig to find it properly.
<ferlzc>
yes I did, how do I use pkgconfig to find the proper path?
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 268 seconds]
xmn has quit [Quit: ZZZzzz…]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
creich has quit [Read error: Connection reset by peer]
creich has joined #yocto
creich has quit [Remote host closed the connection]
creich has joined #yocto
creich has quit [Remote host closed the connection]
Saurabh has joined #yocto
Minvera has quit [Remote host closed the connection]
Saurabh has quit [Quit: Client closed]
<mischief>
ferlzc: usually you use pkg-config --cflags for compiler flags and pkg-config --libs for linker flags.
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
seninha has quit [Quit: Leaving]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
jmiehe has joined #yocto
sakoman has joined #yocto
jmiehe has quit [Quit: jmiehe]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
zwelch has quit [Ping timeout: 250 seconds]
zwelch has joined #yocto
<khem>
jaskij: rusts rolling release model is not inline with yocto release model as you are seeing the effects and it’s a hard sell because the way they distribute the compiler and dev env is via rustup and abstracts on top of distros
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<khem>
And it’s not a problem on desktop distros or native environments since you can always keep up with rustup however cross build infrastructures like yocto has problems
<khem>
Best is to raise the awareness maybe it will stabilize with editions and I am hoping of you write your a/w conservatively and pin to older editions you might not have a big need for newer compilers
<khem>
Right now the modus operandi is update the compiler and move on and to their credit they have made it quite simple to do so with rustup it’s a dream for developers but a nightmare for release engineers
ferlzc has quit [Quit: Leaving]
<moto-timo>
@khem ++
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<jaskij[m]>
I have had no troubles so far, but if their libc FFI drops 1.59 using Rust with Yocto will likely become hell.
<jaskij[m]>
khem @khem:matrix.org: my whole point of pinging you was that I hoped someone with more knowledge would participate in that issue. I know at least the RHEL and Fedora maintainer did join.
<jaskij[m]>
I read Cargo's dock a few times and it does not seem like `--locked` or `--frozen` do what we'd want and keep the build to specific update versions.
<jaskij[m]>
And asking the Rust team to backport features will go nowhere. FYI there's a `MSRV` field introduced which, once Cargo's resolver takes it into account, hopefully use solve this issue.
<jaskij[m]>
Urgh, sorry for the wall of text, Element erased my newlines
<mischief>
speaking of rust, do you guys know if it's possible to make statically linked binaries with rust in yocto?
<mischief>
the ones i tested out were all dynamic.