linux-um archives
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade@yahoo.it>
To: Henrik Nordstrom <uml@hno.marasystems.com>
Cc: Rob Landley <rob@landley.net>,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: merge status
Date: Sun, 20 Nov 2005 17:32:44 +0100	[thread overview]
Message-ID: <200511201732.45180.blaisorblade@yahoo.it> (raw)
In-Reply-To: <Pine.LNX.4.61.0511200029570.16557@filer.marasystems.com>

On Sunday 20 November 2005 00:40, Henrik Nordstrom wrote:
> On Fri, 18 Nov 2005, Rob Landley wrote:
> > was going on.  (And #2 was the case: once I found out it was the 0 length
> > files, I could fix that.  I didn't expect 0 length files screwing up the
> > #include search paths.  The #include search paths are confusing, I'm
> > still a bit fuzzy on the difference between include and include2,
> > actually...)

> 0-length files after patching is generally due to slightly incorrectly
> formatted patches, and can screw up a lot of things.

> From the patch man page:

>    you can remove a file by sending out a context diff that compares
>    the file to be deleted with an empty file dated the Epoch.  The
>    file will be removed unless patch is conforming to POSIX and the
>    -E or --remove-empty-files option is not given.

> A few other formats also works, but what is said above is the safest patch
> format for removal of files.

> If you find patches which removes files using a format not complying with
> the above then it may be wise to ask the person who published the patch to
> change his routines to make correctly formatted patches. On the sad side
> there is a number of widespread tools not generating such patches
> correctly (CVS is one.. have a cleanpatch script at devel.squid-cache.org
> fixing this and a few other CVS diff -u stupidities)

Hmm, quilt, git (and IIRC BitKeeper) don't comply with the above format, but 
they use /dev/null and it seems to work in practice. Jeff's version of quilt 
seems to be broken on this (he said he's using 0.32).

> Regarding the include path, Compliers, make etc just searches their paths
> until a file is found, no attempt in verifying the validity of the file is
> made. If the found file is empty then in the input at that stage is
> empty, and if the actual file which was supposed to be found is in a later
> element in the search path then you get screwed.

This case is a little different as I already explained...

In this case the 0-lenght file, when missing, would trigger make "building 
it" (i.e. creating it as a symlink with correct content).


-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2005-11-20 16:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051109133558.513facef.akpm@osdl.org>
     [not found] ` <20051109150141.0bcbf9e3.akpm@osdl.org>
     [not found]   ` <Pine.LNX.4.64.0511091547160.4627@g5.osdl.org>
2005-11-16 13:36     ` [uml-devel] Re: merge status Rob Landley
2005-11-18  7:08       ` Blaisorblade
2005-11-18  7:17         ` Rob Landley
2005-11-18  7:51           ` Blaisorblade
2005-11-18  8:41             ` Rob Landley
2005-11-19  2:33               ` Blaisorblade
2005-11-19  3:26                 ` Rob Landley
     [not found]                   ` <87hda65mbv.fsf@amaterasu.srvr.nix>
2005-11-21 14:51                     ` Rob Landley
2005-11-21 19:41                       ` Nix
2005-11-19 23:40               ` Henrik Nordstrom
2005-11-20 16:32                 ` Blaisorblade [this message]
2005-11-18 23:52           ` Jeff Dike
2005-11-18 23:37             ` Rob Landley
2005-11-19  0:55               ` Jeff Dike
2005-11-19  0:06                 ` Rob Landley
2005-11-30 17:23                 ` Michael Richardson
2005-12-02  0:15                   ` Blaisorblade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511201732.45180.blaisorblade@yahoo.it \
    --to=blaisorblade@yahoo.it \
    --cc=rob@landley.net \
    --cc=uml@hno.marasystems.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox