**** BEGIN LOGGING AT Wed Sep 16 02:59:59 2015 Sep 16 03:13:55 dhirc: yes, that'll work fine. cached binaries are checksummed, they'll only affect one another if the checksums match, which means they're correct, otherwise they won't affect one another at all Sep 16 03:37:47 kergoth: thanks for confirming Sep 16 07:14:42 good morning Sep 16 07:15:26 moarns the good too. Sep 16 07:53:39 hi! Sep 16 07:53:50 lo! Sep 16 07:54:00 could someone help me by explaining how tmux could interfer with a bitbake build of yocto? Sep 16 07:54:41 not directly, but i can confirm that its detection interfers with the devshell feature IIRC Sep 16 07:54:42 i've had a problem building networkmanager. it failed while patching. Sep 16 07:54:50 i often run bitbake under tmux so define what you mean by interfere Sep 16 07:55:00 rburton: yeah, same here. Sep 16 07:55:02 right Sep 16 07:55:13 so if you've got PATCHRESOLVE=user it will start a devshell for you Sep 16 07:55:15 and that will use tmux Sep 16 07:55:25 which is why poky sets that to noop Sep 16 07:55:33 looking at the log i noticed that there was some tmux related errors. so i draw the conclusion that networkmanager fails to build because i was running in tmux. Sep 16 07:56:05 so its possible that the patch apply failed Sep 16 07:56:12 set PATCHRESOLVE=noop in your local.conf and see if that helps Sep 16 07:56:40 (fwiw, the default is noop in master now) Sep 16 07:56:48 so i closed tmux and now i get these errors: http://pastebin.com/ifh40Ser Sep 16 07:59:13 testing with patchresolve=noop... Sep 16 08:00:13 looks like you didn't set PATCHRESOLVE correctly Sep 16 08:00:30 rburton: that log was from before i set PATCHRESOLVE Sep 16 08:00:56 oh right Sep 16 08:00:57 gotcha Sep 16 08:01:06 yeah that's networkmanager's do_patch failing Sep 16 08:01:08 i'm building with PATCHRESOLVE=noop now, and so far no problems. i get a much better error message for the patch that fails to apply to networkmanager... Sep 16 08:01:30 its trying to drop you into a devshell to fix the apply directly Sep 16 08:01:43 which is helpful but a bit confusing if you're not aware its trying to do that :) Sep 16 08:01:49 (thus why we changed the default) Sep 16 08:02:05 ok. has it always been like that? Sep 16 08:02:22 can't remember being dropped into devshell on patch errors before... Sep 16 08:13:55 ionte_: poky sets noop, the default was user until very recently. its possible that you were using a distro that sets noop until recently? Sep 16 08:18:56 rburton: using poky fido and PATCHRESOLVE is "user" (set in meta/conf/bitbake.conf) Sep 16 08:25:47 the default local.conf sets PATCHRESOLVE = "noop" Sep 16 08:35:03 morning all Sep 16 08:37:07 oops, I seem to have triggered a QA build mail when using the AB yesterday Sep 16 09:23:34 joshuagl: yes, i see that now. but i use a minimal local.conf, so i guess it defaulted to "user" since PATCHRESOLVE was not set in local.conf Sep 16 09:30:22 hi, is it possible in yocto in .bbappend file to remove "something" from RDEPENDS that was set in .bb file? Sep 16 09:31:18 I tried RDEPENDS -= "something", but that results in unparsable line Sep 16 09:31:49 gatisp: you could try RDEPENDS_${PN}_remove = "something" Sep 16 09:32:54 btw, if this is in something like a packagegroup, no worries... but bear in mind in a normal recipe this alone isn't going to do anything to remove the underlying dependency that the RDEPENDS is just there to satisfy Sep 16 09:37:06 bluelightning, thanks, _remove seemed to helped - bitbake succeed. Yes I understand that it would not remove the dependency from the code it self :) Just want to remove a faulty set dependency in upstream code. Sep 16 09:37:28 gatisp: the the upstream code a public layer? Sep 16 09:38:09 yes, it is /sources/meta-openembedded/meta-initramfs/dracut. We talked about this one actually once. dracut does not depend on systemd Sep 16 09:38:36 until now i just copied the recipe and remove the faulty dependency manually Sep 16 09:40:05 now i am just cleaning up my code by adding .bbappend with RDEPENDS_${PN}_remove = "systemd" Sep 16 09:40:34 hmm, well ideally the original recipe would be fixed Sep 16 09:40:47 of course I should fix it upstream, but lazy to setup account :) Sep 16 09:40:57 I'm still a bit puzzled as to how that dependency got in in the first place Sep 16 09:41:20 probably by mistake Sep 16 09:41:30 I did look through the git history but there wasn't anything obvious by way of explanation Sep 16 09:41:50 dracut can take advantage of systemd if it present Sep 16 09:41:58 but it is not mandatory Sep 16 09:42:12 ok, fair enough Sep 16 10:24:11 anyone who's familiar with using nodejs and npm packages in yocto? i have a few packages that are build dependencies for a custom recipe. for example "webpack"... Sep 16 11:28:53 hi I am trying to create a custom layer with some packages whose recipes are only available in this meta-example directory Sep 16 11:29:21 I already modified conf/bblayers.conf to include the absolute path of this directory Sep 16 11:29:47 but still when rootfs is building this packages are not build and nor packaged Sep 16 11:30:33 any idea where I am doing wrong Sep 16 11:31:42 *goingg Sep 16 11:31:56 niteshnarayanlal: does anything add the packages into the image? Sep 16 11:32:43 jku, I tried to add these packages by making a bbappend file Sep 16 11:32:51 under images directory Sep 16 11:34:41 jku, I hope I expressed my query clearly? Sep 16 11:36:46 typically I think you'd either create a your-own-image.bb file or for testing you could just use 'IMAGE_INSTALL_append = " my-package"' in your local.conf Sep 16 11:40:40 jku, is there any example which I could refer as I couldn't find it on internet Sep 16 11:41:18 I used IMAGE_INSTALL +="package" -image-core.bbappend Sep 16 11:50:43 I guess bbappending image bb files works (assuming you actually used the name of a real image) but the normal way to do it is to write a custom .bb file and use e.g. "inherit core-image" in that bb file Sep 16 11:50:45 niteshnarayanlal: see http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb Sep 16 11:52:03 (or just copy-paste some image bb file that is close to what you want) Sep 16 11:54:18 jku, if I have some pre existing abc-image-core.bb which I copy under images of tpm-abc directory Sep 16 11:54:29 then do I have to change its name Sep 16 11:54:46 or is it ok if 2 abc-flash-core.bb exists in separate directory Sep 16 11:55:22 change the name -- I don't see how bitbake could figure out which one you mean otherwise Sep 16 12:01:31 so just changing the name will do and is there any other change I need to make Sep 16 12:02:04 as in how yocto reads it just goes to this directory and see the xyz-image.bb and will start building those packages Sep 16 12:02:07 is that so? Sep 16 12:06:48 as long as the layer is in BBLAYERS and the layers layer.conf sets BBFILES so that xyz-image.bb is found, that should be it Sep 16 12:07:44 (and the image bb file adds the needed packages to IMAGE_INSTALL of course) Sep 16 12:11:23 jku, http://fpaste.org/267899/24054661/ this is how my layer.conf looks atm Sep 16 12:11:42 its present in meta-tp/conf/ Sep 16 12:12:40 other two directories in meta-tp are images and recipes-tp Sep 16 12:13:06 recipes-tp carries trousers and other recipe files in the respective directory of each package Sep 16 12:14:08 in the images I have created image-core-tp.bb Sep 16 12:14:25 where I have added the IMAGE_INSTALL Sep 16 12:14:30 does that make sense? Sep 16 12:17:21 what is the problem you are solving right now? Sep 16 12:17:31 the packages are not getting build Sep 16 12:17:43 when I am building the rootfs Sep 16 12:17:58 but did bitbake build image-core-tp? Sep 16 12:19:17 niteshnarayanlal: it sounds like the image file should be in e.g. meta-tp/recipes-tp/images/image-core-tp.bb Sep 16 12:19:31 to match your BBFILES setting Sep 16 12:25:12 jku, yeah thanks a bunch Sep 16 12:25:29 I didn't write the layer.conf properly Sep 16 12:25:42 due to which it never found the recipe files Sep 16 12:26:13 np (I think I've fallen to the same trap once) Sep 16 12:30:24 jku, a generic question we have so many layers in yocto now if all have their own abc-image-core.bb then size of the whole rootfs would be too large isn't Sep 16 12:30:40 or is it advisable to use bbappend Sep 16 12:32:43 now I don't follow Sep 16 12:34:20 niteshnarayanlal: why would you need one image per layer? surely you should only need one image recipe per set of image contents you actually want to build? Sep 16 12:36:21 niteshnarayanlal: if you just wanted to add packages from this new layer to an existing custom image (without creating an additional image), then just modify that image bb file Sep 16 12:38:52 the recommended best practice is for your custom image recipes to be in your custom distro layer, which has an expectation that all of the layers providing all of the needed recipes are enabled when using it Sep 16 12:45:02 ah ok thanks all Sep 16 14:59:07 Hey, is it possible to make the layer configuration dynamic? I want to include a layer only if a specific machine is used. Sep 16 15:00:37 DatGizmo: not generally, no Sep 16 15:00:55 which is part of why bsp layers should use machine overrides everywhere, so it's safe to include the layer in your layer configuration whether you use that machine or not Sep 16 15:03:06 My problem is, that I have some bbappends in our layer which depends on another layer. So if this layer is missing, bitbake failes. Sep 16 15:03:39 ah, i can tell you how to fix that Sep 16 15:03:48 So I thougt, I could put thoes append files in a subfolder of our layer, and include thoes onlt if a specific machine is used. Sep 16 15:03:56 you can set it up so you can have areas of your layer which are only used when that other layer is included Sep 16 15:04:20 https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/conf/layer.conf#L5-L10 Sep 16 15:04:37 then as an example, https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/meta-ti/recipes-graphics/libgles/libgles-omap3_5.01.01.02.bbappend Sep 16 15:04:55 how meta Sep 16 15:04:57 note how it's under the meta-ti subdir. it goes by the layer name from BBFILE_COLLECTIONS from the layer's layer.conf Sep 16 15:05:18 it's quite common to have a distro layer that wants to apply changes to multiple bsps, so it comes in handy there Sep 16 15:06:58 bluelightning: oops, forgot to cc you on the new recipetool subcommand, but i think you probably saw the bug update anyway, so maybe it doesn't matter Sep 16 15:07:07 i need to get in the habit of cc'ing folks that care on my submissions Sep 16 15:07:25 Ahh, I have seen this in a layer we use. But I didn't quit understand how I could use this. But it just clicked :) Sep 16 15:07:32 kergoth: thanks :) Sep 16 15:08:02 np Sep 16 15:08:58 kergoth: hmm when did you send that? Sep 16 15:09:52 last night, '[PATCH] recipetool: add 'newappend' sub-command' .. it's trivial, not much code Sep 16 15:10:17 thought about putting it in append.py, but i worry that's getting a bit cluttered Sep 16 15:14:12 kergoth: hmm, somehow I'm not seeing it in my mail client but it's in patchwork Sep 16 15:14:19 huh, weird Sep 16 15:14:52 ah, wait... there it is Sep 16 15:27:48 Has the 2.0 release been branched, yet, since it's supposed to be feature frozen? Sep 16 15:29:00 afaik "kinda".. in that M3 isn't out yet AFAIK.. Sep 16 15:29:46 huh, k Sep 16 15:30:22 gcc 5.2, recipe test and build failures, etc have put M3 behind schedule.. Sep 16 15:30:48 technicall M3 release is what should trigger the freeze.. but I don't think RP is accepting new functionality at this point (well he probably is within reason anyay) Sep 16 15:33:47 Hi Sep 16 15:34:56 hello again. How do I tell a recipe to install header files in sysroot? currently I have them only on the image. Sep 16 15:35:41 fray: ah, okay, thanks, was wondering Sep 16 15:35:55 gatisp: you don't have to tell it anything, any headers installed to ${D}${includedir} will end up in the sysroot Sep 16 15:36:02 I've discovered Yocto Autobuilder today and I'm interested on it Sep 16 15:36:52 Is it doing tests on QEMU already? I read that is something you want to add in the future, but don't know when this webpage has been edited last time: https://www.yoctoproject.org/tools-resources/projects/autobuilder Sep 16 15:37:28 kergoth, hm ok, will have to check why they are not there then. I inherit autotools, maybe i have to explicitly add that path in install_append then. Sep 16 15:38:36 kergoth: M3 just went into testing which is our feature freeze point Sep 16 15:39:02 peterdoe: it is... but it's just calling the runtime test code that is within the main build system in order to do that Sep 16 15:39:05 kergoth: I tend to hold off branching for a while and concentrate on bug fixing the release rather than try and do master and the release at the same time Sep 16 15:41:33 bluelightning: nice! can you point me to the jobs in autobuilder buildbot that are doing that? Sep 16 15:43:06 I've been also trying to dig information about "Yocto HW automation testing". All the info I've found is confusing Sep 16 15:43:46 peterdoe: "Running Sanity Tests" is the autobuilder task that does that I believe Sep 16 15:44:10 as for testing on real hardware, what we support is documented in the manual, let me grab the section link Sep 16 15:44:48 peterdoe: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#hardware-image-enabling-tests Sep 16 15:46:12 bluelightning: yes, "sanity tests" looks like them, thanks Sep 16 15:46:50 * peterdoe goes to read Sep 16 15:46:53 thanks for the link Sep 16 15:46:59 no problem Sep 16 15:47:12 it's fairly bare-bones, but does have the basic functionality Sep 16 15:47:36 kergoth, i think i used the wrong work to describe what i was trying to achieve. What I wanted to ask is how do I get the headers into toolchain? not sysroot/image Sep 16 15:48:05 gatisp: how are you building the toolchain? Sep 16 15:48:30 gatisp - for 'toolchain' you mean an SDK? Sep 16 15:49:04 yeah, SDK. I run "bitbake meta-toolchain-b2qt-embedded-sdk" Sep 16 15:49:34 the meta-toolchain-b2qt-embedded-sdk recipe would need to specify the list of things you want in the 'sysroot' part of the SDK.. Sep 16 15:49:43 both mandatory and 'attempted' install.. Sep 16 15:49:58 through TOOLCHAIN_TARGET_TASK Sep 16 15:50:06 correct.. was just going to look that up.. ;) Sep 16 15:51:37 bluelightning, fray : thanks, I think i found the place. Sep 16 15:53:30 there is also an 'SDKIMAGE_FEATURS' which defaults to dev-pkgs and dbg-pkgs Sep 16 15:53:49 Hmm, we put ERROR messages on stderr, but not WARNING messages. given stderr isn't just for errors, but anything out of band, i think warnings would probably be appropriate there as well Sep 16 15:55:01 (context: i want recipetool-newappend to be scriptable, which means nothing but the append path outputted on stdout, but also want to show warnings) Sep 16 15:56:04 oh, actually, we aren't even using BBLogFilterStdErr in scriptutils yet anyway, so even if it worked for warnings, it wouldn't benefit recipetool yet :P Sep 16 16:05:25 I'm kind of new to this whole thing so this might be a dumb question, So much information to try and consume at once ... When a yocto build is made, where / how do you define a script that you want to be put in /etc/rc5.d/ ? I looked at some of the recipes for busybox and I just don't see where that happens Sep 16 16:05:53 oh, i see Sep 16 16:10:48 Can 2 builds use the same SSTATE_DIR without causing problems for each other? Sep 16 16:10:56 bitbake related ^ Sep 16 16:11:37 aaboyd: basically they need to be installed during do_install... often the makefile being run by the recipe is what does that Sep 16 16:12:04 aaboyd: after that there is an inherit and some variables to set in order to get the initscript enabled Sep 16 16:12:44 aaboyd: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-enabling-system-services Sep 16 16:15:49 bluelightning: thanks for pointing me in the right direction, I will take a look at that part of the manual Sep 16 16:16:11 aaboyd: no problem Sep 16 16:18:58 jmesmon: I'm not sure that is a good idea for concurrent builds... you're best off having a primary builder and then any others use SSTATE_MIRRORS to point to the primary's SSTATE_DIR Sep 16 16:23:33 * nerdboy waves from the squeaky-kitty nest Sep 16 16:38:23 joshuagl: ping Sep 16 16:39:47 when you "bitbake [recipe]" shouldn't bitbake select the latest version? "bitbake opencv" seems to want to build 2.4 instead of 3.0 even though opencv_3.0 exists Sep 16 16:40:39 tripzero1: the latest is used if no preferences are specified. your distro could be specifying it, or the recipe could set DEFAULT_PREFERENCE to indicate we don't want it used by default (usually the case with prereleases, git versions, or bits which just aren't well supported yet, etc) Sep 16 16:41:47 kergoth: aah! I see DEFAULT_PREFERNCES = "-1" for 3.0 Sep 16 16:42:19 can I override that in my local.conf? DEFAULT_PREFERNCES_opencv = "0" ? Sep 16 16:43:09 no, the usual way of specifying preferences will override it Sep 16 16:43:16 PREFERRED_VERSION_opencv = "3.0" Sep 16 16:43:27 kk Sep 16 16:43:29 DEFAULT_PREFERENCE is just the default when no preference is specified by the user Sep 16 16:54:46 Hmm, could be useful to be able to specify on a per-recipetool-sub-command basis, to send all log messages to stderr, because our primary output is something actually useful, not just log messages Sep 16 16:55:13 for cases where the log messages are not the primary output -- logging usually *is* out of band for unix tools, just with bitbake we conflate the two, the log messages are the main output Sep 16 16:57:44 Does https://github.com/openembedded/openembedded-core/compare/openembedded:master...kergoth:scriptutils-log-improvements seem reasonably sane? Sep 16 16:58:18 (doesn't do what i just discussed, just switches to using the bits that send error to stderr, then changes that to include warnings, and uses the bb.msg log formatter once we have bb.msg available) Sep 16 16:58:34 hmm Sep 16 16:58:48 kergoth: you wrote the opencv recipe, right? Sep 16 16:58:58 don't think so Sep 16 16:59:07 check the git log. git log --follow Sep 16 17:47:16 oops! /etc/issue still shows 1.7.2 in fido branch ;) Sep 16 17:48:31 * kergoth chuckles Sep 16 17:48:43 need to automate the release process more, including version bumping Sep 16 17:48:47 hmm Sep 16 17:50:30 yeah, DISTRO_VERSION still showing 1.7.2 Sep 16 18:14:40 * nerdboy had a jenkins env sed hack for that once... Sep 16 18:15:07 * nerdboy hears the mewing of day-old kitties Sep 16 18:15:58 aw Sep 16 21:15:03 error: implicit declaration of function 'drmModeSetCursor2' in xserver-xorg, anyone run into this one before? Sep 16 22:24:28 progress, finally Sep 16 22:24:40 kergoth: I've been in hell^H^H^H^Hdigging in libtool some more Sep 16 22:25:05 kergoth: looks like need_relink is not set to 'yes' for nios2, this the libtool doesn't generate wrappers Sep 16 22:25:30 kergoth: now I need to understand why this is the case Sep 16 22:26:32 Marex: heh, progress at least Sep 16 22:27:14 in case anyone else ever runs into the aforementioned error, drmModeSetCursor2 was added in 2.4.46 of libdrm, but meta-ti is currently stuck on 2.4.41, so currently meta-ti machines using libdrm will fail to build the xserver-xorg which is in oe-core Sep 16 22:27:32 that is, without a preference set to pull in oe-core's libdrm Sep 16 22:27:52 kergoth: libtool eats little kittens for breakfast, I'm certain of that Sep 16 22:28:40 that doesn't surprise me in the least. i remember working on some of the early cross patches for it, nightmare Sep 16 22:28:47 though richard did more of that than i Sep 16 22:29:05 kergoth: we still have some of yours I think. We both have scars from that... Sep 16 22:29:05 kergoth: that's unfortunate. I'm trying to push people internally to remove dependency on old libdrm - https://lists.yoctoproject.org/pipermail/meta-ti/2015-August/006937.html Sep 16 22:29:25 denix: yeah, got taht impression from your commit messages :) Sep 16 22:30:43 joshuagl: congrats on achieving the greenest build we've had for a while! Sep 16 22:30:58 * RP just wishes it was master Sep 16 22:33:00 Marex usually the relink is because prelink doesn't think the architecture supports shared libraries.. this could be the result of the arch scan early in libtool -- or it running 'file' to find the type of files and not being able to interpret the results.. Sep 16 22:33:13 kergoth: one dilemma we've got right now is the package directory concurrency issue. rootfs generation is basically serialised by locks on the package directories since changing the indexes half way through would break things. Sep 16 22:33:31 kergoth: now the QA tests are getting upset if we change the index in the middle of the package manager tests :( Sep 16 22:33:53 kergoth: serisouly wondering if we should make things work off a hardlinked copy of the dirs... Sep 16 22:33:56 oh Sep 16 22:34:00 mother...f:-E~ Sep 16 22:34:16 for host in .... *os2*) magically matches nios2 Sep 16 22:34:21 as I said before.. I'm surprised libtool even knows that nios2 architecture exists.. Sep 16 22:34:34 ahh there ya go.. :) you not have a nearly 20 year old OS causing you problems Sep 16 22:34:39 which is why , of course , need_relink is set to no, because for os2 we do not relink Sep 16 22:34:44 but nios2 != OS/2 , so ... Sep 16 22:34:50 that's the whole problem Sep 16 22:34:59 Marex: I really shouldn't laugh, I've been there myself... Sep 16 22:35:02 my suggestion BTW (short term) remove references to os2... long term re-order the matching Sep 16 22:35:11 the later is likely what you need to get it upstream Sep 16 22:35:54 I'll consult this with my doctor ... Sep 16 22:36:02 :) Sep 16 22:36:27 (search and replace of 'os2' to 'XX' would work.. ;) Sep 16 22:36:48 fray: I'd prefer a much more proper solution Sep 16 22:37:00 I need to check how many of these os2 issues are there Sep 16 22:37:08 but hell, this was a stab in the back, ew Sep 16 22:37:13 :) Sep 16 22:38:45 Marex: haha Sep 16 22:47:25 nios we did not have proper fork() for it as well Sep 16 22:48:57 kergoth: I'd like to submit proper nios2 support for Yocto Sep 16 22:49:11 kergoth: should I cook it into meta-nios2 or shall I submit the core bits for inclusion into poky ? Sep 16 22:52:36 Marex: core bits into oe-core yes Sep 16 22:53:59 khem: roger :) Sep 16 22:54:05 khem: btw are you coming for ELCE this year again ? Sep 16 22:54:19 Marex: no, skipping Sep 16 22:54:26 who's coming ? Sep 16 22:54:42 must be lot of folks Sep 16 22:55:38 * fray will be there Sep 16 22:55:41 khem: yeah, it's bigger each year and I think the quality is dropping Sep 16 22:55:43 I think zedd will as well Sep 16 22:55:48 oh cool :) Sep 16 22:56:19 I think the quality is there.. but the type of talks is changing.. (not necessarily bad) Sep 16 22:56:37 I'm seeing a lot more what I would consider "intermediate" embedded topics Sep 16 22:59:17 fewer advanced and beginner topics.. Sep 16 23:12:31 fray: come see my FPGA talk :-) Sep 16 23:12:58 fray: hopefully, it's press you into the seat with it's advanced...ness :-) Sep 16 23:13:19 * Marex is in really good mood after this libtool thing :-) Sep 16 23:19:33 I really need to stop skipping these conferences, I've been to one ELC years ago :\ Sep 17 00:05:59 well, excellent, after I fixed the libtool problem, magically core-image-minimal finished building Sep 17 00:14:28 congrats Sep 17 00:29:43 huh, just noticed a typo, WARNING: Cooker recieved SIGTERM, shutting down... Sep 17 00:48:40 looks like a few other things don't quite build ... like pixman, but there seems to be a semi-finished patch Sep 17 01:17:35 one bug down, one to go Sep 17 01:21:33 Hello! I'm having some trouble with autoconf... it's not finding a header but the header exists in /tmp/sysroots/$target/usr/include Sep 17 01:23:58 Here is the relevant output: http://pastebin.ca/3163303 Sep 17 01:32:51 aport: autotools is the spawn of Satan Sep 17 01:33:13 oh Sep 17 01:33:23 Yes I agree Sep 17 01:33:24 aport: try bitbake -e -c configure cogl Sep 17 01:33:43 aport: it should show you which paths are used and you should be able to figure out why the header is not found :) Sep 17 01:35:22 that's a lot of output... let me dig through this Sep 17 01:35:40 aport: pipe it into less Sep 17 01:35:44 aport: I like this https://www.varnish-cache.org/docs/2.1/phk/autocrap.html :-) Sep 17 02:02:15 hm, libatomic-ops on a CPU which has no facilities for atomic ops might be an issue :-G~ **** ENDING LOGGING AT Thu Sep 17 02:59:59 2015