IRC log for #oe on 20170207

00:04.43*** join/#oe moto-timo (~ttorling@134.134.139.82)
00:04.43*** join/#oe moto-timo (~ttorling@fsf/member/moto-timo)
01:19.05*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
02:10.23*** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-qtnrheophkxilrcm)
02:11.40*** join/#oe uwe_ (~uwe_@dslb-084-056-063-165.084.056.pools.vodafone-ip.de)
02:16.00*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
02:47.36*** join/#oe thaytan (~thaytan@241.80.233.220.static.exetel.com.au)
03:26.39*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
03:33.55*** join/#oe uwe__ (~uwe_@dslb-084-056-063-165.084.056.pools.vodafone-ip.de)
03:39.55*** join/#oe mago1 (~mago@h-103-179.a444.priv.bahnhof.se)
04:09.47*** join/#oe bluelightning (~paul@118.148.113.65)
04:09.47*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
04:18.26*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
05:06.20nerdboyis morty supposed to have old DEPLOY_DIR_IMAGE variable or the new one?
05:55.14khemnew one
06:28.52*** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com)
06:29.23*** join/#oe voltbit (~acid___@5-12-250-180.residential.rdsnet.ro)
07:21.50*** join/#oe t0mmy (~tprrt@217.114.201.133)
07:26.08*** join/#oe vmesons (~rmacleod@24-212-231-150.cable.teksavvy.com)
07:38.19*** join/#oe qt-x (~Thunderbi@217.10.196.2)
07:45.13*** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439)
07:51.55*** join/#oe thaytan (~thaytan@241.80.233.220.static.exetel.com.au)
07:53.50*** join/#oe jku (~jku@192.198.151.45)
07:54.44*** join/#oe thaytan (~thaytan@241.80.233.220.static.exetel.com.au)
07:58.50*** join/#oe JaMa (~martin@217.30.68.212)
08:09.05*** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-pdrujlbsslakfsre)
08:11.06*** join/#oe ant_work (~ant__@host56-27-dynamic.5-87-r.retail.telecomitalia.it)
08:15.19*** join/#oe morphis (~morphis@pD9ED64B5.dip0.t-ipconnect.de)
08:16.03*** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439)
08:20.58*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
08:21.41*** join/#oe stefan_schmidt (~stefan@p20030048093A72563252CBFFFE54190F.dip0.t-ipconnect.de)
08:27.55*** join/#oe joseppc (~josep@sestofw01.enea.se)
08:27.55*** join/#oe joseppc (~josep@linaro/joseppc)
08:28.48ant_workJaMa, hi. Last RSS changes have fixed meta-initramfs issues. I've built it for mips last night.
08:49.29*** join/#oe morphis (~morphis@pD9ED64B5.dip0.t-ipconnect.de)
08:54.12*** join/#oe bluelightning (~paul@118.148.113.65)
08:54.12*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
08:54.55*** join/#oe lumag (~lumag@188.162.65.89)
09:05.18*** join/#oe joshuagl (joshuagl@nat/intel/x-htbmavaxagerivmp)
09:08.57*** join/#oe t0mmy (~tprrt@217.114.201.133)
09:13.31*** join/#oe lumag_ (~lumag@188.162.64.65)
09:20.16*** join/#oe joeythesaint (~joe@vegas.deserted.net)
09:25.40JaMaant_work: good
09:25.49JaMa1 down, 100 to go
09:28.10ant_workProbably more recipes do build correctly today
09:31.52ant_workneverthless I have the feeling that even if building now these recipes are fragile wrt sysroot tricks and could be improved
09:36.22*** join/#oe clopez (~tau@neutrino.es)
09:43.47*** join/#oe hrw (~hrw@redhat/hrw)
10:04.48*** join/#oe Anticom (~quassel@217.6.33.234)
10:17.24*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
10:50.52*** join/#oe berton (~berton@189.114.111.135)
10:51.09*** join/#oe ftonello (~felipe@host81-152-92-225.range81-152.btcentralplus.com)
10:55.14*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
11:02.54*** join/#oe berton (~berton@189.114.111.135)
11:20.31*** join/#oe Anticom (~quassel@217.6.33.234)
11:23.52*** join/#oe dv_ (~quassel@62.178.118.86)
11:46.09*** join/#oe Crofton|work (~balister@pool-108-4-175-67.ronkva.east.verizon.net)
11:53.50JaMaant_work: doesn't look any better, the builds are still running but qemuarm finished with 103 failures again
11:54.53Crofton|workurg
11:54.57Crofton|workhome again
11:58.07ant_workargh
13:00.32*** join/#oe john2 (~john@host86-143-93-17.range86-143.btcentralplus.com)
13:13.23mckoanCrofton|work: welcome back
13:13.39Crofton|workthanks
13:22.43*** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com)
13:40.38*** join/#oe marka (~masselst@128.224.252.2)
13:50.10rburtonCrofton|work: can you still replicate the slang problem you were having?
13:50.24Crofton|workgive me a minute
13:50.36Crofton|workjust updated some stuff and rebuilding things
13:50.50rburtoncool
13:50.59rburtonjust noticed the bug and couldn't remember if we got anywhere with it
13:53.56Crofton|workyeah
13:54.01Crofton|workonly imapcts me apparently
13:55.39Crofton|workERROR: slang-2.3.1-r0 do_configure: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities.
13:55.40Crofton|workRerun configure task after fixing this.
13:55.45Crofton|workjsut hit it
13:56.28rburtonok
13:56.37rburtonwith current master?
13:56.56*** join/#oe Aethenelle (~Aethenell@107.138.98.226)
13:58.40rburtonCrofton|work: you have X headers on your build host?
13:58.49Crofton|workit is liekly
13:59.01rburtonhm i do too
13:59.40*** join/#oe Cubi_ (~sstiller@b2b-94-79-174-114.unitymedia.biz)
14:01.59rburtoni wonder if its not having libx11
14:02.28rburtonnope
14:02.55Crofton|workI should use my new found docker skills
14:03.34XorACrofton|work: you are cloudy now, let me sell you nothing :-D
14:03.46XorAbargain price nothing
14:04.07Crofton|workvery cloudy
14:11.27rburtonah
14:11.31rburtonwe can't autoreconf slang
14:11.37rburtonbecause idiots
14:16.30Crofton|workwhy only showed up now?
14:16.39Crofton|workdid you dupe issue?
14:16.41rburtonbecause we check if configure.ac exists before autoreconfing
14:16.54rburtonno, but i noticed that its failing in a test that we patch out of configure.ac
14:22.37Crofton|worksuggestions?
14:27.58rburtonPSA: slang is now on my special list
14:31.11Crofton|worklol
14:31.39*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
14:35.26*** join/#oe stephano (stephano@nat/intel/x-nktdkdmneuckkkvt)
14:42.19*** join/#oe stephano (~stephano@134.134.139.83)
14:46.20*** join/#oe morphis_ (~morphis@pD9ED7E03.dip0.t-ipconnect.de)
14:49.00ant_workkoen: what about OpenELEC, LibreELEC, lakka? I see you put a meta-kodi together
14:51.25rburtonCrofton|work: can you try the top patch on poky-contrib:ross/mut?  It breaks package_qa for me now, but i'm curious if that fixes the configure
14:52.13Crofton|workok in a few
14:56.41Crofton|workgrumbles about oe-core patches vs poky
14:57.15rburtonit will cherry-pick just fine :)
15:04.50koenant_work: librelec is "just enough OS to run kodi"
15:05.03koenant_work: which means e.g. rsync isn't there
15:05.46koenant_work: I use angstrom+kodi when I can use open source drivers and libreelec when there's only vendor crap
15:09.59ant_workah, ok
15:10.55ant_workI see lakka has moved sources from libretro to librelec but lakka is just a wrapper
15:11.38ant_workI'm more interested in the libretro part than in the kodi (evil binary drivers)
15:12.06ant_workthey are 'porting' the distro sub-optimsally I think, machine by machine
15:12.55ant_workjust wondering if this can be done with OE...
15:19.07*** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com)
15:19.18*** join/#oe tasslehoff (~Tasslehof@77.40.182.98)
15:21.38*** join/#oe davis (~davis@50-76-27-166-static.hfc.comcastbusiness.net)
15:22.23davisi thought I had a working setup for my .bb file to conditionally specify variables, but it turns out its ignoring the lines.
15:22.51davisI've tried if [ "${SOMECONFVAR}" == "1" ]; then
15:23.12davisbut that only works inside a do_fun { routine }
15:23.39davisi saw some other code in a git repot which did something like this
15:23.52davis{{ if SOMECONFVAR == "1": }}
15:23.59davisbut that does not parse either
15:26.18rburtonCrofton|work: better version pushed
15:26.33rburtondavis: what are you actually trying to do
15:26.37Crofton|workstill updating new remote
15:26.42Crofton|workinterent is sluggish here :(
15:26.49rburtonCrofton|work: should have stayed in the EU
15:26.55Crofton|workyep
15:27.01Crofton|workshitty Murican Internet
15:27.41davisrburton: i'm trying to conditionally specify some variables based upon a conf/local.conf variable setting.
15:27.59davisif if FOO=A then GOO=X else GOO=Y
15:28.19daviswhere FOO is specified inn conf/local.conf
15:28.52davisthis guy does something similar but that syntax does not work
15:28.56davishttps://github.com/tiagovignatti/poky/blob/master/scripts/lib/bsp/substrate/target/arch/common/recipes-kernel/linux/%7B%7B%20if%20kernel_choice%20%3D%3D%20%22custom%22:%20%7D%7D%20linux-yocto-custom.bb
15:30.05rburtonthats because that file gets preprocessed by yocto-bsp
15:30.28rburtonand you want GOO to be a bitbake variable? or bash?
15:30.42davisGOO is a bitbake variable
15:34.18rburtonGOO="${@ some python }"
15:34.27rburtonie base.contains
15:34.54rburtonerm, bb.utils.contains even
15:35.00rburtonclasses/ptest.bbclass:PTEST_ENABLED = "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
15:35.30rburtonDISTRO_FEATURES is the variable to fetch, ptest is the value to compare with, then 1 if match otherwise 0
15:35.50davisok let me try that. many thanks
15:37.48*** join/#oe t0mmy (~tprrt@217.114.201.133)
15:38.02davisis the D specifying the variable is a decimal?
15:38.09daviserr d
15:38.12rburtonno, it's passing the datastore
15:38.32rburton${@ just drops you into python
15:38.38rburtond is a reference to the data store at that point
15:38.52davisSRCREV_FORMAT = "${@bb.utils.contains('BB_NO_NETWORK', '1', "v16_pcmx", "${AUTOREV}", d)}"
15:39.39davisif BB_NO_NETWORK is specified as 1, then set the SRCREV_FORMAT to be "v16_pcmx" otherwise set it to "${AUTOREV}"
15:39.42Crofton|workERROR: slang-2.3.1-r0 do_fetch: Fetcher failure for URL: 'file://dont-link-to-host.patch'. Unable to fetch URL from any source.
15:39.49rburtonCrofton|work: damnit
15:39.56Crofton|worklolz
15:40.06Crofton|workbetter me comaplinging then RP
15:40.17rburtonCrofton|work: even with git-ps i didn't notice i failed to add :)
15:40.19rburtonCrofton|work: re-fetch
15:40.28rburtonhuh
15:40.34rburtonno this patch is still broken
15:40.39rburtoncan we just remove slang?
15:40.46rburtonthe maintainer clearly doesn't want anyone to actually build it
15:42.39Crofton|workI saw it was in core and didn't try to see why I needed it :)
15:43.17Crofton|workdamn it, I pulle master
15:43.23Crofton|workwill take a while to test
15:45.05*** join/#oe Bunio_FH (~Bunio_FH@clj-165.netdrive.pl)
15:47.03*** join/#oe ash_charles (~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157)
15:47.27davisrburton: that seems to work. many thanks
15:49.00kergothdavis: you're misusing contains. contains is to check if an item is in a list. BB_NO_NETWORK is a single value, not a list. admittedly it works, since the expected value has no spaces, it's just unnecessary
15:49.05kergothminor complaint, admittedly
15:49.29*** join/#oe jku (~jku@dyj-skycrv18---3wlh9y-3.rev.dnainternet.fi)
15:49.50rburtonkergoth: probably half the users in oe-core are misusing it
15:50.31kergothwouldn't surprise me, though i don't see why
15:50.33rburton${d.getVar("BB_NO_NETWORK") == "1" and "v16_pcmx" or "${AUTOREV}"} is the non-abusing form
15:50.37kergothis it not obvious what 'contains" means?
15:50.48kergothactually there's no need to abuse boolean operations either
15:50.49davisok i'll change it to that.
15:50.52kergothpython supports inline if statements
15:50.55davismany thanks
15:50.56rburtonha
15:51.25kergoth${@'v16_pcmsx' if d.getVar('BB_NO_NETWORK') == '1' else '${AUTOREV}'}
15:51.28kergothfor example
15:52.19kergothwould be nicer yet to just to '${BB_NO_NETWORK}' == '1', but in thep ast bitbake has gotten extremely upset about that if the variable is unset
15:52.24kergoth:\
15:57.47*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
15:58.09*** join/#oe armpit (~akuster@2601:202:4001:9ea0:3c4a:f1ac:8237:eb56)
15:58.22kergoththinks back to when we used the inline indexing of a list with a boolean *shudder*
15:59.31rburtonyeah that was disgusting
16:07.36*** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com)
16:12.22Crofton|workrburton, that patch looks like it solves my problem
16:15.58*** join/#oe ash_charles (~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157)
16:16.23*** join/#oe ftonello (~felipe@host81-152-92-225.range81-152.btcentralplus.com)
16:19.17*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
16:19.21*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
16:24.41*** join/#oe anselmolsm (~anselmols@192.55.54.44)
16:26.19daviskergoth: rburton finally implemented all those variable settings and it has a parse error.  Here is what i'm trying and the result
16:26.23davishttps://gist.github.com/netskink/dbfb72cbb507b8463666c14c8ca6fb20
16:27.57rburtondavis: you didn't put quotes around the values
16:28.36davisSRCREV_FORMAT = "${@'v16_pcmx' if d.getVar('BB_NO_NETWORK') == '1' else '${AUTOREV}'}"
16:28.39davis?
16:28.44rburtonyes
16:28.51davisexcellent. many thanks
16:28.56rburton${@…} is just a special form of ${FOO}
16:29.57davishmm. with all those changes  it gives a exception during parse
16:30.30davisit seems to work for first two. maybe i have a typo with v16
16:35.08*** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029)
16:36.46kergothdavis: i'd really suggest just leveraging buildhistory-collect-srcrevs to explicitly lock down autorevs as needed rather than doing so dynamically, re: support of BB_NO_NETWORK, btw
16:37.21davisi dont know how to do that. i'm barely able to do it this way.
16:37.43davisany pointers that way is appreciated. i can switch approaches
16:43.38davisi give. i saved the lines with a comment, but I just put it back to the misuse of the array/list variant which worked.
16:44.43kergothfair enough
16:45.07kergothbuildhistory-collect-srcrevs is just a standalone script that when run, dumps SRCREV_pn- lines for each recipe using AUTOREV, with specific commit hashes instead
16:45.16kergothso you can write it to a .conf and include that from local.conf or a distro or whatever
16:45.44kergothi.e. can use it as part of a release process to lock down autorevs so customers can build without network, assuming you also ship sources, as one example
16:48.31davisthat would be better
16:48.42davisi would not have to go in and hand edit all the checksums
16:49.07davislet me save this off for future ref and I'll try to convert it later.
16:55.21*** join/#oe lumag (~lumag@93.185.26.131)
17:03.41kergothnods
17:35.36*** join/#oe eFfeM (~frans@dhcp-089-099-139-063.chello.nl)
17:40.34*** join/#oe dv_ (~quassel@62-178-118-86.cable.dynamic.surfer.at)
17:41.55*** join/#oe armpit (~akuster@2601:202:4001:9ea0:3c4a:f1ac:8237:eb56)
17:44.11*** join/#oe stefan_schmidt (~stefan@p20030048093A72833252CBFFFE54190F.dip0.t-ipconnect.de)
17:47.23*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
17:55.01Crofton|work<PROTECTED>
17:55.01Crofton|workException: FileExistsError: [Errno 17] File exists: '/home/balister/src/oe-core/build/tmp-glibc/sysroots-components/armv7ahf-neon/glibc-initial/usr/lib/crtn.o' -> '/home/balister/src/oe-core/build/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/glibc-locale/2.25-r0/recipe-sysroot/usr/lib/crtn.o'
18:56.05*** join/#oe AndersD (~anders@h83-209-191-235.cust.se.alltele.net)
19:22.29*** join/#oe jku (~jku@dyj-skycrv18---3wlh9y-3.rev.dnainternet.fi)
19:27.17bluelightningCrofton|work: did you interrupt the build previously?
19:27.24Crofton|workmaybe
19:27.32Crofton|workI nuked tmp and rebuilt from sstate
19:27.40Crofton|workseems to have recovered
19:28.06bluelightningit's probably https://bugzilla.yoctoproject.org/show_bug.cgi?id=11001
19:28.46Crofton|workI'd been having build fails due to the slang thing rburton just seems to have fixed
19:28.49bluelightningthat would fix it, but it should be fairly easy to fix properly once we decide on the right course of action
19:49.12*** join/#oe Bunio_FH (~Bunio_FH@clj-165.netdrive.pl)
20:06.45*** join/#oe marka (~masselst@128.224.252.2)
20:15.51*** join/#oe ash_charles (~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc)
20:29.51*** join/#oe ant_home (~ant__@host13-229-dynamic.20-79-r.retail.telecomitalia.it)
20:35.49*** join/#oe ant_home (~ant__@host13-229-dynamic.20-79-r.retail.telecomitalia.it)
20:43.23Crofton|work| Copying files into the device: __populate_fs: Could not allocate block in ext2 filesystem while writing file "lto1"
20:43.23Crofton|work| mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system
20:43.32Crofton|workany hints, might have something to do with meta-mender
20:50.01fraysounds like too many files for the number of inodes allocatd
20:50.42Crofton|workhmm
20:51.26Crofton|workyou think the error message would just say that :)
20:52.13rburtonhave you not used linux before?
20:53.05Crofton|worklol
20:53.09Crofton|workfair enough
20:53.41Crofton|workfuck it, I should quit working and go live in a mud hut on beach
20:54.17fraythe fun part... if you are using an ACTUAL disk.. the error is it's full, even though it's not 'full', just out of inodes..
20:54.18bluelightningyou could patch e2fsprogs... if you're lucky in a couple of years the patch might actually make it into a release
20:54.23fraybut the error in the e2fsprogs is odd
20:54.29fray(assumign that is what happened)
20:54.51frayactually e2fsprogs (last time we patched it) was updated pretty quickly.. :)  (surprisingly so)
20:55.07Crofton|workmight be fall out from meta-mender also
20:55.45bluelightningfray: I thought robert's patches sat in their master for a while, have they finally made it into an official release?
20:56.10fraymaybe I'm remembering wrong.. I thought they'd been merged pretty quick and a release within 6 months
20:56.28Crofton|workalt memories
20:56.47frayfake memories.. kind of like fake news
20:56.59frayI'm not about to claim my memory is correct.. :)
20:58.17bluelightningI can't say I was too close to it, so I could be wrong
20:59.29fray(and I don't think either of us cares either way)  :)
20:59.36fraywell not enough to investigate at least.. ;)
21:00.12ant_homerofl
21:00.41*** part/#oe davis (~davis@50-76-27-166-static.hfc.comcastbusiness.net)
21:01.28ant_homeCrofton|work: bad memory bank, mee too...bitrot
21:02.20ant_homemust have been the UV's
21:02.26bluelightningyeah, I'm not too worried :)
21:02.56bluelightningmy memory has always been bad... lack of sleep probably doesn't improve things though
21:04.14ant_homeit's nice how you can fill it: eg. when your wife asks about her vest on wedding 20 yrs ago
21:06.13ant_home's builds seems surviving to RSS reworks
21:08.00ant_homedoh...most -natives are recompiling since yesterdayìs build
21:09.39ant_homebtw the vest was white ;)
21:25.14*** join/#oe Varti (~varthall@dynamic-adsl-78-12-167-18.clienti.tiscali.it)
21:38.06*** join/#oe armpit (~akuster@50-233-148-156-static.hfc.comcastbusiness.net)
21:41.32*** join/#oe marka (~masselst@135-23-92-83.cpe.pppoe.ca)
21:57.59*** join/#oe ao2 (~ao2@2001:1418:100:22::2)
23:23.42*** join/#oe clopez (~tau@neutrino.es)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.