Just ran nginx::source recipe on my vagrant box, and I have very unusual behaviour.
When I include a recipe from the Vagrantfile (as below), everything works like a charm,
chef.add_recipe("project::nginx")
chef.add_recipe("nginx::source")
(project::nginx recipe is very simple. Using it to override default attributes of the nginx cookbook)
but if I include a recipe at the very end of project::nginx (mentioned up), everything falls apart:
node.default['nginx']['server_names_hash_bucket_size'] = 128
include_recipe "nginx::source"
Until now I didn't know there's any difference in behaviour between those two invocations. Does anybody here knows what's the difference?
Gotya! Chef 11 feature. Issue with it exist in chef-solo solely :)
To make a quick resume, difference is:
chef.add_recipe() - loads entire cookbook context (all the files, e.g. recipes, definitions, attributes...)
include_recipe "" - files(attributes, definitions etc.) that are not in the expended run list are not loaded.
There are at least 4 ways to solve the issue(put files in the run list):
include_attribute - include desired attribute file explicitly.
metadata.rb->dependency - if your cookbook is using recipe from another cookbook, put that cookbook in metadata.rb's dependency section, and all it's files will be loaded.
chef.add_recipe() - Load recipe via Vagrantfile. (Mentioned here just for reference)
Berkshelf - you may use this cookbook manager to solve the issue as well. Here's the Stackoverflow thread about this exact problem and some Docs
For those who are interested in further reading, Chef 11 introduced dependency-based cookbook loading for non-recipe files. The new loading logic means that files belonging to cookbooks which exist in the cookbook_path but are not in the expanded run_list or dependencies of the cookbooks in the expanded run_list will no longer be loaded. REF: Opscode breaking changes documentation, and if you need a signature of the error I got, here's the exactly same one, even for the same cause.
Related
I am trying to introduce pre-commit into quite a large existing project and replace the existing direct call to mypy with pre-commit, however, the results differ. It would be unreasonable to try and describe everything I've tried in detail or expect a definitive answer as to what to do. I just hope for some direction or advice as to how to diagnose the situation.
Here's the problem. When I run the 'legacy' mypy invocation, everything passes, but when I call the pre-commit run mypy --all-files, I get a lot of errors along the lines of:
pack_a/pack_b/pack_c/json_formatter.py:171:13: error: Returning
Any from function declared to return "str" [no-any-return]
return orjson.dumps(result, self._default).decode('UTF-8')
The function in question is indeed declared to return str, but so is orjson.dumps, so it seems that this should pass (it returns bytes to be precise, but not Any).
The other type of error I get is Unused "type: ignore" comment
I tried to figure out the difference between the configurations, but couldn't.
Here's how mypy is called now:
$(VENV)/bin/mypy --install-types --non-interactive $(CODE)
Where $(CODE) is the list of all the directories that contain 'code' (as opposed to tests and supporting scripts)
- repo: https://github.com/pre-commit/mirrors-mypy
rev: v0.950
hooks:
- id: mypy
args: [
"--config-file=setup.cfg",
--no-strict-optional,
--ignore-missing-imports,
]
additional_dependencies:
- pydantic
- returns
... (I checked all the types-* files the old mypy installs and added them here)
exclude: (a regex to exclude the non-code dirs)
I am not sure how to check that the both configurations check the same set of files, but the number of files checked they report is the same.
There's also the problem that when I edit a file and then run pre-commit run mypy, I get even more errors than with pre-commit run mypy --all-files
Is there anything I could try to diagnose this?
the mirrors-mypy README addresses this --
Because pre-commit runs mypy from an isolated virtualenv (without your dependencies) you may also find it useful to add the typed dependencies to additional_dependencies so mypy can better perform dynamic analysis
at least from your description you're missing orjson there -- perhaps more
disclaimer: I wrote pre-commit
I am attempting to make a migration from D7 to D8 using Migrate Manifest. I have all the migrate modules installed (i.e. the 3 core migrate modules, Migrate Upgrade, Migrate Plus, Migrate Tools and Migrate Manifest). I followed the directions at this link: https://www.drupal.org/node/2350651 to prepare my manifest file. This is the relevant part of my resulting yaml file (truncated for brevity):
- block_content_body_field
- block_content_entity_display
- block_content_entity_form_display
- block_content_type
- d7_block
- d7_custom_block
When I ran the migrate-manifest via Drush, as specified by the directions in the link above, I received an error declaring a parse error pointing to the first line in the yaml list. This is the exact error: Unable to parse at line 1 (near " - block_content_body_field").
I tried several debugging steps:
I checked a yaml linter to see whether my file was properly formatted. My file passed the test.
I moved the block migrations below the ones that are prefixed with a 'd7' to match the example in the link.
I attempted a piecemeal migration of a file from my list of migrations, it worked.
I tried to alter the spacing on the list items.
All these steps failed to resolve the issue I am seeing.
I am unsure what other debugging steps I should take. All the above failed to resolve my issue.
Any ideas would be appreciated.
I have 2 project on my server with the same configuration(Symfony, MopaBootstrapBundle with Sass).
One works perfect, but it use elder version of Assetic bundle(2.1).
And the second(with Assetic bundle v.2.3) breaks the server with this message in error.log:
[error] child died with signal 11
and css is not compiled.
I have compared two versions of the bundle and found that SassFilter class in the newer version use "goto" operator.
I tried to change it on "break 3" (this has the same logic in this particular method) and everithing works fine.
I searched throw the project and found 2 goto labels with the same name (one in the SassFilter and the other in the LessFilter), but I think that is not the problem because I don't use LessFilter and thanks to lazy loading it souldn't load.
So I googled the issue and didn't find any notices of this problem. May be I should check my server configuration (I have apache2) in order to work properly with "goto"?
Thanks in advance for any help.
We're switching from one to two Zope instances for our productoin Plone deployment. I have the following buildout structure defined:
buildout.cfg
[buildout]
extends = app.cfg
... some environment specific stuff
app.cfg
[buildout]
extends = base.cfg
parts =
zope2
productdistros
instance1
instance2
zopepy
supervisor
[instance1]
<= instance
http-address = 18081
[instance2]
<= instance
http-address = 18082
base.cg
[buildout]
parts =
zope2
productdistros
instance
zopepy
... bulk of buildout configuration suitable for both server and development
Testing this I'd expect this buildout configuration to result in the existing instance part to be deleted and replaced with instance1 and instance2. However the instance part is not deleted - it can still be found in bin and parts directory.
[zopetest#dev home]$ bin/buildout
Updating zope2.
Updating fake eggs
Updating productdistros.
Updating instance1.
Updating instance2.
Updating instance.
Updating zopepy.
Updating supervisor.
I have a very similar set-up on a different zope instance that was configured this way from the start and it has no "instance" part.
We're running zc.buildout 1.4.4 with Python 2.4.6 building Plone 3.3.6.
I've tried the following with no change:
* upgrading to buildout 1.5.2
* removing the parts assignment from base.cfg
This is a "feature" of plone.recipe.zope2instance. Traditionally the recipe has avoided removal of the instances and scripts it creates for running plone (for whatever reason: either poor design or deliberate decision, I am not sure).
For whatever it is worth, as of version 4.2.0 there is support for generating non-plone scripts (similar to zc.recipe.egg) and those scripts are managed properly. See:
https://github.com/plone/plone.recipe.zope2instance/blob/master/src/plone/recipe/zope2instance/init.py#L119
for all the gory details. (I believe the "feature" is that the install method does not return a tuple, unless you are using scripts in which case a tuple containing the scripts is returned.)
This was in fact due to the zc.buildout automatic part selection feature
When a section with a recipe is referred to, either through variable substitution or by an initializing recipe, the section is treated as a part and added to the part list before the referencing part
I had the following section
[zopepy]
# For more information on this step and configuration options see:
# http://pypi.python.org/pypi/zc.recipe.egg
recipe = zc.recipe.egg
eggs = ${instance:eggs}
As it referenced the “instance” section “instance” was included in the list of parts.
To fix I changed it to copy-paste the eggs value of instance
eggs =
Plone
${buildout:eggs}
and then ran bin/buildout
I am trying to find a tool that will extract the module version information (a part of the module record) fron an Xserver module. For example, in the Xorg logs I can see the following information for the librecord module in my Xorg.0.log file...
[ 39.892] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 39.905] (II) Module record: vendor="X.Org Foundation"
[ 39.905] compiled for 1.9.0, module version = 1.13.0
[ 39.905] Module class: X.Org Server Extension
[ 39.905] ABI class: X.Org Server Extension, version 4.0
Is there a tools that would allow me to easily extract the aforementioned information. Sometimes you can use modinfo on the module and that will have version information, but that does not always work. The only consistent way I know of now is to parse the xorg log file. Thanks.
Yes, there is and you can also try to write a small one.
http://gitorious.org/xdriverprobe
The problem is that xdriverprobe won't compile on newer servers since I didn't update it to the newest ABIs. Also, xdriverprobe is only used for video drivers, but it can be adapted to be used on other modules. The main source code file (xdriverprobe.c) has less than 500 lines, so you can easily learn by reading it.
It works in Ubuntu 11.10... ./xdriverprobe -o moduledata gives the information you want.
Look at its source code. It does:
dlopen() the module
find a symbol called modulenameModuleData (if your module is called modulename)
that symbol is a XF86ModuleData* See /usr/include/xorg/xf86Module.h
check its member named vers
Spend a few hours and you'll be able to write a very tiny code that does what you want.
More information: http://www.xfree86.org/current/DESIGN17.html#65 (very old document, but most of what's written there is still true today). If you're not happy with that document, you have to read the Xorg source code.
Happy hacking!