|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dodoradio has joined #yocto
dodoradio has quit [Quit: dodoradio]
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Ablu has quit [Remote host closed the connection]
yates_work has quit [Ping timeout: 245 seconds]
AKN_R has quit [Ping timeout: 252 seconds]
Ablu has joined #yocto
kpo has quit [Ping timeout: 256 seconds]
AKN_R has joined #yocto
Ablu_ has joined #yocto
Ablu has quit [Remote host closed the connection]
Ablu_ is now known as Ablu
<dvergatal>
LetoThe2nd: RP: As I said I'm NOT in a hurry, for me it is REALLY OK that we can wait, besides holidays are SAINT for every worker, that is including me \m/ =^.^= \m/ niah niah :P
<LetoThe2nd>
dvergatal: +1
<dvergatal>
just wanted to get the information to say to my co-workers that we need to arm in patience that's all :P
<RP>
dvergatal: I appreciate that, thanks :). Just to be clear though, feature freeze is in two weeks and if this doesn't merge by then, it would have to wait until October when the new development window opens
Ablu_ has joined #yocto
<dvergatal>
dvergatal: n/p, just to be clear I hate to rush and I respect everyone's time
<dvergatal>
RP: ^
Ablu has quit [Remote host closed the connection]
<dvergatal>
RP: haven't noticed I was typing to you and written to myself:P
<dvergatal>
RP: OK, the window doesn't matter for us, we just want to have it to not lose it and not to develop it just for us
<RP>
dvergatal: I do think we will need to support acls, it is just a question of getting it right. I just want to be clear about the timings and the slightly unusual risks this particular set of patches seems to have!
Ablu_ is now known as Ablu
<dvergatal>
RP: I agree, and I also share your distress since I don't understand what could have happend there what really bothers me
Ablu has quit [Remote host closed the connection]
Ablu has joined #yocto
<dvergatal>
RP: btw. I've been talking to Alex regarding the opkg and opkg-utils patches and he already applied the one regarding locales, whereas the one which touches opkg-build script he asked me to apply one additional fix, which I already did and sent to him so it will be applied also in a moment or two
kpo has joined #yocto
<Ablu>
RP, mcfrisk: Ah... I only checked whether other Rust recipes already existed (which they did), but of course clang-native is another set of dependencies on top of llvm...
Xagen has joined #yocto
AKN has joined #yocto
Ablu has quit [Read error: Connection reset by peer]
AKN_R has quit [Ping timeout: 245 seconds]
Ablu has joined #yocto
|Xagen has joined #yocto
Xagen has quit [Ping timeout: 245 seconds]
AKN has quit [Read error: Connection reset by peer]
<khem>
RP: that recipe needs rust bindgen which depends on libclang
<khem>
I am seeing more and more tools of such kind these days
<khem>
RP:
<khem>
perhaps we should think about making llvm recipe in core to build clang as well at the least to solve this issue but then it wont be llvm but more than that. perhaps time to think about supporting clang in core
<abelloni>
dvergatal: RP: I still have the branch that exhibited the issue but I guess I would have to run that on the AB to get the proper has
<abelloni>
I'm not sure this would work locally
<khem>
RP: we also need to generate new uninative with glibc 2.38 btw.
goliath has quit [Quit: SIGSEGV]
<RP>
khem: patch in -next but it doesn't work
<RP>
Reported to Alexis in relation to gitarchive patch
<khem>
ok
alessioigor has quit [Quit: alessioigor]
dvergatal has quit [Read error: Connection reset by peer]
dvergatal has joined #yocto
vladest has quit [Ping timeout: 248 seconds]
<michele_>
Hi, I am trying to build timescaledb-toolkit. I had some issues I solved, however now I am blocked with building rustfmt. I saw the recipe in meta-rust, however it requires the nightly toolchain - and I think this is the reason it was removed when merging meta-rust to oe. Do you have any hint how to build and use the nightly toolchain?
rfuentess has quit [Remote host closed the connection]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
<khem>
nightly toolchain I think is not available even in meta-rust, is it something that will flow into next rust release I would suggest to wait for that, rust has frequent releases
Kubu_work has quit [Quit: Leaving.]
florian has quit [Quit: Ex-Chat]
alessioigor has joined #yocto
Pinta has joined #yocto
Pinta has quit [Client Quit]
goliath has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<adrianf>
Does anyone have experience with ptests for kernel modules? Our problem is that the combination of e.g. inherit cmake (to compile the test) and inherit module (to compile the kernel driver) obviously cannot work (both bbclasses define the same task like do_compile). Using two recipes would of course work, but has other disadvantages.
prabhakarlad has joined #yocto
amitk has joined #yocto
leon-anavi has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
<RP>
adrianf: I've never seen anyone do both together
<RP>
adrianf: lttng-modules and lttng-tools is the separate recipe approach
starblue has quit [Ping timeout: 245 seconds]
alessioigor has quit [Quit: alessioigor]
zpfvo has quit [Remote host closed the connection]
<adrianf>
RP: Thank you. Knowing that there is no proven approach is also helpful.
tangofoxtrot has joined #yocto
<khem>
adrianf: if you want to take advantages of pre-defined tasks then you have to separate out module into its own recipe, if you want to keep both userspace piece and kernel piece together for whatever reason then you will have to override the pre-populated tasks and re-implement them in recipe. I know some sourcecode where these things are needed
<adrianf>
khem: One reason why I would prefer to have them handled by one recipe is working with external sources respectively devtool modify. This is more handy when the driver and the test are in one git repo which needs to be cloned and setup only once.
<khem>
yes I understand :) you have to know the compromises
<RP>
khem: there is something different with glib 2.38, our search patch tweaks aren't working :(
Wenqing has quit [Remote host closed the connection]
florian has quit [Ping timeout: 256 seconds]
<khem>
RP: Buildtools does not provide GCC
<khem>
is that the error narrowed down
<RP>
khem: the problem is the libc within buildtools, nothing to do with gcc
Wenqing has joined #yocto
<RP>
khem: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by /home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-extended-tarball/1.0/testimage-sdk/bitbake-build-4x_nam_t/tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib64/libpseudo.so)
<RP>
khem: it should have found the one in uninative :(
<khem>
which process loads libpseudo.so
<RP>
khem: that build is building a buildtools-extended-tarball, extracting it and running a build under buildtools
Kubu_work has joined #yocto
<RP>
khem: so it is bitbake inside bitbake that runs pseudo, looks to be server side failing
<RP>
the RUNPATH for libpseudo.so is XORIGIN/../../../sqlite3-native/usr/lib/:/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-extended-tarball/1.0/testimage-sdk/bitbake-build-4x_nam_t/tmp/work/x86_64-linux/pseudo-native/1.9.0+git/recipe-sysroot-native/usr/lib:/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-extended-tarball/1.0/testima
vladest has quit [Remote host closed the connection]
JonathanFischer has joined #yocto
<JonathanFischer>
Hi there, I'm not sure where exactly to look for this, but: I'm using Yocto to build images for a couple of devices. Those devices have identical CPUs and other hardware, and only differ in the amount of memory and SSD size on them. Is there a good way to set up machine definitions in such a way that the various packages I'm building get shared
<JonathanFischer>
between the two of them so I don't end up building each recipe twice?
<khem>
JonathanFischer: these seems like can have 1 machine definition and same image would run on both with. no issues
<JonathanFischer>
At the moment I have a common include file that provides 99% of the configuration and two machine configuration files that include that file and specify different Wic scripts for the partition layout. It's working, but I build all of the recipes twice.
<JonathanFischer>
Manually overriding WKS_FILE in my local.conf for one of the devices works as well, but I was hoping to capture the differences in my BSP layer.
vladest has joined #yocto
<JonathanFischer>
The same image definitely works on both, but on the one with a larger SSD the remaining space doesn't get partitioned.
<khem>
JonathanFischer: yeah I dont know how you define your image but generally if image size is same then you want one partition which is r/w to grow at runtime
<khem>
systemd can do it
yates_work has joined #yocto
<khem>
or look at 96boards-tools recipe
<khem>
that can do it too
amitk has quit [Ping timeout: 258 seconds]
flom_84 has joined #yocto
amitk has joined #yocto
<JonathanFischer>
We have a set of partitions that kind of need to remain fixed size to support field updates.
<khem>
so you write the full SSD on update ?
<khem>
I thought only rootfs is what is updated and data partitions are kept
<khem>
do you have different storage for persistent data
<JonathanFischer>
We have an active/inactive partition setup, data isn't kept separate at the moment.
<khem>
then update is almost like factory reset then
<JonathanFischer>
That might do the trick, thanks!
yates_work has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 245 seconds]
yates_work has joined #yocto
<dvergatal>
abelloni: ok thx
<dvergatal>
abelloni: JFYI we need the package_tar.zst file(s) from sstate for wrong ipks
<yates_work>
i built the qemuarm emulator in my previous lubuntu session, then rebooted. now when i try to run a command in a normal, native xterm under lubuntu i get: /lib/ld-linux-armhf.so.3: No such file or directory
<yates_work>
any clues what's happened?
<yates_work>
i checked my LD_LIBRARY_PATH and it looks normal
yates_work has quit [Remote host closed the connection]
<yates_work>
nm, found it. i had copied the entire /usr/bin folder of my qemuarm machine into bin in my lubuntu home folder. apparently that is a standard place to look for binaries
<yates_work>
i did that because i wanted to look at someof the binaries, and i thought the bin folder in my home directory was a safe place.
<yates_work>
pfzzzt!
JonathanFischer has quit [Quit: Client closed]
<yates_work>
can someone please suggest how i would modify core-image-sato to use openssh instead of dropbear?
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Chaser_ has quit [Quit: Chaser_]
<LetoThe2nd>
yates_work: as usual, create your own custom image
flom_84 has quit [Ping timeout: 245 seconds]
Estrella has joined #yocto
prabhakarlad has joined #yocto
sakoman has quit [Quit: Leaving.]
yates_work has quit [Ping timeout: 252 seconds]
<sudip>
just noticed that when I am building openembedded-core the patches for kea are not getting applied, but when I am building it in poky the patches are applied. In openembedded-core, even "bitbake -c listtasks kea" is not listing do_patch in openembedded-core.
sakoman has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
paulg has quit [Ping timeout: 258 seconds]
starblue has joined #yocto
old_boy has joined #yocto
<old_boy>
I have a python() overload in my bitbake recipe and it is getting called twice one for ${pn} test-package and other for lib32-test-package, does anyone know if this is expected? I thought when multi-lib is enabled it is called only for 32 bit?
<RP>
JPEW: We could tweak the tests mechanism but we should document it can't cope with anything compex
<JPEW>
RP: What's the best way to document that?
<JaMa>
anyone seeing cross-localedef-native-2.38.do_compile failing with ../git/localedef/include/sys/cdefs.h:85:51: error: missing binary operator before token "("?