mailbox plugin demo

This page exists to keep the corresponding blog post shortish. The page after the title is produced from an MH directory (maildir and mbox also supported) with the directive [[!mailbox type="MH" path="blog/files/example-mhdir"]]

Start example mailbox

Date: Wed, 30 Jul 2008 10:51:44 +0200
From: "Jens Peter Secher" <address deleted>
Subject: pbuilder/pdebuild mini-howto (Was: Building a build environment)

2008/7/29 Richard Hurt <rnhurt@kangaroobox.com>:
> I am just getting started in Debian package building and I need to know if
> this idea is valid or if there is a better way.
> [...]
>  What do you use?

I find pbuilder easiest to work with.  Since I am mostly running
Testing, I have two setups, one for Sid and one for Backports.  Here is
a mini-howto for what to do.

Create a ~/deb/unstable-pbuilderrc:

  DISTRIBUTION="sid"
  BASETGZ="$HOME/var/pbuilder/$DISTRIBUTION-base.tgz"
  BUILDPLACE="$HOME/var/pbuilder/$DISTRIBUTION"
  MIRRORSITE="http://ftp.se.debian.org/debian"
  USEPROC="yes"
  USEDEVPTS="yes"
  USEDEVFS="no"
  BUILDRESULT="$HOME/var/presult"
  APTCACHE="/var/cache/apt/archives"
  APTCACHEHARDLINK="no"
  REMOVEPACKAGES="lilo grub"
  HOOKDIR=""
  export DEBIAN_FRONTEND="noninteractive"
  DEBEMAIL="Jens Peter Secher <jps@debian.org>"
  BUILDSOURCEROOTCMD="fakeroot"
  PBUILDERROOTCMD="sudo"
  DEBBUILDOPTS=""
  APTCONFDIR="$HOME/deb/apt.config"
  BUILDUSERID="1000"
  BINDMOUNTS=""
  DEBOOTSTRAPOPTS[0]='--variant=buildd'

And create a ~/deb/backports-pbuilderrc:

  DISTRIBUTION="etch"
  BASETGZ="$HOME/var/pbuilder/backports-base.tgz"
  BUILDPLACE="$HOME/var/pbuilder/backports"
  MIRRORSITE="http://ftp.se.debian.org/debian"
  OTHERMIRROR="deb http://www.backports.org/debian/
$DISTRIBUTION-backports main"
  USEPROC="yes"
  USEDEVPTS="yes"
  USEDEVFS="no"
  BUILDRESULT="$HOME/var/presult"
  APTCACHE="/var/cache/apt/archives"
  APTCACHEHARDLINK="no"
  REMOVEPACKAGES="lilo grub"
  HOOKDIR=""
  export DEBIAN_FRONTEND="noninteractive"
  DEBEMAIL="Jens Peter Secher <jps@debian.org>"
  BUILDSOURCEROOTCMD="fakeroot"
  PBUILDERROOTCMD="sudo"
  DEBBUILDOPTS=""
  APTCONFDIR="$HOME/deb/apt.config"
  BUILDUSERID="1000"
  BINDMOUNTS=""
  DEBOOTSTRAPOPTS[0]='--variant=buildd'

To stop apt complaining, create an
~/deb/apt.config/apt.conf.d/allow-unauthenticated:

  APT::Get::AllowUnauthenticated 1;

To give pbuilder a place to store its stuff, do

  mkdir -p ~/var/presults ~/var/pbuilder

To create the environments, do

  sudo pbuilder create --configfile ~/deb/unstable-pbuilderrc
  sudo pbuilder create --configfile ~/deb/backports-pbuilderrc

To build a new package, in your package directory
(eg. ~/deb/libfoo/libfoo-2.13/) you then just do

  pdebuild --configfile ~/deb/unstable-pbuilderrc

or to build a backport, use the -sa -v options:

  pdebuild --configfile ~/deb/backports-pbuilderrc --debbuildopts '-sa -v2.12-1'

To manually install dependencies in the environment, you can do

  sudo pbuilder login --configfile ~/deb/backports-pbuilderrc

and then manually copy (source) packages into the chroot.  To tweak
things in the environment in general, you can do

  sudo pbuilder login --save-after-exec --configfile ~/deb/unstable-pbuilderrc

To sponsor a package, use the -k option:

  pdebuild --configfile ~/deb/unstable-pbuilderrc --debbuildopts '-kFE63E8A1'

Remember to update the environments before building:

  sudo /usr/sbin/pbuilder update --configfile ~/deb/unstable-pbuilderrc

The resulting packages are placed in ~/var/presults, where you need to
sign them with debsign, which works best with GPG Agent running, so put
something like this in your .xsession file:

  if test -f $HOME/.gpg-agent-info && \
      kill -0 `cut -d: -f 2 $HOME/.gpg-agent-info` 2>/dev/null;
  then
      GPG_AGENT_INFO=`cat $HOME/.gpg-agent-info`
      export GPG_AGENT_INFO
  else
      eval `gpg-agent --daemon`
      echo $GPG_AGENT_INFO >$HOME/.gpg-agent-info
  fi


HTH,
-- 
                                                    Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 11:29:02 +0200
From: "markus schnalke" <address deleted>
Subject: Re: pbuilder/pdebuild mini-howto (Was: Building a build environment)

[2008-07-30 10:51] Jens Peter Secher <jps@debian.org>
> 2008/7/29 Richard Hurt <rnhurt@kangaroobox.com>:
> > I am just getting started in Debian package building and I need to know if
> > this idea is valid or if there is a better way.
> > [...]
> >  What do you use?
> 
> I find pbuilder easiest to work with.  Since I am mostly running
> Testing, I have two setups, one for Sid and one for Backports.  Here is
> a mini-howto for what to do.

Thanks for the howto, this looks useful.


One point I want to mention:
When I configured pbuilder some time ago, I couldn't manage to use
different locations than /var/cache/pbuilder when using
cowdancer/cowbuilder with it.
So I was not able to have chroots for different distributions.

But I haven't digged deeper in that, cause having only sid satisfied
me.


meillo

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Wed, 30 Jul 2008 12:39:26 -0700
From: "Don Armstrong" <address deleted>
Subject: Re: pbuilder/pdebuild mini-howto (Was: Building a build environment)

On Wed, 30 Jul 2008, markus schnalke wrote:
> When I configured pbuilder some time ago, I couldn't manage to use
> different locations than /var/cache/pbuilder when using
> cowdancer/cowbuilder with it.

You set BASEPATH instead of BASETGZ (or use --basepath instead of
--basetgz).


Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

http://www.donarmstrong.com              http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 08:26:58 +0200
From: "markus schnalke" <address deleted>
Subject: Re: pbuilder/pdebuild mini-howto (Was: Building a build environment)

[2008-07-30 12:39] Don Armstrong <don@debian.org>
> On Wed, 30 Jul 2008, markus schnalke wrote:
> > When I configured pbuilder some time ago, I couldn't manage to use
> > different locations than /var/cache/pbuilder when using
> > cowdancer/cowbuilder with it.
> 
> You set BASEPATH instead of BASETGZ (or use --basepath instead of
> --basetgz).

Thanks ... i'm gonna try this


meillo

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Wed, 30 Jul 2008 15:50:10 +0400
From: "Stanislav Maslovski" <address deleted>
Subject: ftp-masters

If a package has been uploaded to NEW, but has not been yet approved or
rejected by ftp-masters, and if this package has a mistake that is
better to be corrected before the package gets into unstable, then what
is the official procedure of doing such correction? 

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 14:53:14 +0300
From: "Eugene V. Lyubimkin" <address deleted>
Subject: Re: ftp-masters

Stanislav Maslovski wrote:
> If a package has been uploaded to NEW, but has not been yet approved or
> rejected by ftp-masters, and if this package has a mistake that is
> better to be corrected before the package gets into unstable, then what
> is the official procedure of doing such correction? 
> 
IANADD

As I know, just simply upload new revision of package. It will go into
NEW too, and ftp-masters will approve or reject latest upload of package

-- 
Eugene V. Lyubimkin aka JackYF

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

From: "Tobias Quathamer" <address deleted>
Subject: Re: ftp-masters
Date: Wed, 30 Jul 2008 14:04:46 +0200

On Wednesday 30 July 2008 13:50:10 Stanislav Maslovski wrote:
> If a package has been uploaded to NEW, but has not been yet approved or
> rejected by ftp-masters, and if this package has a mistake that is
> better to be corrected before the package gets into unstable, then what
> is the official procedure of doing such correction?

You can send an email to ftpmaster@d.o and ask them to REJECT your package 
now, without doing further checks and then upload again. You can even re-use 
the same version number then.

Regards,
Tobias

-- 
Tobias Quathamer | Every 4 seconds a woman has a baby.
Hamburg, Germany | Our problem is to find this woman and stop her.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

From: "Ben Finney" <address deleted>
Subject: Re: ftp-masters
Date: Wed, 30 Jul 2008 23:11:34 +1000

Tobias Quathamer <t.quathamer@gmx.net> writes:

> You can send an email to ftpmaster@d.o and ask them to REJECT your
> package now, without doing further checks and then upload again. You
> can even re-use the same version number then.

Though there's no good reason I can see to re-use a release number
after it's uploaded. It's not as though release numbers are a scarce
resource; just increment to the next one so there's no confusion
between the two.

-- 
 \         âDad always thought laughter was the best medicine, which I |
  `\    guess is why several of us died of tuberculosis.â âJack Handey |
_o__)                                                                  |
Ben Finney

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 15:15:48 +0200
From: "Sandro Tosi" <address deleted>
Subject: Re: ftp-masters

On Wed, Jul 30, 2008 at 15:11, Ben Finney <ben+debian@benfinney.id.au> wrote:
> Tobias Quathamer <t.quathamer@gmx.net> writes:
>
>> You can send an email to ftpmaster@d.o and ask them to REJECT your
>> package now, without doing further checks and then upload again. You
>> can even re-use the same version number then.
>
> Though there's no good reason I can see to re-use a release number
> after it's uploaded.

Because it never reach the archive, so it's better to keep the same
version for a REJECTED package: jumping revision is useless.

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 12:37:44 -0700
From: "Don Armstrong" <address deleted>
Subject: Re: ftp-masters

On Wed, 30 Jul 2008, Sandro Tosi wrote:
> On Wed, Jul 30, 2008 at 15:11, Ben Finney <ben+debian@benfinney.id.au> wrote:
> > Tobias Quathamer <t.quathamer@gmx.net> writes:
> >
> >> You can send an email to ftpmaster@d.o and ask them to REJECT your
> >> package now, without doing further checks and then upload again. You
> >> can even re-use the same version number then.
> >
> > Though there's no good reason I can see to re-use a release number
> > after it's uploaded.
> 
> Because it never reach the archive, so it's better to keep the same
> version for a REJECTED package: jumping revision is useless.

There's no reason not to increment the version. You've made a release,
and have made changes to that release. Whether it actually hits the
archive is immaterial. You just build with the appropriate -v option,
and you're done. Moreover, a new revision makes it easier for everyone
to follow what had changed between a version which was reviewed by the
ftpmasters and the next version that was uploaded.

There's nothing magical about the -1 version number.

Don Armstrong

-- 
She was alot like starbucks.
IE, generic and expensive.
 -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/001376.html

http://www.donarmstrong.com              http://rzlab.ucr.edu

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 22:34:38 +0200
From: "Cyril Brulebois" <address deleted>
Subject: Re: ftp-masters

Don Armstrong <don@debian.org> (30/07/2008):
> > Because it never reach the archive, so it's better to keep the same
> > version for a REJECTED package: jumping revision is useless.
> 
> There's no reason not to increment the version. You've made a release,
> and have made changes to that release. Whether it actually hits the
> archive is immaterial. You just build with the appropriate -v option,
> and you're done.

And when one checks in which revision this or that happened, that's
quite misleading not to see any upload in the archive matching those
revisions (yeah for QA work!).

> Moreover, a new revision makes it easier for everyone to follow what
> had changed between a version which was reviewed by the ftpmasters and
> the next version that was uploaded.

That was already discussed at length in another mentors.d.n thread
(other threads actually). Improving the mentoring system seems to be the
key (at least to me). Maybe Signum could post some report on his GSOC
debexpo project?

> There's nothing magical about the -1 version number.

There's no need to keep intermediate work-in-progress never-uploaded
not-matching-anything-in-the-archive revision.

Mraw,
KiBi.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Wed, 30 Jul 2008 14:08:57 -0700
From: "Don Armstrong" <address deleted>
Subject: Re: ftp-masters

On Wed, 30 Jul 2008, Cyril Brulebois wrote:
> Don Armstrong <don@debian.org> (30/07/2008):
> > There's no reason not to increment the version. You've made a
> > release, and have made changes to that release. Whether it
> > actually hits the archive is immaterial. You just build with the
> > appropriate -v option, and you're done.
> 
> And when one checks in which revision this or that happened, that's
> quite misleading not to see any upload in the archive matching those
> revisions (yeah for QA work!).

In QA work you're always comparing revisions. There's no difference
between dealing with versions which skipped the archive because they
were QAed elsewhere, or versions which are no longer in the archive
because they have been superseded. Furthemore, in this case, there was
an upload, it just never made it out of NEW.

> > Moreover, a new revision makes it easier for everyone to follow
> > what had changed between a version which was reviewed by the
> > ftpmasters and the next version that was uploaded.
> 
> That was already discussed at length in another mentors.d.n thread
> (other threads actually).

There's a significant difference between uploads to mentors.d.n and
uploads to debian.org. If you actually uploaded to the archive, even
if it never made it out of NEW, you should never elide changelogs.

Don Armstrong

-- 
Three little words. (In descending order of importance.)
I
love
you
 -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php

http://www.donarmstrong.com              http://rzlab.ucr.edu

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

From: "Ben Finney" <address deleted>
Subject: Re: ftp-masters
Date: Thu, 31 Jul 2008 08:33:33 +1000

"Sandro Tosi" <matrixhasu@gmail.com> writes:

> On Wed, Jul 30, 2008 at 15:11, Ben Finney <ben+debian@benfinney.id.au> wrote:
> > [T]here's no good reason I can see to re-use a release number
> > after it's uploaded.
> 
> Because it never reach the archive, so it's better to keep the same
> version for a REJECTED package

Why is it better? What benefit does it bring to retain the same
version string, including release number, for two different packages
that have both been uploaded by the maintainer?

> jumping revision is useless.

It's useful because it clearly distinguishes two different package
uploads by the maintainer. By definition, they are at least different
enough that one was REJECTED and the later one hopes not to meet the
same fate.

That keeps discussions about which one is which easy, and it even
makes it trivial to distinguish in the package changelog, by
separating the two releases and describing what was done for the later
one to make it different.

That's a tangible benefit, not "useless". What is the benefit in not
doing that?

-- 
 \         âMy girlfriend has a queen sized bed; I have a court jester |
  `\   sized bed. It's red and green and has bells on it, and the ends |
_o__)                                         curl up.â âSteven Wright |
Ben Finney

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 00:42:36 +0200
From: "Sandro Tosi" <address deleted>
Subject: Re: ftp-masters

On Thu, Jul 31, 2008 at 00:33, Ben Finney <ben+debian@benfinney.id.au> wrote:
> "Sandro Tosi" <matrixhasu@gmail.com> writes:
>
>> On Wed, Jul 30, 2008 at 15:11, Ben Finney <ben+debian@benfinney.id.au> wrote:
>> > [T]here's no good reason I can see to re-use a release number
>> > after it's uploaded.
>>
>> Because it never reach the archive, so it's better to keep the same
>> version for a REJECTED package
>
> Why is it better? What benefit does it bring to retain the same
> version string, including release number, for two different packages
> that have both been uploaded by the maintainer?
>
>> jumping revision is useless.
>
> It's useful because it clearly distinguishes two different package
> uploads by the maintainer. By definition, they are at least different
> enough that one was REJECTED and the later one hopes not to meet the
> same fate.
>
> That keeps discussions about which one is which easy, and it even
> makes it trivial to distinguish in the package changelog, by
> separating the two releases and describing what was done for the later
> one to make it different.
>
> That's a tangible benefit, not "useless". What is the benefit in not
> doing that?

Because it doesn't add any information for the end users, if not
confusion: it seems that 2 different version reached the archive,
since the users will see 2 different entries in the changelog (for
example using apt-listchanges) when indeed there is only 1 package
uploaded after the one previou in the archive.

So, simply changing the current REJECTED changelog entry
adding/modifing/removing items in it it's clearer.

Ah, did I forgot to remember that "Our priorities are our users and
free software"?

Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 16:07:43 -0700
From: "Don Armstrong" <address deleted>
Subject: Re: ftp-masters

On Thu, 31 Jul 2008, Sandro Tosi wrote:
> Because it doesn't add any information for the end users,

Sure it does. It tells end users what was changed in between the
REJECT and the new upload. Eliding this means that it's no longer
possible to trivially tell what was changed between uploads.[1]

> if not confusion: it seems that 2 different version reached the
> archive, since the users will see 2 different entries in the
> changelog (for example using apt-listchanges) when indeed there is
> only 1 package uploaded after the one previou in the archive.

There were two uploaded, not just one. Furthermore, it doesn't matter
how many have reached the archive when a user is examining changelogs.
All you care about is the version that you have, the version that
you're upgrading to, and any previous versions you had installed. None
of those necessarily correlate with versions that are actually in the
archive.

> Ah, did I forgot to remember that "Our priorities are our users and
> free software"?

Obviously, which is why you should do what I suggested.

You shouldn't treat changelogs of packages which happen to stop off at
NEW any differently, even if they get REJECTed.

Don Armstrong

1: Furthermore, you really should be tagging your uploads with the
release that you uploaded to Debian with in your VCS. You are doing
that, right?
-- 
NASCAR is a Yankee conspiracy to keep you all placated so the South
won't rise again.
 -- http://www.questionablecontent.net/view.php?comic=327

http://www.donarmstrong.com              http://rzlab.ucr.edu

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 01:16:28 +0200
From: "Sandro Tosi" <address deleted>
Subject: Re: ftp-masters

On Thu, Jul 31, 2008 at 01:07, Don Armstrong <don@debian.org> wrote:
> On Thu, 31 Jul 2008, Sandro Tosi wrote:
>> Because it doesn't add any information for the end users,
>
> Sure it does. It tells end users what was changed in between the
> REJECT and the new upload. Eliding this means that it's no longer
> possible to trivially tell what was changed between uploads.[1]

But does really an end user knows/cares about it? You are talkink from
a developer POV, that's a little bit low-level than most of our users.

>> if not confusion: it seems that 2 different version reached the
>> archive, since the users will see 2 different entries in the
>> changelog (for example using apt-listchanges) when indeed there is
>> only 1 package uploaded after the one previou in the archive.
>
> There were two uploaded, not just one. Furthermore, it doesn't matter
> how many have reached the archive when a user is examining changelogs.
> All you care about is the version that you have, the version that
> you're upgrading to, and any previous versions you had installed. None
> of those necessarily correlate with versions that are actually in the
> archive.

mh, so the latest changelog entry should report why the previous
upload was REJECTED, and what was done to fix it.

>> Ah, did I forgot to remember that "Our priorities are our users and
>> free software"?
>
> Obviously, which is why you should do what I suggested.
>
> You shouldn't treat changelogs of packages which happen to stop off at
> NEW any differently, even if they get REJECTed.

I suggest this only because a REJECTED package is a sort of
half-release, and you still need to rework (hopefully a bit) the
previous changes: you rework the previous upload (that you think it
was right) to meet our standards.

Of course, this is just what I *feel* is correct, since no ufficial
doc is available for this.

Cheers,
Sandro

> 1: Furthermore, you really should be tagging your uploads with the
> release that you uploaded to Debian with in your VCS. You are doing
> that, right?

Of course, but I can retag ;)

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 03:15:15 -0700
From: "Don Armstrong" <address deleted>
Subject: Re: ftp-masters

On Thu, 31 Jul 2008, Sandro Tosi wrote:
> But does really an end user knows/cares about it? You are talkink
> from a developer POV, that's a little bit low-level than most of our
> users.

Someone who is looking at the changelog is getting to the lower levels
anyway. [Plus, it's not like this is particularly complicated stuff.]
 
> mh, so the latest changelog entry should report why the previous
> upload was REJECTED, and what was done to fix it.

Ideally, what was done to fix it is enough, because that'd tell you
why it was rejected.


Don Armstrong

-- 
As nightfall does not come at once, neither does oppression. In both
instances, there is a twilight when everything remains seemingly
unchanged. And it is in such twilight that we all must be most aware
of change in the air however slight lest we become unwitting victims
of the darkness.
 -- William O. Douglas

http://www.donarmstrong.com              http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 22:22:18 +0400
From: "Stanislav Maslovski" <address deleted>
Subject: versioned Build-Depends on debhelper

Hello again,

My sponsor asked me to delete versioned build dependency on
debhelper. I had it in the form "debhelper (>= 5)" and changed
it to just "debhelper". I am wondering if this is right.

In debian/compat I put "5".

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Subject: Re: versioned Build-Depends on debhelper
From: "Russ Allbery" <address deleted>
Date: Wed, 30 Jul 2008 14:14:53 -0700

Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:

> My sponsor asked me to delete versioned build dependency on debhelper.

I think this is bad advice.

> I had it in the form "debhelper (>= 5)" and changed it to just
> "debhelper". I am wondering if this is right.
>
> In debian/compat I put "5".

It is considered best practice to always depend on the minimum version of
debhelper corresponding to the compat level that you're using.  It's not
strictly necessary to version the debhelper dependency if your compat
level is old enough that it's supported by any debhelper that a building
host is likely to be able to install (in practice, old enough that it's
supported in stable), but there's really no reason not to use the more
accurate and informative dependency.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 23:57:44 +0200
From: "Marc Haber" <address deleted>
Subject: Re: versioned Build-Depends on debhelper

On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote:
> Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:
> > My sponsor asked me to delete versioned build dependency on debhelper.
> 
> I think this is bad advice.

I agree. There are people building Debian packages on older releases,
and having a package fail because a known versioned dependency had its
version removed it a disservice to those people.

I might be missing arguments for removing the version, but I have only
been a DD for like seven years.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

From: "Romain Beauxis" <address deleted>
Subject: Re: versioned Build-Depends on debhelper
Date: Thu, 31 Jul 2008 16:10:12 +0200

Le Wednesday 30 July 2008 23:57:44 Marc Haber, vous avez Ã©critÂ :
> On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote:
> > Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:
> > > My sponsor asked me to delete versioned build dependency on debhelper.
> >
> > I think this is bad advice.
>
> I agree. There are people building Debian packages on older releases,
> and having a package fail because a known versioned dependency had its
> version removed it a disservice to those people.
>
> I might be missing arguments for removing the version, but I have only
> been a DD for like seven years.

Well, while I wouldn't ask to remove a versioned build-dep,
you could also argue with your reasoning that all build-dep
should be versioned..

I think a relatively safe requirement is to version if it needs more than
the current stable (or perhaps oldstable) version.


Romain
-- 
I've got to get away from here
This is not a place for me to stay
I've got to take my family
We'll find a quiet place


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Subject: Re: versioned Build-Depends on debhelper
From: "Russ Allbery" <address deleted>
Date: Thu, 31 Jul 2008 16:47:04 -0700

Romain Beauxis <toots@rastageeks.org> writes:

> Well, while I wouldn't ask to remove a versioned build-dep, you could
> also argue with your reasoning that all build-dep should be versioned..
>
> I think a relatively safe requirement is to version if it needs more
> than the current stable (or perhaps oldstable) version.

I think of debhelper as a special case since it's so easy to know what
versioned dependency to use and it's possible to programmatically check
that you've got the right one (against the compat file).  For most other
cases, I would only version a dependency if I knew there was an oldstable
(or even just stable) version that didn't support what I needed, but with
debhelper it's just so easy to always version it for consistency.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 12:05:21 +0400
From: "Stanislav Maslovski" <address deleted>
Subject: Re: versioned Build-Depends on debhelper

On Wed, Jul 30, 2008 at 11:57:44PM +0200, Marc Haber wrote:
> On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote:
> > Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:
> > > My sponsor asked me to delete versioned build dependency on debhelper.
> > 
> > I think this is bad advice.
> 
> I agree. There are people building Debian packages on older releases,
> and having a package fail because a known versioned dependency had its
> version removed it a disservice to those people.

That was my concern also. However, Romain pointed out that Etch
(which will soon become oldstable) has debhelper of ver. > 5 so there
should not be problems with backporting to it.

> I might be missing arguments for removing the version, but I have only
> been a DD for like seven years.

Marc, Russ, thank you for your answers. Unfortunately, the package has been
already sponsored and uploaded to NEW. I think that at this stage this change
should be harmless. I will return the versioned dependency back when
preparing the next modification of the package.

-- 
Stanislav

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 18:30:31 +0200
From: "Marc Haber" <address deleted>
Subject: Re: versioned Build-Depends on debhelper

On Thu, Jul 31, 2008 at 12:05:21PM +0400, Stanislav Maslovski wrote:
> On Wed, Jul 30, 2008 at 11:57:44PM +0200, Marc Haber wrote:
> > On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote:
> > > Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:
> > > > My sponsor asked me to delete versioned build dependency on debhelper.
> > > 
> > > I think this is bad advice.
> > 
> > I agree. There are people building Debian packages on older releases,
> > and having a package fail because a known versioned dependency had its
> > version removed it a disservice to those people.
> 
> That was my concern also. However, Romain pointed out that Etch
> (which will soon become oldstable) has debhelper of ver. > 5 so there
> should not be problems with backporting to it.

There have been Debian releases before etch. Which is the reason why I
wrote "older releases" instead of etch.

> > I might be missing arguments for removing the version, but I have only
> > been a DD for like seven years.
> 
> Marc, Russ, thank you for your answers. Unfortunately, the package has been
> already sponsored and uploaded to NEW. I think that at this stage this change
> should be harmless. I will return the versioned dependency back when
> preparing the next modification of the package.

And please deliver a cluebat to your sponsor and ask him to give
better advice to newbies in the future.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

From: "Romain Beauxis" <address deleted>
Subject: Re: versioned Build-Depends on debhelper
Date: Wed, 30 Jul 2008 20:30:15 +0200

Le Wednesday 30 July 2008 20:22:18 Stanislav Maslovski, vous avez écrit :
> Hello again,

    Hi !

> My sponsor asked me to delete versioned build dependency on
> debhelper. I had it in the form "debhelper (>= 5)" and changed
> it to just "debhelper". I am wondering if this is right.
>
> In debian/compat I put "5".

Why didn't you ask him directly ?

I believe the fact that current etch already sips debhelper >= 5
makes this versioned build-dep void..


Romain
-- 
And all the crowd comes in day by day
No one stop it in anyway
And all the peacemaker turn war officer
Hear what I say


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Wed, 30 Jul 2008 23:47:47 +0400
From: "Stanislav Maslovski" <address deleted>
Subject: Re: versioned Build-Depends on debhelper

On Wed, Jul 30, 2008 at 08:30:15PM +0200, Romain Beauxis wrote:
> Le Wednesday 30 July 2008 20:22:18 Stanislav Maslovski, vous avez Ã©critÂ :
> > Hello again,
> 
>    Hi !
> 
> > My sponsor asked me to delete versioned build dependency on
> > debhelper. I had it in the form "debhelper (>= 5)" and changed
> > it to just "debhelper". I am wondering if this is right.
> >
> > In debian/compat I put "5".
> 
> Why didn't you ask him directly ?

I asked, however I was not fully satisfied with his explanations
(I hope he will excuse me for this :) ) and wanted to ask a broader
audience to make things bright and clear to me.

> I believe the fact that current etch already sips debhelper >= 5
> makes this versioned build-dep void..

All right. I simply saw too many packages built with that kind of
versioned dependency.

-- 
Stanislav


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 31 Jul 2008 16:00:38 +0200
From: "Hervé Rousseau" <address deleted>
Subject: RFS: paris-traceroute (updated package)

Dear mentors,

I am looking for a sponsor for the new version 0.92-dev-2
of my package "paris-traceroute".

It builds these binary packages:
paris-traceroute - New version of well known tool traceroute

The package appears to be lintian clean.

The upload would fix these bugs: 432606

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/paris-traceroute
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/paris-traceroute/paris-traceroute_0.92-dev-2.dsc

I would be glad if someone uploaded this package for me.

Kind regards

-- 
Herve Rousseau


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Fri, 01 Aug 2008 09:54:11 +0800
From: "Thomas Goirand" <address deleted>
Subject: Re: RFS: paris-traceroute (updated package)

HervÃ© Rousseau wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 0.92-dev-2
> of my package "paris-traceroute".
> 
> It builds these binary packages:
> paris-traceroute - New version of well known tool traceroute

What's the advantage of paris-traceroute comparing to the old one and to
mtr (and mtr-tiny) for example? If it does the same, or less than the
other 2, it's useless to work on it, IMHO.

Thomas

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Fri, 1 Aug 2008 04:42:24 +0200
From: "Cyril Brulebois" <address deleted>
Subject: Re: RFS: paris-traceroute (updated package)

Bleh:
> To: debian-mentors@lists.debian.org
> CC: debian-mentors@lists.debian.org

Thomas Goirand <thomas@goirand.fr> (01/08/2008):
> What's the advantage of paris-traceroute comparing to the old one and
> to mtr (and mtr-tiny) for example? If it does the same, or less than
> the other 2, it's useless to work on it, IMHO.

Check the homepage[1]. HervÃ©: I think you should run the latest lintian
version on your package, which would have spotted that your Homepage:
should be moved to a proper source field, and that your
Standards-Version is outdated (and maybe other, didn't check).

 1. http://www.paris-traceroute.net/

Mraw,
KiBi.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Fri, 1 Aug 2008 07:56:52 +0200
From: "Hervé Rousseau" <address deleted>
Subject: Re: RFS: paris-traceroute (updated package)

On Fri, Aug 1, 2008 at 4:42 AM, Cyril Brulebois <kibi@debian.org> wrote:
[...]
>
> Check the homepage[1]. HervÃ©: I think you should run the latest lintian
> version on your package, which would have spotted that your Homepage:
> should be moved to a proper source field, and that your
> Standards-Version is outdated (and maybe other, didn't check).

Ooops,

Yes, I didn't use the latest version of lintian sorry. It should be fixed now.

I have updated the package in mentors.debian.net :

- URL: http://mentors.debian.net/debian/pool/main/p/paris-traceroute
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/paris-traceroute/paris-traceroute_0.92-dev-2.dsc

Cheers,

-- 
Herve Rousseau

Date: Fri, 1 Aug 2008 09:54:10 +0200
From: "Hervé Rousseau" <address deleted>
Subject: RFS: getstream (updated package)

Dear mentors,

I am looking for a sponsor for the new version 20080426-1
of my package "getstream".

It builds these binary packages:
getstream  - DVB streaming application

The package appears to be lintian clean.

The upload would fix these bugs: 481771

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/getstream
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/getstream/getstream_20080426-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards

-- 
Herve Rousseau


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

From: "Vincent Bernat" <address deleted>
Subject: Re: RFS: getstream (updated package)
Date: Fri, 01 Aug 2008 20:24:17 +0200

OoO En cette  matinée ensoleillée du vendredi 01  août 2008, vers 09:54,
"Hervé Rousseau" <herve@moulticast.net> disait :

> - dget http://mentors.debian.net/debian/pool/main/g/getstream/getstream_20080426-1.dsc

Uploaded.

For a next version:
 - remove the last "." in debian/control.
 - CFLAGS is now set  automatically by dpkg-buildpackage, you can remove
   the "noopt" snippet from the top of debian/rules
-- 
 /* Identify the flock of penguins.  */
    2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Fri, 01 Aug 2008 16:49:24 +0200
From: "Giuseppe Iuculano" <address deleted>
Subject: RFS: procinfo-ng

Dear mentors,

I am looking for a sponsor for my package "procinfo-ng".

* Package name    : procinfo-ng
  Version         : 2.0.196-1+svn204
  Upstream Author : Thaddeus Messenger <tabrisnet@users.sourceforge.net>
* URL             : http://procinfo-ng.sourceforge.net
* License         : GPL
  Section         : utils

It builds these binary packages:
procinfo-ng - Displays system information from /proc and /sys

The package appears to be lintian clean.


Procinfo-NG is a small program that gathers some system information from
diverse files under /proc and /sys and prints it to the screen.

Procinfo-NG is a replacement for procinfo. Has most of the same features, but is
written in clean C++ and has fixed many of the features that were broken due to
changes in the 2.4 and 2.6 kernels.

Plus, it uses uint64 for almost everything, and thus should be 64-bit safe.


The upload would fix these bugs: 492807

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/procinfo-ng
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/p/procinfo-ng/procinfo-ng_2.0.196-1+svn204.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Giuseppe Iuculano

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

From: "Ben Finney" <address deleted>
Subject: Re: RFS: procinfo-ng
Date: Sat, 02 Aug 2008 09:38:24 +1000

Giuseppe Iuculano <giuseppe@iuculano.it> writes:

> Dear mentors,
> 
> I am looking for a sponsor for my package "procinfo-ng".
> 
> * Package name    : procinfo-ng
>   Version         : 2.0.196-1+svn204
>   Upstream Author : Thaddeus Messenger <tabrisnet@users.sourceforge.net>
> * URL             : http://procinfo-ng.sourceforge.net
> * License         : GPL
>   Section         : utils
> 
> It builds these binary packages:
> procinfo-ng - Displays system information from /proc and /sys

Please rewrite the synopsis as guided by the Best Packaging Practices
<URL:http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>.
The synopsis should be an appositive clause (see that reference for
more).

Suggested improved synopsis:

    reporter for system information from /proc and /sys

-- 
 \       âTwo possibilities exist: Either we are alone in the Universe |
  `\   or we are not. Both are equally terrifying.â âArthur C. Clarke, |
_o__)                                                             1999 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Sat, 2 Aug 2008 01:49:30 +0200
From: "Cyril Brulebois" <address deleted>
Subject: Re: RFS: procinfo-ng

Giuseppe Iuculano <giuseppe@iuculano.it> (01/08/2008):
> I am looking for a sponsor for my package "procinfo-ng".

I thought the plan was to replace the old procinfo package without
introducing a new one?

Mraw,
KiBi.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Sat, 02 Aug 2008 03:11:15 +0200
From: "Giuseppe Iuculano" <address deleted>
Subject: Re: RFS: procinfo-ng

Cyril Brulebois ha scritto:

> I thought the plan was to replace the old procinfo package without
> introducing a new one?

I didn't read about replacing, but my plan was a new package (procinfo-ng) and
after some testing, if procinfo maintainer agree, obsoleting procinfo (with
replace field and a dummy package).


Giuseppe.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Sat, 2 Aug 2008 03:15:48 +0200
From: "Cyril Brulebois" <address deleted>
Subject: Re: RFS: procinfo-ng

Giuseppe Iuculano <giuseppe@iuculano.it> (02/08/2008):
> I didn't read about replacing, but my plan was a new package (procinfo-ng) and
> after some testing, if procinfo maintainer agree, obsoleting procinfo (with
> replace field and a dummy package).

20080729080145.GA32251@wavehammer.waldi.eu.org and below.

Mraw,
KiBi.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Sat, 02 Aug 2008 03:40:37 +0200
From: "Giuseppe Iuculano" <address deleted>
Subject: Re: RFS: procinfo-ng

Cyril Brulebois ha scritto:
> 
> 20080729080145.GA32251@wavehammer.waldi.eu.org and below.
> 
> Mraw,
> KiBi.

Thanks.

> You don't need an ITP to upload the new software as procinfo.
> 
> Bastian

procinfo-ng is not procinfo, upstream changes, copyright changes, code changes,
is it possible upload a new version of procinfo that actually is procinfo-ng,
and so bypass the NEW upload queue? If yes, no problem for me.



Giuseppe.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Fri, 1 Aug 2008 23:49:30 -0500
From: "William Vera" <address deleted>
Subject: RFS: scrot (updated package)

Dear mentors,

I am looking for a sponsor for the new version 0.8-8
of my package "scrot".

It builds these binary packages:
scrot      - command line screen capture utility

The package appears to be lintian clean.

The upload would fix these bugs: 492502

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/scrot
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/s/scrot/scrot_0.8-8.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 William Vera


-- 
William Vera <billy@billy.com.mx>
PGP Key: 1024D/F5CC22A4
Fingerprint: 3E73 FA1F 5C57 6005 0439  4D75 1FD2 BF96 F5CC 22A4


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Sat, 2 Aug 2008 15:20:53 +1000
From: "Aníbal Monsalve Salazar" <address deleted>
Subject: Re: RFS: scrot (updated package)

On Fri, Aug 01, 2008 at 11:49:30PM -0500, William Vera wrote:
>I am looking for a sponsor for the new version 0.8-8 of my package
>"scrot".

Please don't include changes to autotools files in scrot_0.8-8.diff.gz

All other upstream files should be modified with patches. So, Please put
those cahnges in a series of patches in debian/patches and build depend
on quilt.

diffstat scrot_0.8-8.diff.gz
 Makefile.am      |    8
 Makefile.in      |  635 +++--
 aclocal.m4       | 1111 +++++++--
 config.guess     | 1407 ++++++++++++
 config.sub       | 1505 +++++++++++++
 configure        |  629 ++++-
 debian/changelog |   92
 debian/compat    |    1
 debian/control   |   16
 debian/copyright |   32
 debian/rules     |    4
 depcomp          |  479 ++++
 install-sh       |  169 -
 ltmain.sh        | 6322 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 missing          |  158 +
 mkinstalldirs    |  117 -
 src/Makefile.am  |    4
 src/Makefile.in  |  509 ++--
 src/options.c    |    4
 19 files changed, 12247 insertions(+), 955 deletions(-)

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

From: "Ben Finney" <address deleted>
Subject: Re: RFS: scrot (updated package)
Date: Sun, 03 Aug 2008 09:43:24 +1000

AnÃbal Monsalve Salazar <anibal@debian.org> writes:

> All other upstream files should be modified with patches.

Or by some other method that results in the Debian source package
format, with a pristine upstream tarball and all maintainer changes in
the .diff.gz.

> So, Please put those cahnges in a series of patches in
> debian/patches and build depend on quilt.

Or use some other method (e.g. a VCS and the corresponding command
foovcs-buildpackage) to track differences from upstream and generate
the changes for the Debian package.

The "quilt" format is favoured by many, but is certainly not mandatory
nor even "best practice".

-- 
 \       âFor fast acting relief, try slowing down.â âJane Wagner, via |
  `\                                                       Lily Tomlin |
_o__)                                                                  |
Ben Finney

-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

From: "George Danchev" <address deleted>
Subject: Re: RFS: scrot (updated package)
Date: Sun, 3 Aug 2008 10:58:38 +0300

On Sunday 03 August 2008 02:43:24 Ben Finney wrote:
> AnÃbal Monsalve Salazar <anibal@debian.org> writes:
> > All other upstream files should be modified with patches.
>
> Or by some other method that results in the Debian source package
> format, with a pristine upstream tarball and all maintainer changes in
> the .diff.gz.
>
> > So, Please put those cahnges in a series of patches in
> > debian/patches and build depend on quilt.
>
> Or use some other method (e.g. a VCS and the corresponding command
> foovcs-buildpackage) to track differences from upstream and generate
> the changes for the Debian package.

This do not exclude the usage of debian/patches. Make sure to understand that. 

> The "quilt" format is favoured by many, but is certainly not mandatory
> nor even "best practice".

Using quilt to clearly separate patches does not exclude nor contradicts with 
the usage of a $VCS. Thus I don't see what are you trying to correct in 
Anabal's statements.

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Sun, 3 Aug 2008 01:52:04 +0200
From: "Cyril Brulebois" <address deleted>
Subject: Re: RFS: scrot (updated package)

Ben Finney <ben+debian@benfinney.id.au> (03/08/2008):
> The "quilt" format is favoured by many, but is certainly not mandatory
> nor even "best practice".

That could be understood as the dpkg quilt format. While what is
favoured is only using quilt to manage the patches, which makes a huge
difference.

Mraw,
KiBi.

[ omitting part 2: file MIME type is application/pgp-signature, not text/html ]

Date: Sun, 3 Aug 2008 15:24:41 +0100
From: "Iulian Udrea" <address deleted>
Subject: RFS: gtkmm-utils

Dear mentors,

I am looking for a sponsor for my package "gtkmm-utils".

gtkmm-utils is a C++ utility and widget library based on glibmm and gtkmm.

Package name: gtkmm-utils
Version: 0.3.2-1
Upstream Authors: Marko Anastasov <marko@marko.anastasov.name> and
Dodji Seketeli <dodji@seketeli.org>
URL: http://savannah.nongnu.org/projects/gtkmm-utils
License: LGPL
Section: libs

It builds these binary packages:
libglibmm-utils-dev - utility functions, classes and widgets written on top of glibmm
libglibmm-utils2 - utility functions, classes and widgets written on top of glibmm
libgtkmm-utils-dev - utility functions, classes and widgets written on top of gtkmm
libgtkmm-utils2 - utility functions, classes and widgets written on top of gtkmm

The package appears to be lintian clean.

The upload would fix these bugs: 492480

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gtkmm-utils
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/gtkmm-utils/gtkmm-utils_0.3.2-1.dsc

Sincerely,
--
Iulian

Date: Sun, 3 Aug 2008 18:11:48 +0200
From: "Carsten Hey" <address deleted>
Subject: RFS: pal (updated package - new upstream bugfix release)

Dear mentors,

I am looking for a sponsor for the new version 0.4.3-1 of my package "pal".

It builds these binary packages:
pal        - command-line calendar program that can keep track of events

The package is lintian clean.

The upload would fix these bugs: #492464

Changes:
 pal (0.4.3-1) unstable; urgency=low
  .
  * New Upstream Version
    - Fix segfault when printing strings not valid in user's locale
      (Closes: #492464)
  * Removed patches that are included in pal's latest upstream release from
    debian/patches.  No remaining patches.

The package can be found on:
 - URL: http://debian.stateful.de/pbuilder/sid/
 - dget http://debian.stateful.de/pbuilder/sid/pal_0.4.3-1.dsc

I would be glad if someone uploaded this package for me.


Kind regards,
Carsten


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Sun, 3 Aug 2008 19:49:36 +0200
From: "Carsten Hey" <address deleted>
Subject: Re: RFS: pal (done)

On Sun, Aug 03, 2008 at 06:11:48PM +0200, Carsten Hey wrote:
> I am looking for a sponsor for the new version 0.4.3-1 of my package "pal".

I just found a sponsor, thanks!

Carsten


-- 
To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Date: Thu, 28 Aug 2008 09:03:33 -0300
Subject: testing binary attachment
From: "David Bremner" <address deleted>

This message has a 7 second Ogg Vorbis file of nothing attached to it.

That is all.

[ omitting part 2: file MIME type is application/ogg, not text/html ]

Date: Sat, 30 Aug 2008 10:08:32 -0300
Subject: testing HTML mail
From: "David Bremner" <address deleted>

This is some groovy HTML text