| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:00 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:16 | |
| *** MiskaX <MiskaX!g06thq0ncf@rankki.sonarnerd.net> has joined #yocto | 00:17 | |
| *** dreyna_ <dreyna_!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 00:24 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:27 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 00:33 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has quit IRC | 00:38 | |
| *** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto | 00:40 | |
| *** creich <creich!~unknown@ip5f5aa2a2.dynamic.kabel-deutschland.de> has joined #yocto | 00:58 | |
| *** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 01:32 | |
| *** creich <creich!~unknown@ip5f5aa2a2.dynamic.kabel-deutschland.de> has quit IRC | 01:40 | |
| *** Willy-- <Willy--!~william@drmons0552w-159-2-38-13.dhcp-dynamic.fibreop.ns.bellaliant.net> has quit IRC | 01:55 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-frnvfbnwqehqseql> has joined #yocto | 02:39 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC | 02:42 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d00:b1:225:90ff:feda:2428> has joined #yocto | 02:43 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d00:b1:225:90ff:feda:2428> has quit IRC | 03:01 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto | 03:04 | |
| *** Domin1k <Domin1k!c1669b04@193.102.155.4> has quit IRC | 03:04 | |
| *** gtristan__ <gtristan__!6e0be3b1@110.11.227.177> has joined #yocto | 04:08 | |
| gtristan__ | Hi, I'm trying to preserve the sstate cache directory between builds in a project which was previously not doing this, in order to increase build time... and in doing so I've encountered an error which appears to be quite exactly like this one: https://www.yoctoproject.org/pipermail/yocto/2016-June/030534.html , basically I get a "value foo.service | 04:11 |
|---|---|---|
| gtristan__ | does not exist" from do_package | 04:11 |
| gtristan__ | This only happens the second time, after checking out the whole fresh source tree a second time but rigging it up so that it's sstate-cache directory is a symlink to an out of tree directory where I preserved the cache from a previous (successful) build | 04:12 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 04:14 | |
| gtristan__ | Now, I've followed the advice of Matt Madison from the mentioned post and used systemd_system_unitdir instead of the previous "${systemd_unitdir}/system", and still get the same error... so my question (...drumroll...) is do I need to delete the sstate cache and start over in order to properly test my change ? | 04:14 |
| gtristan__ | Also, at the same time I'll start reading into systemd.bb in this project but, if there are any recommendations on how I should be debugging this that would be very helpful | 04:16 |
| gtristan__ | Extra verbose mode possible ? | 04:16 |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 04:19 | |
| yocti | New news from stackoverflow: Bitbake not installing files from recipe to rootfs <https://stackoverflow.com/questions/59206759/bitbake-not-installing-files-from-recipe-to-rootfs> | 04:40 |
| gtristan__ | Ok simpler question: Once I've sourced the set_bb_env for the given project and am ready to build things... how can I find out what the value of a given variable would be for a given recipe ? | 04:59 |
| gtristan__ | Like say, DISTRO_FEATURES for example, how can I print what bitbake thinks it is ? | 05:00 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 05:23 | |
| *** opello <opello!~opello@about/csharp/regular/opello> has joined #yocto | 05:24 | |
| opello | hi, it seems as of openembedded-core 6661718158f8fdcdf63b0d48e8fe72d3ac4778f2 the ultimate package architecture (TUNE_PKGARCH) has changed under some circumstances (including mine; from cortexa9hf-vfp-neon to cortexa9hf-neon) which makes generated rpms incompatible; the commit suggests there's a way to preserve an upgrade path, but i don't quite understand what "don't forget to migrate PR service database to new TUNE_PKGARCH" is suggesting | 05:29 |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has joined #yocto | 05:44 | |
| *** gtristan__ <gtristan__!6e0be3b1@110.11.227.177> has quit IRC | 05:45 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:00 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:21 | |
| *** pohly <pohly!~pohly@p5B0564A0.dip0.t-ipconnect.de> has joined #yocto | 06:49 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:59 | |
| *** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has joined #yocto | 07:02 | |
| bojones | If a recipe is depending on another package being installed, will IMAGE_INSTALL_append = " <package>" give the same result as RDEPENDS += "<package>" ? | 07:03 |
| bojones | The right way to specify the dependency, is using RDEPENDS, right? | 07:04 |
| bojones | Well, never mind my question before. After thinking about it for a while, the difference is obvious. | 07:08 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:08 | |
| yocti | New news from stackoverflow: Yocto - Files/directories were installed but not shipped in any package <https://stackoverflow.com/questions/49748528/yocto-files-directories-were-installed-but-not-shipped-in-any-package> | 07:11 |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 07:16 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:41 | |
| *** mckoan|away is now known as mckoan | 07:42 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:46 | |
| *** frsc <frsc!~frsc@i6DFA871A.versanet.de> has joined #yocto | 07:49 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 07:58 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 08:21 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qpvicoefgbzyjryo> has joined #yocto | 08:28 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 08:39 | |
| Ad0 | I can't seem to find a .gitignore template for yocto projects, maybe it's too variable. only thing I can think of is to ignore build directory | 08:53 |
| LetoThe2nd | ? | 08:54 |
| LetoThe2nd | just ignore the buld directory, done. | 08:54 |
| * alessioigor waves all | 09:04 | |
| alessioigor | I'm trying to find what package add a file into the image. To do this I use find into all "image" directory of all packages. Unfortunately after first build bitbake doesn't make the image directory. How force it to do it? | 09:04 |
| alessioigor | Thanks in advance! | 09:05 |
| LetoThe2nd | alessioigor: oe-pkgdata-uril | 09:06 |
| LetoThe2nd | util, even | 09:06 |
| angelo__ | hi, is there a simple way to know all packages of an image recipe that involves postinst scripts ^ | 09:18 |
| angelo__ | ^ | 09:18 |
| angelo__ | ops .. ? | 09:18 |
| Ad0 | LetoThe2nd, hehe. | 09:24 |
| Ad0 | if I add a bb with a higher version in my custom layer, overriding another layer's recipe, can I refer to the other layer's files in a nice way? or do I have to do something like ../../other-layer or something | 09:25 |
| Ad0 | it has a bunch of .patch files that I don't touch | 09:26 |
| LetoThe2nd | huh? | 09:28 |
| LetoThe2nd | i think it should work just like they were in the directory next to each other. | 09:28 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:28 | |
| Ad0 | it says missing files :/ | 09:28 |
| LetoThe2nd | then i'm probably wrong. happends, that. | 09:28 |
| Ad0 | hehe the structure is a bit different to in that layer | 09:29 |
| qschulz | Ad0: FILEEXTRAPATHS_prepend := to the other layer recipe | 09:29 |
| Ad0 | it's meta-security/meta-tpm - so it's a layer in it's subdir. but I include that layer in the bblayers.conf like meta-security and meta-security/meta-tpm (and under that /recipes-tpm. in my layer it's meta-mylayer/recipes-tpm | 09:30 |
| qschulz | but it's still relative to something. you have THISDIR or COREBASE available but that's still not great great | 09:30 |
| LetoThe2nd | qschulz: i would have expected the file lookup to happen after the virtual layer flattening, but hey, i'm often mistaken there. | 09:30 |
| LetoThe2nd | and of course, if the structure is different, then it doesn't work | 09:31 |
| Ad0 | yeah | 09:31 |
| qschulz | LetoThe2nd: "the virtual layer flattening" what's that? | 09:32 |
| Ad0 | but a meta layer subdir will be flat when included in the bblayers | 09:32 |
| LetoThe2nd | Ad0: to my understanding, all layers basically flattened into one state, which is what bitbake actually uses to run its tasks then. but like i said, i might be wrong | 09:33 |
| Ad0 | hm | 09:33 |
| LetoThe2nd | that was for qschulz. :) but better ask kergoth or RP about it :) | 09:34 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 09:36 | |
| qschulz | LetoThe2nd: anything that isn't set with := is done after flattening is my gut feeling. | 09:36 |
| LetoThe2nd | qschulz: no idea, honestly. | 09:36 |
| qschulz | (hence FILEEXTRAPATHS_prepend := "${THISDIR}/files" in bbappends | 09:36 |
| qschulz | otherwise if it's resolved after flattening, THISDIR is the dir of the original bb (?) | 09:37 |
| *** sashko <sashko!~sashko@83.218.80.243> has quit IRC | 09:39 | |
| Ad0 | hm | 09:41 |
| qschulz | kanavin__: FYI, error at compilation time for gobject-introspection happens only with icecc enabled also on plain poky. I tested on Warrior 2.7.2 and master (109ef2e5c4161a2c0ac58bede3daa48c7b4881ec). Going to send a mail | 09:48 |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 09:51 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:53 | |
| RP | qschulz: correct, that is why := is needed with THISDIR | 09:55 |
| wertigon | What is a symlink to /etc/ld.so.cache doing in the mingw folder? | 09:57 |
| RP | wertigon: a bug? | 10:00 |
| wertigon | RP: Possibly | 10:00 |
| wertigon | Or simply a mingw artifact | 10:01 |
| RP | wertigon: there is image/sdk post processing and I suspect it assumes linux and needs turning off for mingw | 10:01 |
| wertigon | It does seem weird to me that the x86_64-mingw32 toolchain folder contains that link in particular | 10:02 |
| wertigon | RP: Yeah, I think most of these bugs I'm finding have already been fixed since I'm on thud ;) | 10:02 |
| RP | wertigon: its hardcoded in sdk.py. Needs to be fixed by abstracting to a function and disabling on mingw, Worth opening a bug | 10:03 |
| jaganteki | paulbarker: I found the same issue with fstype=ext4 | 10:03 |
| wertigon | Ok, I'll see if I can get a bugzilla account going :) | 10:03 |
| RP | (it in meta/lib/oe/sdk.py and not fixed in master) | 10:03 |
| wertigon | I doubt it breaks anything | 10:04 |
| wertigon | But still... | 10:04 |
| RP | wertigon: right, its not going to harm anything but is pointless | 10:04 |
| wertigon | Yeah, I'll open a bug in the eSDK component | 10:07 |
| RP | wertigon: sdk, not eSDK | 10:09 |
| wertigon | RP: Bugzilla only allows eSDK or eclipse plugin :P | 10:12 |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has quit IRC | 10:15 | |
| wertigon | RP: Bug filed under yoctoproject as bug #13686 | 10:16 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13686 minor, Undecided, ---, paul.eggleton, NEW , meta-mingw produces a symlink to host /etc/ld.so.cache in the x86-64_mingw32 folder | 10:16 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:16 | |
| wertigon | And there we got it :D | 10:16 |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has joined #yocto | 10:19 | |
| wertigon | Also related: empty /var/ directory | 10:19 |
| wertigon | (it does contain two other empty directories) | 10:19 |
| jaganteki | part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boota --active --align 4096 --size 20M --extra-space 0part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label bootb --active --align 8192 --size 20M --extra-space 0 | 10:25 |
| jaganteki | Hi any work around for this partition layout. to create bootable flag. | 10:26 |
| jaganteki | here bootb is creating bootable but boota won't | 10:26 |
| jaganteki | I have tried with ext4, same behavior. | 10:26 |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has quit IRC | 10:31 | |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has joined #yocto | 10:32 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 10:36 | |
| RP | kanavin__: around? My patch from yesterday doesn't work but I have another in mind, wondering if you have a setup which can easily test? | 11:06 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 11:14 | |
| *** Chrusel <Chrusel!5b15581c@91.21.88.28> has joined #yocto | 11:28 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 11:31 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 11:31 | |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 11:38 | |
| kanavin__ | RP, yes please | 11:44 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:44 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:45 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 11:47 | |
| mcfrisk | why doesn't PACKAGEGROUP_x86-64 += "bla" work, but PACKAGEGROUP_append_x86-64 += "bla" does? The first one seems to overwrite the whole PACKAGECONFIG. | 11:47 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:47 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:48 | |
| mcfrisk | the same strongswan recipe bbappend was setting a generic PACKAGEGROUP and I was moving aesni to be x86-64 | 11:51 |
| RP | kanavin__: patch is on top of master-next and on the list | 11:56 |
| kanavin__ | RP: testing now | 11:56 |
| RP | kanavin__: thanks! | 11:57 |
| kanavin__ | RP: yes, it seems to work :) | 11:58 |
| RP | kanavin__: cool, thanks! | 12:02 |
| RP | kanavin__: your logs from yesterday put me on the track of the problem thanks! | 12:04 |
| kanavin__ | RP, right, glad we got it contained and sorted quickly :) | 12:04 |
| RP | kanavin__: me too as that one is ugly on the autobuilder and causes lots of noise | 12:04 |
| wertigon | Ok, here is a fugly workaround to the mingw x86_64 symlinks | 12:11 |
| wertigon | Extract | 12:11 |
| wertigon | for link in $(find x86_64-spark-mingw32-tmp/usr/ -type l); do FILE=$(readlink -f $link); rm $link; cp $FILE $link; done | 12:11 |
| wertigon | Archive | 12:11 |
| wertigon | :D | 12:11 |
| wertigon | Sorry, the path is supposed to be sysroots/x86_64-spark-ming32/usr/ | 12:12 |
| wertigon | Then everything just works nativelty | 12:12 |
| wertigon | *natively | 12:12 |
| *** Chrusel <Chrusel!5b15581c@91.21.88.28> has quit IRC | 12:13 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has quit IRC | 12:14 | |
| *** jaganteki <jaganteki!31cecb5c@49.206.203.92> has quit IRC | 12:16 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has joined #yocto | 12:19 | |
| yocti | New news from stackoverflow: Meson version in Yocto <https://stackoverflow.com/questions/59213125/meson-version-in-yocto> | 12:42 |
| wertigon | Any concrete plans about FOSDEM for the Yocto team yet? | 12:48 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:51 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 13:05 | |
| rburton | mcfrisk: because that's how overrides work. | 13:05 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 13:33 | |
| *** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 13:33 | |
| *** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 13:36 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 13:39 | |
| *** rchard2scout <rchard2scout!59cad575@wikipedia/rchard2scout> has joined #yocto | 13:42 | |
| GeneralStupid | Hi, where do i put mtd partitions in the dts file? | 13:53 |
| qschulz | GeneralStupid: I think U-boot can patch the device tree for you, like transparently, depending on what's in the mtdparts env variable | 13:54 |
| qschulz | so if anyway you need to load something from the NAND in U-Boot, use mtdparts maybe | 13:55 |
| qschulz | GeneralStupid: but I think that's a question you can ask on #mtd ;) | 13:57 |
| GeneralStupid | qschulz: i talked to LetoThe2nd yesterday and he told me that mtdparts is 2005 :) | 13:59 |
| GeneralStupid | i need to modify the dts anyway | 13:59 |
| qschulz | GeneralStupid: what's suggested in lieu of mtdparts? | 14:00 |
| GeneralStupid | qschulz: writing the partition table in the dts | 14:01 |
| GeneralStupid | but then i need to do it twice. ... I dont know :D | 14:01 |
| qschulz | what i'm saying is that u-boot should be able to fixup your dts from what you put in mtdparts | 14:03 |
| qschulz | that might be a kconfig options though | 14:03 |
| qschulz | so if you need it in u-boot already, use that option (if it exists) | 14:03 |
| roussinm | kanavin__: I have a question regarding cmake OEToolchain.cmake... This patch 7da988887c. It will not look into the native sdk sysroot, but when we invoke cmake, it find certains tools that it need, like `ar` inside the target sdk sysroot(aarch64 for us), which can't be used on native(x64_64 for us). So I'm wondering if both CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH points to the target sysroot, how cmake is | 14:03 |
| roussinm | suppose to find the x86_64 version of `ar` | 14:04 |
| qschulz | GeneralStupid: also.. be careful because mtdparts changed last year in u-boot and `mtd` cmd is used instead so I don't know exactly how everything's handled | 14:04 |
| GeneralStupid | qschulz: iam using 2017.03 | 14:04 |
| *** rchard2scout <rchard2scout!59cad575@wikipedia/rchard2scout> has quit IRC | 14:06 | |
| GeneralStupid | qschulz: i will call it a day. Have a nice weekend :) | 14:09 |
| qschulz | GeneralStupid: you too | 14:09 |
| yocti | New news from stackoverflow: How to make yocto recipe ( zeus branch ) for postgresql 9.6? <https://stackoverflow.com/questions/59018525/how-to-make-yocto-recipe-zeus-branch-for-postgresql-9-6> || Building python3-psycopg2-native recipe error [ yocto ] <https://stackoverflow.com/questions/59214386/building-python3-psycopg2-native-recipe-error-yocto> | 14:12 |
| JPEW | RP: Ack :/ sorry about the MinGW failure | 14:15 |
| RP | JPEW: I nearly asked you whether I needed to stage and test that :) | 14:23 |
| RP | JPEW: just let me know if its an easy fix or I should revert | 14:24 |
| *** ruru4143 <ruru4143!~ruru4143@vmi243882.contaboserver.net> has quit IRC | 14:25 | |
| kanavin__ | roussinm, I am not sure which patch you mean? | 14:32 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:35 | |
| *** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 14:38 | |
| roussinm | kanavin__: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7ea988887c577aa6c62bdada8db7218d852d9edd | 14:39 |
| roussinm | I think I figured it out, in theory cmake will use the prefix from the compiler to find the other tools like ar,nm,ranlib... but I think my IDE is changing that path somehow... | 14:40 |
| kanavin__ | roussinm, I am not a cmake expert really, I only know as much as the commit msg says | 14:41 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 14:44 | |
| angelo__ | I am getting a "Transaction failed" error at end of the build. Some packages "Failed", but not finding much more info. How can i debug this ? | 14:44 |
| angelo__ | ok, sry, scrolling up the log i found something useful | 14:45 |
| angelo__ | it is "cpio: open failed - Inappropriate ioctl for device" | 14:46 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 14:52 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 14:54 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 14:56 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 14:59 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:02 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 15:19 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC | 15:27 | |
| Ad0 | rust-native is brutal on RAM | 15:32 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:33 | |
| *** fl0v0 <fl0v0!~fvo@89.244.121.126> has joined #yocto | 15:35 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 15:36 | |
| *** cadsys <cadsys!~cadsys@199.243.155.130> has joined #yocto | 15:45 | |
| cadsys | Hi | 15:45 |
| cadsys | I have question in my mind | 15:45 |
| cadsys | If we are making a project on linux in c++ / C , Is it beneficial if we create its yocto layer stack | 15:46 |
| cadsys | Is it necessary to create a yocto layered project for long run | 15:47 |
| cadsys | Please anyone ans | 15:48 |
| roussinm | From us side we create a layer with our compagny name(meta-....) . Use that layer with our projects. | 15:50 |
| roussinm | s/us/our | 15:51 |
| cadsys | roussinm : I mean , Is there really need of create yocto layer | 15:51 |
| cadsys | What are the benefits of yocto over a simple standard application or makefile project | 15:52 |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 15:55 | |
| bojones | Hello. I have a package which is basically just a kernel module and a shared library. Another package (the main application) is depending on the package (well, actually just the header files). My problem is, if the kernel is rebuilt, the kernel module is rebuilt and hence my main application is rebuilt. Can this be fixed? I'm probably doing something wrong.. | 15:55 |
| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has joined #yocto | 15:56 | |
| *** frsc <frsc!~frsc@i6DFA871A.versanet.de> has quit IRC | 15:56 | |
| qschulz | cadsys: Yocto is a build system. It uses cmake, meson, ninja, make, autootls, whatever to compile the application. So do that first and try to not ignore variables coming by parameters so that people can easily cross-compile without patching your stuff | 15:57 |
| qschulz | bojones: separate the kernel-module recipe from the other stuff so that you depend only on the other stuff recipe | 15:59 |
| bojones | qschulz: But the problem is, the main application depends on the shared library, which depends on the kernel module | 16:00 |
| bojones | But since the interface to the kernel module and the shared library doesn't change, it shouldn't be necessary to rebuild the application | 16:01 |
| qschulz | bojones: how is Yocto supposed to know that? | 16:02 |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 16:02 | |
| bojones | qschulz: It's not supposed to know that - but maybe I could help it.. thats my question. My thought was something like, the main application was only depending on the header files for the shared library. The shared library was only depending on the header files of the kernel module. | 16:07 |
| rburton | JPEW: got a do_install postfunc to hopefully clean up the pod2man versions | 16:07 |
| bojones | But I don't know if this is something that your can do in Yocto.. | 16:07 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 16:08 | |
| JPEW | rburton: Ah, excellent. I got sidetracked from asking about getting that finished up | 16:08 |
| rburton | JPEW: all new implementation, literally just look in every man page for the bad string and rip it out | 16:08 |
| JPEW | rburton: Ya, I think that makes sense and is probably a lot simpler to maintain | 16:09 |
| rburton | bojones: the library doesn't depend on the kernel module at build time though right | 16:09 |
| rburton | if you've really got new kernel headers then just split up the recipes a bit so you build the kernel module entirely separately | 16:10 |
| bojones | rburton: no. But it depends on the header files from the kernel module. | 16:10 |
| rburton | JPEW: ross/pod2 if you want to heckle | 16:11 |
| rburton | build of sato running now to check nothing else breaks | 16:11 |
| cadsys | qschulz : Hi thank you but my question is , Is that good to make yocto project rather than a cmake project ? | 16:11 |
| cadsys | Right now I create a cmake project | 16:11 |
| JPEW | RP: Odd, nativesdk-wayland isn't detecting libxml2 on the AB. Of course, I can't reproduce that locally :( | 16:12 |
| cadsys | but someone told me yocto is a build tool which are used by multiple companies | 16:12 |
| cadsys | You also need to use it | 16:12 |
| rburton | cadsys: different scopes: cmake can't build an entire system, and a yocto recipe on its own doesn't build source code | 16:12 |
| armpit | Was systemd intended to be used in e/SDK ? there is no natvivesdk package | 16:13 |
| cadsys | rburton : can I explain everything which I want ? | 16:13 |
| rburton | armpit: why would you need nativedk-systemd? | 16:13 |
| cadsys | I have a lakhs lines of project which is developed in c/c++ but it was running only on windows and it is simple standard application | 16:14 |
| cadsys | But recently we compiled it for linux by help of cmake tool | 16:14 |
| cadsys | We also want to make it standalone application of linux , So we need to configure our linux os as per application requirement | 16:15 |
| cadsys | So in that scenario how yocto is perfect ? | 16:16 |
| cadsys | I mean we need to use yocto or not ? | 16:16 |
| cadsys | anyone suggest me please | 16:20 |
| JPEW | cadsys: If you want to build a complete Linux system that includes your application, you can use Yocto | 16:20 |
| qschulz | bojones: I think the point of rburton was to have a recipe only with this header. Then another one for the kernel-module which depends on the header recipe. Then another one for your application which dpeend on the header recipe. | 16:21 |
| cadsys | JPEW : I mean is it seriously beneficial because it will required great effort to import whole project on yocto thats why I want to confirm first | 16:22 |
| qschulz | cadsys: "We also want to make it standalone application of linux , So we need to configure our linux os as per application requirement" this isn't explicit enough for context. I didn't understand exactly what you wanted | 16:23 |
| armpit | rburton, I need libsystemd for a package I want to add to the sdk | 16:24 |
| JPEW | cadsys: What do you run on today? An embedded device? What OS (e.g. Ubuntu, Fedora)? | 16:24 |
| cadsys | qschulz : I mean we will remove extra drivers or application which we not required for application | 16:25 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 16:25 | |
| armpit | WillMiles, nice domain.. storm.ca. so you brought us all the rain : ) | 16:26 |
| bojones | qschulz: Ahh ok, that makes sense. But can you have it in a single .bb file? | 16:27 |
| rburton | armpit: a nativesdk tool in the sdk? | 16:28 |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 16:28 | |
| WillMiles | armpit: Yup, they're a small local ISP. If you've got rain I'm envious - it's all snow up here today | 16:29 |
| armpit | rburton, I want to add python-systmed to the sdk | 16:29 |
| armpit | rburton, once I get the python-systemd sorted to support nativesdk, and add it to TOOLCHAIN_HOST_TASK_append = it failes with missing libsystemd | 16:32 |
| *** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 16:32 | |
| rburton | armpit: still curious how that is useful in the nativesdk context :) | 16:32 |
| rburton | but if thats what you really want then you'll most likely want a minimal packageconfig_class-nativesdk override | 16:33 |
| bojones | .. the headers and the library I mean | 16:36 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:38 | |
| armpit | rburton, if I want a 3rd party to develop systemd apps or tweek systemd configs , isn't that a usecase for an e/SDK ? | 16:41 |
| qschulz | bojones: if your lib does not depend on anything else but the header (wrt kernel module), should be doable indeed | 16:42 |
| bojones | qschulz: neither the kernel module or the shared library "ever" changes.. So the header files are "static".. | 16:44 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:45 | |
| *** FailDev <FailDev!18d83107@24.216.49.7> has joined #yocto | 16:48 | |
| qschulz | but the header is the same file for both, and I don't like duplicates personally :) | 16:57 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:02 | |
| rburton | armpit: no, they'd use the target systemd in the sysroot | 17:02 |
| rburton | armpit: nativesdk is stuff the user can *run* in the sdk | 17:03 |
| RP | kanavin__: those gettext changes really don't like existing build directories do they? :/ | 17:04 |
| kanavin__ | RP, probably not, I've had them in my tree for such a long time that I don't remember how it was when transitioning from previous version | 17:05 |
| *** fl0v0 <fl0v0!~fvo@89.244.121.126> has quit IRC | 17:05 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qpvicoefgbzyjryo> has quit IRC | 17:05 | |
| RP | kanavin__: I just cleared stuff out but we need to keep it in mind when they merge I guess | 17:06 |
| *** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-vrxobbleezmitueb> has joined #yocto | 17:09 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 17:17 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has joined #yocto | 17:21 | |
| armpit | rburton, I thought I could use the esdk to build a systemd service then send it to the target to run and debug | 17:22 |
| *** mckoan is now known as mckoan|away | 17:23 | |
| armpit | an esdk contains all the headers and libs needed to support such an task | 17:23 |
| * armpit is what is my understanding | 17:23 | |
| rburton | armpit: right, but they're all class-target | 17:25 |
| rburton | nativesdk is the pieces that you can run in the sdk itself | 17:25 |
| armpit | k | 17:26 |
| * armpit breaks out his Yocto pre-school set to do some more learning | 17:28 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:39 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 18:00 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 18:15 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 18:20 | |
| *** palate <palate!~palate@unaffiliated/palate> has quit IRC | 18:31 | |
| *** hpsy <hpsy!~hpsy@85.203.15.88> has joined #yocto | 18:36 | |
| *** hpsy <hpsy!~hpsy@85.203.15.88> has quit IRC | 18:41 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 18:42 | |
| *** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto | 18:50 | |
| moosnat | Hi, I just upgraded a Yocto-based build from rocko to thud, and I'm experiencing a huge performance loss in the parsing stage: on rocko it parsed recipes in a matter of seconds, now it takes 15 minutes. Is there a way I can profile this? | 18:51 |
| Ad0 | there are different layers for different boards, only one of them can be used at a time, I already have separate image build files but maybe I have to sort this out on a distro level? | 18:59 |
| Ad0 | make a distro per board, and use BBMASK to exclude other board's layers? | 19:06 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 19:07 | |
| *** pohly <pohly!~pohly@p5B0564A0.dip0.t-ipconnect.de> has quit IRC | 19:55 | |
| *** FailDev <FailDev!18d83107@24.216.49.7> has quit IRC | 20:41 | |
| moto-timo | zeddii: has anybody sent a patch for meta-virtualization/recipes-extended/images/xen-guest-image-minimal.bb:3: Could not inherit file classes/features_check.bbclass | 20:44 |
| moto-timo | zeddii: oh wait, maybe my poky is out of sync ... now that I read it again | 20:45 |
| JPEW | RP: http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290149.html + master-next of meta-mingw should fix the build errors | 20:45 |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has quit IRC | 20:45 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-frnvfbnwqehqseql> has quit IRC | 21:01 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 21:01 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:03 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 21:03 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 21:04 | |
| moto-timo | JPEW: have you ever used buildah? wondering if it is faster than podman build | 21:05 |
| JPEW | podman build uses buildah for the backedn | 21:05 |
| JPEW | I don't recommend invoking them independently, it's easy to get things very confused :) | 21:06 |
| moto-timo | noted :) | 21:06 |
| moto-timo | seems like avoiding docker-engine on CI is a good thing though :) | 21:06 |
| JPEW | Ya. The problem we ran into is that podman build is *so* slow with the vfs driver our TravisCI job would timeout | 21:07 |
| JPEW | The best compromise I've found is to build images in docker + buildkit, then import to podman using 'podman pull docker-daemon:IMAGE' | 21:08 |
| JPEW | moto-timo: This script will do that for you: https://github.com/garmin/pyrex/blob/master/ci/podman-helper.py | 21:09 |
| moto-timo | JPEW: what do you do about registry? do you run a local podman registry? or is that not even a thing... | 21:10 |
| JPEW | moto-timo: Sorry, here's a better one: https://github.com/garmin/pyrex/blob/next/ci/podman-helper.py | 21:10 |
| moto-timo | and thanks for the script | 21:10 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:10 | |
| JPEW | podman's registry is just a bunch of files in ~/.local/share/containers | 21:11 |
| moto-timo | JPEW: oh right, I read that somewhere already. | 21:11 |
| JPEW | moto-timo: FWIW, the podman build time is more bearable with the fuse-overlay driver; I just haven't found a new enough version that works to build on Ubuntu 18.04 | 21:15 |
| moto-timo | JPEW: probably better support on Fedora, given the RedHat origins? | 21:16 |
| JPEW | moto-timo: Yep. I've been pretty happy with it. | 21:17 |
| moto-timo | JPEW: other than the brain shift from Docker, seems very promising | 21:17 |
| JPEW | moto-timo: Ya, I hope it sticks around. They've put a lot of effort into make it work the same way as docker | 21:18 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 21:19 | |
| JPEW | Most of the bugs I've found have been in regard to differences in how it deals with our convoluted Dockerfiles, which is to be expected given its a clean implementation | 21:19 |
| moto-timo | lol | 21:19 |
| moto-timo | We've done some nasty things in Dockerfiles too | 21:20 |
| JPEW | Well, FWIW, podman can run the C-preprocess on Dockerfiles before it builds them... which seems like a double edged sword :) | 21:20 |
| JPEW | C preprocessor | 21:20 |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 21:20 | |
| JPEW | We don't use that feature b/c we want to also be able to build them in Docker | 21:21 |
| *** guerinoni <guerinoni!~guerinoni@95.238.42.152> has joined #yocto | 21:26 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:31 | |
| *** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC | 21:45 | |
| *** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto | 21:45 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 21:58 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 21:59 | |
| *** guerinoni <guerinoni!~guerinoni@95.238.42.152> has quit IRC | 22:19 | |
| roussinm | I would like to remove gcc from the target sysroot in the sdk, because we don't need a aarch64 gcc, we only want the one that is inside the x86 that generates aarch64 binaries. | 22:27 |
| roussinm | We tried removing packagegroup-cross-canadian-${MACHINE} from the TOOLCHAIN_HOST_TASK, but then we only get the gcc aarch64. | 22:28 |
| *** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has quit IRC | 22:39 | |
| RP | roussinm: cross-canadian *is* the x86 gcc that generates aarch64 binaries. "gcc" is the target gcc | 22:45 |
| roussinm | Oh, right we just figured that, we were looking at the wrong variable. But still remain, how to remove gcc binairy from the aarch64 sysroot. | 22:47 |
| roussinm | Or it shouldn't be installed by default and we are doing something funky that does that. | 22:48 |
| RP | roussinm: I'm slightly surprised its there | 22:54 |
| roussinm | Ok that's why I thought too, it's probably because of the meta-clang layer actually... | 22:54 |
| roussinm | I'm trying a build without the meta-clang layer right now and see if gcc reside inside the aarch64 sysroot. | 22:55 |
| roussinm | khem: maybe you know something about this? | 22:56 |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 22:56 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 22:57 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has quit IRC | 23:03 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has joined #yocto | 23:04 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has quit IRC | 23:08 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 23:10 | |
| *** roussinm <roussinm!459c73ba@qubcpq0336w-lp130-03-69-156-115-186.dsl.bell.ca> has joined #yocto | 23:43 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 23:45 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!