*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 00:14 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:25 | |
*** matthewzmd <matthewzmd!~user@72.138.138.18> has quit IRC | 01:27 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:29 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:31 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:31 | |
*** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has quit IRC | 01:36 | |
*** stew-dw <stew-dw!~stew-dw@2607:fb90:982a:7308:b6b7:6a91:ba07:3be8> has joined #yocto | 01:37 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:15 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:18 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:33 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:34 | |
*** manuel1985 <manuel1985!~manuel@089144216248.atnat0025.highway.a1.net> has quit IRC | 02:40 | |
*** manuel1985 <manuel1985!~manuel@089144217056.atnat0026.highway.a1.net> has joined #yocto | 02:54 | |
kiwi_29 | Hello.. my custom distro is based on deb pacakges. One of my custom recipes "custrecipe1" installs a file in /usr/lib/SHAREDLIB.SO this shared lib is also provided by another package - "anotherpkg1" . | 02:56 |
---|---|---|
kiwi_29 | Therefore while generating rootfs, when custrecipe1.deb is being installed there is an error | 02:56 |
kiwi_29 | dpkg: error processing archive custrecipe1.deb (--unpack): | 02:56 |
kiwi_29 | trying to overwrite '/usr/lib/SHAREDLIB.so which is also in package anotherpkg1 | 02:57 |
kiwi_29 | How do I deal with this situation | 02:57 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:57 | |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC | 03:14 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 03:21 | |
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 03:29 | |
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 03:29 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:36 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 03:36 | |
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has quit IRC | 04:00 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.169.99.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 04:00 | |
*** wooosaiii <wooosaiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC | 04:01 | |
*** stacktrust <stacktrust!~stacktrus@cpe-67-250-48-90.nyc.res.rr.com> has joined #yocto | 04:01 | |
*** wooosaiii <wooosaiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 04:02 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.169.99.nat.umts.dynamic.t-mobile.pl> has quit IRC | 04:02 | |
*** jobroe <jobroe!~manjaro-u@p579eb542.dip0.t-ipconnect.de> has joined #yocto | 04:28 | |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 04:32 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 04:32 | |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 04:40 | |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-135.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 04:44 | |
*** zkrx <zkrx!~quassel@adsl-89-217-234-211.adslplus.ch> has quit IRC | 04:48 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 04:58 | |
*** NiksDev <NiksDev!~NiksDev@192.91.75.30> has joined #yocto | 05:00 | |
*** kiwi_2962 <kiwi_2962!49e7d3d6@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 05:02 | |
*** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has joined #yocto | 05:09 | |
*** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 05:11 | |
*** davidinux <davidinux!~davidinux@185.93.183.164> has quit IRC | 05:11 | |
*** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 05:13 | |
*** davidinux <davidinux!~davidinux@net-93-66-67-41.cust.vodafonedsl.it> has joined #yocto | 05:13 | |
*** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 05:15 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:16 | |
*** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:19 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 05:19 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:39 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 05:43 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 05:43 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 05:43 | |
*** CoLa|work <CoLa|work!~cordlandw@port-92-192-53-185.dynamic.as20676.net> has joined #yocto | 05:45 | |
*** CoLa|work <CoLa|work!~cordlandw@port-92-192-53-185.dynamic.as20676.net> has quit IRC | 05:50 | |
*** manuel1985 <manuel1985!~manuel@089144217056.atnat0026.highway.a1.net> has quit IRC | 06:04 | |
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 06:07 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 06:08 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:09 | |
*** camus1 is now known as kaspter | 06:09 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 06:10 | |
*** agust <agust!~agust@p54833a5e.dip0.t-ipconnect.de> has joined #yocto | 06:24 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 06:35 | |
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.181.14> has joined #yocto | 06:38 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 06:38 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:42 | |
*** mihai- is now known as mihai | 06:50 | |
*** kamel_b is now known as kamel | 06:55 | |
*** fl0v0 <fl0v0!~fvo@88.130.223.183> has joined #yocto | 06:55 | |
*** davidinux <davidinux!~davidinux@net-93-66-67-41.cust.vodafonedsl.it> has quit IRC | 07:07 | |
*** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 07:12 | |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 07:22 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:24 | |
*** manuel1985 <manuel1985!~manuel@089144217056.atnat0026.highway.a1.net> has joined #yocto | 07:27 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 07:31 | |
*** mckoan|away is now known as mckoan | 07:31 | |
mckoan | good morning | 07:31 |
erbo | good morning | 07:37 |
*** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 07:40 | |
*** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:45 | |
*** jkimblad <jkimblad!~jacob@h-161-8.A137.corp.bahnhof.se> has quit IRC | 07:51 | |
*** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has quit IRC | 08:00 | |
leon-anavi | hi :) | 08:01 |
*** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 08:01 | |
fbre | Hi! I'm in the menuconfig of an ARM64 5.4.61 kernel configuration and want to select the i.MX8. What should I choose in "Platform selection"? Can I unselect one of the preselected settings? I can see "ARMv8 based Freescale Layerscape SoC family", "ARMv8 based NXP i.MX SoC family", "i.MX8M busfreq" and "NXP S32 SoC Family" are on. | 08:06 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-oohxudqwyrsqakqb> has joined #yocto | 08:10 | |
*** eduardas <eduardas!~eduardas@85.254.96.13> has joined #yocto | 08:11 | |
eduardas | hello, is it now possible to specify the kernel in-tree defconfig file to use for kernel build? | 08:15 |
eduardas | it seems to me this is not possible with standard poky's kernel.bbclass | 08:16 |
eduardas | Phytec for example make their own kconfig.bbclass where they have an INTREE_DEFCONFIG variable for this purpose | 08:17 |
eduardas | I think something like this would be very useful to have in standard kernel.bbclass | 08:18 |
*** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has joined #yocto | 08:18 | |
eduardas | honestly, it surprises me something like this is not already there | 08:18 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:20 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 08:21 | |
qschulz | eduardas: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n570 | 08:21 |
qschulz | if there's a "defconfig" in ${WORKDIR} (passed with the file fetcher in SRC_URI), it's used | 08:22 |
*** sno <sno!~sno@p5b25b0d4.dip0.t-ipconnect.de> has joined #yocto | 08:23 | |
qschulz | eduardas: otherwise, if you inherit kernel-yocto, you can use KBUILD_DEFCONFIG and install your defconfig in arch/<arch>/configs/ to use it | 08:24 |
*** zkrx <zkrx!~quassel@adsl-89-217-238-166.adslplus.ch> has joined #yocto | 08:36 | |
*** psnsilva <psnsilva!~psnsilva@2001:818:dae7:b100:c990:8de1:5141:d0ec> has joined #yocto | 08:37 | |
eduardas | qschulz: is it ok to use kernel-yocto.bbclass on regular mainline linux source tree? | 08:48 |
eduardas | qschulz: or does the kernel source need some kind of yocto-specific modifications? | 08:48 |
eduardas | qschulz: because it sounds like linux-yocto is special in some way | 08:48 |
qschulz | eduardas: who does not try does not know :D | 08:50 |
eduardas | qschulz: what is "linux-yocto style kernel source" anyway? | 08:50 |
qschulz | (and I don't use kernel-yocto soooo... I don't know :) ) | 08:50 |
qschulz | but it brings config fragment support for example | 08:50 |
eduardas | qschulz: ok, will try it... thank you for the advice since I was not aware of this class | 08:51 |
qschulz | eduardas: remember, to use KBUILD_)DEFCONFIG, you need to install your defconfig in the sources in arch/<ARCH>/configs ;) | 08:52 |
*** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 08:58 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 08:59 | |
eduardas | qschulz: seems it at least needs KERNEL_VERSION_SANITY_SKIP="1" to be set in my kernel recipe to work | 09:00 |
*** davidinux <davidinux!~davidinux@217.138.219.141> has joined #yocto | 09:01 | |
rburton | eduardas: linux-yocto has mainline tags in, so you can just use linux-yocto and set the branch/revision yourself | 09:03 |
rburton | http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.8.11&id=16b1d77227fe8fedbded9e103c74bf83610f28b1 <-- that is mainline 5.8.11 | 09:04 |
qschulz | rburton: they are using phytec's bsp so probably not mainline? | 09:05 |
rburton | in that case, the fact that linux-yocto builds mainline kernels implies that the classes don't need magic | 09:06 |
*** florian_kc is now known as florian | 09:36 | |
eduardas | qschulz: I am using mainline 5.8.5 actually... a Phytec SoM, but not Phytec's BSP... I usually put together my own BSP based on latest stable Yocto branch | 09:36 |
* qschulz applauds loudly | 09:37 | |
* qschulz screams: "More people like eduardas please!" | 09:37 | |
eduardas | Phytec's docs are relatively ok for a SoM vendor... I've seen much worse... but it is still not up-to-date with latest Yocto/OE | 09:38 |
eduardas | qschulz: thanks... I don't deserve so much praise :D | 09:39 |
eduardas | though this approach that most people more familiar with Yocto think of as normal is really difficult to explain to managers | 09:40 |
qschulz | eduardas: it's refreshing to see, many people do not want/"cannot" upgrade from BSP's Yocto versions (we've seen people asking for help for jethro still...) | 09:41 |
eduardas | middle management still thinks that "vendor BSP is best BSP, vendor bootloader is best bootloader, vendor kernel is best kernel" | 09:41 |
qschulz | eduardas: it can be, but you bear the costs of maintaining it when vendor don't want to take care of it anymore | 09:41 |
qschulz | eduardas: it's all short-term vs long-term and it's hard to force people on doing long term things (because it also usually costs more short-term) | 09:42 |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto | 09:43 | |
eduardas | also, if anyone from Phytec is hearing this, please add u-boot as a bootloader option since barebox is really niche and has some incompatibility with mainline dtb parsing | 09:43 |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 09:48 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 09:48 | |
*** ak77 <ak77!c12e4b03@193.46.75.3> has joined #yocto | 10:03 | |
*** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:30 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 11:07 | |
eduardas | qschulz: using linux-yocto does not work after all | 11:11 |
eduardas | qschulz: even though the in-tree defconfig gets copied over to WORKDIR, it does not get applied at the end | 11:12 |
qschulz | eduardas: how is your defconfig named? what's its entry in SRC_URI? | 11:12 |
eduardas | qschulz: it's not in SRC_URI since the whole point is to use the in-tree one | 11:14 |
eduardas | qschulz: it's arch/<arch>/configs/product_defconfig | 11:15 |
eduardas | qschulz: and i set KBUILD_DEFCONFIG_imx6ul-product-mainline = "product_defconfig" | 11:16 |
RP | It is lovely when you can watch a build rolling straight to the key part reusing sstate all the way :) | 11:20 |
qschulz | eduardas: are you requiring linux-yocto or inheriting kernel-yocto? | 11:22 |
eduardas | qschulz: inheriting kernel-yocto | 11:24 |
qschulz | what tasks have youd efined in your recipe? is it possible you bypass some task or override one? | 11:25 |
eduardas | qschulz: except for the KERNEL_VERSION_SANITY_SKIP="1" there is hardly anything worthy of suspicion, no direct task customization | 11:26 |
qschulz | eduardas: and you inherit kernel also right? | 11:27 |
qschulz | eduardas: I;m out of ideas, I'd check tha tall/most tasks are run and try to understand what should happen and what actually happens before the recipe's do_compile :/ | 11:28 |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 11:29 | |
eduardas | qschulz: something like this: https://pastebin.com/LkQbbrpB | 11:29 |
qschulz | eduardas: I think you can use KBRANCH directly? | 11:30 |
qschulz | instead of SRC_BRANCH | 11:30 |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 11:30 | |
eduardas | qschulz: because of time limitations I am probably going to drop the idea of using in-kernel defconfig for now | 11:30 |
eduardas | will implement the "classic" defconfig in metadata | 11:31 |
eduardas | I really feel "normal" kernel.bbclass should have an in-kernel defconfig option | 11:31 |
eduardas | can I make yocto release feature requests here? | 11:31 |
qschulz | eduardas: you can send patches :D | 11:32 |
eduardas | though sadly I do not belong to an organization that is a member of Yocto | 11:32 |
eduardas | qschulz: I know, but I probably won't get paid to do them | 11:32 |
eduardas | it is really difficult to convince management we should work upstream | 11:33 |
qschulz | eduardas: what we do is that we cp the intree defconfig to ${WORKDIR}/defconfig in kernel_do_configure_prepend() and this seems to work | 11:33 |
eduardas | would be very nice doing open-source as a dayjob | 11:33 |
qschulz | you can override this per machine | 11:33 |
*** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-wghqohgsroutxvpu> has joined #yocto | 11:33 | |
qschulz | eduardas: some people here contribtue on their free time too :) | 11:34 |
qschulz | but I get what you mean :) | 11:34 |
qschulz | eduardas: I'd probably send a mail to the mailing list giving your recipe, what you're trying to achieve, what's happening and ask for help? | 11:35 |
qschulz | maybe you forgot a few variables? maybe it's a bug :) | 11:35 |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-jhbiegtolzfopwtz> has joined #yocto | 11:36 | |
rburton | eduardas: feature requests in bugzilla please. patches very much welcome, obviously you don't have to be a member to send a patch. if management are making it difficult to contribute then really they should be paying for a support contract as open source != free support. there's plenty of discussion to remind management of that fact. | 11:39 |
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 11:40 | |
ThomasD13 | Hi, is there a easy way to list all packagegroups, which are really going to be added to the linux image with bitbake? | 11:45 |
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 11:46 | |
*** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:46 | |
qschulz | ThomasD13: I think that's something you can have from the buildhistory | 11:48 |
ThomasD13 | qschulz, I can see which packages are installed, and which files belongs to it. But packagegroups..? | 11:51 |
ThomasD13 | I'll have a look. Maybe I have overseen something | 11:51 |
ThomasD13 | Argh!! Thanks qschulz !! image-info.txt is it :) | 11:53 |
RP | khem: the minifi-cpp issue is the fact the recipe uses ${B}/minifi-install. Change that to ${WORKDIR}/minifi-install and it should work | 11:54 |
RP | khem: I sent a patch | 12:02 |
*** micka_ is now known as micka | 12:05 | |
*** xantoz <xantoz!~tewi_inab@c-d5bfe255.013-124-73746f25.bbcust.telenor.se> has quit IRC | 12:16 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 12:25 | |
OutBackDingo | dumb question can say distro = "test" inherit all from another distru "test2" ?? | 12:29 |
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto | 12:35 | |
*** mihai is now known as Guest25496 | 12:36 | |
*** mihai- is now known as mihai | 12:36 | |
*** Guest25496 <Guest25496!~mihai@unaffiliated/mihai> has quit IRC | 12:39 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 12:46 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 12:46 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 12:46 | |
RP | OutBackDingo: definitely, poky-altcfg and poky-tiny do that | 12:53 |
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 12:59 | |
*** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 13:04 | |
*** d32 <d32!2ef3c527@46.243.197.39> has joined #yocto | 13:07 | |
*** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 13:09 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has quit IRC | 13:11 | |
*** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has quit IRC | 13:13 | |
*** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 13:15 | |
*** d32 <d32!2ef3c527@46.243.197.39> has quit IRC | 13:16 | |
eduardas | rburton: do suggestions to improve standard poky bitbake classes fit within the meta-yocto category here? https://bugzilla.yoctoproject.org/buglist.cgi?product=Meta-yocto&component=meta-yocto&resolution=--- | 13:29 |
rburton | no | 13:29 |
eduardas | rburton: then what category in bugzilla do I use? | 13:30 |
rburton | for anything in oe-core, build system -> oe-core | 13:30 |
rburton | meta-yocto is https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/ | 13:31 |
eduardas | rburton: thank you. It was confusing for me. | 13:32 |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has quit IRC | 13:40 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:47 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 13:47 | |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has joined #yocto | 13:49 | |
eduardas | rburton: registered enhancement request here https://bugzilla.yoctoproject.org/show_bug.cgi?id=14064 | 13:51 |
eduardas | rburton: if I have messed this up, please let me know | 13:51 |
rburton | triage will deal with that on thursday | 13:51 |
eduardas | rburton: ok, was not aware | 13:52 |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 13:56 | |
eduardas | tried building lapack nad got "libgfortran was skipped: libgfortran needs fortran support to be enabled in the compiler" | 13:59 |
eduardas | how am I supposed to properly enable fortran support in yocto? | 13:59 |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 14:00 | |
*** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 14:01 | |
rburton | eduardas: google? FORTRAN_forcevariable = ",fortran" in local.conf | 14:04 |
*** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has quit IRC | 14:06 | |
*** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto | 14:07 | |
*** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto | 14:09 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 14:12 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:1ce8:b073:6e6a:c331> has quit IRC | 14:15 | |
*** ptsneves <ptsneves!b0dd7824@176.221.120.36> has joined #yocto | 14:20 | |
ptsneves | Hey guys, i just rebased on the latest master and having issues building. | 14:21 |
ptsneves | RROR: gnu-config-native-20200831+gitAUTOINC+0b5188819b-r0 do_unpack: Unpack failure for URL: 'git://git.savannah.gnu.org/config.git'. No up to date source found: clone directory not available or not up to date: /var/fpwork/desousan/home/emergency-fix1/builds/yoctobuild/downloads/git2/git.savannah.gnu.org.config.git; shallow clone not enabled | 14:21 |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:9d97:e0e:5802:c8f4> has joined #yocto | 14:28 | |
pev | Im playing with a qemuarm target and making various changes - it seems that it's not that easy to extend qemuarm or the runqemu script... Is it the 'right' thing to do to create a new machine cloning qemuarm and a new run script? | 14:28 |
ptsneves | pev yes. It is trivial to create new machines in yocto. I think you can even include the other conf | 14:30 |
*** OnkelUll1 is now known as OnkelUlla | 14:31 | |
qschulz | ptsneves: indeed, you just need to do `require path/to/machine/qemu.conf` with path/to/machine/qemu.conf being the path relative to the root of the layer in which it is stored | 14:32 |
ptsneves | qschulz thanks for the extra detailed info :) | 14:33 |
pev | ptsneves, Yeah, I can see that for the machine, but with the 'runqemu' script should one just create a new bsp specific version? | 14:33 |
*** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has quit IRC | 14:34 | |
ptsneves | @pev can i ask what exactly are you trying to extend in runqemu? There are some extra variables that allows some configurability of runqemu | 14:35 |
pev | for example I need to setup additional flash images. I can use QB_OPT_APPEND, but then Im forced to use (potentially incorrect) full paths into tmp/deploy... as reqemu isn't that clever... | 14:36 |
pev | Im adding u-boot build for qemuarm, persistant image backing for the two flash images to allow saveenv to work. Im also trying to work out why u-boots virtio networking is failing with qemu ... and currently failing! | 14:37 |
*** eduardas <eduardas!~eduardas@85.254.96.13> has quit IRC | 14:38 | |
ptsneves | hmm are you able to use runqemu through yocto to run qemu? Would you not need completely different flags? If your problem is only with the deploy dir there is the https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-DEPLOY_DIR_IMAGE | 14:39 |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 14:40 | |
*** RobertBerger <RobertBerger!~rber@2a02:587:3b0d:ecec:6db1:3adf:bfd6:e7ed> has joined #yocto | 14:41 | |
pev | ptsneves, I can use runqemu to do it but only if I hardcode paths given to QB_OPT_APPEND e.g. QB_OPT_APPEND += "-drive if=pflash,format=raw,index=0,file=tmp/deploy/images/qemuarm-swu/flash0.img" | 14:42 |
pev | in my bsps conf/machine/qarmemu-flash.conf | 14:43 |
pev | that keeps letting me use "runqemu" which is convenient, but Im aware it's a bodge | 14:43 |
ptsneves | pev what about the QB_OPT_APPEND += "-drive if=pflash,format=raw,index=0,file=${DEPLOY_DIR_IMAGE}/flash0.img" | 14:43 |
pev | Hm, I hope it's really not that embarassingly simple... :-D | 14:44 |
*** Bunio_FH <Bunio_FH!~bunio@188.146.171.231.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 14:44 | |
ptsneves | well i hope it is :D | 14:45 |
pev | Oh man, it was. Total brain fart last night at 1am...! | 14:46 |
pev | ty | 14:46 |
ptsneves | no problem, you are into deep stuff and the manual is big. Glad to be of help | 14:47 |
*** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 14:48 | |
pev | On the topic of bodges, Im creating flash images in the u-boot's recipe using do_deploy_append() but I have a sneaking suspicion it's probably not the 'right' place...? | 14:49 |
*** ak77 <ak77!c12e4b03@193.46.75.3> has quit IRC | 14:49 | |
*** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 14:50 | |
ptsneves | pev do not know. The issue with bootloaders is that often uboot is just one of the blobs. I honestly just use the do_deploy also :D | 14:52 |
ptsneves | qschulz do you now how to properly generate the uboot binary blobs? | 14:52 |
ptsneves | i would read the default uboot recipes as well as the inc files | 14:53 |
qschulz | ptsneves: the question is not really complete | 14:53 |
qschulz | but basically, compilation or logic to do to create something? do_compile | 14:53 |
ptsneves | i guess to make the binary blob available in the DEPLOY_DIR_IMAGE | 14:54 |
qschulz | then you install them where they need to be in the target FS in do_install and if you need something in the deploydir (think and rethink again if you REALLY need to dot hat and why) available as an artifact: do_deploy | 14:54 |
pev | ptsneves : Yeah, it's more complicated soon too as what Im ultimately needing todo is to create an initial set of qemu images with various emulated partitions created. I suspect all of them, including the pflash images should be created in the same recipe / rule, but not sure which | 14:54 |
*** Bunio_FH <Bunio_FH!~bunio@188.146.171.231.nat.umts.dynamic.t-mobile.pl> has quit IRC | 14:55 | |
qschulz | take do_deploy as do_install but to make files available as a build artifact available on the host (but compiled for the target ofc) | 14:55 |
pev | *** qemu virtual *disk* images, that is' | 14:55 |
ptsneves | qschulz thanks. That was our idea also :) | 14:55 |
qschulz | pev: new to this, but probably you are looking for a new IMAGE_FSTYPES (using IMAGE_CMD IIRC, read image_types.bbclass) or some ROOTFS_POSTPROCESS_COMMAND or IMAGE_POSTPROCESS_COMMAND or something along those lines | 14:56 |
*** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 14:57 | |
qschulz | https://docs.yoctoproject.org/overview-manual/overview-manual-concepts.html#image-generation ? | 14:57 |
pev | qschulz: Ah thanks... I was starting to think along those lines as "virtual flash images" don't quite fit into the box of rootfs or recipe install rule... Just can't quite get my head around what's "right" or "yocto-ish" yet! | 14:57 |
qschulz | pev: distro, machine, image recipe, package recipe are all the things you can change/add and safely share in a layer | 15:04 |
qschulz | pev: with what you're telling us, it really looks like something to handle in an image recipe :) | 15:04 |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 15:05 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 15:08 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 15:09 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 15:10 | |
ptsneves | pev the way i normally did the image recipe also "produce" the bootloaders, was to add a do_image_<your fstype>[depends] = "<your boot loader recipe> <your extra blobs>" | 15:10 |
ptsneves | normally i chose IMAGE_FSTYPES += "wic" and so do_image_wic[depends] += "boot-image:do_deploy" | 15:11 |
ptsneves | of course i had a recipe which was called boot-image that deployed all my boot blobs | 15:12 |
qschulz | ptsneves: not really, it's EXTRA_IMAGEDEPENDS set in the machine conf file :) | 15:12 |
ptsneves | qschulz thanks for the tip :D | 15:12 |
ptsneves | qschulz did not know :) | 15:13 |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:13 | |
qschulz | ptsneves: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-EXTRA_IMAGEDEPENDS :) | 15:13 |
qschulz | ptsneves: which probably does exactly what you wrote :) | 15:13 |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 15:14 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 15:14 | |
ptsneves | continuing: Then i would create a wks file which would generate the whole binary image containing not only the fs image but also the binary blobs. The wks for something like i am talking looked like this https://pastebin.com/ZKgwiHLt | 15:15 |
ptsneves | qschulz that is slightly different. It is a depends on a recipe and i wanted dependency on tasks, specifically the do_deploy | 15:15 |
ptsneves | qschulz for that to be useful the recipe of the bootloader would need to install something in a linux like path which does not make sense for a boot loader blob | 15:16 |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has quit IRC | 15:17 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 15:20 | |
qschulz | ptsneves: mmmm.... I learned something today. So EXTRA_IMAGEDEPENDS is just an "alias" for do_image_complete[depends] += "recipe:do_populate_sysroot" | 15:21 |
qschulz | i'd have expected it to depends on do_depend actually | 15:21 |
qschulz | still, it is indeed not enough if you need it before do_image_complete (which is probably the case if you want to use it in a wks) | 15:22 |
ptsneves | qschulz that is my understanding let me look at image.bbclass... | 15:22 |
qschulz | s/do_depend/do_deploy/ | 15:22 |
ptsneves | qschulz d.appendVarFlag('do_image_complete', 'depends', extraimage_getdepends('do_populate_sysroot'))@image.bbclass | 15:24 |
ptsneves | so yep what you described a normal DEPENDS | 15:24 |
*** Bunio_FH <Bunio_FH!~bunio@188.146.161.165.nat.umts.dynamic.t-mobile.pl> has quit IRC | 15:24 | |
qschulz | ptsneves: not really, because DEPENDS also populates the recipe-sysroot* of the recipe (yes, even for an image recipe) :) but yeah, same hooks are used | 15:26 |
ptsneves | qschulz ohhhh. i am an old timer on krogoth :( so this subtelties were lost in me. Very good info to keep in mind on my upcoming update | 15:27 |
qschulz | ptsneves: oh jeez, poor you | 15:28 |
ptsneves | :) | 15:29 |
qschulz | ptsneves: had the chance to never work on it (though parts of our projects still use this version, I could until now not debug it :) ) | 15:29 |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:30 | |
qschulz | ptsneves: so I tend to forgot per recipe sysroot is still not used by some people :/ | 15:32 |
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has quit IRC | 15:32 | |
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has joined #yocto | 15:32 | |
ptsneves | actually the per sysroot feature is the biggest reason we want to update. The races on a shared sysroot are mind buzzing :( | 15:33 |
ptsneves | auto detection build systems detecting something sometimes and others not | 15:33 |
kergoth | i dont miss those issues, builds were never reproducible and sstate reuse was problematic as a result | 15:36 |
kergoth | thank goodness rp and the rest made it happen. i think that was on our todo list for like 8 years or something :) | 15:36 |
kergoth | can i just take a moment (not for the first time) to note that oe has existed for 17-18 years now? holy hell | 15:38 |
ptsneves | congrats and big thanks to the people who make it happen | 15:38 |
*** Nooks <Nooks!~jasonp@c-98-239-234-32.hsd1.pa.comcast.net> has joined #yocto | 15:41 | |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has joined #yocto | 15:41 | |
*** ptsneves <ptsneves!b0dd7824@176.221.120.36> has quit IRC | 15:43 | |
*** ptsneves <ptsneves!b0dd7824@176.221.120.36> has joined #yocto | 15:46 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 15:47 | |
moto-timo | kergoth: time flies | 15:47 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 15:47 | |
*** kiwi_29 <kiwi_29!49e7d3d6@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 15:58 | |
kiwi_29 | Hello.. my custom distro is based on deb pacakges. One of my custom recipes "custrecipe1" installs a file in /usr/lib/SHAREDLIB.SO this shared lib is also provided by another package - "anotherpkg1" . | 15:59 |
kiwi_29 | Therefore while generating rootfs, when custrecipe1.deb is being installed there is an error | 15:59 |
qschulz | kiwi_29: why do you need this lib twice? | 16:00 |
kiwi_29 | dpkg: error processing archive custrecipe1.deb (--unpack): | 16:00 |
kiwi_29 | Don't need it twice | 16:00 |
qschulz | kiwi_29: then don't install it :) | 16:00 |
kiwi_29 | anotherpkg1 is installed as package directly as dependeny of other packages | 16:01 |
kiwi_29 | Custerecipe1 compiles some software and also generated the shared lib which is same as name as anotherpkg1 | 16:02 |
zeddii | so change the recipe for Custerecipe1 and don't package that library. | 16:03 |
ptsneves | are these sharedd libs based on the exact same code? | 16:03 |
*** kiwi_29 <kiwi_29!49e7d3d6@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 16:04 | |
RP | kergoth: makes us feel old! :) | 16:05 |
zeddii | I'm a young one in the mix. and I've been at it for 10 years :D | 16:06 |
kergoth | yeah.. i just dug into the meta-metnor history to figure out when i changed something. it was 8 years ago. still at mentor. :) | 16:06 |
*** leonanavi <leonanavi!~Leon@78.130.197.211> has joined #yocto | 16:06 | |
RP | kergoth: its when it gets back to the bitkeeper cvs it gets scary :) | 16:07 |
moto-timo | bitkeeper **shudder** | 16:07 |
kergoth | ha | 16:08 |
kergoth | yeah i still have the bkbits tarballs on my nas somewhere from the exports from that. i don't think i have the cvs archives that preceded it though | 16:08 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 16:09 | |
kergoth | it bothers me some days how much history of software gets lost over the years. versions of major projects that nobody has anymore unless its on some cd in someone's closet | 16:09 |
kergoth | prior to scm, anyway | 16:09 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 16:09 | |
*** kiwi_29 <kiwi_29!49e7d3d6@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 16:09 | |
kiwi_29 | the code in custrecipe1 for shared lib is a lil different than anotherpkg1 | 16:10 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 16:10 | |
kiwi_29 | ptsneves | 16:10 |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC | 16:11 | |
RP | kergoth: I think we did an ok job of at least pulling in the majority of the history. It is useful, the bigger problem was our lack of comments back then! :) | 16:11 |
RP | (and I'm as guilty as anyone) | 16:11 |
ptsneves | kiwi_29 then if it is different you should either name the library differently or version it differently. Of course if it is getting there by mistake you should rework the recipe | 16:12 |
kergoth | agreed. i used to have a habit of not including enough *why* in my commit messages. lets just list what i'm doing, which is already in the damn diff. *eyeroll* | 16:12 |
ptsneves | kergoth you would be surprised how in 2020 almost 2021 this is still not done :( | 16:13 |
RP | kergoth: right, I've made assumptions about things I'd remember too, which misses another key point | 16:13 |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto | 16:13 | |
kiwi_29 | There was something related to assume_shlibs ..will that help ? | 16:13 |
sgw | RP: Morning, So my dumper changes failed badly or uncovered different issues? | 16:13 |
RP | sgw: they cause backtraces on the autobuilder | 16:14 |
RP | sgw: I didn't look into why | 16:14 |
kergoth | kiwi_29: like ptsneves implied, the answer is "don't do that". either don't install both, or rename one, or otherwise avoidt he conflict | 16:15 |
kiwi_29 | 👍 | 16:16 |
sgw | RP: that's strange, I did not see that, but I did local testing with a couple of different qemu images, I will have to try to force different errors. | 16:18 |
RP | sgw: I'm assuming the autobuilder tested some path you didn't. You can see a few failures so I'm hoping it will reproduce ok | 16:18 |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 16:20 | |
sgw | RP: yeah, I saw those, I will give them a try later today. | 16:20 |
*** kiwi_29 <kiwi_29!49e7d3d6@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 16:21 | |
Nooks | I'm having trouble building a /usr/bin/php that has fnmatch() support, and I'm not really sure how to fix it. The version of PHP I'm building is 7.2.10 from meta-openembedded. | 16:22 |
*** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:22 | |
JaMa | my first change was in monotone and OE was the only reason for me to ever use monotone :) | 16:22 |
Nooks | (it's 7.2.10 becuase the project is based on Thud for other reasons) | 16:22 |
Nooks | I'm not totally sure about what's gone wrong, but it looks like PHP checks for fnmatch.h using AC_FUNC_FNMATCH, which looks like it might be checking for cross-compilation. | 16:23 |
*** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has joined #yocto | 16:24 | |
RP | JaMa: its the only time I ever used monotone either | 16:24 |
*** mckoan is now known as mckoan|away | 16:24 | |
RP | sgw: I'm keen to get the changes in, I just had bigger issues with pseudo over the weekend | 16:25 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 16:28 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 16:30 | |
*** camus1 is now known as kaspter | 16:30 | |
RP | A green master-next with the pseudo changes in too: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1430 :) | 16:37 |
JaMa | nice :) | 16:41 |
kergoth | nice | 16:44 |
moto-timo | \o/ | 16:45 |
moto-timo | pseudo makes my head hurt | 16:46 |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has quit IRC | 16:46 | |
*** leonanavi <leonanavi!~Leon@78.130.197.211> has quit IRC | 16:51 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 16:51 | |
*** fl0v0 <fl0v0!~fvo@88.130.223.183> has quit IRC | 16:53 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:55 | |
rburton | moto-timo: if it doesn't, then worry | 16:57 |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-135.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 17:00 | |
RP | I'm still kind of in awe of the way the wrapper generation works | 17:01 |
ptsneves | where does the need for changes in pseudo come from? Is its functionality changing over time? | 17:06 |
*** meow` <meow`!~sbourdeli@107.159.31.190> has quit IRC | 17:09 | |
RP | ptsneves: realisation that its corrupting file modes quietly | 17:09 |
ptsneves | uhhh, how come quietly? In our system we have a file list checker that also checks for permission changes and no issues. Is it a recent issue? | 17:10 |
ptsneves | i mean root file system file list checker | 17:10 |
ptsneves | does it happen for packaged files or generally | 17:11 |
armpit | moto-timo, I have a patch for that | 17:11 |
RP | ptsneves: its a rare race problem related to inode number reuse | 17:12 |
RP | ptsneves: it would happen for packaged files, its certainly rare but I don't like rare issues like this | 17:12 |
*** davidinux <davidinux!~davidinux@217.138.219.141> has quit IRC | 17:13 | |
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 17:16 | |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 17:27 | |
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 17:29 | |
sgw | RP: got it to reproduce with the qemuarm-oecore build local. trying to understand why now. | 17:33 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:35 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 17:39 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:40 | |
*** davidinux <davidinux!~davidinux@217.138.219.141> has joined #yocto | 17:43 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 17:46 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 17:47 | |
*** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has quit IRC | 17:47 | |
zeddii | RP: I recently introduced a busybox recipe/config that is tailored for initrds in meta-virt. Martin followed up to say that due to it having a static configuration, some distros can blow up when they include meta/conf/distro/include/no-static-libs.inc .. What's the policy in adding exceptions to that file ? I can't think of a way to work around this in the meta-virt layer without breaking yocto policy (we | 17:47 |
zeddii | ll, I suppose I can make a new distro feature). | 17:47 |
*** jobroe <jobroe!~manjaro-u@p579eb542.dip0.t-ipconnect.de> has quit IRC | 17:49 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 17:53 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:54 | |
*** Tofe <Tofe!~Tofe@82-65-104-134.subs.proxad.net> has joined #yocto | 17:54 | |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has joined #yocto | 17:55 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:06 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:08 | |
RP | zeddii: we can make exceptions to the no-static-libs | 18:08 |
RP | zeddii: we used to do it for pseudo-native. The point of the file is to stop building stuff we don't need/use/care about | 18:09 |
zeddii | ok. so if I sent a patch to add libxcrypt, it won't be denied as 100% incorrect. (It may be denied for other reasons, but that's a different story). | 18:11 |
RP | rburton: master-next is throwing a ton of warnings about not being able to reset nice levels. Is that related to anything you changed? | 18:11 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:11 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:11 | |
RP | zeddii: as long as you can state why and probably document that in comments in the file, not automatic | 18:13 |
zeddii | will do. otherwise, I'm doing some kind of funky distro feature dance. I can fall back to that as appropriate. | 18:14 |
RP | zeddii: would you video the funky dancing? :) | 18:14 |
zeddii | no video of me dancing shall ever be made :P | 18:14 |
RP | :D | 18:14 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:14 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:20 | |
rburton | RP: huh, shouldn't be | 18:27 |
RP | rburton: its happening in rpm postinsts, other than that the logs are unhelpful | 18:29 |
rburton | very surprised if its something i broke | 18:30 |
RP | rburton: looking at the patches in -next, its hard to know which others :/ | 18:30 |
RP | rburton: I'm not saying it is yours but I am puzzled as to what else has touched rpm | 18:32 |
RP | rburton: the pseudo ones are unchanged since the previous run | 18:32 |
rburton | 'i'm not saying its yours, but it's yours' ;) | 18:34 |
RP | rburton: I just can't prove it yet | 18:34 |
rburton | on boot or at rootfs? | 18:35 |
RP | rburton: do_rootfs with rpm | 18:36 |
rburton | kicking a build now | 18:36 |
rburton | maybe its the plugin stuff | 18:37 |
rburton | ah i have a hunch | 18:37 |
rburton | yeah fine its my fault | 18:37 |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has quit IRC | 18:38 | |
RP | rburton: :) | 18:38 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:39 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-oohxudqwyrsqakqb> has quit IRC | 18:39 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:39 | |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has joined #yocto | 18:41 | |
rburton | RP: v2 sent | 18:43 |
RP | rburton: thanks :) | 18:44 |
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:10b2:ae0f:a8cb:5231> has joined #yocto | 18:47 | |
sgw | RP: found 1 of the issues and recent v2, it might still run more frequently, need to fix the status check in ssh.py still | 18:48 |
havok101 | Hey, I've written a simple recipe for an app I'm building. But each time I build it I see fatal error: unistd.h: No such file or directory. If I used the sdk to build it, it builds fine. | 18:49 |
Nooks | ok, editing main/php_config.h in do_configure_append() makes a php binary with fnmatch() (according to php --rf fnmatch) | 18:50 |
havok101 | Only thing I feel I'm doing unconventional is OECMAKE_SOURCEPATH = "${S}/Apps-c++". Because the root cmake list is located under a sub directory | 18:50 |
Nooks | if I had to guess I would say that the cross-compile check in AC_FUNC_FNMATCH is to blame, but I am still curious as to how other autoconf-using software built by Yocto gets a working fnmatch() | 18:51 |
*** Bunio_FH <Bunio_FH!~bunio@77-255-134-153.adsl.inetia.pl> has quit IRC | 18:51 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:53 | |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 18:55 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:55 | |
havok101 | yeah I can build a whole image. Just this one is having a problem. | 18:55 |
RP | sgw: ok, I'll give it another try on the autobuilder, thanks | 18:56 |
sgw | RP: sorry about that, I think I tested it one way. | 18:59 |
RP | sgw: its ok, we have a lot of codepaths in this case | 19:01 |
*** paulg_ <paulg_!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 19:03 | |
* RP suspects cancelling his build succeeded in giving sakoman all the workers :) | 19:03 | |
*** paulg_ <paulg_!~paulg@24-212-228-244.cable.teksavvy.com> has quit IRC | 19:03 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:04 | |
sgw | RP: on a different topic, what's your thoughts on debugging a sstate issues? | 19:05 |
RP | sgw: that its a good thing to do? ;-) | 19:08 |
RP | sgw: (you may need to be more specific) | 19:08 |
sgw | yeah, I see bitbake do the setscenes but then starts fetching, unpacking, ... | 19:09 |
RP | sgw: when you weren't looking we changed the way this works a bit | 19:09 |
sgw | This is not a poky related issue, so there are other things I need to deal with. | 19:09 |
RP | sgw: as part of the hash equivalence work, we removed the contraints around setscene, then build | 19:10 |
RP | sgw: bitbake now dynamically adapts as it goes | 19:10 |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 19:12 | |
sgw | Thoughts on where to go looking then or enabling debug on? | 19:12 |
RP | sgw: you've given me no idea what kind of issue you're looking at so I have no idea | 19:13 |
moto-timo | not the first time sgw has been slightly random ;) | 19:13 |
sgw | What we are seeing is the kernel rebuilding and not using sstate from fresh build directories with no configuration changes. | 19:13 |
RP | sgw: ah, now there is a better clue | 19:14 |
sakoman | RP: yes, it did! Thanks :-) | 19:14 |
RP | sgw: I'm going to guess its module which needs a full kernel build directory | 19:14 |
RP | guess its some kernel module which | 19:14 |
RP | sgw: that is expected unfortunately | 19:15 |
sgw | Interestingly, if I just rm TMPDIR and run bitbake in the same builddir it does use sstate correctly | 19:15 |
RP | was there an external module in the second build that wasn't in the first? | 19:15 |
sgw | but if have a different BBPATH (ie different builddir) it rebuilds. | 19:16 |
sgw | Nope everything is identical | 19:16 |
sgw | Only the actual build directory changes | 19:16 |
RP | hmm, that is stranger then. It shouldn't depend on BBPATH or TOPDIR | 19:16 |
RP | sgw: save the stamps directories from both builds and compare? | 19:16 |
RP | sgw: oh, is hashequiv enabled? | 19:17 |
sgw | I saves the siginfo from one build and then tried diffsig from the second and they are the same | 19:17 |
RP | a non-common hash equiv and shared sstate dir would do this | 19:17 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:17 | |
RP | sakoman: I need to write the prioritisation function a little differently :) | 19:19 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:20 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:21 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:26 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:27 | |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 19:32 | |
*** WillMiles <WillMiles!~Will@209.87.231.80> has joined #yocto | 19:35 | |
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.181.14> has quit IRC | 19:41 | |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has quit IRC | 19:42 | |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-11-174-88-220-58.dsl.bell.ca> has joined #yocto | 19:44 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 19:56 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 19:56 | |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-135.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 20:02 | |
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC | 20:03 | |
*** ecdhe_ <ecdhe_!~ecdhe@mms-rf-support.com> has joined #yocto | 20:03 | |
*** lucaceresoli <lucaceresoli!~lucaceres@37.163.45.187> has joined #yocto | 20:03 | |
*** lucaceresoli <lucaceresoli!~lucaceres@37.163.45.187> has quit IRC | 20:11 | |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 20:15 | |
*** ericch_ <ericch_!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 20:16 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 20:20 | |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC | 20:21 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 20:45 | |
*** ecdhe_ <ecdhe_!~ecdhe@mms-rf-support.com> has quit IRC | 20:48 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 20:48 | |
*** leonanavi <leonanavi!~Leon@78.130.197.211> has joined #yocto | 20:48 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 20:48 | |
*** kamensky <kamensky!806bf1bc@128.107.241.188> has joined #yocto | 20:51 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 20:51 | |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-135.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 20:53 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 20:56 | |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has joined #yocto | 20:57 | |
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:03 | |
*** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:07 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 21:09 | |
*** berton <berton!~berton@181.220.78.182> has quit IRC | 21:16 | |
sgw | RP: so much for getting it right the first time, looks like v3 should do the correct trick. Got the status and string checks fixed the right way around! | 21:23 |
RP | sgw: https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/2513/steps/8/logs/step1c | 21:23 |
RP | sgw: ah. So I abort this one and retry? | 21:24 |
sgw | That looks like it still has to original code, so abort and use v3 please. | 21:25 |
RP | sgw: done, restarted | 21:26 |
RP | sgw: hanks | 21:26 |
RP | thanks :) | 21:26 |
sgw | np | 21:26 |
sgw | sorry about the re-tries. | 21:27 |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 21:27 | |
*** leonanavi <leonanavi!~Leon@78.130.197.211> has quit IRC | 21:27 | |
sgw | halstead: It was great to have a real happy hour with you friday! | 21:29 |
RP | sgw: I had a few with pseudo and its not the only patchset which has been fun recently | 21:31 |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 21:31 | |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 21:38 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:39 | |
*** dusry <dusry!46a3cfac@ip70-163-207-172.ph.ph.cox.net> has joined #yocto | 21:53 | |
dusry | Hi, everyone. Has anyone ever seen 'devtool modify' fail on do_unpack for the u-boot recipe. I get a ModuleNotFoundException for _sysconfigdata. Devtool has only failed on this one recipe. | 21:57 |
khem | seems like a python related error | 21:58 |
khem | is it on master branch | 21:59 |
dusry | Yeah, that's what I noticed. I get a stack trace from Python. Currently it is. I have tried both dunfell and master. | 21:59 |
dusry | This same issue also occurs for u-boot-ti-staging in meta-ti, but the TI guys haven't responded. | 22:00 |
RP | dusry: there have been reports on the mailing list but we've never had a patch to fix this properly (and we don't fully understand the error) | 22:03 |
kergoth | hmm, seems -fuse-ld doesn't work with our gcc-cross-canadian in an sdk, it just always uses what we built with using LDGOLD, even though we enabled gold whether it was default or not.. | 22:04 |
kergoth | guessing its probably something to do with our various symlinks in the gcc-cross-canadian build process | 22:05 |
dusry | RP I recently posted on the mailing list about it. I'd be happy to help look into it, but I'm not really sure where to start looking. Still learning the whole system. | 22:06 |
dusry | You can also find the stack trace in what I sent to the mailing list, or I can send it again. | 22:06 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 22:07 | |
kergoth | running into ""ARM external linker must be gold"" in the go-runtime build using an external oe sdk as an external toolchain, since it fails to use -fuse-ld=gold to switch | 22:08 |
RP | dusry: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=482da97cfc8b926fd5e5f3c9e8e7933741937ad1 was one "fix" and there were others, this has been going on for a while. I stopped taking these patches as there is clearly a bugger issue we need to get to grips with | 22:08 |
kergoth | dusry: you sh ould chekc the mailing list archives, there've been at least 3 threads that i know of | 22:08 |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 22:08 | |
*** camus1 is now known as kaspter | 22:09 | |
RP | dusry: I suspect the real fix will be to patch our python to look for an OE specific variant of this environment variable name, then we can set one for our python which the OS python won't see/use | 22:11 |
RP | but I am guessing at it | 22:12 |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC | 22:13 | |
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 22:13 | |
dusry | RP thank you for the info. Might be the push I need to go explore the inner workings of OE. | 22:14 |
RP | dusry: I think in some ways it may be a similar issue to this one http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/python?id=4a42d6907ab3fb1e890b82c2ac9427b742ad5a4b | 22:18 |
RP | different variable name, possibly similar issue though? | 22:18 |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 22:19 | |
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:10b2:ae0f:a8cb:5231> has quit IRC | 22:19 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:24 | |
*** The_Pacifist <The_Pacifist!~The_Pacif@cpe-104-174-238-53.socal.res.rr.com> has joined #yocto | 22:25 | |
The_Pacifist | Is there a way to share a custom/vendor_specific kernel object between multiple meta-bsp layers? | 22:30 |
*** kamensky <kamensky!806bf1bc@128.107.241.188> has quit IRC | 22:31 | |
The_Pacifist | For clarity, I have a driver I pull down from a vendor's website as part of a .bbappend file inside a recipe-bsp dir, inside a a meta-bsp dir | 22:31 |
*** itseris <itseris!~itseris@d64-180-147-137.bchsia.telus.net> has quit IRC | 22:31 | |
The_Pacifist | My question is, can I share that driver with multiple meta-bsp's | 22:32 |
*** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 22:32 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:32 | |
The_Pacifist | Is it a bad idea to put it in a non-hardware meta layer? | 22:32 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:33 | |
*** itseris <itseris!~itseris@d64-180-147-137.bchsia.telus.net> has joined #yocto | 22:33 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 22:33 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 22:34 | |
*** camus1 is now known as kaspter | 22:34 | |
*** pev <pev!~pev@cpc123816-trow7-2-0-cust2.18-1.cable.virginm.net> has quit IRC | 22:41 | |
*** dev1990 <dev1990!~dev@dynamic-81-168-186-230.ssp.dialog.net.pl> has quit IRC | 22:54 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:55 | |
dusry | The_Pacifist I feel like that's the only way outside of maintaining two copies. Doesn't seem like there is anything wrong with it. Just make sure you prioritize your layer correctly. | 22:56 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:57 | |
*** dusry <dusry!46a3cfac@ip70-163-207-172.ph.ph.cox.net> has quit IRC | 23:02 | |
*** agust <agust!~agust@p54833a5e.dip0.t-ipconnect.de> has quit IRC | 23:03 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:05 | |
halstead | sgw, Just caught your message. Thank you. It was nice to have an in person conversation about Yocto Project. And the porter was darn good too. | 23:08 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:08 | |
RP | halstead: wish I could join you for some porter! :) | 23:27 |
halstead | I wish you could too RP | 23:27 |
zeddii | sakoman: I built the one arch that still builds with 5.4.61+ and lttng-modules. which is why mine didn't blow up :D | 23:27 |
sakoman | zeddii: what are the odds . . . ;-) | 23:28 |
zeddii | when I looked at your links, it was obvious :D | 23:28 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:29 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:29 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:40 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:43 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!