linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Scott James Remnant <scott@ubuntu.com>
Cc: Karel Zak <kzak@redhat.com>,
	linux-ext4@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: [PATCH] blkid: add --disable-libblkid (v2)
Date: Wed, 29 Apr 2009 16:54:58 -0400	[thread overview]
Message-ID: <20090429205458.GA24749@mit.edu> (raw)
In-Reply-To: <1241025728.16780.21.camel@quest>

Scott, thanks for submitting these patches.   Two quick comments:

1) It's greatly preferred if you submit each patch as separate e-mail
messages, with the one-line summary as the subject (as you might find
in a git submission or as described in sections 5.4 and 5.5 in the file
Documentation/development-process/5.Posting in the Linux kernel sources).
The reason for this is that the patchs will then be tracked in patchwork:

    http://patchwork.ozlabs.org/project/linux-ext4/list/

and if it's accurately reflected there, it's much less likely that I
won't accidentally forget to act on your patches, especially when I
get busy/overloaded.  The best thing to do is to use "git
format-patch" (which you apparenlty did to generate the patch), and
then use "git send-email" to send out the patches.

I find that this is in fact the fastest way for me to do work.  So
after I commit two patches, I'll do something like this:

rm -rf /tmp/p
git format-patch -n -o /tmp/p -2
git send-email --to linux-ext4@vger.kernel.org /tmp/p

(and in fact I have an aliases file configured in ~/.gitconfig, so I
have sendemail.aliasesfile=/home/tytso/.mutt/aliases and
sendemail.aliasfiletype=mutt, in which case all I have to type is:
"git send-email --to linux-ext4 /tmp/p")

2) While lsb_release is mandatory on Ubuntu systems (there is a
dependency from ubuntu-minimal), it is not guaranteed to exist on
Debian systems.  So how I already test for Ubuntu in the rules file is
via this construct:

	if test -f /etc/lsb-release && \
		grep -q DISTRIB_ID=Ubuntu /etc/lsb-release; then \
	$(INSTALL) -p -m 0644 e2fsck/e2fsck.conf.ubuntu \
       		${debdir}/e2fsprogs/etc/e2fsck.conf; \
	fi

Hmm, one of these days I should probably check and see if Ubuntu
finally fixed the installer and init scripts breakage which forced me
to set a special e2fsck.conf file just for Ubuntu.  (See git commit
60702c26 in the e2fsprogs repository for more details.)

But in any case, I'd suggest checking for Ubuntu using the above
construct instead of trying to use the lsb_release command, since it's
not guaranteed to be there on Debian systems.

3) In the "nice to have" category, it would be nice if whether or not
blkid is built is controled via DEB_BUILD_OPTIONS flag instead of a
free-standard environment variable, but I won't insist on that.

					- Ted

  reply	other threads:[~2009-04-29 20:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23 17:38 uti-linux-ng libblkid Karel Zak
2009-02-23 17:38 ` [PATCH] blkid: add --disable-libblkid to build with external libblkid Karel Zak
2009-02-24  8:44   ` [PATCH] blkid: add --disable-libblkid (v2) Karel Zak
2009-03-24 12:11     ` Scott James Remnant
2009-04-16 10:22       ` Karel Zak
2009-04-17 13:36         ` Kay Sievers
2009-04-17 13:48         ` Scott James Remnant
2009-04-22 13:33           ` Theodore Tso
2009-04-22 13:42             ` Scott James Remnant
2009-04-22 13:49               ` Theodore Tso
2009-04-22 14:07                 ` Scott James Remnant
2009-04-29 17:22                 ` Scott James Remnant
2009-04-29 20:54                   ` Theodore Tso [this message]
2009-05-05 11:30                     ` Scott James Remnant
2009-04-27  9:21             ` Karel Zak
2009-04-28 20:36               ` Karel Zak
2009-04-29 13:59             ` Scott James Remnant
2009-04-29 17:17               ` Theodore Tso
2009-04-29 20:23         ` Theodore Tso
2009-04-30  8:28           ` Karel Zak
2009-02-23 17:38 ` [PATCH] tune2fs: make findfs code optional Karel Zak
2009-03-09  1:08 ` uti-linux-ng libblkid Theodore Tso
2009-03-09 10:42   ` Karel Zak
2009-03-09 11:45   ` Karel Zak
2009-03-18 19:28   ` Karel Zak

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=20090429205458.GA24749@mit.edu \
    --to=tytso@mit.edu \
    --cc=kay.sievers@vrfy.org \
    --cc=kzak@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=scott@ubuntu.com \
    /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;
as well as URLs for NNTP newsgroup(s).