**** BEGIN LOGGING AT Tue Feb 16 02:59:59 2016 Feb 16 10:04:39 hi, i need partx in my image, and i find it in util-linux in package-split util-linux-partx, so how to get it into the image? Feb 16 10:10:33 ericbutters: append the package in local conf? Feb 16 10:13:01 add util-linux-partx to your image recipe Feb 16 10:13:15 CORE_IMAGE_EXTRA_INSTALL or IMAGE_INSTALL or however you're defining your image Feb 16 10:33:22 hi folks Feb 16 10:34:23 i am using a target with two serial ports Feb 16 10:34:32 one is setup as the kernel console Feb 16 10:34:47 and i would like to use the other as well and just start a getty on it Feb 16 10:35:22 i am using systemd Feb 16 10:35:36 and the serial-getty systemd service uses --keep-baud Feb 16 10:35:55 so although I am specifying 115200 for the port Feb 16 10:36:19 agetty never uses it and I only see a prompt with 9600 baud Feb 16 10:36:36 if I manually alter the baud with stty and restart the service Feb 16 10:36:38 it works Feb 16 10:37:04 is this a bug or an expected behavior Feb 16 10:37:27 if it is something expected than why even use the baud rate in service file? :) Feb 16 11:27:52 has anyone had a build fail when using the archiver set to 'patched'? Feb 16 11:30:51 I'm currently having a kernel fail on do_patch, it does not fail when without the archiver, or with the archiver set to default Feb 16 13:06:56 Hi all. I'm trying to run a recipe for our image which is still using some svn repositories. We're currently porting everything to git but it's not completed yet. However i'm getting a weird svn fetch error "Can't get username or password". Is there any way to kind of debug/trace this error down? Feb 16 13:07:57 when i try to checkout the same svn repo i haven't got any problems. My credentials for that repo are cached in ~/.subversion/auth/svn.simple/ dir Feb 16 13:29:08 Is there any good way to debug ExpansionErrors? Feb 16 15:23:15 RP: Hmm, I'm going through the metadata to clean out and remove manual recipe prefixing in log messages, and realizing that in some cases we might not know in what context a given method is called, anonymous python / event handler or a task. I wonder if recipe info should be just always injected into log messages in every appropriate context, somehow Feb 16 15:23:22 * kergoth ponders, also goes to get some caffeine Feb 16 15:24:30 would be nie to hve that info captured in the 'log format' somewhere, and then the final screen /log-file format could be adjusted dyanmically to include things like time stampes, recipes, tasks, contexts, etc.. Feb 16 15:24:35 (I can dream right?) Feb 16 15:24:44 kergoth: we could probably do that given log messages from task execution have pids Feb 16 16:00:22 I temporarily checked out 2.0 to try out toaster and when I switched back to v1.6 I am not getting toaster related errors with bitbake. Do I need to rm something or clean anything up to remove any toaster-related errors? Feb 16 16:01:19 the bblayers was likely automatically changed, and your build tree will have a newer version Feb 16 16:01:31 easiest way to fix is to delete tmp and bblayers Feb 16 16:02:04 thanks! That did it Feb 16 17:46:47 <_berke_> I have a .bbappend that installs a file using do_install_append() { ... } ; this is part of a layer. I am using this layer in another project, but I want to not have that file. how can I remove it? should I add a "rm" command in a do_install_append() in a .bbappend? Feb 16 17:54:05 <_berke_> ^ that worked :) so never mind. Feb 16 18:05:40 <_berke_> ok I have a similar one. I want to not have a package added in an included layer. I'm looking for something like IMAGE_INSTALL_remove but that doesn't seem to exist. Feb 16 18:13:53 RP: with http://lists.openembedded.org/pipermail/openembedded-core/2016-February/117578.html poky-tiny should succeed Feb 16 18:14:15 RP: let me know if something is still is pending for it Feb 16 18:28:09 RP: but wait there is a race in that patch somewhere Feb 16 18:28:15 I need to fix that Feb 16 18:28:26 see http://errors.yoctoproject.org/Errors/Details/34519/ Feb 16 20:04:30 anyone know what pulsar Linux is (from wind river) ? Feb 16 20:22:01 Crofton|work: yocto + WR shiny Feb 16 20:22:40 morats was grumbling about it Feb 16 20:22:49 I have a borad with a card Feb 16 20:22:57 have to see if it works Feb 16 20:25:12 theyve got some cloudy integration and IoT bling Feb 16 20:25:17 not looked into it much myself Feb 16 21:02:03 * kergoth does a little celebratory dance about https://github.com/openembedded/openembedded-core/commit/aeb6538 Feb 16 21:03:21 though the commit message is inaccurate. it's not a 'historical accident', it was done intentionally, by me, to let the majority of recipes Just Work without adding extra logic to the recipe itself, but it was a mistake, as it was too implicit and led to both confusion and a need for workarounds in particular cases Feb 16 21:10:35 kergoth: maybe calling it an accident was being nice to you Feb 16 21:10:42 it could have said "kergoth was an idiot" Feb 16 21:10:46 haha, that's true Feb 16 21:10:58 still, i don't mind taking the hit on that, not all the decisions we made were for the best Feb 16 21:13:18 one thing that still leaves me with doubts about this.. don't most makefiles set things for CC etc. that are useless when cross-compiling? doesn't this make it harder to add a recipe for a makefile-only piece of software? Feb 16 21:13:44 not really, just need to pass the vars explicitly in EXTRA_OEMAKE if they don't define with ?= Feb 16 21:13:53 and that encourages folks to actually *read the damn makefiles* and see what vars are used Feb 16 21:14:05 instead of just trusting that oe does all the magic they need Feb 16 21:14:08 * kergoth shrugs Feb 16 21:14:27 hmm Feb 16 21:15:16 I have been considering whether we should add additional logic to recipetool create to try to handle makefiles a bit more automatically, i.e. figuring out which variables to pass Feb 16 21:22:51 epic: Linux 192.168.1.10 3.8.0-xilinx Feb 16 21:27:38 bluelightning: i just ported glew to use the upstream makefile thing, just had to do lots of assignments in EXTRA_OEMAKE. -e didn't impact that. Feb 16 21:27:51 bluelightning: if you can make recipetool do magic then you're a genius, imho Feb 16 21:28:17 took about an hour to figure out the right variables for glew… Feb 16 21:28:44 if the variables use standard naming then it's easy Feb 16 21:29:24 did you already post the patch for that? Feb 16 21:29:36 (the glew reworking) Feb 16 21:30:03 yeah just did Feb 16 21:31:38 hmm, some of those could be detected, others look like they're specific to glew's makefile Feb 16 21:31:58 unless you could look at the value and somehow determine what it's meant to be Feb 16 21:33:14 yeah you could guess CC Feb 16 21:33:44 another historical thing, i dislike the default behavior of compile doing nothing if it can't find the makefile, as it's common for it to do that when S is set wrong. would be nice to split out make.bbclass or so, and make it fatal to inherit that and have no makefile Feb 16 21:34:12 hmm, pseudo-native is failing due to being unable to find libsqlite3.a, anyone run into that one? Feb 16 21:34:16 kergoth: *really* want to do that Feb 16 21:34:51 kergoth: are you trying no-static builds? Feb 16 21:35:07 poky now does no-static-libs but does whilstlist sqlite for that reason Feb 16 21:36:12 it's a poky-based build (mel), but no-static-libs isn't being pulled in, afaict Feb 16 21:38:18 so yeah when does mel release its smack integration Feb 16 21:39:46 rburton1: so, just looking at the glew makefile - it doesn't seem to be setting LD, so do you actually need to pass it? Feb 16 21:40:15 ah, because it's CC Feb 16 21:40:37 config/Makefile.linux sets LD=cc Feb 16 21:40:54 kergoth: hmm, the no-staticlibs leaves sqlite static enabled Feb 16 21:40:55 that's the other thing, you can't just look at whats defined, but also what's used, and it could be using implicit rules rather than explicit ones. it may be using vars without setting default values Feb 16 21:41:02 RP: hmm, k, will dig further Feb 16 21:41:32 kergoth: and yes I thought you'd appreciate the EXTRA_OEMAKE change. I just worry about what impact this has on other layers :/ Feb 16 21:41:48 rburton1: hmm, that include is dependent on SYSTEM which we can't know to begin with :/ Feb 16 21:41:53 yeah.. well, folks have to expect they may have to fix their layers after a major version bump in oe-core Feb 16 21:41:56 * RP is now fighting layer config upgrade issues :( Feb 16 21:42:03 :( Feb 16 21:42:22 bluelightning: yeah, turns out the same people that think "i'll write my own makefiles" also think "lets make it mental" Feb 16 21:42:23 kergoth: not to do with that, this is a different pain with poky verses oe-core sample config files Feb 16 21:42:30 ahh Feb 16 21:42:38 RP: yeah don't think we can do this automatically Feb 16 21:42:40 rename of meta-yocto -> meta-poky Feb 16 21:42:48 rburton1: I think we can, ish Feb 16 21:42:53 rburton1: well, I don't know that it's mental, but it certainly makes it harder to read/parse outside of make itself Feb 16 21:43:41 RP: can we avoid a split in the version numbers between OE-Core and poky this time? Feb 16 21:44:00 bluelightning: wait until you see the patches :/ Feb 16 21:44:40 I will... FWIW I'd hoped the mechanism I set up would help with this sort of thing Feb 16 21:45:42 I think I'll just leave this automagic makefile thing for now Feb 16 21:46:08 bluelightning: it can't cope basically and I'm considering a few changes Feb 16 21:46:08 bluelightning: probably for the best :) Feb 16 21:47:01 any though of renaming linux-yocto to linux-poky ? Feb 16 21:47:18 armpit: no, because that doesn't make sense Feb 16 21:47:48 so its the kernel for the yocto Feb 16 21:47:53 not poky? Feb 16 21:48:12 armpit: poky is the distribution, the kernel tooling and methodology are one of the subcomponents of the Yocto Project Feb 16 21:48:42 Note I'm renaming meta-yocto with meta-yocto, not the repo itself Feb 16 21:48:49 s/with/within/ Feb 16 21:50:23 linux-yocto might be why one hears Yocto Linux Feb 16 21:50:53 the layer rename should help with some of the yocto/poky confusion, looking forward to it Feb 16 21:51:05 * armpit waits for Crofton to start in Feb 16 21:52:48 kergoth: I'd love someone to try writing the upgrade code, its horrible Feb 16 21:52:54 :( Feb 16 21:55:43 Pulsar Linux! Feb 16 21:59:05 kergoth: rng-tools is still broken on musl Feb 16 21:59:18 | checking for argp_parse in -largp... ../rng-tools-5/configure: line 4391: ac_fn_c_try_link: command not found Feb 16 21:59:18 | no Feb 16 21:59:18 | configure: error: in `/data/poky-master/tmp-musl/work/corei7-64-poky-linux-musl/rng-tools/5-r0/build': Feb 16 21:59:18 | configure: error: libargp not found Feb 16 21:59:34 the packageconfig adds the dep on argp-standalone, no? Feb 16 21:59:36 i'm confused Feb 16 21:59:43 my local builds went okay, but maybe i missed something Feb 16 22:00:22 yeah, that's built Feb 16 22:01:08 ac_fn_c_try_link: command not found, that's worrisome, it just does a normal ac link test, i don't see how that could fail to expand and run properly Feb 16 22:01:10 hmm Feb 16 22:01:15 * kergoth fires up a local build Feb 16 22:01:47 yeah something went wrong with the configure patch Feb 16 22:02:21 hi sno Feb 16 22:02:25 odd, i did a bunch of tests in the source tree with various combinations of arguments to try to check all the conditionals. must have missed one. i wonder why it built fine with bitbake for me though Feb 16 22:02:28 * kergoth scratches head Feb 16 22:02:37 i'll look into it Feb 16 22:02:42 cheers Feb 16 22:03:35 there's some other bits to do for rng-tools also one of these days. we need the systemd service file that's in a number of other distros, and there are a few patches in other distros we should pull in too. figured i'll do that as a later task Feb 16 22:05:17 kergoth, rburton1: does it need a DEPENDS? Feb 16 22:05:48 nah, that's there apparently, it's one of the macros not expanding correctly, i probably missed a ] or something, though i don't know how it slipped through my tests Feb 16 22:05:49 bluelightning: see what you think of http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=9fd2e64bf29742d9cf95116eb06edd57919f8ab8 Feb 16 22:05:59 so easy to get the quoting wrong in m4 Feb 16 22:06:04 * kergoth hates, hates, hates it Feb 16 22:06:04 corresponding poky change is http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=1adc6f7a47dee083ad3cefd58655f51927f38de4 Feb 16 22:06:38 * RP notes the stray orig file :/ Feb 16 22:07:17 and the debug warnings Feb 16 22:07:24 really not my day... Feb 16 22:07:45 hi rburton1 Feb 16 22:12:12 RP: it's ugly, but I can see why you've redone it this way Feb 16 22:13:21 bluelightning: I'm open to better ideas... Feb 16 22:13:55 bluelightning: I also dislike having to have the meta-yocto directory around but without it, we hit parse issues and never get to the sanity code Feb 16 22:14:16 right Feb 16 22:15:02 removal of the IMAGE_GEN_DEBUGFS example, the example changes to site.conf.sample, assuming those belong in a different commit Feb 16 22:15:20 right I noticed those too Feb 16 22:15:22 other than that, seems reasonable to me Feb 16 22:15:26 the naming of the variables is a bit painful... how about POKY_BBLAYERS_CONF_VERSION and REQUIRED_POKY_BBLAYERS_CONF_VERSION ? Feb 16 22:16:15 I'm also wondering if there's a way to avoid having the OE-Core logic need to know about those Feb 16 22:16:25 even indirectly Feb 16 22:16:44 kergoth: there are a few oddities in there, some mismatch between the layers. need to fix that Feb 16 22:16:47 * bluelightning reads more closely Feb 16 22:17:34 bluelightning: ultimately, only the layer needs to care. We just have to have a single transition point which does need to know Feb 16 22:17:57 bluelightning: the one nice thing is that as a result, other layers can handle their own config files using the same mechanism Feb 16 22:20:14 right Feb 16 22:20:34 in the end this area was always pretty hideous, at least it's now a bit more flexible... Feb 16 22:35:37 bluelightning: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=5c89c625a7728122c6cd051b4bc1f69baa6ce68d and http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=c8c763c0f4ac8be593ffbf7400401ac98b7eb7bf are cleaned up verisons Feb 16 22:35:46 * RP fixed the layer mismatches Feb 16 23:14:26 kergoth: tip for reproducing the rng-tools issue - build from scratch/sstate in a clean tmp. Looking into what is going on... Feb 16 23:19:47 yeah, repro'd it Feb 16 23:20:04 <3 the fact that devtool modify doesn't require -x or the source tree path nowadays Feb 16 23:22:25 kergoth: seems to depend if gcrypt is present or not :/ Feb 16 23:23:39 huh. that'd be weird, it's a completely different block in configure.ac with different variables Feb 16 23:24:29 kergoth: build gcrypt first and it works Feb 16 23:25:14 clearly it needs a packageconfig to make the use of gcrypt deterministic, but beyond that, i have no idea why it'd cause that failure. strange Feb 16 23:25:17 * kergoth tests here Feb 16 23:40:33 kergoth: underquoted previous entry afaict Feb 16 23:40:46 ah Feb 16 23:43:11 kergoth: I'll send a patch, I need this fixed :/ Feb 16 23:43:56 thanks, appreciated, sorry my fix wasn't complete Feb 16 23:45:21 kergoth: what scares me is the RDEPENDS = "libgcrypt" in there :/ Feb 17 00:02:03 RP: fyi, poky_update_bblayersconf failure leads to 1. a traceback from NotImplementedError, and 2. a traceback from FuncFailed. possibly should clean up the error cases (testing master-next, obviously) Feb 17 00:04:51 kergoth: ouch, thanks for the heads up :/ Feb 17 00:04:54 SNP Feb 17 00:04:58 er, np Feb 17 00:05:20 kid loves to push buttons on my keyboard :) Feb 17 00:05:41 kergoth: :) Feb 17 00:06:00 kergoth: question is why that function is even getting called :/ Feb 17 00:07:12 i switched a couple times between master and master-next, might have gotten it upset, going to start again with another build dir Feb 17 00:07:17 * kergoth shrugs **** ENDING LOGGING AT Wed Feb 17 02:59:59 2016