Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There are some components not explicitly listed in our composer.json file that where not upgraded to 2.7.0. Also somehow the console and translation component was upgraded only to the beta release.
Comment | File | Size | Author |
---|---|---|---|
#12 | update_additional-2498515-12-interdiff.txt | 223 bytes | Berdir |
#12 | update_additional-2498515-12.patch | 146.26 KB | Berdir |
#1 | update_additional-2498515-1.patch | 166.4 KB | neclimdul |
Comments
Comment #1
neclimdulPatch.
I had to add .exe to .gitattributes to get git to stop complaining. It seems the binary might have had converted line endings in the previous patch.
Comment #2
neclimdulComment #3
webchickGood catch. This seems like something we can't ship with, so escalating to critical.
Comment #4
dawehnerOh packageist.org--
Comment #5
neclimdulFor reference, I've been watching it here. Much easier then trying to parse composer.lock manually.
https://www.versioneye.com/user/projects/54cbab50fb6ebae9240000fa#tab-de...
Comment #6
dawehnerOh, that is a super helpful website!
Comment #7
webchickOk, in the spirit of #2470693-80: Upgrade to Symfony 2.7.0, getting this in sooner than later so we can uncover any bugs it introduces. Encouraging to see a passing test suite, though! :)
Committed and pushed to 8.0.x. Thanks!
Comment #10
alexpottThis file has not changed in three years - and whatever changed here stopped me, dawehener and wimleers from working. Not sure what is going on here. Obviously the problem could be with the original console patch or my original commit. But I've reverted for now to allow us to continue working.
If you are stuck on the commit and can't do
git pull
because of the changes doinggit reset HEAD~4 --hard
and thengit pull
works.Comment #11
alexpottSo it does indeed look like the original patch is the problem :(
Not sure how to proceed. @neclimdul what did you add to .gitattributes?
Comment #12
BerdirAs discussed.
It looks like there are two things that could be done in .gitattributes.
a) removing the default eol=lf option
b) Add .exe to the explicit list of binary files.
Seems like b) is better for a quick-fix, since that's consistent with how we deal with other binary files but we should probably re-visit that default option in a separate issue. People might be adding binary files that don't match one of the explicit file endings in custom projects and this could mess that up badly?
My patch seems to be a lot smaller, but it should be the same, I just reverted the revert and then a git diff of that..
Comment #13
neclimdulThe exe file hadn't changed in 3 years but did not match the one in our repository. To confirm this I downloaded the file directly from github and compared it. That is why I changed it.
Comment #14
alexpottThanks everyone.
Comment #15
neclimdulSorry, I was just talking to alex and I mentioned the gitattribute problems I had in #1 but clearly it is not in my patch. Many apologies. :(
Comment #17
dawehnerBetter do mistakes than don't do something! It is always helpful to make such errors so you can learn about them.