**** BEGIN LOGGING AT Tue Feb 07 03:00:01 2017 Feb 07 05:06:20 is morty supposed to have old DEPLOY_DIR_IMAGE variable or the new one? Feb 07 05:55:14 new one Feb 07 08:28:48 JaMa, hi. Last RSS changes have fixed meta-initramfs issues. I've built it for mips last night. Feb 07 09:25:40 ant_work: good Feb 07 09:25:49 1 down, 100 to go Feb 07 09:28:11 Probably more recipes do build correctly today Feb 07 09:31:52 neverthless I have the feeling that even if building now these recipes are fragile wrt sysroot tricks and could be improved Feb 07 11:53:50 ant_work: doesn't look any better, the builds are still running but qemuarm finished with 103 failures again Feb 07 11:54:53 urg Feb 07 11:54:57 home again Feb 07 11:58:07 argh Feb 07 13:13:23 Crofton|work: welcome back Feb 07 13:13:39 thanks Feb 07 13:50:10 Crofton|work: can you still replicate the slang problem you were having? Feb 07 13:50:24 give me a minute Feb 07 13:50:36 just updated some stuff and rebuilding things Feb 07 13:50:50 cool Feb 07 13:50:59 just noticed the bug and couldn't remember if we got anywhere with it Feb 07 13:53:56 yeah Feb 07 13:54:01 only imapcts me apparently Feb 07 13:55:39 ERROR: 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. Feb 07 13:55:40 Rerun configure task after fixing this. Feb 07 13:55:45 jsut hit it Feb 07 13:56:28 ok Feb 07 13:56:37 with current master? Feb 07 13:58:40 Crofton|work: you have X headers on your build host? Feb 07 13:58:49 it is liekly Feb 07 13:59:01 hm i do too Feb 07 14:01:59 i wonder if its not having libx11 Feb 07 14:02:28 nope Feb 07 14:02:55 I should use my new found docker skills Feb 07 14:03:34 Crofton|work: you are cloudy now, let me sell you nothing :-D Feb 07 14:03:46 bargain price nothing Feb 07 14:04:07 very cloudy Feb 07 14:11:27 ah Feb 07 14:11:31 we can't autoreconf slang Feb 07 14:11:37 because idiots Feb 07 14:16:30 why only showed up now? Feb 07 14:16:39 did you dupe issue? Feb 07 14:16:42 because we check if configure.ac exists before autoreconfing Feb 07 14:16:54 no, but i noticed that its failing in a test that we patch out of configure.ac Feb 07 14:22:37 suggestions? Feb 07 14:27:58 PSA: slang is now on my special list Feb 07 14:31:11 lol Feb 07 14:49:00 koen: what about OpenELEC, LibreELEC, lakka? I see you put a meta-kodi together Feb 07 14:51:25 Crofton|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 Feb 07 14:52:13 ok in a few Feb 07 14:56:41 * Crofton|work grumbles about oe-core patches vs poky Feb 07 14:57:15 it will cherry-pick just fine :) Feb 07 15:04:50 ant_work: librelec is "just enough OS to run kodi" Feb 07 15:05:03 ant_work: which means e.g. rsync isn't there Feb 07 15:05:46 ant_work: I use angstrom+kodi when I can use open source drivers and libreelec when there's only vendor crap Feb 07 15:09:59 ah, ok Feb 07 15:10:55 I see lakka has moved sources from libretro to librelec but lakka is just a wrapper Feb 07 15:11:38 I'm more interested in the libretro part than in the kodi (evil binary drivers) Feb 07 15:12:06 they are 'porting' the distro sub-optimsally I think, machine by machine Feb 07 15:12:55 just wondering if this can be done with OE... Feb 07 15:22:23 i thought I had a working setup for my .bb file to conditionally specify variables, but it turns out its ignoring the lines. Feb 07 15:22:51 I've tried if [ "${SOMECONFVAR}" == "1" ]; then Feb 07 15:23:12 but that only works inside a do_fun { routine } Feb 07 15:23:39 i saw some other code in a git repot which did something like this Feb 07 15:23:52 {{ if SOMECONFVAR == "1": }} Feb 07 15:23:59 but that does not parse either Feb 07 15:26:18 Crofton|work: better version pushed Feb 07 15:26:33 davis: what are you actually trying to do Feb 07 15:26:37 still updating new remote Feb 07 15:26:42 interent is sluggish here :( Feb 07 15:26:49 Crofton|work: should have stayed in the EU Feb 07 15:26:55 yep Feb 07 15:27:01 shitty Murican Internet Feb 07 15:27:41 rburton: i'm trying to conditionally specify some variables based upon a conf/local.conf variable setting. Feb 07 15:27:59 if if FOO=A then GOO=X else GOO=Y Feb 07 15:28:19 where FOO is specified inn conf/local.conf Feb 07 15:28:52 this guy does something similar but that syntax does not work Feb 07 15:28:56 https://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 Feb 07 15:30:06 thats because that file gets preprocessed by yocto-bsp Feb 07 15:30:28 and you want GOO to be a bitbake variable? or bash? Feb 07 15:30:42 GOO is a bitbake variable Feb 07 15:34:18 GOO="${@ some python }" Feb 07 15:34:27 ie base.contains Feb 07 15:34:54 erm, bb.utils.contains even Feb 07 15:35:00 classes/ptest.bbclass:PTEST_ENABLED = "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}" Feb 07 15:35:30 DISTRO_FEATURES is the variable to fetch, ptest is the value to compare with, then 1 if match otherwise 0 Feb 07 15:35:50 ok let me try that. many thanks Feb 07 15:38:03 is the D specifying the variable is a decimal? Feb 07 15:38:09 err d Feb 07 15:38:12 no, it's passing the datastore Feb 07 15:38:33 ${@ just drops you into python Feb 07 15:38:38 d is a reference to the data store at that point Feb 07 15:38:52 SRCREV_FORMAT = "${@bb.utils.contains('BB_NO_NETWORK', '1', "v16_pcmx", "${AUTOREV}", d)}" Feb 07 15:39:39 if BB_NO_NETWORK is specified as 1, then set the SRCREV_FORMAT to be "v16_pcmx" otherwise set it to "${AUTOREV}" Feb 07 15:39:42 ERROR: slang-2.3.1-r0 do_fetch: Fetcher failure for URL: 'file://dont-link-to-host.patch'. Unable to fetch URL from any source. Feb 07 15:39:49 Crofton|work: damnit Feb 07 15:39:57 lolz Feb 07 15:40:06 better me comaplinging then RP Feb 07 15:40:17 Crofton|work: even with git-ps i didn't notice i failed to add :) Feb 07 15:40:19 Crofton|work: re-fetch Feb 07 15:40:28 huh Feb 07 15:40:34 no this patch is still broken Feb 07 15:40:39 can we just remove slang? Feb 07 15:40:46 the maintainer clearly doesn't want anyone to actually build it Feb 07 15:42:39 I saw it was in core and didn't try to see why I needed it :) Feb 07 15:43:17 damn it, I pulle master Feb 07 15:43:23 will take a while to test Feb 07 15:47:27 rburton: that seems to work. many thanks Feb 07 15:49:00 davis: 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 Feb 07 15:49:05 minor complaint, admittedly Feb 07 15:49:50 kergoth: probably half the users in oe-core are misusing it Feb 07 15:50:31 wouldn't surprise me, though i don't see why Feb 07 15:50:33 ${d.getVar("BB_NO_NETWORK") == "1" and "v16_pcmx" or "${AUTOREV}"} is the non-abusing form Feb 07 15:50:37 is it not obvious what 'contains" means? Feb 07 15:50:48 actually there's no need to abuse boolean operations either Feb 07 15:50:49 ok i'll change it to that. Feb 07 15:50:52 python supports inline if statements Feb 07 15:50:55 many thanks Feb 07 15:50:56 ha Feb 07 15:51:26 ${@'v16_pcmsx' if d.getVar('BB_NO_NETWORK') == '1' else '${AUTOREV}'} Feb 07 15:51:28 for example Feb 07 15:52:19 would 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 Feb 07 15:52:24 :\ Feb 07 15:58:22 * kergoth thinks back to when we used the inline indexing of a list with a boolean *shudder* Feb 07 15:59:31 yeah that was disgusting Feb 07 16:12:22 rburton, that patch looks like it solves my problem Feb 07 16:26:19 kergoth: rburton finally implemented all those variable settings and it has a parse error. Here is what i'm trying and the result Feb 07 16:26:23 https://gist.github.com/netskink/dbfb72cbb507b8463666c14c8ca6fb20 Feb 07 16:27:57 davis: you didn't put quotes around the values Feb 07 16:28:36 SRCREV_FORMAT = "${@'v16_pcmx' if d.getVar('BB_NO_NETWORK') == '1' else '${AUTOREV}'}" Feb 07 16:28:39 ? Feb 07 16:28:44 yes Feb 07 16:28:51 excellent. many thanks Feb 07 16:28:56 ${@…} is just a special form of ${FOO} Feb 07 16:29:57 hmm. with all those changes it gives a exception during parse Feb 07 16:30:30 it seems to work for first two. maybe i have a typo with v16 Feb 07 16:36:46 davis: 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 Feb 07 16:37:21 i dont know how to do that. i'm barely able to do it this way. Feb 07 16:37:43 any pointers that way is appreciated. i can switch approaches Feb 07 16:43:38 i give. i saved the lines with a comment, but I just put it back to the misuse of the array/list variant which worked. Feb 07 16:44:43 fair enough Feb 07 16:45:07 buildhistory-collect-srcrevs is just a standalone script that when run, dumps SRCREV_pn- lines for each recipe using AUTOREV, with specific commit hashes instead Feb 07 16:45:17 so you can write it to a .conf and include that from local.conf or a distro or whatever Feb 07 16:45:44 i.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 Feb 07 16:48:31 that would be better Feb 07 16:48:42 i would not have to go in and hand edit all the checksums Feb 07 16:49:07 let me save this off for future ref and I'll try to convert it later. Feb 07 17:03:41 * kergoth nods Feb 07 17:55:01 0273: else: Feb 07 17:55:01 Exception: 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' Feb 07 19:27:17 Crofton|work: did you interrupt the build previously? Feb 07 19:27:24 maybe Feb 07 19:27:32 I nuked tmp and rebuilt from sstate Feb 07 19:27:40 seems to have recovered Feb 07 19:28:06 it's probably https://bugzilla.yoctoproject.org/show_bug.cgi?id=11001 Feb 07 19:28:46 I'd been having build fails due to the slang thing rburton just seems to have fixed Feb 07 19:28:49 that would fix it, but it should be fairly easy to fix properly once we decide on the right course of action Feb 07 20:43:23 | Copying files into the device: __populate_fs: Could not allocate block in ext2 filesystem while writing file "lto1" Feb 07 20:43:23 | mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system Feb 07 20:43:32 any hints, might have something to do with meta-mender Feb 07 20:50:01 sounds like too many files for the number of inodes allocatd Feb 07 20:50:42 hmm Feb 07 20:51:26 you think the error message would just say that :) Feb 07 20:52:13 have you not used linux before? Feb 07 20:53:05 lol Feb 07 20:53:09 fair enough Feb 07 20:53:41 fuck it, I should quit working and go live in a mud hut on beach Feb 07 20:54:17 the 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.. Feb 07 20:54:18 you could patch e2fsprogs... if you're lucky in a couple of years the patch might actually make it into a release Feb 07 20:54:23 but the error in the e2fsprogs is odd Feb 07 20:54:29 (assumign that is what happened) Feb 07 20:54:52 actually e2fsprogs (last time we patched it) was updated pretty quickly.. :) (surprisingly so) Feb 07 20:55:07 might be fall out from meta-mender also Feb 07 20:55:46 fray: I thought robert's patches sat in their master for a while, have they finally made it into an official release? Feb 07 20:56:10 maybe I'm remembering wrong.. I thought they'd been merged pretty quick and a release within 6 months Feb 07 20:56:28 alt memories Feb 07 20:56:47 fake memories.. kind of like fake news Feb 07 20:56:59 I'm not about to claim my memory is correct.. :) Feb 07 20:58:17 I can't say I was too close to it, so I could be wrong Feb 07 20:59:29 (and I don't think either of us cares either way) :) Feb 07 20:59:36 well not enough to investigate at least.. ;) Feb 07 21:00:12 rofl Feb 07 21:01:28 Crofton|work: bad memory bank, mee too...bitrot Feb 07 21:02:20 must have been the UV's Feb 07 21:02:26 yeah, I'm not too worried :) Feb 07 21:02:56 my memory has always been bad... lack of sleep probably doesn't improve things though Feb 07 21:04:14 it's nice how you can fill it: eg. when your wife asks about her vest on wedding 20 yrs ago Feb 07 21:06:13 * ant_home 's builds seems surviving to RSS reworks Feb 07 21:08:00 doh...most -natives are recompiling since yesterdayìs build Feb 07 21:09:39 btw the vest was white ;) **** ENDING LOGGING AT Wed Feb 08 03:00:02 2017