camus has quit [Remote host closed the connection]
camus has joined #yocto
prabhakarlad has quit [Quit: Client closed]
AKN has joined #yocto
sakoman has quit [Quit: Leaving.]
AKN has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
AKN has joined #yocto
duncan^ has quit [Server closed connection]
duncan^ has joined #yocto
rfuentess has joined #yocto
Flo88 has joined #yocto
Flo88 has quit [Client Quit]
Flo72 has joined #yocto
mkazantsev has joined #yocto
AKN has quit [Read error: Connection reset by peer]
rob_w has joined #yocto
mvlad has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
torbenh3 has quit [Ping timeout: 256 seconds]
torbenh3 has joined #yocto
manuel_ has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
Flo72 has quit [Quit: Client closed]
Guest28 has joined #yocto
<Guest28>
Hi
<Guest28>
I am having issues with the apt on yocto
<Guest28>
updating apt-get removes the .so files and the image is corrupted
Guest28 has quit [Client Quit]
zpfvo has joined #yocto
florian_kc has joined #yocto
<PhoenixMage>
You're using apt-get inside an image?
seccar has joined #yocto
<LetoThe2nd>
yo dudX
<LetoThe2nd>
PhoenixMage: gone already
<PhoenixMage>
Ah yeah, oh well
d-s-e has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Kubu_work has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<LetoThe2nd>
PhoenixMage: people randomly trying to magically make a YP image feel like debian are not exactly new, though.
zpfvo has quit [Ping timeout: 246 seconds]
* RP
notes we had a green nightly build. Sad this is such a occasion :/
ptsneves has joined #yocto
zpfvo has joined #yocto
gsalazar has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
zpfvo has joined #yocto
frieder has joined #yocto
adrian_ has joined #yocto
alessioigor has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
apt/dnf/opkg work inside an image just fine, i use it all the time
<rburton>
quicker to run a local python -mhttp.server and reinstall packages than rebuild an image
d-s-e has quit [Remote host closed the connection]
d-s-e has joined #yocto
amitk has joined #yocto
Guest21 has joined #yocto
<Guest21>
Hello, How do I cross-compile a python wheel with an yocto sdk?
<Guest21>
and what is the best way to do that
<Guest21>
?
<Guest21>
thank you in advance
florian_kc has joined #yocto
<PhoenixMage>
LetoThe2nd: Agreed, it takes a different mindset, I am doing a bit of casual work for the company a mate works for and took a while to get through that there is no package management
<landgraf1>
LetoThe2nd: I have package-management feature enabled in some debug images. As PhoenixMage mentioned it's much easier to test something by installing of the package (and much more predictable than scp'ing stuff here and there).
<LetoThe2nd>
landgraf1: i know and I'm not disputing that. but I've seen too many people like "i have added apt and tried to install from those debian repositories, why doesn't it magically work". if someone understands that package management in yocto implies also providing the package feed, i'm totally okay with it.
<qschulz>
landgraf1: you also have devtool upload or something like this to install some things without package management support in the image
<rburton>
Guest21: in theory, build it like usual.
<rburton>
Guest21: if that fails, tell us why :)
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
starblue2 has quit [Ping timeout: 252 seconds]
starblue2 has joined #yocto
dv_ has quit [Ping timeout: 240 seconds]
Patrick95 has joined #yocto
pidge has joined #yocto
<Guest21>
rburton the build doesn't fail, but the *.so lib as tags with _x86_64_ in its name, and it is the same with the *.whl file. But if we unzip it, and run the "file" command on it, it is cross-compiled aarch64 as well. The issue is when we "pip install" the whl file, it is refused by pip, because the name of the wheel or its soname lib contain x86_84
<Guest21>
in its name. I suppose the issue is not in the sdk, but I don't know how to force pip to replace x86_64 by aarch64 or something else. When it is cross-compiled with the sdk.
alessioigor has quit [Quit: alessioigor]
dv_ has joined #yocto
alessioigor has joined #yocto
<rburton>
amazing, well done python
<rburton>
so you can't use pip in a cross environment
<rburton>
is that pip install on the target after you transferred the file?
<Guest21>
yes
<rburton>
so basically python and cross is a nightmare
<rburton>
its entirely possible that our SDKs don't yet do all the magic needed
nemik has quit [Ping timeout: 240 seconds]
<Guest21>
ok
nemik has joined #yocto
xmn has joined #yocto
<Patrick95>
Hi all,
<Patrick95>
we want to push results from the cve-check directly to our elastic stack. Therefor I wanted to do a quick proof of concept and hacked the pushing into the cve-check.bbclass. I'm pushing with the python requests module. However from within the build I cannot get the connection but following error message : "Failed to establish a new connection:
<Patrick95>
[Errno 101] Network is unreachable'))"
<Patrick95>
From the same PC from a python shell it works absolutely fine.
<Patrick95>
How can this be explained?
<Patrick95>
Thanks
<Patrick95>
Hi all,
<Patrick95>
we want to push results from the cve-check directly to our elastic stack. Therefor I wanted to do a quick proof of concept and hacked the pushing into the cve-check.bbclass. I'm pushing with the python requests module. However from within the build I cannot get the connection but following error message : "Failed to establish a new connection:
<Patrick95>
[Errno 101] Network is unreachable'))"
<Patrick95>
On the same PC from a python shell it works absolutely fine.
<Patrick95>
How can this be explained?
<Patrick95>
Thanks
<rburton>
Patrick95: tasks don't have access to the network unless they ask for it
<rburton>
do my_task[network] = "1" alongside your task
<Patrick95>
rburton Thanks, will give it a try
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
kanavin has quit [Remote host closed the connection]
davidinux3 has quit [Quit: WeeChat 3.5]
bps2 has joined #yocto
bps has quit [Ping timeout: 240 seconds]
Patrick95 has quit [Quit: Client closed]
<paulg>
Happy Stonehenge Day!
Crofton has quit [Server closed connection]
Crofton has joined #yocto
rob_w has quit [Remote host closed the connection]
Flo95 has joined #yocto
<Flo95>
Hi everyone
<Flo95>
I have a question regarding modifications to the device-tree.. is it possible to view the final result after inclusion and patches?
<yocton>
Flo95: You can always decompile the dtb to dts and see what's in it
<Flo95>
That sounds good. Could you tell me in which environment the dtc is available? I tried using it in the devshell for virtual/kernel but I cannot seem to locate it.
jmk1 has quit [Server closed connection]
jmk1 has joined #yocto
marka has quit [Ping timeout: 240 seconds]
Patrick79 has joined #yocto
Patrick79 is now known as pvogelaar
<Flo95>
Ah, ok. Nevermind.. I can use the hosts dtc (after installing). I assumed that I needed an arch-compatible dtc.
<mckoan>
Flo95: you will find the resulting DTS in build/tmp/work-shared/MACHINENAME/kernel-source/arch/arm/boot/dts
<Flo95>
mckoan: are you sure? does the file get renamed? in my case the folder (.../work-shared/phyboard-segin-imx6ul-2/kernel-source/arch/arm/boot/dts) looks like it contains all the device-tree sources but i cannot find the final result after all includes and patches were done
<mckoan>
Flo95: look at your kernel recipe and machine configuration then
marka has joined #yocto
<Flo95>
mckoan: Sorry but I don't get it. Maybe it's just a misunderstanding. I know which "imx6...dtb" is expected from the machine configuration and I know where the corresponding dts file is located. But my understanding is, that this is just a copy of the source file from the kernel repo and not the final result after applying patches and includes. Am
<Flo95>
I wrong?
<qschulz>
Flo95: patches should already be applied in the source directory (likely WORKDIR/git ?)
<qschulz>
after the includes, the only way to get it is from the dtb indeed as far as i know
<qschulz>
Flo95: and you can decompile with `dtc -I dtb -O dts`
<Flo95>
Ah, okay.. Maybe I should have stated my goal, which is to remove a few unused sections (e.g. lcd support) and use the pins as gpios, and I assumed that I could patch against a finished tree and that this finished tree is located somewhere in the work-shared directory and can be modified before the dtc is called.
<Flo95>
Decompilation as yocton mentioned earlier worked just fine :)
<yocton>
Flo95: yay :)
<Flo95>
Hm when I delete a node using /delete-node/ and this particular note is added through a pathc after my owm patch wanted to remove it: What happens? ^^
kanavin has joined #yocto
<yocton>
No idea... but I usually limit my patching to the status = "okay"/"disabled" attribute
<qschulz>
Flo95: it's re-applied
<qschulz>
Flo95: I can also suggest to just override the whole device tree instead of patching it manually?
<Flo95>
qschulz: probably - for now all i did whas setting 'status = "okay"' and I am slowly trying to the grips whith the devicetree stuff. Another question/assumption: Limiting the device-tree size does not effect the boot-time much and it would probably wiser to limit the kernel size by remove unneeded modules?
camus has quit [Quit: camus]
<qschulz>
Flo95: the size of the device tree itself is very likely not really efficient
<qschulz>
however you can disable device tree nodes you don't use
<qschulz>
and/or strip down as much as you can from the kernel configruation
<qschulz>
then you have compression of the kernel itself (and potentially the initramfs if you're using one)
<seccar>
Hi guys, I was wondering if there is a rule that help to choose where to set "global" variable in local.conf or in distro/${DISTRO}.conf ? both being included from bitbake.conf ?
<rburton>
seccar: the only things in local.conf should be your local settings (where you want DL_DIR and SSTATE_DIR to be), the DISTRO selector, and any specific-to-your tweaks (like "add this packge to the image as i'm working on it").
<rburton>
seccar: the idea is that if someone clones your distro layer and sets DISTRO, it works
<rburton>
if you end up needing to commit local.conf files then you're doing it wrong
<fray>
My rule, does someone else need this setting to build the same thing? Likely not local.conf
<fray>
As rburton said.. local.conf is setting local to your specific build, not general things required for the build to work for others
<seccar>
Thanks for the tips sounds logical and sane :-)
florian has quit [Quit: Ex-Chat]
<fray>
The key places for configurations: recipes "does it affect this one recipe only?", distribution "does it affect [potentially] all recipes in this configuration?", machine "does it affect how the BSP is defined and how the build [think architecture, cflags, etc] is performed?" local.conf "my local build settings"
<fray>
(recipe includes individual image configurations as well)
florian_kc has quit [Ping timeout: 246 seconds]
marka has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
zpfvo has quit [Quit: Leaving.]
d-s-e has quit [Quit: Konversation terminated!]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
kpo has quit [Ping timeout: 260 seconds]
vladest has quit [Quit: vladest]
vladest has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bps2 has quit [Ping timeout: 240 seconds]
Peter[m]12 has quit [Remote host closed the connection]
jnugen[m] has quit [Remote host closed the connection]
cambrian_invader has quit [Server closed connection]
ptsneves has quit [Quit: ptsneves]
rfuentess has quit [Remote host closed the connection]
ptsneves has joined #yocto
cambrian_invader has joined #yocto
<RP>
kanavin: thanks for the reproducibility fix! Nice to have one less failure to worry about! :)
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kpo has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<zeddii>
RP/anyone. have an ideas about this multconfig error ? I'm trying to complete some cross container install features, and I'm no longer even able to get to my roots. I've cleaned perl about 5 times, diffreent ways and this always comes back.
<zeddii>
next I'm going to remove all of tmp and see if that helps.
<RP>
zeddii: I'd probably try a "bitbake perl" and see if that put the right files in place
<RP>
zeddii: I'd probably see if there is any perl manifest to compare against that search list
<zeddii>
unfortunately I tried that :( I did that, then a cleansstate -> build, cleanall -> build, and they always work, but when I bitbake "container-host" my BBMULTI image, it comes back.
roussinm has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<zeddii>
although, looking at it right now. I still see those rpm's being created, and the do_rootfs error has already been shown.
<zeddii>
that doesn't seem right
* zeddii
checks if a dependency is wrong.
<RP>
zeddii: it sounds as if dependencies aren't right
<zeddii>
yah. this is the same config I've had for a year, but I haven't worked on it for about 4 months, maybe my syntax is now wrong.
<RP>
zeddii: you're reminding me I need to change that code and ditch that message
<RP>
not that it will likely help your problem
<kanavin>
RP: cheers :) it was just a badly written test, because it takes any compiler fail whatsoever as 'does not satisfy the condition in c++ snippet'
<kanavin>
I additionally pointed this out to upstream
<kanavin>
'&& echo 1 || echo 0' is horrible
<RP>
kanavin: I'm just hoping the fix it somehow
<RP>
kanavin: I saw you'd filed an issue with them, thanks
<zeddii>
RP: yes, it is strange that I can't defeat the bad dependency by just explicitly cleaning it, but the recipe specific sysroot, etc, are doing their job.
<RP>
kanavin: I'm looking at the time64 pieces. I don't really like disabling lttng-tools and strace so I'm wondering if we can do better
florian_kc has joined #yocto
<kanavin>
RP: the disable is only for ptests on 32 bit x86?
<kanavin>
RP: and in both cases there are upstream tickets or upcoming versions that fix it?
<RP>
zeddii: cleaning shouldn't matter, its the fact you're building it so the manifest should exist...
<kanavin>
my memory is slightly fuzzy at this point...
<RP>
kanavin: lttng-tools 2.14 won't be until the end of the year but they're willing to consider a backport to 2.13 if we test it so I'm taking a look. I don't know what strace will do
<RP>
kanavin: disabling ptests like that doesn't look good :/
* RP
suspects lttng is probably broken
<RP>
strace is more problematic tests
marka has quit [Ping timeout: 260 seconds]
<kanavin>
RP: I see you're taking the option of disabling 64 bit time for those, which also doesn't look good :(
<RP>
kanavin: I tested it, it failed
<kanavin>
RP: did it? why?
marka has joined #yocto
<kanavin>
RP: I think it should work, as at some point I did run x86 ptest and it all passed
amitk has quit [Ping timeout: 240 seconds]
<RP>
kanavin: I thought it should work but it didn't :(
<RP>
kanavin: my preference is probably to exclude strace and fix lttng-tools with a backport
<kanavin>
RP: the next step is to look into runtime failures when qemu is set to the future post-2038 time
florian_kc has quit [Ping timeout: 240 seconds]
roussinm has joined #yocto
<RP>
kanavin: right, I just want to get the patch backlog resolved :/
<zeddii>
RP: yah, it's strange (to me). I can see one of the manifests exists. start the build, the error says it doesn't exist. I'm going to build the mc:container perl explicitly and see if that helps.
marka has quit [Ping timeout: 240 seconds]
gsalazar has quit [Ping timeout: 240 seconds]
prabhakar has quit [Quit: Connection closed]
marka has joined #yocto
marka has quit [Ping timeout: 258 seconds]
marka has joined #yocto
frieder has quit [Remote host closed the connection]
<kanavin>
rburton, I vaguely remember someone (probably this very person) invited me to join a cross-compile python sig in one of the pull requests to fix a specific issue, but I dont remember when and where
<rburton>
looks like we can't cross build python extensions in a sdk because the target sysconfig magic isn't packaged
<rburton>
but i need to go instead of digging further
beroset has joined #yocto
florian_kc has joined #yocto
adrian_ has quit [Remote host closed the connection]
adrian_ has joined #yocto
beroset has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
dacav has joined #yocto
<dacav>
Hi. I've promoted a certain package to be in the SDK, so that developers can use it. I'd like to rebuild only the package and pass it to developers so that they can update the SDK without re-generating the whole if it. Could this be done?
adrian_ has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 240 seconds]
adrian_ has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian_kc has joined #yocto
RP has quit [Server closed connection]
RP has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
mvlad has quit [Remote host closed the connection]
<kanavin>
dacav, not with a classical SDK. with extensible sdk, or direct sdk there are options.
<dacav>
kanavin: thanks. What is the "direct" sdk?
<khem>
you might have some luck with your doom demo just in time !
<khem>
Alistair was kind enough to review them so all merged in now so just try master branch
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kevinrowland has joined #yocto
<kevinrowland>
Kind of an odd question: can I force a task hash to include the contents of a file without putting the file in SRC_URI? I want the task to re-run when the file contents change, but I don't really need to fetch the file.
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
<kevinrowland>
aha, the [file-checksums] varflag does exactly what I want