I have an issue with composer update that creates /b directory in my project, I found some answers that suggested to set composer patchLevel to -p2. It works and fix my issue,
so what it means really and what is the difference between patchLevel -p1, -p2 ,-p0 and -p4?
PatchLevel is for a specific release of a given major revision. The first release would be patch level 0. As bugs are fixed, each new releases would have a higher patch level number. If the patch level is the letter "x", it indicates a development snapshot (see [-Extra] immediately below for more information).
Drupal docs.
Or translated, it's minor following semantic versioning where
<major> "." <minor> "." <patch>
in your (Drupal's) case semver's minor is Drupal's patchLevel
Related
A recent update (of either MinTTY/MSYS2/bash or sbt) started breaking the output of sbt such that control characters are appearing instead of displaying rich text output in the terminal:
From the image you can see that rich text does still work as can be seen from my prompt line, but sbt started showing control characters like ←[0m[.
I'm on windows 11 and it was working perfectly fine last week, and my TERM terminal setting is set to xterm.
After some searching, I found these two posts:
https://github.com/gradle/gradle/issues/13279
https://youtrack.jetbrains.com/issue/IDEA-247532
both suggesting that I should try setting my TERM to cygwin but this did not solve the issue.
Question
How can I isolate where the issue is happening? I highly suspect it's an internal sbt update because the version it's indicating is 1.6.0 but the version I installed was 1.4.4 last year. I just tried uninstalling it and installing 1.6.2 via the installer but the issue still persists.
Does anyone have a solution to this issue? Is it a general thing that affects certain CLIs? From the links above it looks like it used to impact gradle as well.
Looks like it was MinTTY or MSYS2 because an update of those fixed the issue.
Working version of MSYS2:
$ cat /proc/version
MINGW64_NT-10.0-19044 version 3.3.5-341.x86_64 (#WIN-MG5BEJ9M9JD) (gcc version 11.3.0 (GCC) ) 2022-07-08 09:41 UTC
and MinTTY:
I'm trying to require the bundle in my Symfony project: FOSUserBundle. But it doesn't work, apparently I have to increase the memory_limit. But I can't make it work.
I've already tried to look for the php.ini file to change the memory_limit. But there is no php.ini file in my Symfony project. Why is it not there? Have I forgotten to install something? And if I want to add it manually, where can I put it? There are PHP.INI files in the MAMP folder. I've tried to change the memory_limit value, doesn't help.
And I've tried to run this in the terminal after navigating to the right project folder: php -d memory_limit=2G composer update.
The reaction I get is more or less this:
Nothing to install or update
Generating autoload files
Incenteev\ParameterHandler\ScriptHandler::buildParameters
Updating the "app/config/parameters.yml" file
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
Here is the error I get after trying to require the bundle:
Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in...
As you might see, I'm new to Symfony and Composer. Can you please help me out?
Thanks in advance!
There are a few things which will help a lot.
Ensure you are running the latest version of Composer.
Ensure you are running at least a recent version of PHP - version 7 improved the memory use substantially - sometimes halving the amount of memory used. Versions 7.2 or (better) 7.3 should be the versions being used now (summer 2019).
Actively limit the number of different versions of packages that Composer must check to see what could be valid to use.
Roave/SecurityAdvisories is a good start. This will also stop you installing versions of packages that have known security issues. It will also limit the search-space for valid packages, allowing Composer to ignore large swathes of possible packages, meaning that it does not need to hold large amounts of data for the various potential combinations.
You can add other versions of packages to further narrow the search-space. For example, you may have a number of wildcard "*" versions (also known as 'The Death Star Version Constraint') - which are almost always a bad idea. Mostly, a version number of the form "^3.4" or "^4.3" would be better - allowing upgrades from bug-fix versions and features (the 3rd and 2nd numbers), but not major versions, which can often contain breaking changes.
I solved it by setting the composer_memory_limit in the composer.json file under the 'config' part:
"COMPOSER_MEMORY_LIMIT": "2G"
i was trying to build "brackets sprint 40" from source code (by following #jasonsanjose instructions look #4816 and the official wiki's page here) in my 32bit Wheezy, Using CEF3 (Verion 3.1547.1406_linux32_release with glibc 2.13) and everything was OK .
when i ran grunt build and grunt installer the output was: Running "build" task
Running "build-linux" task
Done, without errors.
and when i installed .deb package and executed it in the terminal , this error has been thrown:brackets: libcef_dll/wrapper/libcef_dll_wrapper.cc:120: int CefExecuteProcess(const CefMainArgs&, CefRefPtr): Assertion `false' failed.
Aborted
I did rebuild it many times, but the problem persist.
And this is where i stopped, i don't know where the problem lies.
some help will be appreciated, thank you in advance.
There's a duplicate of this question with longer discussion posted here - https://github.com/adobe/brackets/issues/8170.
Note: This problem shouldn't affect a "vanilla" brackets-shell build on Linux -- it's specific to a hack some people have developed to support an older version of Debian than Brackets officially supports. This requires swapping in a newer version of the CEF library, which is not always easy to do since they are not usually backwards-compatible.
I'm running a Capifony deployment. However, I notice that Capifony's in-built commands are running against the previous release, whereas my custom commands are correctly targeting the current release.
For example, if I run cap -d staging deploy, I see some commands output like this (linebreaks added):
--> Updating Composer.......................................
Preparing to execute command: "sh -c 'cd /home/myproj/releases/20130924144349 &&
php composer.phar self-update'"
Execute ([Yes], No, Abort) ? |y|
You'll see that this is referring to my previous release - from 2013.
I also see commands referring to this new release's folder (from 2014):
--> Running migrations......................................
Preparing to execute command: "/home/myproj/releases/20140219150009/
app/console doctrine:migrations:migrate --no-interaction"
Execute ([Yes], No, Abort) ? |y|
In my commands, I use the #{release_path} variable, whereas looking at Capifony's code, it's using #{latest_release}. But obviously I can't change Capifony's code.
This issue against Capistrano talks about something similar, but I don't think it really helps, as again I can't change Capifony's code.
If I delete my releases folder on the server, I have a similar problem - #{latest_release} doesn't have any value, so it attempts to do things like create a folder /app/cache (since the code is something like mkdir -p #{latest_release}/app/cache).
(Assuming I don't delete the current symlink and the release folder, the specific error I see is when it fails to copy vendors: cp: cannot copy a directory, /home/myproj/current/vendor, into itself. However, this is just the symptom of the bigger problem - if it thinks the new release is actually the previous one, that explains why current also points there!)
Any ideas? I'm happy to provide extracts from my deploy.rb or staging.rb (I'm using the multistage extension) but didn't just want to dump in the whole thing, so let me know what you're interested in! Thanks
I finally got to the bottom of this one!
I had a step set to run before deployment:
before "deploy", "maintenance:enable"
This maintenance step (correctly) sets up maintenance mode on the existing site (in the example above, my 2013 one).
However, the maintenance task was referring to the previous release by using the latest_release variable. Since the step was running before deployment, latest_release did indeed refer to the 2013 release. However, once latest_release has been used, its value is set for the rest of the deployment run - so it remained set to the 2013 release!
I therefore resolved this by changing the maintenance code so that it didn't use the latest_release variable. I used current_release instead (which doesn't seem to have this side-effect). However, another approach would be to define your own variable which gets its value in the same way as latest_release would:
set :prev_release, exists?(:deploy_timestamped) ? release_path : current_release
I worked out how latest_release was being set by looking in the Capistrano code. In my environment, I could find this by doing bundle show capistrano (since it was installed with bundler), but the approach will differ for other setups.
Although the reason for my problem was quite specific, my approach may help others: I created an entirely vanilla deployment following the Capifony instructions and gradually added in features from my old deployment until it broke!
Very new to setting up Plone 4 and trying to integrate Solgema.fullcalendar but when running buildout I get an error saying it needs zope.schema 3.6.0 and I have 3.5.4. I cannot for the life of me work out how to update it. I assume I am missing something fundamental here but it is doing my head in as I imagine as I will encounter this kind of issue again and again as I progress.
" Installing instance.
Error: There is a version conflict.
We already have: zope.schema 3.5.4
but z3c.form 2.4.2 requires 'zope.schema>=3.6.0'."
Looked around and noticed that putting zope.schema>=3.6.0 in eggs might work but that didn't actually trigger an update just caused a bad install error.
If anyone has any ideas or needs something more to go on please let me know!
Thanks
Chris
If you want to use z3c.form inside Plone, best update to Plone 4.1 which is currently available as a release candidate. 4.1 comes with z3c.form in it and has the newer zope.schema version.
In the general case you will need to have a versions section in your buildout configuration in which you can specify exact version requirements for all distributions you want.
[buildout]
extends = ...
versions = versions
[versions]
zope.schema = 3.6.0
Inside the setup.py files you should never specify exact version requirements. Only put minimum requirements into these if your specific library absolutely requires a new feature from another library.
See Hanno's answer. I will add that I cannot think of a good reason anymore to use '>=' (or '<=' or '==') to specify minimum, maximum or exact versions anywhere in a buildout config. Version specifications should only be in a [versions] section. It has been a while since I last used a buildout config that used the comparison operators, but I remember it could lead to problems, especially when upgrading; the only way out would at times be to remove the '.installed.cfg' file to make bin/buildout run in a fresh state.
(Note that '>=' in a setup.py is perfectly fine.)