Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I had several D6 patches in my issue queue that suddenly decided to be tested by qa.drupal.org in the last 12 hours, and all of them failed with the same "cannot apply patch" error, although the patches all apply fine. Here's an example from the log:
[10:09:06] Command [patch -p0 -i /var/lib/drupaltestbot/sites/default/files/review/942718-d6-2.drupal.docs-drupal_get_form-params-stash.patch 2>&1] failed with status [1] and output:
can't find file to patch at input line 8
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: includes/form.inc
|===================================================================
|RCS file: /cvs/drupal/drupal/includes/form.inc,v
|retrieving revision 1.265.2.34
|diff -u -p -r1.265.2.34 form.inc
|--- includes/form.inc 6 Aug 2010 11:02:49 -0000 1.265.2.34
|+++ includes/form.inc 20 Oct 2010 17:35:08 -0000
--------------------------
Here are several specific test runs that failed:
http://qa.drupal.org/pifr/test/103249
http://qa.drupal.org/pifr/test/79784
http://qa.drupal.org/pifr/test/99369
http://qa.drupal.org/pifr/test/101864
Comment | File | Size | Author |
---|---|---|---|
#48 | pifr.d6_core_patches_failing.patch | 2.72 KB | rfay |
#37 | 961172-2.2-hotfix.patch | 1.05 KB | boombatower |
#18 | 961172-2.2-hotfix.patch | 879 bytes | boombatower |
#18 | 961172-drupal-6-dependencies.patch | 1.12 KB | boombatower |
#11 | 961172-2.2-hotfix.patch | 1.04 KB | boombatower |
Comments
Comment #1
Gábor HojtsySeen the same while maintaining the issue queue for D6.
Comment #2
boombatower CreditAttribution: boombatower commentedI have seen this as well...almost seems like the checkout doesn't work properly...I'll try and look into this in the next few days.
Comment #3
chaps2 CreditAttribution: chaps2 commentedStill broken.
Comment #4
webchickThis seems fairly critical..?
Comment #5
Kars-T CreditAttribution: Kars-T commentedI fear that a lot people may try rewriting their patches because they believe it's their fault and waste time.
If this takes longer maybe someone could provide some kind of message or information to the devs?
Comment #6
boombatower CreditAttribution: boombatower commentedTested using the following code.
and I cannot reproduce this.
Comment #7
boombatower CreditAttribution: boombatower commentedTest bots, qa.drupal.org, and my local (HEAD) are all different versions and I see very different results. I'll see if I can ensure latest code is stable and see if we can get full update of everything and this bug should disappear.
One issue with the different versions is the defaults passed from server to workers may not match up right and could cause this and other interesting issues.
Comment #8
boombatower CreditAttribution: boombatower commentedSeems I have a bit to review and double check before update (http://drupalbin.com/16674)...I think it would be best if I get a few other issues in with this one before the update. Since I changed the argument values around this will require a tweak to pift...would be cool to get .info patch in with that as well..hmm. Seems like updates to d.o stuff are a pain so I'd rather get this all in one, but ensure it all works will require a bit of work.
Comment #9
Gábor HojtsyI understans you'd like to have a bunch of other fixes in as well, but this is not a nice to have, this is a critical problem with the issue queues for Drupal 6!
Comment #11
boombatower CreditAttribution: boombatower commentedThis patch is against 2.2. I'll commit a modified version to HEAD. Since the code adds SimpleTest as a dependency for Drupal 6 it thinks it is testing a contrib project and cd's to the modules directory when attempting to apply the patch.
Comment #12
Gábor HojtsyAh, hah, that sounds like a problem indeed.
Comment #13
jhodgdonI was going to re-launch a failed (or passed) past test and see what happens... ran into:
#973432: D6 patches named -D6 are not tested
which is a new issue (I filed it in the PIFT queue, hope that's OK).
I found an issue with a test that had failed with this, and relaunched it:
#488166: Search relevance calculation fails if last_comment_timestamp is NULL
specifically, the patch at
http://drupal.org/node/488166#comment-3339748
I'll report back when the test is done.
Comment #14
jhodgdonNo, it didn't work
http://qa.drupal.org/pifr/test/79784
Comment #15
boombatower CreditAttribution: boombatower commentedThis has not been deployed yet so it should still fail for Drupal 6.x core patches only. Need to get the test workers updated which isn't the simplest thing to do. Multiple people involved....stopping and starting stuff...lots of fun.
EDIT: Cross-post on status, but probably better since it wasn't expected to work on production.
Comment #16
jhodgdonAh. Sorry for the misunderstanding, and thanks for working on it! :)
Comment #17
boombatower CreditAttribution: boombatower commentedComment #18
boombatower CreditAttribution: boombatower commentedProper patch against HEAD (committed).
It occurred to me the hotfix above will work for all projects except simpletest d6...so I fixed in the same style as HEAD.
Comment #20
boombatower CreditAttribution: boombatower commentedShould fail since 2.2-hotfix isn't made for HEAD and other has already been committed + a followup.
Comment #21
rfaySo if we're going to get this onto machines, we'll have to get the change into DamZ's puppet world. @boombatower, please prescribe exactly what you want.
-Randy
Comment #22
boombatower CreditAttribution: boombatower commentedJust http://drupal.org/files/issues/961172-2.2-hotfix_0.patch applied to the codebase currently being used (assume straight 2.2 tag?).
Comment #23
boombatower CreditAttribution: boombatower commentedPromising outlook for 2.3-dev...I seem to have squashed any issues with it.
Tests I could easily find and d6 core and patches.
http://qa.scratch.drupal.org/pifr/test/34
http://qa.scratch.drupal.org/pifr/test/78 (incorrect patch and thus doesn't find file)
http://qa.scratch.drupal.org/pifr/test/48 (attempt to apply correctly but patch is old)
http://qa.scratch.drupal.org/pifr/test/16784
Would like to see #972956: Update Drupal 7 installer to reflect installer form changes land before deployment, but I don't see any reason once we get fresh db update and do further testing, tomorrow hopefully, that we just updated to 2.3 and skip all the other fuss.
With updated data I will try the once listed at top of this issue.
Comment #24
hanoiiSubscribing.. if interested, this one's failing too: #234377: tableheader.js: breaks on Drupal.attachBehaviors()
Comment #25
dpovshed CreditAttribution: dpovshed commentedFriends,
I am a newbie in a patching system but not in Drupal itself.
Can anyone give me a hint - is there any chance that all my tries here - http://drupal.org/node/976426 - related to the discussed topic?
Thanks!
Dennis
Comment #26
jhodgdondenikin: Yes, that is what is causing your patches to fail on that issue. I am able to apply your patch without a problem. Sorry that your first experience patching ran into this issue!
Comment #27
dpovshed CreditAttribution: dpovshed commentedThank you jhodgdon, it is a great relief for me! I'll keep an eye on this thread...
Comment #28
chaps2 CreditAttribution: chaps2 commented@denikin, you won't be the only one....
Comment #29
Eric_A CreditAttribution: Eric_A commentedIs the D6 version tag really supposed to be doing anything for core these days? There is still a fairly simple "workaround". When this issue first appeared, I instructed some people to just rename their D6 patches (RTFM) and they were happy that the bot now ignored their D6 core patch, so that humans could review.
Maybe the way D6 contrib testing works has been confusing people, but for core patches the file name suffix was always the thing to do, right? Well, if you follow the instructions in the help text, it just works.
Comment #30
jhodgdonThe way things are now, if you want a patch to be tested (and we generally want patches to be tested -- D6, D7, etc.), you name it something.patch and it will be tested. If the issue is in the Drupal Core issue queue and the version is 6.x-dev, it should be tested against Drupal 6, and if the version is 7.x-dev, it should be tested against Drupal 7.
If you want any patch not to be tested, perhaps because you are attaching a D7 patch to a D6 issue or vice versa, you name it something-D#.patch, where # is a number, and it won't be tested. As stated in the help text for attachments: "For patches that apply specifically to a version of core other than the one the issue is pointing to, you can prefix the extension with -D(number) to prevent them from being queued for testing. For example, foo.patch and bar.diff would both be queued for testing, whereas foo-D5.patch and bar-D6.diff would not be queued for testing."
Saying this system should be bypassed for all D6 patches is incorrect. We do generally want them to be tested at least by the minimal amount of testing we have for D6, contrary to what is written in #29. But right now, the testing system is broken for D6, and all patches on D6 are failing tests. That is what this issue is about. Please leave the title as-is -- the title is accurate.
Comment #31
Eric_A CreditAttribution: Eric_A commentedIf the issue is in the Drupal Core issue queue and the version is 6.x-dev, it should be tested against Drupal 6
Core D6 has tests? I must have missed the announcement. I cannot find these tests. I have not seen a Core D6 issue where someone submitted a D6 test, either. I'll start digging, but this is just a Drupal WTF to me.
Comment #32
Eric_A CreditAttribution: Eric_A commentedWhen all this started, the help text was very different:
Only files ending in .patch or .diff will be sent for testing. For patches that apply specifically to Drupal 5 or Drupal 6, you can prefix the extension with -D5 or -D6 to prevent them from being queued for testing. For example, foo.patch and bar.diff would both be queued for testing, whereas foo-D5.patch and bar-D6.diff would not be queued for testing.
When did we get automated testing for D6 core patches?
Comment #33
rfayI don't think this is related, but #996512: D6 contrib project tests: [MySQL] Drupal installation failed..
Comment #34
jhodgdonRE #32: Can we keep this issue to discussing that D6 testing is currently failing? It was started quite a while ago, was working for quite a while, and suddenly started failing around when I filed this issue. The attach doc change and accompanying code change was discussed on a separate issue in the drupal.org webmasters or infrastructure queue, which I don't have in front of me at the moment.
Comment #35
Kars-T CreditAttribution: Kars-T commentedI just can't get any patch working in this issue. #357021: #after_build_done set after 1st after_build func was run
http://qa.drupal.org/pifr/test/119759
Is this releated to this issue or what am I doing wrong?
Comment #36
jhodgdonYes, this is the same issue - you are having the exact same symptoms reported here.
Comment #37
boombatower CreditAttribution: boombatower commentedHaven't had time to test this (busy next day or so), but this is same logic that was applied to HEAD and confirmed to work. If DamZ want to try applying the hotfix via the puppet server that would be great.
Comment #38
beefzilla CreditAttribution: beefzilla commentedYea, that would be great. I have a patch waiting on this. Wonder how many others do too.
Comment #39
jonathan1055 CreditAttribution: jonathan1055 commentedSubscribing. I have #292790: Menu machine-name validation error (The menu name can't be longer than 27 characters) waiting (and its been a long long time!). The issue started when we were at D6.3, it's been to D7, fixed there, and now back to D6.20
For those who are working to fix the testing bot, thank you.
Comment #40
salvisIs there anyone out there? -- Like, anyone who can get this fixed?
Comment #41
rfayYes, there are people out here. And we'll be sprinting at Drupalcon on Friday. Maybe we'll get this going.
But *not* all D6 patches are failing. If you have a specific patch you want me to look at, let me know and I'll chase it down.
-Randy
Comment #42
salvisHey Randy
Lots of us are desperately waiting for some movement with #113611: Forum count incorrect when using access control modules, since last June 1! My prior cry for help (#995452: Perfectly fine D6 patch keeps failing to be applied) was closed.
I suspect that having most D6 patches failing is a good excuse for letting them sit and rot...
Thanks a lot for looking into it!
Hans
P.S. I really appreciate your blog posts!
Comment #43
rfayThe problem here is with patches against Drupal core (D6). I thought the complaint was about all D6 contrib.
Comment #44
boombatower CreditAttribution: boombatower commented#37 should solve issue, or update to HEAD.
Comment #45
jonathan1055 CreditAttribution: jonathan1055 commented@rfay in #41 Thanks for the offer - could you look at #292790: Menu machine-name validation error (The menu name can't be longer than 27 characters)? This is very long-running thread (June 2008), which has been fixed in D7 and the correct very simple patch coded and tested for D6. The patch in that thread in #58, #63, #68 and #69 are all essentially the same, but we just need to see green not red as the result. I have just requested a re-test of the patch in #69 and it failed with the same 'non-applicable patch' problem.
Thanks very much for looking into this. Many folks on that thread will also appreciate it.
Jonathan
Comment #46
salvisI can't remember ever seeing any non-core D6 patches being picked up by the testbot, so the title may have been correct, but it's more to the point now.
Comment #47
drewish CreditAttribution: drewish commentedI'm not sure if people are still looking for examples of this but #1087092-11: Invalid @result in drupal_map_assoc() documentation seems to be getting tripped up by it.
Comment #48
rfayI think this should work fine now as soon as it's deployed. I won't mark it fixed until then.
Committed:
http://drupalcode.org/project/project_issue_file_review.git/commit/da266cd
What was happening was that the checkout of simpletest and related patch of core were treated like just any dependency, but it really is not the same as a dependency. I changed to make it handled explicitly inline.
Comment #49
rfayI would appreciate if any interested parties would test the current code in the staging environment.
Information about how to test is at http://groups.drupal.org/node/137189
Comment #50
jhodgdonHere are a couple of current d6 issues that have not been committed yet, and whose patches failed tests recently:
http://drupal.org/node/1087092#comment-4194424 (patch: http://drupal.org/files/issues/docs_1087092.patch)
http://drupal.org/node/1089332#comment-4196484 (patch: http://drupal.org/files/issues/1089332_at_see_doc_5.patch)
The patches there would be good candidates to test on the patched testing framework.
Comment #51
rfayRE: #50: These two patches seem fine:
http://rfay.redesign.devdrupal.org/node/1103679
http://rfay.redesign.devdrupal.org/node/1103680
Comment #52
rfayYay. These named patches seem to be OK now.
Comment #53
webchickYES!!! Thank you SO much for fixing this, guys!! :D
Comment #54
Kars-T CreditAttribution: Kars-T commentedThank you so much! :D