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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Seen the same while maintaining the issue queue for D6.

boombatower’s picture

I 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.

chaps2’s picture

Still broken.

webchick’s picture

Priority: Normal » Critical

This seems fairly critical..?

Kars-T’s picture

I 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?

boombatower’s picture

Tested using the following code.

require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

header('Content-Type: text/plain');
module_load_include('review.inc', 'pifr_client');
$test = array( /* Information copied from qa.d.o */ );

$review = pifr_client_review_load($test);
if ($review) {
  $review->run();
}
print_r($review->get_result());

and I cannot reproduce this.

boombatower’s picture

Test 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.

boombatower’s picture

Seems 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.

Gábor Hojtsy’s picture

I 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!

boombatower’s picture

Status: Active » Needs review
FileSize
1.04 KB

This 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.

Gábor Hojtsy’s picture

Ah, hah, that sounds like a problem indeed.

jhodgdon’s picture

I 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.

jhodgdon’s picture

Status: Needs review » Needs work
boombatower’s picture

Status: Needs work » Needs review

This 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.

jhodgdon’s picture

Ah. Sorry for the misunderstanding, and thanks for working on it! :)

boombatower’s picture

Project: Drupal.org infrastructure » Project Issue File Review
Version: » 6.x-2.x-dev
Component: qa.drupal.org » Code
Assigned: Unassigned » boombatower
boombatower’s picture

Proper 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.

Status: Needs review » Needs work

The last submitted patch, 961172-drupal-6-dependencies.patch, failed testing.

boombatower’s picture

Should fail since 2.2-hotfix isn't made for HEAD and other has already been committed + a followup.

rfay’s picture

So 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

boombatower’s picture

Just http://drupal.org/files/issues/961172-2.2-hotfix_0.patch applied to the codebase currently being used (assume straight 2.2 tag?).

boombatower’s picture

Promising 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.

hanoii’s picture

Subscribing.. if interested, this one's failing too: #234377: tableheader.js: breaks on Drupal.attachBehaviors()

dpovshed’s picture

Friends,

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

jhodgdon’s picture

denikin: 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!

dpovshed’s picture

Thank you jhodgdon, it is a great relief for me! I'll keep an eye on this thread...

chaps2’s picture

@denikin, you won't be the only one....

Eric_A’s picture

Title: All D6 patches are failing » Some core D6 patches are being tested and are failing

Is 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.

jhodgdon’s picture

Title: Some core D6 patches are being tested and are failing » All D6 patches are failing

The 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.

Eric_A’s picture

If 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.

Eric_A’s picture

When 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?

rfay’s picture

jhodgdon’s picture

RE #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.

Kars-T’s picture

I 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?

jhodgdon’s picture

Yes, this is the same issue - you are having the exact same symptoms reported here.

boombatower’s picture

FileSize
1.05 KB

Haven'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.

beefzilla’s picture

Yea, that would be great. I have a patch waiting on this. Wonder how many others do too.

jonathan1055’s picture

Subscribing. 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.

salvis’s picture

Is there anyone out there? -- Like, anyone who can get this fixed?

rfay’s picture

Yes, 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

salvis’s picture

Hey 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!

rfay’s picture

Title: All D6 patches are failing » All D6 Core patches are failing

The problem here is with patches against Drupal core (D6). I thought the complaint was about all D6 contrib.

boombatower’s picture

#37 should solve issue, or update to HEAD.

jonathan1055’s picture

Status: Needs review » Needs work

@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

salvis’s picture

I 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.

drewish’s picture

I'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.

rfay’s picture

Status: Needs work » Needs review
FileSize
2.72 KB

I 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.

rfay’s picture

I 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

jhodgdon’s picture

Here 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.

rfay’s picture

Status: Needs work » Needs review
rfay’s picture

Status: Needs review » Fixed

Yay. These named patches seem to be OK now.

webchick’s picture

YES!!! Thank you SO much for fixing this, guys!! :D

Kars-T’s picture

Thank you so much! :D

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.