**** BEGIN LOGGING AT Mon Feb 27 03:00:01 2017 Feb 27 07:09:03 Hi guys! Feb 27 07:09:08 Anybody awake? Feb 27 07:12:53 I have a class where I set in a python function (anonymous) a specific variable. This is used. In the image type generation function. For whatever reason, from 0a4e1f968ada5099e3270ed06404d2827e9729aa, this function doesn't set the variable anymore. Feb 27 07:13:02 https://github.com/resin-os/resin-raspberrypi/blob/master/layers/meta-resin-raspberrypi/recipes-core/images/resin-image.bbappend#L16 Feb 27 07:13:07 This is the code. The variable is RESIN_BOOT_PARTITION_FILES. Feb 27 07:38:51 Good Morning all ^^ Feb 27 07:39:11 Was wondering if anyone knows a fix for this error: sudo: no tty present and no askpass program specified Feb 27 07:39:42 Maka_: and in what context would one see that error? Feb 27 07:40:16 It's trying to run some lines from a makefile, which uses the sudo command. For every sudo command it gives that error Feb 27 07:41:01 Maka_: then the Makefile is broken and needs fixing. Feb 27 07:41:33 Well its not broken, but its probably not perfectly optimized for Yocto then Feb 27 07:41:40 Maka_: nope, it is broken. Feb 27 07:41:57 it works on ubuntu, so its not exactly broken right? Feb 27 07:42:07 Maka_: a Makefile under no circumstances has to decide under which right it gets executed. Feb 27 07:42:40 Maka_: nope, your interpretation is incorrect. it means that it is broken, but somebody tinkered it long enough that it *almost* works on ubuntu Feb 27 07:43:01 Hmm alright then Feb 27 07:43:04 Maka_: tell me, why exactly should a Makefile require sudo? Feb 27 07:43:25 Well, it executes command that would normally require sudo Feb 27 07:44:09 Maka_: nope. it tries to get around some limitations by the rights system. that alone tells me it assumes that it knows/thinks it will do something that needs system privilege. Feb 27 07:45:12 Maka_: and there is exactly *one* operation that a Makefile might need system privileges for: installation. and even there, it is not exactly mandatory. i can easily decide to prefix the installation by my home, therefore do a user install Feb 27 07:45:46 The problem is, once i remove the sudo's it wont work at all Feb 27 07:45:54 So i'll have to find some other way then Feb 27 07:45:57 Maka_: so if the Makefile thinks it needs system privileges and tries to acquire it automatically, then it is broken by definition. Feb 27 07:46:25 Hmm, alright then, thanks ^^ Feb 27 07:47:21 Maka_: maybe look at what it tries to do? if it tries to "streamline" the installation by that sudo, then just throw it out, and have the user explicitly execute it as privileged Feb 27 07:47:34 if it does something else, it is very, very fishy Feb 27 07:48:20 What it does, is unpack a tar, and try to do a make, depmod, mv, ln, mkdir, cp and sed Feb 27 07:48:28 *sigh* Feb 27 07:49:18 then look at the steps, find out which are system cricital, provide a make target for them that then is explicitly documented to use system privilege Feb 27 07:50:03 Could i provide these steps in my recipe? Feb 27 07:50:05 but a Makefile that requires sudo sounds like it has been written by somebody who thinks that all the linux world behaves just like his ubuntu desktop. (which is not exactly true) Feb 27 07:50:17 of course you can Feb 27 07:51:13 Hmm, the thing is, i have yet to find a good tutorial/example how to write these recipes, especially the do_xxxx functions Feb 27 07:51:24 You send me some links before Feb 27 07:51:28 its just that a makefile who shows such assumptions is prone to be broken in other ways too. e.g. not repecting paths, prefixes, architectures, etc. Feb 27 07:52:07 Maka_: the complete how-to-write-your-own-recipe is at http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Feb 27 07:52:43 Yea i've seen it multiple times, and sadly still don't get it ._. Feb 27 07:53:08 and always remember to look up comparable recipes, preferred from oe-core as they are probably the best maintained. Feb 27 07:53:22 Yea i've been doing that ^^ Feb 27 07:53:42 I'll just keep trying some more stuff for now Feb 27 08:51:59 good morning Feb 27 08:52:34 Morning ^^ Feb 27 09:56:11 We are building three rootfs for three different MACHINES (same tune) by running the same bitbake target three times. Now I want to bundle them into a common image for distribution. Now should I implement this outside bitbake, or can I run three different MACHINE builds from bitbake (Jethro)? Feb 27 10:00:55 Hello All, I am trying to compile the Mariadb 10.1.21 using the cross-compile in Yocto. During the compilation of the mariadb its failed with the error says "make[2]: *** No rule to make target sql/gen_lex_hash', needed by 'sql/lex_hash.h'. Stop." The manual compilation just worked fine but cross-compile doesn't. I am using Fedora-24 as my host system. Any hint or a quick help will be very helpful. Feb 27 10:07:01 RobbinParrish_: I know nothing about mariadb, so be warned... gen_lex_hash is a binary that needs to be run at build time (and oviously using a target version on your fedora doesn't work so the build system doesn't even try to build it when cross compiling). Feb 27 10:09:19 RobbinParrish_: if there's no way around this build tool requirement, you'll probably have to make a native recipe that provides gen_lex_hash, and make mariadb depend on that Feb 27 10:11:23 RobbinParrish_: ... now that I look in meta-oe, this is exactly what the mariadb 5.5.52 recipes do: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/mysql Feb 27 10:17:17 jku: Thank you very much for the quick reply. I really appreciate it. Yes thats right. FYI I have created two recipes one is mariadb-native and other is mariadb only. The mariadb-native depends on the mariadb recipe. FYI the mariadb-native works fine it get compiled, installed and sysroot task also completed successfully. However during the do_compile of the Mariadb recipe I am getting the above error. Feb 27 10:18:36 jku: Yes thats correct, FYI I have created this recipes thats based on the "mariadb 5.5.52 recipes" from meta-oe but I have made some changes in prior to make it work for me. Feb 27 11:19:45 RP: Has the name of the successor to Pyro been announced yet? Feb 27 11:22:54 Saur: not yet, I need to decide and do that Feb 27 11:38:20 joshuagl: have you made the AB changes that wic needs? Feb 27 11:39:09 RobbinParrish_: oh then it might just be you need to patch out the DEPENDS line from the CMakelists.txt Feb 27 11:39:11 rburton: not deployed yet Feb 27 11:40:54 ok Feb 27 11:51:27 rburton: take it you've seen the same failures in a recent build? Feb 27 11:52:09 * joshuagl had a vague recollection from a past discussion that we wouldn't need to change the AB for wic Feb 27 11:52:58 joshuagl: wic patches on the list break with current AB Feb 27 11:53:04 something about required dependencies Feb 27 11:53:23 it should be building wic-tools instead of the bits individually, or something Feb 27 11:53:34 i suspect we need to do a layer version compare to know what to build though... Feb 27 11:53:42 (speak to ed2) Feb 27 11:53:43 rburton: right, but I thought wic-tools had been required for a while because of rss Feb 27 11:54:00 yeah, the change I have queued checks layer version Feb 27 11:56:04 rburton: which patches? Last time i saw the failure it was caused by AB. Feb 27 11:56:19 yeah exactly Feb 27 11:56:35 your patches were breaking because the ab wasnt doing the right thing Feb 27 11:59:15 jku: sorry but honestly I didnt understand what that mean to patchout in the CMakelists.txt? Feb 27 12:01:31 RobbinParrish_: the ADD_CUSTOM_COMMAND portion that builds lex_hash.h has the line "DEPENDS gen_lex_hash": it probably should not in cross compile case Feb 27 12:02:00 this is in mariadb sql/CMakeLists.txt Feb 27 12:06:23 jku: Yes thats true its being added as dependecies. Thanks, got it let me try to create a patch to validate it. Feb 27 12:18:44 BORED waiting for new linux-yocto to download Feb 27 12:18:52 zeddii: please can we have shallow clones :) Feb 27 12:29:26 Everytime i set my PACKAGE_CLASSES to package_deb it gives me: Debian package install does not support BAD_RECOMMENDATIONS Feb 27 12:29:30 Anyone knows why Feb 27 12:29:33 ?* Feb 27 12:33:35 maka__: maybe because the deb package format does not support bad recommendations? sounds like its a rpm specific thing. so something you use is in turn trying to do something rpm specific Feb 27 12:33:38 maka__: because package_deb does not support BAD_RECOMMENDATIONS and you're building something which needs it Feb 27 12:33:47 opkg supports it too Feb 27 12:33:57 rburton: ah interesting Feb 27 12:33:59 really, package_deb is the worst choice. opkg and rpm are better supported. Feb 27 12:34:34 So if i add opkg its fine or..? Feb 27 12:34:59 you'd need to change PACKAGE_CLASSES Feb 27 12:35:12 package_deb isn't the default so you must have changed it in the first place Feb 27 12:35:42 Correct Feb 27 12:36:27 Since im trying something with .deb files, and everywere i read i should use package_deb then Feb 27 12:36:43 But it seems it doesn't work Feb 27 12:37:42 maka__: you are messing up things (again). just because a lot of the software you try to install comes as deb (which is bad enough), it does not mean that using deb as your package format is a godd choice when dealing with OW Feb 27 12:38:30 It seems i'm always messing things up haha Feb 27 12:38:57 maka__: if you really want or need to stick with those obscure packages, generating your own distro won't work anyways. run debian or ubuntu, then. Feb 27 12:42:41 Sadly i have to stick to these packages yea, and also to yocto, so yea Feb 27 12:45:37 sticking to the packages is easy enough - just unpack the deb and get the contents out Feb 27 12:46:05 as said, that's unrelated to your package manager choice. i'd recommend rpm if you intend to do on-target upgrades in the field, otherwise opkg as its simplier. Feb 27 12:58:23 rburton: and what do i do with the unpacked deb? Feb 27 12:58:58 maka__: get the contents out and install them to get it repackaged Feb 27 12:59:44 How do you mean that exactly? sorry if i seem like an idiot.. Feb 27 13:01:12 you need a native dpkg, and use that to unpack. then repack through a manually carved do_install function Feb 27 13:01:25 do_unpack will partially open up a deb anyway Feb 27 13:01:36 unpack the rest and mkdir/install in your do_install() Feb 27 13:03:26 Alrright, thanks ^^ Feb 27 13:04:29 and while you're at it, have a thorough look at the dependencies, arch, etc. too. otherwise you will have them repackages, but the binaries won't work. Feb 27 13:05:30 Alright, will do Feb 27 13:22:39 Hi all! i have a question but i dont know if here is the right place to ask for Feb 27 13:22:56 im working with yocto and i need to run a custom distro on my rpi3 Feb 27 13:23:11 i have no problem with this Feb 27 13:23:22 my problem is that i cant decompress the extended attributes and then make the rpi boot Feb 27 13:23:33 it gets stuck at Uboot terminal Feb 27 13:23:45 you know any tutorial or something to solve this problem? Feb 27 13:23:56 many thanks Feb 27 13:46:37 maybe adding this lines to local.conf? IMAGE_CMD_TAR = "tar --xattrs-include='*'" IMAGE_DEPENDS_tar_append = " tar-replacement-native" EXTRANATIVEPATH += "tar-native" Feb 27 13:51:41 mrpelotazo: Which archive file is the right one to load it to the root partition ? Feb 27 13:55:00 jobro: .ext4 Feb 27 13:55:18 using dd if=.ext4 of=partition Feb 27 14:18:16 jku: ready for another mission? the useradd/pseudo thing is driving me insane. there's a path in useradd postinst which points into the recipe sysroot. Feb 27 14:18:23 (PSEUDO_PASSWD) Feb 27 14:24:23 rburton: I'm missing a bit of context Feb 27 14:25:50 huh thought i'd filed a bug Feb 27 14:27:30 jku: the useradd class generates postinsts to make the users. the bit of it that runs at image rootfs time tells pseudo to use a passwd file in the sysroot, but as we don't have "the" sysroot now it points at the recipe's sysroot. not only may this not exist at rootfs time, but it changes every time the recipe version changes. Feb 27 14:27:38 i suspect we just need to delete or rethink this code Feb 27 14:27:49 if maxin is around, he has a bit of experience in that class Feb 27 14:27:53 right Feb 27 14:32:59 rburton: so what's the problem, as in what part here drives you insane ? Feb 27 14:36:01 do we not actually get a real passwd file when rootfs is generated? Feb 27 14:37:51 jku: drives me insane becuase i get a page-long chunk in buildhistory-diff :) Feb 27 14:38:06 but its also just not working because the recipe sysroot may not be there anymore Feb 27 14:39:23 oh yeah if it points not to the image sysroot but the "package" sysroot Feb 27 14:41:00 I don't get it, why not run user/group management commands against the image rootfs? Feb 27 14:42:18 it used to point to the global rootfs but the assumptions there are all invalid now Feb 27 14:43:32 I mean, postinsts are all executed at image rootfs time, and with a bit of effort you can point the native commands you want to run to execute against that Feb 27 14:46:37 kanavin: it's just that the actual recipe that wants a new user sets PSEUDO_PASSWD to a bogus value. maxin promised to handle at least that bit Feb 27 14:48:12 jku: I still don't see why useradd.bbclass needs to be so complicated Feb 27 14:48:25 I need to try out the per recipe sysroot stuff with all of my internal layers, loads of stuff is bound to break. Feb 27 14:48:38 georgem: going by how badly meta-oe broke, yes :) Feb 27 14:48:41 kanavin it probably does not Feb 27 14:48:50 rburton: hehe Feb 27 14:49:31 kanavin: it drives me nuts too but not sure I can think of a better way to handle it that accounts for all of the covered use cases. Feb 27 14:50:40 georgem: what are the use cases? Feb 27 14:50:52 For anyone doing image based upgrades and not allowing optional package installation at runtime I think they'd generally be better off just hand writing a passwd, group file. Feb 27 14:51:54 kanavin: one of the trickier ones is installing a package at runtime. the required users, groups for the package must be added into passwd, group. Feb 27 14:52:13 georgem: so you call useradd, what is the problem? Feb 27 14:53:24 kanavin: well, that's what it does Feb 27 14:53:54 it also has to worry about uid, gid collisions of course Feb 27 14:54:34 and then there is the provision for static uids, gids Feb 27 14:55:57 it really gets screwy when multiple packages require the same user, group Feb 27 14:57:57 won't useradd tell you when you try to add a uid or user that already exists? Feb 27 14:58:33 yeah Feb 27 14:59:35 then you treat that as an error, no? Feb 27 15:02:09 kanavin: it checks if the user already exists before trying to add it. and no it's not an error if it already exists. two packages can create the same user. Feb 27 15:04:13 georgem: so what gets screwy then? Feb 27 15:04:28 kanavin: Though if you remove one of those packages it might remove the user even though the other package still needs it. Can't remember. Feb 27 15:05:12 There have been changes to that in the last year and I have hard time keeping up with exactly how it works at any given time :) Feb 27 15:06:01 georgem: I'll take code that can be understood over code that handles all the use cases :) Feb 27 15:06:38 kanavin: yeah, I understand where you're coming from. and most people say this until it's a use case they care about :) Feb 27 15:07:02 georgem: then they should write their own code to handle it, and not force it into oe-core Feb 27 15:12:15 kanavin: at least until recently (I haven't tested with recipe specific sysroot yet) it worked relatively well (apart from some fringe usecases that you've stated you don't care about) so there wasn't really a need to simplify it. Feb 27 15:22:14 rburton: I saw your comment in bug for '\n' in DESCRIPTION for opkg. Isn't better to let know the user about the issue instead of silently replace '\n' for '.'? Feb 27 15:34:08 justanotherboy: not if opkg does what dpkg does and say to embed newlines, add a '.' on its own. Feb 27 15:36:11 rburton: OK, let me work on that then Feb 27 15:46:28 Hi, I'm currently having trouble to understand how sstates and setscenes actually works behind, anybody have an hint for where to search ? Feb 27 15:51:09 geoffrey_l: maybe meta/classes/sstate.bbclass? Feb 27 15:53:45 i'm trying to do_populate_sdk_ext but I'm getting an error due to core-image-minimal/1.0-r0/locked-sigs.inc not being created, is this file supposed to be created automaticaly or sth? Feb 27 15:55:53 I can generate it manually through `bitbake -S none core-image-minimal` but I'm guessing it's supposed to be done automatically during do_populate_sdk_ext Feb 27 15:56:03 mborzecki: i predict you've got rm_work enabled Feb 27 15:56:15 indeed, remove it? Feb 27 15:56:16 (discovered this on friday) Feb 27 15:56:17 yeah Feb 27 15:56:28 thx, checking :) Feb 27 15:56:45 i filed a bug, but thinking about it the likely default assignee is on paternity leave Feb 27 15:59:20 kanavin: Thanks. I still don't understand how it's linked to bitbake since sstate are present in bitbake code, but I will try to figure it with that. Feb 27 16:05:35 rburton: will you be able to do another full AB pass of the dnf branch later tonight? Feb 27 16:05:38 (not yet) Feb 27 16:05:52 regardless of results, I will ignore them for two weeks, promise :) Feb 27 16:06:08 but I almost have finished fixing everything that was reported in the previous run Feb 27 16:06:09 rburton: many thanks, populate_sdk_ext worked this time Feb 27 16:08:51 anyone apart from bluelightning understand eSDK generation? Feb 27 16:13:10 denix: is the best way to get the revisions / tags of meta-ti corresponding to a particular processor sdk version to just check the config file used by the oe-layertool-setup? I noticed the ti version tags don't correspond to processor sdk release versioning Feb 27 16:13:47 meh, need more coffee Feb 27 16:16:08 hmm still don't understand why *-native are not taken from sstate cache, identical revisions of layers, identical config, both using poky (uninative?), still most (all) of *-native packages are getting rebuilt on the other host Feb 27 16:16:52 bitbake -S printdiff is your friend Feb 27 16:25:36 rburton: me, but I suspect that isn't the answer you were looking for :/ Feb 27 16:26:36 RP: i think i can blame the AB :O Feb 27 16:27:36 rburton: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/dnf-rpm4 is ready :) Feb 27 16:27:51 hopefully it's not worse than the previous time :D Feb 27 16:27:57 haha Feb 27 16:28:02 high hopes Feb 27 16:28:24 like I said, any result will be ignored for two weeks :) Feb 27 16:28:34 kergoth: thx, actually this is a bit unexpected, printdiff lists do_fetch of all packages :/ Feb 27 16:29:31 i guees that's why everything is getting rebuilt Feb 27 16:29:33 * kanavin ---> tea time Feb 27 16:39:30 hmm something fishy, it's trying to fetch files from my SSTATE_MIRROR[S] but i'm seeing this: Feb 27 16:39:42 DEBUG: For url file://63/sstate:acl:arm1176jzfshf-vfp-poky-linux-gnueabi:2.2.52:r0:arm1176jzfshf-vfp:3:63308c495378a3449a106ab9bced49ac_packagedata.tgz returning http://1 Feb 27 16:39:44 72.27.0.30:9009/sstate-cache/63/sstate%3Aacl%3Aarm1176jzfshf-vfp-poky-linux-gnueabi%3A2.2.52%3Ar0%3Aarm1176jzfshf-vfp%3A3%3A63308c495378a3449a106ab9bced49ac_packagedata.t Feb 27 16:39:46 gz Feb 27 16:39:48 DEBUG: checkstatus() urlopen failed: Feb 27 16:42:12 obvioulsy works with wget Feb 27 16:55:36 in case anyone is wondering, serving sstate cache via python3 -m http.server is a really bad idea Feb 27 16:58:40 rburton: there ? Feb 27 16:59:02 rburton: your go-cross error is new to me but I see it has been seen before in go world Feb 27 16:59:17 rburton: whats the best way to reproduce it I wonder Feb 27 16:59:32 I have arch/ubuntu14.04/centos7 boxes and did not see it Feb 27 17:02:39 khem: iirc we might have seen something similar in mender, let me take a look Feb 27 17:03:40 khem: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131659.html Feb 27 17:03:41 mborzecki: ok, Feb 27 17:03:58 mborzecki: how did you solve it Feb 27 17:04:33 other places they seem to have it fixed with another box install so it seems its related to box/os Feb 27 17:04:40 but there must be a root cause for it Feb 27 17:05:48 khem: https://github.com/mem/oe-meta-go/commit/fc6d8ac2951aa4548c2e1c67d1f3437eb2a8981f Feb 27 17:06:07 umm i deleted my initramfs files and bitbake now is giving me an error Feb 27 17:06:12 what should i do Feb 27 17:07:18 khem: quite postive this is the patch :) there's an accompanying change in poky as well: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2313a77d8474c742e1cd8cee246f6c05847dd3c6 Feb 27 17:07:28 the ones located in tmp/deploy/images/intel-corei7-64/ Feb 27 17:24:07 Hello hello. I see a lot of references to Dizzy as a stable branch. Is there a more recent stable branch? Feb 27 17:24:08 mborzecki: ok, let me see Feb 27 17:24:19 kergoth: yes, processor sdk releases do correspond to meta-ti/meta-arago tags and you can double-check which tags were used in config files of oe-layersetup Feb 27 17:27:58 denix: okay, thanks, appreciated. is there a timeline as to when the release will happen which includes the 4.9 kernel, by chance? Feb 27 17:38:06 kergoth: I'm cutting rc2 tag later today. will be rc3 and rc4 each week and the final tag will be in about 3 weeks. that's 2017.00, which is a baseline on morty and 4.9 kernel. official releases will follow after that, as it will take them time for collateral and documentation... Feb 27 17:38:15 * kergoth nods Feb 27 17:38:18 okay, thanks Feb 27 17:40:11 kergoth: are you interested in anything in particular I can help you with? Feb 27 18:37:21 majuk: only four :) https://wiki.yoctoproject.org/wiki/Releases Feb 27 18:37:33 (pyro is in development now) Feb 27 18:44:36 rburton: Man, I tried rolling up Chromium on the Krogoth branch and the thing was a house of cards. It ran but seg faulted at random. Feb 27 18:44:58 Just as likely user error as anything else, it would be a stretch to say I know what I'm doing. Feb 27 18:45:23 I'm rolling up a Jethro build as we speak, see if it's any better. Feb 27 18:59:04 <_Ben> Has anybody added PyOpenCL to a build before? Feb 27 19:04:00 rburton: i still don't see any of my 27 patches in ross/mut. Any chance to get them there? Feb 27 19:55:51 ed2: they'll be in shortly. is ed/wic/wip still the brnach to pull? Feb 27 19:56:36 rburton: thanks. yes, you can pull from ed/wic/wip Feb 27 20:07:59 rburton: just sent a v2 of go patch, it is a single patch as you suggested and has a potential fix for error you are seeing Feb 27 20:08:20 http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/go&id=76b3dc7000fa5940fedb3fcebccd9d23b0b46047 Feb 27 20:22:57 khem: great Feb 27 20:37:44 rburton: I am hoping to get this going before m3 cutoff Feb 27 20:39:11 khem: RP is keen, so i'll try it now Feb 27 20:42:35 ok Feb 27 20:42:53 yes we talked about it last week in Portland Feb 27 20:51:51 the next challenge will be the horrible way that go dependencies are dealt with and that most packages are sneaking out in the background and downloading things. Feb 27 20:53:15 anything on the AB will fail there as we need a proxy to get to internet Feb 27 20:53:38 I didn’t check the latest version, it may not have anything that does that. Feb 27 20:54:00 but let’s just say ,there are lots of crimes in more complicated packages. I spent more than a day packaging dependencies last week. Feb 27 20:54:44 the model we have done for nodejs shouldn't be followed, IMO... it's been a real struggle :( Feb 27 20:55:16 yah. it is about as fun as packing a zillion pypi modules just to make the build deps available. go is simply horrible how it does it IMHO. Feb 27 20:55:37 most of these lang-specific packaging solutions are similar in their behaviour Feb 27 20:55:46 latest is best, always connect to the net... Feb 27 20:56:04 yah. go clones and checks them out locally in a gopath. Feb 27 20:56:41 personally I'd like to see a common framework for supporting these kinds of things through the metadata, if that's practical Feb 27 20:57:23 agreed. I did a docker fix by using a multi SRCREV SRC_URI. but that is something that could be described generally for all the dependencies. Feb 27 20:57:57 since if I package them all up, eventually you’ll get two packages looking for different REVs, and then things get messy with specificying multiple versions of the same dependency, etc, etc. Feb 27 20:58:06 bluelightning: how do you handle mirroring then? Feb 27 20:59:05 RP: the fetcher still has to be involved Feb 27 20:59:21 bluelightning: I do like the idea of using BBCLASSEXTEND somehow for these, or some similar mechanism Feb 27 21:00:23 that might be a nice idea, but I'm not sure it really helps beyond providing a means of having one recipe represent the multiple underlying packages Feb 27 21:00:32 bluelightning: or a generated layer Feb 27 21:00:46 plus it would mean parsing would trigger a repo query Feb 27 21:00:51 bluelightning: so what do we need then? I'm not sure I understand the problem Feb 27 21:01:25 having to have this support for each language-specific packaging solution in bitbake's fetcher code is really painful Feb 27 21:01:56 it belongs in the same place as the support for that language-specific packaging solution is provided, i.e. the layer where the recipes for it are provided Feb 27 21:02:15 bluelightning: fwiw rust are trying to do a fetcher module in their layer. They have it working bar one problem which they agreed to talk to me about Feb 27 21:04:00 ok, I'd be interested to see that Feb 27 21:04:35 I suspect not all of the languages will require as hard a battle as we've had with npm... that's been a nightmare :( Feb 27 21:04:58 and it's still broken Feb 27 21:05:12 (worse in master, but it's on my todo list to fix...) Feb 27 21:05:59 after fighting with go packaging, I was wishing for the sweet embrace of kernel complexities again. Feb 27 21:07:30 haha Feb 27 21:08:22 Is there a way in krogoth to run multiple builds? that is multiple MACHINE= but same target? Feb 27 21:09:15 sveinse: not concurrently in the same TMPDIR, no... that's multiconfig which only came in in the next release Feb 27 21:09:45 We are building three images (different MACHINEs, same tune), and want to bundle this into a common installer. Question is if I can build this bundling into a yocto recipe, or if I need to handle this outside yocto Feb 27 21:09:53 bluelightning: ah, allright Feb 27 21:25:36 Hello, I was curious if this is the best place, or if there is a better place to ask questions about things regarding yocto (such as why something isnt working) Feb 27 21:31:34 inkspell4: Asking to ask a question is always a bad start. Feb 27 21:32:33 majuk: valid point, I just wasnt sure if this is more of a developer or user space Feb 27 21:34:18 majuk: I'm running into a kernel build issue that I have tried to debug and reached a dead end. Essentially using meta-xilinx to build a kernel my custom kernel config fragment is applied and built for qemu-zynq7 but is applied and not build for the microzed-zynq7 Feb 27 22:26:43 hm should core-image-lsb-sdk ship with 700mb of kernel sources? Feb 27 22:28:25 would have figured anything SDK would have been happy with headers and not a full git clone Feb 27 22:29:18 that must be history free to fit in 700MB. Feb 27 22:29:39 (as in "rm -rf .git" kind of history free...) Feb 27 22:31:48 yeah not sure why it ships the full source Feb 27 22:32:00 tempted to save 700mb by ripping that out Feb 27 22:34:16 might as well, and then see what breaks. :) Feb 27 22:34:52 wonder if you'd see the same thing in any of the build appliance images. Feb 27 23:48:39 Front page of https://www.yoctoproject.org should probably be update as 'Developer Day Successful' points to 2015 event. **** ENDING LOGGING AT Tue Feb 28 03:00:00 2017