Thursday, 2019-09-12

« Wednesday, 2019-09-11 Index Friday, 2019-09-13 »
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC00:27
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.156.11> has quit IRC01:21
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto01:31
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto01:54
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto04:26
*** onlyesterday <onlyesterday!~onlyester@113.160.58.178> has quit IRC04:51
iceawayIs there any way in a recipe to reference the base path of the layer that it exists in?05:10
iceawayI have some private key files etc. that are not placed in the recipe dir, but in a subdir directly under my layer root.05:11
krooniceaway, I know at least you can capture THISDIR with immediate expansion, :=, and use a relative path to any place in your layer05:21
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:24
iceawaykroon: thanks, will try that!05:26
iceawayI have another really strange issue, related to u-boot. I want to change between two different root file system, for firmware upgrade purposes, and in my uboot env the variable mmcroot=<dev> sets which root file system to boot from. The issue is that if I modify mmcroot from Linux with fw_setenv, it looks like it is successful with fw_printenv. But when I reboot mmcroot (if I print it in u-boot) will have05:28
iceawayreverted to the default value. If I continue booting into Linux and use fw_printenv however, I can see the value I set before rebooting.05:28
iceawayI can even add new variables with fw_printenv, which are retained after rebooting, but mmcroot seems like it always is overwritten when u-boot starts.05:29
krooniceaway, sounds like u-boot is not looking at the same env file that linux updates ?05:34
krooniceaway, can you see the variables you set with fw_printenv in u-boot ?05:36
iceawayThat is what I thought too, but if  I create a new variable with fw_setenv, I can see that variable in u-boot.05:36
iceawayI can also change other variables like mmcpart. but there seems to be some magic with mmcroot.05:36
krooniceaway, maybe some u-boot script resets it ?05:36
iceawayPossibly, not anything in the env though, I grepped the entire env for mmcroot and it does not appear to be set by any other script.05:37
kroonnot even via some sneaky variable substitution tricks05:37
iceawayHmm I suppose it could be that, u-boot scripting is a bit of black magic to me.05:39
kroondev=root, mmc$dev=foobar - you get the deal05:39
iceawayI will have another look at the enviroment stuff :)05:40
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC05:41
iceawayNothing really pops out for me. If anyone cares to have a look: https://pastebin.com/DkYqK9F005:43
iceawayWeird thing is that when Linux starts again, the mmcroot variable has been reverted to what I set before the reboot. So the change in u-boot does not seem to go into non-volatile storage.05:45
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto05:50
*** armpit <armpit!~armpit@2601:202:4180:c33:f9e2:21e5:8b16:9d92> has quit IRC06:00
krooniceaway, nothing stands out to me. maybe its time to patch u-boot to debug if/when mmcroot is set06:09
*** armpit <armpit!~armpit@2601:202:4180:c33:94af:b4e3:6058:dfc8> has joined #yocto06:11
iceawaykroon: yes, might have to do that. Thanks for the help.06:14
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:21
*** frsc <frsc!~frsc@200116b8248f7d00a8b4905239d22ba1.dip.versatel-1u1.de> has joined #yocto06:29
*** frsc <frsc!~frsc@200116b8248f7d00a8b4905239d22ba1.dip.versatel-1u1.de> has quit IRC06:31
*** frsc <frsc!~frsc@200116b8248f7d0034785c205e37db7b.dip.versatel-1u1.de> has joined #yocto06:33
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC06:33
*** Klox <Klox!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC06:36
*** alimon <alimon!alimon@gateway/shell/linaro/x-kdxwurhyvcmjuqof> has quit IRC06:40
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-aiynxuzngodwwpba> has quit IRC06:40
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto06:40
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-kzrmbxcmvnbhjopk> has joined #yocto06:40
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC06:52
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto06:57
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto06:59
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has joined #yocto07:24
*** monkeyman79 <monkeyman79!504f5681@80.79.86.129> has joined #yocto07:24
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:28
*** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC07:34
*** seebs <seebs!~seebs@24.196.59.174> has quit IRC07:34
*** seebs <seebs!~seebs@24.196.59.174> has joined #yocto07:35
*** julmust <julmust!a5e1c069@165.225.192.105> has joined #yocto07:40
*** leitao <leitao!~leitao@2620:10d:c092:380::1:f9be> has joined #yocto08:17
*** leitao <leitao!~leitao@2620:10d:c092:380::1:f9be> has quit IRC08:21
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto08:23
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto08:38
*** cquast <cquast!~cquast@90.85.130.193> has joined #yocto08:39
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto08:39
*** cquast <cquast!~cquast@90.85.130.193> has quit IRC08:39
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto08:47
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC09:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto09:08
yoctiNew news from stackoverflow: How do i patch in yocto? <https://stackoverflow.com/questions/57903358/how-do-i-patch-in-yocto>09:10
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto09:42
*** monkeyman79 <monkeyman79!504f5681@80.79.86.129> has quit IRC09:45
*** julmust <julmust!a5e1c069@165.225.192.105> has quit IRC09:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC09:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:54
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:00
kpohello, i'm developing gui application in qt for raspberry pi, the application should start on boot (via sytemd service), I'd rather not start it as root, so I've added some users using extrausers class. Unfortunately, my application needs access to /dev/vchciq (GPU interface), which is owned by root/root. I'd like to add user group, such as gui for users that should be able to use GPU - that's not a problem, extrausers to the resque. The problem (or10:04
kpoquestion) is where/when should I change the ownership of /dev/vchciq? Am I able to d that on build level? Or should I make some kind of service, that changes that on boot?10:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:05
rburtonwrite a udev rule to change the permissions as the node is created10:05
rburton(as all the nodes in /dev are generated by udev)10:05
kpothank you, I'll investigate10:05
kpo(as all the nodes in /dev are generated by udev) <- this looks exactly like the thing I was looking for, thanks rburton10:06
*** monkeyman79 <monkeyman79!504f5681@80.79.86.129> has joined #yocto10:34
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto10:34
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto10:39
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC10:47
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC10:50
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto10:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC10:56
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto11:00
*** monkeyman79 <monkeyman79!504f5681@80.79.86.129> has quit IRC11:26
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC11:26
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto11:27
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC11:32
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto11:33
*** berton <berton!~berton@181.220.83.67> has joined #yocto11:43
kanavin_zeddii, if I need to bisect a linux-yocto regression, what is the standard procedure?11:46
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC11:52
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto11:55
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has joined #yocto12:04
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC12:24
*** anujm <anujm!~anujm@134.134.139.77> has joined #yocto12:26
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto12:34
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC12:40
*** alimon <alimon!alimon@gateway/shell/linaro/x-umqzdehtpsigkkxb> has joined #yocto13:01
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto13:06
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC13:12
*** rewitt <rewitt!rewitt@nat/intel/x-hrzfvohlnvxyqomo> has quit IRC13:17
*** rewitt <rewitt!~rewitt@134.134.139.74> has joined #yocto13:17
iceawayI'm trying to find out how to get rid of a large lib in my image that I don't need. So I ran "oe-pkgdata-util find-path /usr/lib64/libVSC.so", to get the name of the recipe. But I cannot find that recipe anywhere. I tried looking for .bb files in my meta layers, and ran "bitbake-layers show-recipes" but it did not show up.13:20
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:29
krooniceaway, maybe you have better luck with: oe-pkgdata-util find-path *libVSC*13:30
*** falk0n <falk0n!~falk0n@a109-49-142-1.cpe.netcabo.pt> has joined #yocto13:31
iceawaykroon: I did find the recipe that brings in that lib, or at least the name of it, but when I search for that name I cannot find the actual recipe.13:32
iceawayCould it be hidden by some PROVIDES variable in another recipe?13:33
krooniceaway, packages can get renamed13:34
kroondebian-style13:34
kroonso you found which *package* the file comes from, but not the recipe which generated that package13:36
iceawayahh right, the old package vs recipe confusion strikes again.13:36
iceawaymore digging...13:37
*** kaspter <kaspter!~Instantbi@115.204.208.100> has quit IRC13:59
*** kaspter <kaspter!~Instantbi@115.204.208.100> has joined #yocto13:59
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC13:59
*** learningc <learningc!~learningc@218.111.14.130> has joined #yocto14:00
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto14:04
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC14:14
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC14:14
*** learningc <learningc!~learningc@218.111.14.130> has quit IRC14:14
*** anujm <anujm!~anujm@134.134.139.77> has quit IRC14:19
*** stephano <stephano!stephano@nat/intel/x-uintfwsxfkrtyrbq> has joined #yocto14:19
fullstopI'm having great difficulty cross compiling a python3 package which is not a yocto /oe recipe yet.14:20
fullstopIt uses cmake to build some binary components and it consistently finds libraries in the recipe-sysroot-native directory instead of recipe-sysroot.14:21
fullstopcmake.bbclass has "set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})"14:21
fullstopwhich suggests that both are added and, from what I've read, it should find stuff in ${STAGING_DIR_HOST} first.  The library is there, but it still tries to link to the native one and fails.14:22
*** dreyna <dreyna!~dreyna@rrcs-76-80-82-53.west.biz.rr.com> has joined #yocto14:22
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has quit IRC14:24
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has quit IRC14:29
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has joined #yocto14:29
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto14:30
armpitYP bug triage as started14:32
*** PinkSnake23 <PinkSnake23!51ff1123@81.255.17.35> has quit IRC14:33
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto14:39
*** florian_kc is now known as florian14:41
*** learningc <learningc!~learningc@121.122.76.45> has joined #yocto14:41
*** Crofton|mini <Crofton|mini!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has quit IRC14:41
*** learningc <learningc!~learningc@121.122.76.45> has quit IRC14:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:04
rburtonJPEW: if you want to fix RPs bitbake patch go for it :)15:07
JPEWrburton: I'm fixing it by replacing the whole thing :)15:10
JPEWrburton: We have to completely re-write the server and change the protocol in order for it to scale as well as we need.15:10
armpitreplacing it like writing it in Java ?15:14
*** mischief <mischief!~mischief@wopr.sciops.net> has quit IRC15:24
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:24
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto15:27
smurrayarmpit: heh, that would almost be worthwhile if it lead to more meta-java improvements ;)15:29
*** kaspter <kaspter!~Instantbi@115.204.208.100> has quit IRC15:37
khemJava is only good in cup but rust or goland might be good options15:37
*** kaspter <kaspter!~Instantbi@115.204.208.100> has joined #yocto15:38
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC15:38
*** learningc <learningc!~learningc@121.122.76.45> has joined #yocto15:46
*** rewitt <rewitt!~rewitt@134.134.139.74> has quit IRC16:01
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:03
*** learningc <learningc!~learningc@121.122.76.45> has quit IRC16:04
*** stephano <stephano!stephano@nat/intel/x-uintfwsxfkrtyrbq> has quit IRC16:09
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC16:09
*** learningc <learningc!~learningc@121.122.76.45> has joined #yocto16:09
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:16
*** marler8997 <marler8997!0f41fc0d@ztxe01hpics303.austin.hp.com> has joined #yocto16:20
marler8997I'm getting errors with "<package> rdepends on <package> [debug-deps]".  Is there an easy way to see why these rdepends are occuring? Sometimes when I see these errors it will say one so rdpeends on another, but I'm not getting that output this time16:22
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC16:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto16:40
marler8997I looked at the do_package_qa log and I saw some bbnote messages, I think I found out which file it was16:40
kroonmarler8997, you can always check insane.bbclass16:47
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:48
marler8997Yeah I could add some debug in there16:48
*** learningc <learningc!~learningc@121.122.76.45> has quit IRC17:06
*** learningc <learningc!~learningc@121.122.76.45> has joined #yocto17:12
*** frsc <frsc!~frsc@200116b8248f7d0034785c205e37db7b.dip.versatel-1u1.de> has quit IRC17:16
*** rewitt <rewitt!~rewitt@134.134.139.74> has joined #yocto17:18
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has quit IRC17:18
*** User__ <User__!~learningc@121.122.76.45> has joined #yocto17:27
*** learningc <learningc!~learningc@121.122.76.45> has quit IRC17:28
*** khem <khem!~khem@unaffiliated/khem> has quit IRC17:29
Piratyadelcast: if [ ! -z "$SOURCE_DATE_EPOCH"  ]; then => if [ -n "$SOURCE_DATE_EPOCH"  ]; then17:40
Piratyadelcast: also is it really necessary to depend on gnu tar?17:52
kroonCan I have multiple but different versions of yocto/bitbake-memory-resident servers running at the same time ?17:53
kroon(for different builds of course)17:53
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC18:00
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has joined #yocto18:02
kroonAnd is there a faster way to extract TMPDIR besides running "bitbake -e | grep ^TMPDIR=" ?18:02
*** User__ <User__!~learningc@121.122.76.45> has quit IRC18:05
*** dreyna <dreyna!~dreyna@rrcs-76-80-82-53.west.biz.rr.com> has quit IRC18:05
adelcastPiraty: the issue is --clamp-mtime, AFAIK that requires gnu tar > 1.2818:11
Piratyyes, that's what the comment says18:11
Piratywhy not set the time to SOURCE_EPOCH to all files alike ?18:12
Piratyusually developers have a mechanism to determine SOURCE_EPOCH on their own (or the buildsystem), at least i have18:13
adelcastthe idea is to only modify the mtime for files that are created at build time, to have consistency18:13
*** learningc <learningc!~learningc@121.122.76.45> has joined #yocto18:13
*** yann|work <yann|work!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has joined #yocto18:14
adelcasthttps://git.dpkg.org/git/dpkg/dpkg.git/tree/dpkg-deb/build.c18:14
adelcast(that's what dpkg build does)18:14
Piratythat would be a good point (if feature parity is a goal ;) )18:16
adelcastnot necessarily parity since opkg is more lightweight18:17
adelcastbut for most functionality, I do try to stay as close to debian as possible18:17
Piratybtw if gnu tar is the required one, tar -a would save you from the pipe to the compressor by only specifying the suffix. as far as i know, busybox tar has (or used to have) a different way of handling -a18:17
Piratynevermind my noise then, thanks for maintaining opkg18:18
adelcast=), no worries, I do appreciate all input to improve the codebase18:18
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto18:21
*** learningc <learningc!~learningc@121.122.76.45> has quit IRC18:27
*** yacar_ <yacar_!~yacar@242.25.24.93.rev.sfr.net> has quit IRC18:30
rburtonadelcast: patch looks good, i can test it later18:38
adelcastrburton: thanks!18:38
Piratyadelcast: shouldn't you have prefix opkg-utils ? also, which bugzilla do you refer to?18:40
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto18:41
adelcastPiraty, yeah, that was my bad, the header message should have had [opkg-utils] to make sure this message was going to opkg-utils, not regular opkg18:44
Piratywas slightly confused for 5 sec18:44
adelcastall opkg bugs are tracked in bugzilla, under the yocto project18:44
Piratyi think you can set that prefix in the respective repo's .git/config18:44
adelcasthttps://bugzilla.yoctoproject.org/buglist.cgi?product=opkg&component=opkg18:44
adelcastah, good to know, might as well just do that now18:45
Piratyah this was new to me18:45
adelcastyeah, officially opkg is part of the yocto project, the source code is on yocto's git servers and bugs are tracked in yocto's bugzilla18:45
Piratyyet the ML is on google18:47
Piratyonly yocto's opkg, not openwrt's yocto ;)18:47
adelcastyeah.....that other opkg is, well, a different story...I have been trying to see if we can merge, but haven't had luck18:48
kergoththe ML being on google really doesn't mean much, yocto has adopted projects that originally started elsewhere, transitioning mailing lists is a pain for everybody..18:55
Piratymerging is hard code-wise or people-wise?18:59
adelcastpeople-wise, unsurprisingly....a couple of years ago someone took the effort of porting the OpenWRT patches to master yocto opkg and I worked with him to merge all of them19:01
adelcastbut the openWRT guys showed no interest on starting using upstream yocto opkg19:02
adelcastand their opkg is weird...is branched off a random commit on 0.2.7, at least that's what it used to be last time I checked19:02
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC19:08
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto19:09
Piratyat least the use cmake, but that's a very small win then19:14
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC19:16
*** Bunio_FH1 <Bunio_FH1!~bunio@clj-165.netdrive.pl> has joined #yocto19:28
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC19:30
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:54
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto20:05
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto20:07
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC20:08
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC20:08
*** gondor <gondor!~gond@5-13-192-177.residential.rdsnet.ro> has joined #yocto20:10
gondorhi all20:10
gondoris it possible to alter MACHINE_FEATURES from my layer but without re-creating the machine .conf file from the bsp that I use?20:11
gondorI tried from local.conf and layer.conf but I can't do a MACHINE_FEATURES_remove on a per-machine basis20:12
gondorthanks20:12
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:19
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto20:37
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC20:49
khemgondor: I would suggest to create a new machine conf20:51
khemwhich inherits the original machine and you override needed bits in that config20:51
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto21:10
*** berton <berton!~berton@181.220.83.67> has quit IRC21:17
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC21:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto21:40
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC21:46
*** dv_ <dv_!~dv@62.178.50.190> has quit IRC21:49
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:58
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto21:59
*** dv_ <dv_!~dv@62.178.50.190> has joined #yocto22:03
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:04
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC22:07
jwesselJaMa: Thanks for the pointer.  I seriously doubt it fixes the problem in the case, but I did figure out the issue I asked about yesterday.22:10
jwesselhttps://pastebin.com/Y8T6kbcZ22:10
jwesselThe FILERPROVIDES was getting scrambled when usrmerge was on.22:10
jwesselSo it causes the lib32-bash to look like it doesn't actually provide /bin/bash22:10
jwesselI'll send a patch out for consideration after more builds and analysis of the issue.22:11
JaMayes, so it set the FILERPROVIDES as providing lib32-/bin/bash for you, right?22:12
JaMathat's the same as what I was seeing, but that's because of multilib, not usrmerge, isn't it?22:13
jwesselThe multilib case seems to work ok.22:14
jwesselThe usrmerge adds in a hard specification which gets overwritten.22:14
jwesselI had been debugging between a multilib build with and without usrmerge.22:15
jwesselAt any rate, that seems to be logical way to fix it, but I don't want to break something worse.  That condition is pretty deep in the call chain of lots of other functions for the variable manipulation.22:16
JaMaok, for me this is broken in all builds using multilib without usrmerge, but my work arounds work as well, so I can live with it22:21
*** __angelo <__angelo!~prefetch@unaffiliated/ad/x-0785363> has quit IRC22:24
jwesselAh... I can explain away why it breaks in the generic multilib case.22:26
jwesselIt is the update-alternatives code that bash used that caused it to work for the multilib case without usrmerge.22:26
jwesselIf the update alternatives are off, or not processed etc... You'd get the same exact error.22:27
*** __ad <__ad!~prefetch@unaffiliated/ad/x-0785363> has joined #yocto22:27
*** __ad is now known as __angelo22:27
jwesselThat is why I figured the classextend change wouldn't exactly fix your issue.22:27
jwesselYou would also need to have the same line of code the usrmerge activates in the bash recipe, and then you'd stop seeing all those errors.22:28
jwesselI had added a pile of print()'s to figure out what was going on.22:28
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto22:35
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC22:36
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:39
JaMaunfortunatelly u-a isn't the only issue with multilib, see http://git.openembedded.org/openembedded-core/commit/?id=01b9810ff1cea53ae321f6fbe760b83573ed78c022:41
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has quit IRC22:45
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC22:59
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto23:21
« Wednesday, 2019-09-11 Index Friday, 2019-09-13 »

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!