Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude

[Chip Norkus]

Package: general
Severity: normal


When installing Debian from the small net-install CD it shouldn't ask for the 
installation 
media by default in aptitude.  This is small but kind of irritating when 
working on a fresh 
debian system in remotely.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Raphael Hertzog]

On Sun, 24 Feb 2008, Charles Plessy wrote:
> Therefore we did not make progress since the beginning of the
> discussion:

You're trying to make progress somewhere where it's not expected.

> - The most efficient way to deal with changes to the sources for the
>   packager is to use his preferred tools.

That should stay as it is.

> - We do not know if the whole concept of breaking up the monolithic diff
>   into logical units is something that the persons who often do NMUs in
>   Debian are intersted in.

Seperating logical changes has always been useful to understand the
changes and is thus required for any independant reviewer who hasn't
access to the VCS where the changes are reviewable separately.

> - When modifying a package that uses dpatch, quilt or simple-patchsys,
>   developpers have to find out by themselves if the target for patching
>   the sources is patch, apply-patches or apply-dpatches.

Once the new dpkg-source format is in standard use, those rules disappear
completely... because they are no more needed during build.

Frank Lichtenheld and myself have started hacking on dpkg-source with the
goal to support an extend wig&pen and possibly even more. I'd encourage
interested parties to subscribe to debian-dpkg to follow discussions
there.

http://lists.debian.org/debian-dpkg/2008/02/msg00012.html
http://lists.debian.org/debian-dpkg/2008/02/msg00036.html

We're working in the "sourcev3" branch of dpkg's git repo. We've only
doing some ground work for now, but we've been doing good progress and I
expect the work on new features to start pretty soon.

http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=sourcev3

(Subscribe to the PTS with "cvs" keyword and you'll get git commit notice
in live :-))

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467258: marked as done (general: Net-install CD still defaults to asking for CD in aptitude)

[Debian Bug Tracking System]

Your message dated Sun, 24 Feb 2008 02:06:14 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#467258: general: Net-install CD still defaults to 
asking for CD in aptitude
has caused the Debian Bug report #467258,
regarding general: Net-install CD still defaults to asking for CD in aptitude
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
467258: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467258
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: general
Severity: normal


When installing Debian from the small net-install CD it shouldn't ask for the 
installation 
media by default in aptitude.  This is small but kind of irritating when 
working on a fresh 
debian system in remotely.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


--- End Message ---
--- Begin Message ---
On Sat, 23 Feb 2008, Chip Norkus wrote:
> When installing Debian from the small net-install CD it shouldn't
> ask for the installation media by default in aptitude. This is small
> but kind of irritating when working on a fresh debian system in
> remotely.

This is because it's assumed that pulling files which are known to be
on the CD you used to install the system will be faster than
downloading. It's quite trivial to remove them from the sources.list
if you know this to not be the case. [Removal is far easier then
actually adding the proper entries, so having them present is the
right course of action.]


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

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

--- End Message ---

Re: triggers in dpkg, and dpkg maintenance

[Raphael Hertzog]

Hi Ian,

On Fri, 22 Feb 2008, Ian Jackson wrote:
> There is in my opinion no reason why this code should not be merged
> into sid's dpkg immediately - although there may be some merge
> conflicts by now.  (I haven't been playing merge catch-up since I
> don't presently feel that my changes are going to be accepted.)

This is the only point to which I agree in your mail. 

However you haven't made it easy to merge your code... you repository is a
mess to proof-read and the cleaning work that you don't want to do has
thus to be done by Guillem.

Guillem has some responsibility in the delay here but he's perfectly aware
of it. I've been nagging him a bit to merge your work and he told us that
he has been orphaning other packages to be able to work more on dpkg.

His latest plans are still to merge your triggers work for 1.14.17 AFAIK.

> During some of the discussions surrounding my return to dpkg
> development, the view was expressed that I ought to do some work to
> persuade particularly Guillem Jover of my usefulness and competence.
> I was encouraged by various members of the current dpkg maintenance
> team to pull my weight by doing some bug triage and fixing.

For other people, that was mainly me AFAIK.

> I request that the current dpkg maintainers formally reinstate me as a
> maintainer of the package, and that they agree that I should merge my
> triggers branch, and other fixes, into the main dpkg git tree so that
> it may be uploaded.

FWIW, you do have access to the repository but I would request you to be
removed from the team if you made usage of it in a way that doesn't
conform to the rules of the team. This includes having meaningful commit
logs and using private rebased branches for most of the work except when
we have a public branch where multiple persons of the team cooperate (such
as what happens with the sourcev3 branch currently).
http://wiki.debian.org/Teams/Dpkg/GitUsage

FWIW, each commit pushed generates a mail sent to the PTS and I believe
that all main developers review changes that way (thus it's important to
have good log messages and changes committed in separate logical steps).

> I would like to see this happen without getting into bikeshedding
> about the proper use of git (and without pointless revision log
> polishing and without history-losing merges).

FWIW, IMO, either you follow the rules and you will be authorized to
commit on your own after some time, or you don't and you keep sending us
patches to merge (and you'll have to wait for someone to integrate your
work). Make your choice, invest a bit more time in preparing something
ready to be merged or wait...

I made all the path from external contributor to regular contributor and
I've been added to Uploaders recently. You can do it too I'm sure. I had
the chance to have djpig available to review my work and you're a bit more
dependant on Guillem to get started, but hopefully this won't stay a
problem for too long.

And last point, when we have problems withing the -dpkg team (and it
happens, we're only humans), we tend to resolve them by discussion on
#debian-dpkg and not by sending mails to -devel.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Looking for co-maintainer for mercurial

[Ondrej Certik]

On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock
>  <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  >  I'll be happy to help with this package.
>
>  Hi, I'll help with this package too, because I use Mercurial everyday.
>  Let's maintain it in:
>
>  http://wiki.debian.org/Teams/PythonAppsPackagingTeam
>
>  ?
>
>  There are many good DD's around the "Python Applications Packaging
>  Team" and the "Debian Python Modules Team", because generally,
>  this is a Python program, so they may help with many python related issues.

Any news on this? Do you agree with me importing to package to
Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT?

Ondrej


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

intend to take over gpsk31 maintenance

[Joop Stakenborg]

I intend to take over gpsk31 package maintenance from the previous
maintainer, Carlos Barros. I think this would be more convenient as I
am also the upstream maintainer.

Carlos, I you read this please respond if you object.

Thanks,
Joop pa3aba at debian dot org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely --> Debian New Maintainers'

[Michael Banck]

On Sat, Feb 09, 2008 at 10:53:55AM +0100, Patrick Schoenfeld wrote:
> (BTW. there is no need to CC me with your answers, I did not ask for
> that as I am subscribed to the list :-)
> 
> On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote:
> >   quilt is way more powerful to refresh patches when a new upstream
> > occurs. It does what it can do best without having mergeing features,
> > that only an advanced SCM can provide anyways.
> 
> That does mean quilt is able to refresh patches on upstream changes, so
> that with luck the maintainer does not have to refresh the patches for
> changes sources himself? That would be quiet nice, however I still fail
> to see why this is a reason to prefer quilts *format* as an *exchange
> format* if quilt itself is not to be used, which is what you say.

Who said quilt itself is not to be used?  The point of the discussion is
that we agree on a patch-exchange format, without forcing an
implementation on people.  People who like the quilt implementation will
still be able and encouraged to use quilt with it.  Others might just
use vi to edit quilt patches, or git, or something else.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Looking for co-maintainer for mercurial

[William Pitcock]

Hi,

On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote:
> On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock
> >  <[EMAIL PROTECTED]> wrote:
> >  > Hi,
> >  >
> >  >  I'll be happy to help with this package.
> >
> >  Hi, I'll help with this package too, because I use Mercurial everyday.
> >  Let's maintain it in:
> >
> >  http://wiki.debian.org/Teams/PythonAppsPackagingTeam
> >
> >  ?
> >
> >  There are many good DD's around the "Python Applications Packaging
> >  Team" and the "Debian Python Modules Team", because generally,
> >  this is a Python program, so they may help with many python related issues.
> 
> Any news on this? Do you agree with me importing to package to
> Python Applications Packaging Team (PAPT) and changing it's maintainer to 
> PAPT?
> 
> Ondrej
> 
> 

I disagree because mercurial is a very specific tool, and needs to be
maintained by people who care about mercurial specifically. But if that
is what Vincent wants to do, then that's fine.

William


signature.asc
Description: This is a digitally signed message part

Bug#467274: ITP: pcc -- the portable C compiler

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

Hi,

I am interested in pcc for several months, so I intend to package
it in Debian.

* Package name: pcc
  Version : 0.9.9
  Upstream Author : Anders Magnusson <[EMAIL PROTECTED]>
* URL : http://pcc.ludd.ltu.se/
* License : BSD
  Programming Lang: C
  Description : the portable C compiler
 pcc is the continuation of the portable C compiler source included
 in ancient Unix. It has been modernized to support C99 standards and
 other great features. An advantage to using pcc is that it is stricter
 about code structure than gcc is. To some extent, it is compatible with
 gcc CFLAGS, but this is not guaranteed.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#465334: ITP: speed-game -- A fast paced space-invader style arcade game

[SZERVÁC Attila]

 Hello:

 bubulle wrote:

> We still have a few games of the nineties in the archive which make
> interesting claims such as "high speed" or "nice graphics" and would
> just seem like jokes on 21st century machines or compared to 21st
> century games..:-)'

 hm - expect that Go (http://en.wikipedia.org/wiki/Weiqi) is the most
 addictive game

 compared to my quake1 on my 20th century machine (166MMX 128MB DOS), I
 can't play any interesting today (Celeron500 256MB Lenny). I can write
 game music modules for a game wich uses a q1-like engine in DFSG-free
 environment without proprietary hw-acceleration.

-- 
 sas ( satie ) - SZERVÁC Attila - zeneszerző - szoftvergazda  \
 elnökhelyettes - Linux-felhasználók Magyarországi Egyesülete - http://lme.hu/
 HU/Budapest - http://321.hu/sas/http://321.hu/Elig


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Practical solutions to: the new style "mass tirage" of bugs

[Stefano Zacchiroli]

On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote:
> Here are some things that occur to me quickly:

I'll be just pointing to existing tools I'm aware of that are related to
your points. People probably already know all of them, but since I'm a
bit surprised to not having them mentioned in this thread I'll do that.

> 4) Integration with BTS and $DVCS.  I have some code that marks bugs pending 
> when mentioned in a VCS change log.  But this could go farther: branches 
> tied to bugs, etc.

My workflow for that is using dch + debcommit + tagpending, all in
devscripts. With dch I play with the changelog as usual, possibly adding
the "Closes: #xx" entry. Then I commit with debcommit, which reuses
the changelog entry as it is. Then I run tagpending which extracts bug
numbers from the changelog entry and send the appropriate message to the
BTS.

I find this quite satisfying, the only extra integration which I would
like is alioth-side post-commit hooks (which I believe exists for
whatever $VCS) grepping for "Closes: #xx" lines in commit messages.
It won't be life changing, but having them by default on all repos on
alioth would be nice.

Were you expecting something like this? more/less?

> 6) Better tools to integrate Debian BTS with upstream BTS.  I would love a 

Uhm, we have bts-link (http://bts-link.alioth.debian.org/) which is
quite nice, though I must say that thus far I've been lucky, and
madcoder has always made the setup I needed instead of me :-)

> command-line tool where I could say "debforward 123456".  It would look up 
> the package name for 123456, figure out from some metadata what type of BTS 
> it uses and where it lives, look up my account on that BTS in ~/.forward, 
> and create a bug report there and mark the Debian one forwarded.  Then, if 
> there is no automated mechanism, some scanner at Debian would look for 
> changes on either end and forward them back and forth.  I would love this.

I guess madcoder already have this kind of information for bts-link, if
the information is available somewhere it would be trivial to add this
feature to bts (the commandline tool in devscripts, not the BTS of
course).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: dash bug which is affecting release goal

[Ian Jackson]

John H. Robinson, IV writes ("Re: dash bug which is affecting release goal"):
> Pierre Habouzit wrote:
> >   echo() { /bin/echo "$@" }
> 
> echo() { /bin/echo ${1+"$@"}; }
> 
> I believe you mean.

Why ?!

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: QUESTION: Debian Policy: Manual pages

[Ian Jackson]

Bas Zoetekouw writes ("Re: QUESTION: Debian Policy: Manual pages"):
> Why a recommends?  In order to satisfy the spirit of policy ("every
> binary must have a man page") it would need to be a depends, imo.

I think the point of policy is to ensure the manpage exists, not to
require that it be installed.

I think Suggests is the right dependency.  There is nothing wrong with
installing a package without its documentation.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[William Pitcock]

On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
> John H. Robinson, IV writes ("Re: dash bug which is affecting release goal"):
> > Pierre Habouzit wrote:
> > >   echo() { /bin/echo "$@" }
> > 
> > echo() { /bin/echo ${1+"$@"}; }
> > 
> > I believe you mean.
> 
> Why ?!

Because stand-alone $@ is undefined when used in this case. By using ${1
+"$@"}, it is ensured that $@ always starts with $1.

What a load of POSIX.

William


signature.asc
Description: This is a digitally signed message part

Re: dash bug which is affecting release goal

[William Pitcock]

On Sun, 2008-02-24 at 08:30 -0600, William Pitcock wrote:
> On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
> > John H. Robinson, IV writes ("Re: dash bug which is affecting release 
> > goal"):
> > > Pierre Habouzit wrote:
> > > >   echo() { /bin/echo "$@" }
> > > 
> > > echo() { /bin/echo ${1+"$@"}; }
> > > 
> > > I believe you mean.
> > 
> > Why ?!
> 
> Because stand-alone $@ is undefined when used in this case. By using ${1
> +"$@"}, it is ensured that $@ always starts with $1.
> 
> What a load of POSIX.
> 
> William

Oops, I mean "Because the behaviour of stand-alone $@ is undefined".

William


signature.asc
Description: This is a digitally signed message part

Re: the new style "mass tirage" of bugs

[Ian Jackson]

John Goerzen writes ("Re: the new style "mass tirage" of bugs"):
> Here's the thing.  If bugs I submit actually get looked at by a human, and 
> humans are fixing a reasonable percentage of bugs submitted, I don't mind 
> testing things out on new versions whenever I can.

I think this is a key point.

I've had a number of cases recently where very old bugs of mine have
had responses apparently by people other than the maintainer saying
`can you reproduce this' or `is this still relevant in the new
version'.  These messages are IMO useless, in the vast majority of
cases.

A good test is: what would I do if I were both the maintainer and the
bug submitter ?  Looking at it that way avoids getting confused, and
avoids adopting approaches which just shuffle work about or which even
create more work.

If I have reported a longstanding bug in a package of mine, I don't
usually say to myself `oh look this is years and years old let me see
if I can still reproduce it so I can just forget about it if not'.

Rather I'll ask `has anything changed in the package which one might
expect to have a bearing on this bug'.  If the answer is `no' then the
bug should stay open until I have effort to actually investigate it.
That this might take months or years if the bug is not very important.

If the answer is `yes, the package has changed', then the next
question is `what is the best way forward'.  Sometimes it will be
obvious that the code which had the bug has been entirely removed, so
that the bug report no longer serves a useful purpose.  At other times
a quick glance at the relevant code changes shows that actually the
changes couldn't fix the reported symptoms.  And then there are cases
where the best approach is to try it again with the new version.  etc.

But these decisions cannot be made by unskilled `triagers' who just go
around sending emails to what they think of as `stale' bugs.


Of course there are packages (OOo and Mozilla are probably examples)
which are so huge and so full of bugs that dealing properly with all
of the bugs is impossible.  In particular, if a package has so many
bugs, or is generally so large or in such poor shape, that it is
inconceivable that anything but a small inority will ever be properly
investigated and fixed, there is no point recording minor bugs in the
Debian BTS.  That just serves to clutter the bug listings to no useful
effect.

So I don't mind it at all when then Mozilla maintainers say `is it
still doing this crazy thing'.  After all I don't even bother
reporting most of the bad things Mozilla does; one-offs definitely
don't make the cut.  If I can't reproduce it then if I were both
submitter and maintainer I wouldn't spend any more time on it.  So
then just closing it is fine.

Whether or not a package is like this is probably a question for the
maintainer to decide - but if the number of bugs is only a few dozen
then I think saying the package is unmaintainable is not a reasonable
point of view.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-buildpackage now reorganizing debian/control Depends field??

[Ian Jackson]

Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control 
Depends  field??"):
> I won't revert anything unless you come up with some proof that this
> causes severe issues that will disturb the lenny release process.

I think this is the wrong approach.

Surely you should revert the change if people can demonstrate that
it's wrong ?

(IMO it has been demonstrated that sorting should not override the
package maintainer's specified ordering.)

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Looking for co-maintainer for mercurial

[Ondrej Certik]

On Sun, Feb 24, 2008 at 12:57 PM, William Pitcock
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
>  On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote:
>  > On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>  > > On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock
>  > >  <[EMAIL PROTECTED]> wrote:
>  > >  > Hi,
>  > >  >
>  > >  >  I'll be happy to help with this package.
>  > >
>  > >  Hi, I'll help with this package too, because I use Mercurial everyday.
>  > >  Let's maintain it in:
>  > >
>  > >  http://wiki.debian.org/Teams/PythonAppsPackagingTeam
>  > >
>  > >  ?
>  > >
>  > >  There are many good DD's around the "Python Applications Packaging
>  > >  Team" and the "Debian Python Modules Team", because generally,
>  > >  this is a Python program, so they may help with many python related 
> issues.
>  >
>  > Any news on this? Do you agree with me importing to package to
>  > Python Applications Packaging Team (PAPT) and changing it's maintainer to 
> PAPT?
>  >
>  > Ondrej
>  >
>  >
>
>  I disagree because mercurial is a very specific tool, and needs to be
>  maintained by people who care about mercurial specifically. But if that
>  is what Vincent wants to do, then that's fine.

Well, that's what PAPT is for. All python apps and modules (those go
into the DPMT team) share
a lot of things in common, they all need the same care when switching
from python2.4 to python2.5 etc.
You can still require to approve all changes before each upload.

Ondrej


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Raphael Hertzog writes ("Re: triggers in dpkg, and dpkg maintenance"):
> However you haven't made it easy to merge your code... you repository is a
> mess to proof-read and the cleaning work that you don't want to do has
> thus to be done by Guillem.

This is precisely the git bikeshedding I was talking about.
The `work' that needs to be done is simply `git pull'. [1]

My changes are not that hard to review and in any case they have been
ready for merge for SIX MONTHS and deployed in a widely-used released
Linux distribution for four months.

What more evidence is needed of their suitability ?

> FWIW, you do have access to the repository but I would request you to be
> removed from the team if you made usage of it in a way that doesn't
> conform to the rules of the team. This includes having meaningful commit
> logs and using private rebased branches for most of the work except when
> we have a public branch where multiple persons of the team cooperate (such
> as what happens with the sourcev3 branch currently).
> http://wiki.debian.org/Teams/Dpkg/GitUsage

This development model has been imported from the Linux kernel.  It
may be appropriate when there are hundreds or thousands of people
generating huge quantities of patches, all trying to get their changes
committed, with no organisational connection to the handful of people
picked by the original author who need to act as gatekeeper.

It is not appropriate for a project which has about four people
submitting any significant number of patches, all of whom are fully
signed-up members of a shared governance infrastructure, and where the
gatekeepers are just the people in that project whose hands the code
has most recently fallen into.

Ian.

[1] Well, `git pull' is what needed to be done in August.  Now
obviously a bit of merge conflict sorting will need to be done.  I am
obviously volunteering to do this but only if it means I can be sure
it will be the last time.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: triggers in dpkg, and dpkg maintenance

[Ian Jackson]

Raphael Hertzog writes ("Re: triggers in dpkg, and dpkg maintenance"):
> Guillem has some responsibility in the delay here but he's perfectly aware
> of it. I've been nagging him a bit to merge your work and he told us that
> he has been orphaning other packages to be able to work more on dpkg.

I don't think this is an acceptable answer at this stage.

The current maintainers have failed to shit.
Now they should get off the pot.

My bugfixes for #281057 and #432893, and my implementation of `Breaks'
support in dselect, are outstanding too, since early November.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Charles Plessy]

Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit :
> 
> > - When modifying a package that uses dpatch, quilt or simple-patchsys,
> >   developpers have to find out by themselves if the target for patching
> >   the sources is patch, apply-patches or apply-dpatches.
> 
> Once the new dpkg-source format is in standard use, those rules disappear
> completely... because they are no more needed during build.

I must have missed something. I thought that the new format was to keep
the debian directory in a tar.gz format. With this format, people who
want to modify upstream sources will have to use a patch system. What is
the plan to make the patch targets in debian/rules unneeded?

Have a nice day (and thank you for your work on a new format for source
pacakages.)

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Looking for co-maintainer for mercurial

[Vincent Danjean]

William Pitcock wrote:
> Hi,
> 
> On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote:
>> On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>>>  There are many good DD's around the "Python Applications Packaging
>>>  Team" and the "Debian Python Modules Team", because generally,
>>>  this is a Python program, so they may help with many python related issues.
>> Any news on this? Do you agree with me importing to package to
>> Python Applications Packaging Team (PAPT) and changing it's maintainer to 
>> PAPT?
>>
>> Ondrej
> 
> I disagree because mercurial is a very specific tool, and needs to be
> maintained by people who care about mercurial specifically. But if that
> is what Vincent wants to do, then that's fine.

I'm already in the perl teams and, even if I did not know about the PAPT, I
think it is similar. I mean that I think that even if the package is maintained
within a team, specific work about one package will be done by the few members
that care about it.
The PAPT will be add value when python transitions occurs or similar 'global'
event in the python world.

This is why I asked to be added in the PAPT. Piotr Ożarowski just added me
in this alioth project and I plan to upload the current version of mercurial
in the SVN today or tomorrow.

If it happens that someone willing to work on mercurial packaging (such as
William Pitcock) were denied the access to the PAPT on the ground that they
do not do other python work, I will reconsider my decision and move mercurial
elsewhere (probably in the collab-maint alioth project). But until evidence of
that, I consider that PAPT admins are quite reasonable and that hosting 
mercurial
in the PAPT alioth project will add a little more value that in the collab-maint
project.
And, to answer to a private suggestion, I do not think at all that creating a
specific alioth project for mercurial is interesting : there already exist
several uptream ML to discuss development, an upstream BTS, several upstream
repo, ... So I do not see any benefice to create a new alioth project.

  Best regards,
Vincent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Looking for co-maintainer for mercurial

[William Pitcock]

Hi,

On Sun, 2008-02-24 at 15:59 +0100, Vincent Danjean wrote:
> William Pitcock wrote:
> > Hi,
> > 
> > On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote:
> >> On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> >>>  There are many good DD's around the "Python Applications Packaging
> >>>  Team" and the "Debian Python Modules Team", because generally,
> >>>  this is a Python program, so they may help with many python related 
> >>> issues.
> >> Any news on this? Do you agree with me importing to package to
> >> Python Applications Packaging Team (PAPT) and changing it's maintainer to 
> >> PAPT?
> >>
> >> Ondrej
> > 
> > I disagree because mercurial is a very specific tool, and needs to be
> > maintained by people who care about mercurial specifically. But if that
> > is what Vincent wants to do, then that's fine.
> 
> I'm already in the perl teams and, even if I did not know about the PAPT, I
> think it is similar. I mean that I think that even if the package is 
> maintained
> within a team, specific work about one package will be done by the few members
> that care about it.
> The PAPT will be add value when python transitions occurs or similar 'global'
> event in the python world.
> 
> This is why I asked to be added in the PAPT. Piotr Ożarowski just added me
> in this alioth project and I plan to upload the current version of mercurial
> in the SVN today or tomorrow.
> 
> If it happens that someone willing to work on mercurial packaging (such as
> William Pitcock) were denied the access to the PAPT on the ground that they
> do not do other python work, I will reconsider my decision and move mercurial
> elsewhere (probably in the collab-maint alioth project). But until evidence of
> that, I consider that PAPT admins are quite reasonable and that hosting 
> mercurial
> in the PAPT alioth project will add a little more value that in the 
> collab-maint
> project.
> And, to answer to a private suggestion, I do not think at all that creating a
> specific alioth project for mercurial is interesting : there already exist
> several uptream ML to discuss development, an upstream BTS, several upstream
> repo, ... So I do not see any benefice to create a new alioth project.

PAPT is indeed fine if that's the way you want to go. I'll bounce over
to IRC and ask that my account is added.

William


signature.asc
Description: This is a digitally signed message part

Re: dash bug which is affecting release goal

[Sergei Golovan]

On 2/24/08, William Pitcock <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
>  > John H. Robinson, IV writes ("Re: dash bug which is affecting release 
> goal"):
>  > > Pierre Habouzit wrote:
>  > > >   echo() { /bin/echo "$@" }
>  > >
>  > > echo() { /bin/echo ${1+"$@"}; }
>  > >
>  > > I believe you mean.
>  >
>  > Why ?!
>
>
> Because stand-alone $@ is undefined when used in this case. By using ${1
>  +"$@"}, it is ensured that $@ always starts with $1.

Expression ${1+"$@"} means "if $1 exists use "$@", otherwise nothing".
It's a workaround for a bug in some old bash version which erroneously
converted "$@" in case of empty command line into a single empty
argument. I think in new releases it isn't necessary to account for
this.

-- 
Sergei Golovan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Florian Weimer]

* William Pitcock:

> On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
>> John H. Robinson, IV writes ("Re: dash bug which is affecting release goal"):
>> > Pierre Habouzit wrote:
>> > >   echo() { /bin/echo "$@" }
>> > 
>> > echo() { /bin/echo ${1+"$@"}; }
>> > 
>> > I believe you mean.
>> 
>> Why ?!
>
> Because stand-alone $@ is undefined when used in this case. By using ${1
> +"$@"}, it is ensured that $@ always starts with $1.
>
> What a load of POSIX.

| If there are no positional parameters, the expansion of '@' shall
| generate zero fields, even when '@' is double-quoted.

Given that requirement, Sergei's explanation as an ancient bash bug
makes more sense.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Practical solutions to: the new style "mass tirage" of bugs

[Stefano Zacchiroli]

On Fri, Feb 22, 2008 at 05:19:50PM +0100, Roland Mas wrote:
> > Now, if I could run an 'apt-get source -t unstable foo' and create
> > my patch against the resulting source package, and be sure that the
> > maintainer won't reject it on the grounds of the patch not being
> > against the head (or latest, or whatever) of whichever $DVCS they
> > happen to be using, then things would be a little better.
> 
> I believe that's exactly what debcheckout(1) is for.

Indeed.

>   As for generating the patch, maybe debcommit(1) could be extended to
> provide a --diff-only option that would just output a patch rather
> than try to actually commit.  And while we're at it, maybe there could

I've just committed such a change, try "debcommit --diff" from ... well,
only from "debcheckout devscripts" for the moment.

> be a debcheckout --update option that would update the working copy to
> the current state of the repository.

I see less the point of this, but maybe it's just me. What we are
basically doing with these features is to abstract over a particular
$VCS. The initial point about debcheckout was most about retrieving the
information about where a given package is maintained and use the
appropriate tool to check it out. It was not (at least in my mind) to
enable a developer not knowing a given $VCS to use it, so I'm a bit
scared about this proposal: can't the developer just do "$VCS update"
from the last working copy she checked out?

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Looking for co-maintainer for mercurial

[Vincent Danjean]

Vincent Danjean wrote:
>   Hi,
> 
>   I'm the maintainer of the DSCM mercurial.
> At this moment, I do not have lot of free time. Moreover, I'm not a
> big user of mercurial anymore (I often use git that I find less
> intuitive but more powerful).
>   So I'm looking for co-maintainer of this package. I would be very
> disappointed if mercurial is not in a good shape for the next release.
> Anyone interested ? (I think the collab-maint alioth project would be
> a good place for further development)

mercurial in now imported in the PAPT repo:
Vcs-Svn: svn://svn.debian.org/python-apps/packages/mercurial/trunk
Vcs-Browser: http://svn.debian.org/wsvn/python-apps/packages/mercurial/trunk

> For now, there is 18 opened bugs :

For people willing to help, I think one of the first things to do is
check for each bug in the BTS if it is fixed upstream or not (the 1.0 release
is not very far) and, if not, to ensure the bug has been forwarded upstream.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 [EMAIL PROTECTED]
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude

[Jeffrey Ratcliffe]

Package: gtkimageview
Version: 1.5.0-1
Severity: normal


gtkimageview 1.6.0 has been released. I have written Perl bindings,
but they only compile against the new version, so I would appreciate
the new version of the library being packaged so that I can do the
same for the Perl bindings.

I would also be prepared to take over maintaining the library, if you
don't have time.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Florian Weimer]

* Teemu Likonen:

>> That would be one possible way of implementing it. I'd be satisfied
>> with that, and it's in the spirit of the way Debian tries to
>> standardize on interfaces that don't unduly limit implementation.
>
> To add up to this suggestion:
>
> If some patch system is used, there would be mandatory targets 
> like "patch", "patch-new" and "patch-save" in the debian/rules. These 
> can probably be included from /usr/share/quilt/quilt.make 
> or /usr/share/dpatch/dpatch.make or similar. Also a target 
> like "unpack" must be available if upstream sources are in compressed 
> form inside the orig.tar.gz.

You still need to deal with corner cases such as copying files before
patching them (unpacking the tarball is just a special case of that).

Personally, what I want to see is something that allows me to switch to
a new upstream version, to add an additional patch the top of the stack
(that's the easy case), and to add one at the bottom of the stack.  The
latter is the case relevant to security updates for which there are
suitable upstream patches.  If there are conflicts, I really want a
regular three-way merge (like in "git rebase --interactive"), not the
two-way merge plain patch provides.

It appears that both quilt and guilt do not meet the three-way merge
requirement.  I'm not sure about StGIT.  Some Mercurial docs suggest
that it's got something with queues and three-way merging, but it's
still considered experimental.

Until these tools issues have been resolved (in whatever tool, if the
workflow has been hashed out in one tool, it's relatively
straightforward to port it), those who despise patch queues in Debian
have my full support.  If this has actually been addressed in a
satisfactory manner in one tool, I'd be happy to hear about it.

And that's why I think that for the time being, Russ' policy proposal is
the right thing to do (at least the debian/README.source part, the
"patched" target is problematic and doesn't add much).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed (with 1 errors): Re: Processed: Re: Bug#467258: Info received (Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 467258 general: Net-install CD still defaults to asking for CD
Bug#467258: version 1.6.0 available
Changed Bug title to `general: Net-install CD still defaults to asking for CD' 
from `version 1.6.0 available'.
(By the way, that Bug is currently marked as done.)

> in aptitude
Unknown command or malformed arguments to command.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#467258: Info received (Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 467258 version 1.6.0 available
Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude
Changed Bug title to `version 1.6.0 available' from `general: Net-install CD 
still defaults to asking for CD in aptitude'.
(By the way, that Bug is currently marked as done.)

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: triggers in dpkg, and dpkg maintenance

[Mike Bird]

On Sun February 24 2008 06:34:44 Ian Jackson wrote:
> Raphael Hertzog writes ("Re: triggers in dpkg, and dpkg maintenance"):
> > Guillem has some responsibility in the delay here but he's perfectly
> > aware of it. I've been nagging him a bit to merge your work and he told
> > us that he has been orphaning other packages to be able to work more on
> > dpkg.
>
> I don't think this is an acceptable answer at this stage.
>
> The current maintainers have failed to shit.
> Now they should get off the pot.
>
> My bugfixes for #281057 and #432893, and my implementation of `Breaks'
> support in dselect, are outstanding too, since early November.

For those like me with short memories, would you mind (re-)posting links to
the specs for Triggers and Breaks and any other features you're suggesting.

Thanks,

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-buildpackage now reorganizing debian/control Depends field??

[Ian Jackson]

Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control 
Depends  field??"):
> I can certainly change dpkg-shlibdeps to define ${shlibs:Depends} that way.
> For other variables, it's more difficult (substition variables do not
> always contain dependencies, and the substitution is done globally on all
> the fields at the same time without any knowledge of what they are
> substituting).

This is a discussion of implementation details.  There is no
particular reason why things have to be this way.

> Note however that the dependency is always simplified... redundant
> information are discarded and I probably don't want to codify in stone
> precisely how this simplification is done. ("pkg (>= C)" implies "pkg" and
> thus "pkg" is discarded and "pkga | pkgb" is similarly discarded by
> "pkga", etc.).

I think that we should specify how the simplification is done.  This
would come out in the wash if we wrote down as part of the official
specification the currently-understood semantics of similar branches
in ands and ors.

If we wrote that specification, then the basis for the simplification
would be straightforward: it should be done only insofar as it doesn't
change the meaning.

Ian.

Re: dash bug which is affecting release goal

[Ian Jackson]

Sergei Golovan writes ("Re: dash bug which is affecting release goal"):
> Expression ${1+"$@"} means "if $1 exists use "$@", otherwise nothing".
> It's a workaround for a bug in some old bash version which erroneously
> converted "$@" in case of empty command line into a single empty
> argument. I think in new releases it isn't necessary to account for
> this.

Ah.  I haven't encountered that bug.  Was it in any recently released
version.  I don't think we should be worrying about it now, surely ?

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 16:58:01 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said: 

> On Sat, Feb 23, 2008 at 03:08:23PM +, Manoj Srivastava wrote:
>> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said:
>> 
>> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> >> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> >> <[EMAIL PROTECTED]> said:
>> >> > That does not help me during an NMU from the source package.
>> >> 
>> >> For an NMU of one of my source packages, if you can't deal with
>> >> the distributed SCM, then you need not worry about differentiating
>> >> the feature branches, fix the source conflicts, upload. I'll deal
>> >> with fallout.  Comes with the territory.
>> 
>> > If you're applying 10 to 20 different feature branches to your
>> > upstream, then that all comes to the NMU'er as one giant diff. This
>> > obviously sucks and it's what we've been complaining about Ubuntu
>> > doing to us for years. We can do better.
>> 
>> I have hear you say this before, but I am not convinced that the
>> situations are really similar.  You see, with Ubuntu, I do not see
>> any place they provide the information in a nice separate area, even
>> using their preferred SCM, bzr.
>> 
>> That is not the case when using featrure branches, the NMUer can get
>> the information they need.

>   Not really, he needs to grok your $SCM, and well, really, nobody but
> you (and his author maybe, and even that is unsure) grok baz. And not
> even everybody groks git that I'm so fond of.

If you want to NMU a package, and ituses CDBS, you need to
 understand CDBS. If it uses dpatch, you need to understand dpatch.
 Same with quilt.

You only need to understand tla and git if you need to keep
 track of the independent features in the the package development; which
 is an issue only for maintainers (not security NMUers, who are rightly
 more concerned with fixing the security hole in a timely fashion).

>   Having a clean exchange format where _anyone_ groking diff, ls,
> $EDITOR, their shell and some as basic tools is much much
> better. Nobody asks you to _work_ with those, it would be just plain
> great if you just could generate those instead of a big bloat of
> unreadable diff (maybe your packages don't have megabytes of diffs,
> but as soon as you relibtoolize a package, they do).

It is non-trivial to generate a linear series of patches from a
 set of pure feature branches.  If anyone thinks it is indeed trivial,
 and they can implemet a general solution, I'd be happy to stand
 corrected, and will use the tool. I don't think, with my experience of
 pure feature branches, that it is as trivial as the people painting
 this bikeshed think it is.

manoj
-- 
If your life was a horse, you'd have to shoot it.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dash bug which is affecting release goal

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:
> Sergei Golovan writes ("Re: dash bug which is affecting release goal"):

>> Expression ${1+"$@"} means "if $1 exists use "$@", otherwise nothing".
>> It's a workaround for a bug in some old bash version which erroneously
>> converted "$@" in case of empty command line into a single empty
>> argument. I think in new releases it isn't necessary to account for
>> this.

> Ah.  I haven't encountered that bug.  Was it in any recently released
> version.  I don't think we should be worrying about it now, surely ?

The Autoconf manual doesn't mention bash, just some pre-POSIX shells:

`$@'
 One of the most famous shell-portability issues is related to
 `"$@"'.  When there are no positional arguments, POSIX says that
 `"$@"' is supposed to be equivalent to nothing, but the original
 Unix Version 7 Bourne shell treated it as equivalent to `""'
 instead, and this behavior survives in later implementations like
 Digital Unix 5.0.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467332: RFS: bzr-eclipse - Support for Bazaar as a VCS in Eclipse

[Emilio Pozuelo Monfort]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]

* Package name: bzr-eclipse
  Version : 0.0.17
  Upstream Author : Guillermo González <[EMAIL PROTECTED]>
* URL or Web page : http://bazaar-vcs.org/BzrEclipse
* License : GPLv2
  Description : bzr support for the Eclipse IDE


bzr-eclipse is a plugin for Eclipse that enables Bazaar support in the Eclipse
SDK (JDT and CDT). The plugin should currently be considered alpha.




signature.asc
Description: OpenPGP digital signature

Re: triggers in dpkg, and dpkg maintenance

[Ian Jackson]

Mike Bird writes ("Re: triggers in dpkg, and dpkg maintenance"):
> On Sun February 24 2008 06:34:44 Ian Jackson wrote:
> > My bugfixes for #281057 and #432893, and my implementation of `Breaks'
> > support in dselect, are outstanding too, since early November.
> 
> For those like me with short memories, would you mind (re-)posting links to
> the specs for Triggers and Breaks and any other features you're suggesting.

These aren't features I'm suggesting; they've already been proposed,
designed, discussed and implemented.


The spec for Breaks: is here
 http://lists.debian.org/debian-devel/1997/10/msg00643.html
(yes, 1997!).  The implementation has already been merged into lenny's
dpkg, apt and aptitutude but it is unfortunately not practical to use
it in lenny, so the relevant packaging manuals have not yet been
updated.  The only thing which is missing is the (almost trivial)
change to dselect, which it is imperative that we include in lenny.


The spec for triggers as implemented is here:
 http://lists.debian.org/debian-dpkg/2007/08/msg9.html
and also in my dpkg git tree's doc subdirectory.


Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Jarg Sommer writes ("Re: triggers in dpkg, and dpkg maintenance"):
> Ian Jackson <[EMAIL PROTECTED]> wrote:
> > 24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email
> >   address in my git commit logs, and so forth, allegedly
> >   in order to make my changes easier to review.  At the
> >   time I was reliably informed by git experts that
> >   published branches should not be rebased.  As a rather
> >   more experienced git user it seems clear to me now that
> >   I was right to resist.
> 
> There's no problem starting a new branch and rebasing this.
> 
> % git branch trigger-new trigger
> % git rebase master trigger-new

But for the reasons which were discussed at length on debian-dpkg in
October, this is not a good idea.  Sadly I was not able to persuade
Raphael.

One should not rebase a git branch which has had other branches taken
from it, nor should one rebase a git branch which has ever been
published (at least, unless it has been published with a warning
announcing that it might be rebased).  Both of these practices lead to
severe problems.

The triggers branch has both properties: my experimental flex parser
branch is based off the triggers branch, as well as various smaller
bugfix branches, and obviously the branch has been published by my
various mailing list announcements and bug reports.


If the main git branch pulls a rebased version of my triggers branch
rather than the original, or if the same thing is attempted with patch
and diff, then attempts to merge the main head back into the flex
parser branch fail with conflicts.  Raphael assured me that it would
work just fine so I actually tried it, and so did Raphael later.  The
results were a pile of conflicts to fix up, as I had predicted.

See the results of the workflow that Raphael is suggesting:
 http://lists.debian.org/debian-dpkg/2007/10/msg00206.html
You probably want to skip the discussion and look at the transcript,
about two thirds of the way down.  Note that this is Raphael's message
and the transcript he is presenting is what he apparently considers
acceptable behaviour!

The reason it doesn't work well is that rebase, like patch/diff,
discards the revision history.  git no longer knows when trying to do
the second merge that the triggers commits on the main branch are the
same as the ones on the flex branch.  So it tries to apply them again,
which doesn't work.  git's algorithm is clever enough, like cvs's but
unlike some version control systems', to spot the identical changes in
cases where there is no interaction between the flex and triggers
changes.  But there are quite a few such interactions and every one
generate a spurious conflict.

This can be avoided by using git properly.  It already knows how to
track which changes have already been merged.  If you do it the right
way (ie, just merge from my branch) then there are no conflicts.
Everything is automatic; it just does the right thing.

Of course you get a slightly messier revision history because the main
dpkg revision history will then contains everything I actually did,
rather than some sanitised rewrite of history.  I think this is good
because I want to know the actual context of a change, but Raphael
thinks it is a problem because he wants a clean and pretty revision
log.

Even if you thought a revision log containing an invented history was
a good idea, it's surely not worth manually resolving conflicts to get
it - especially in a project which has about three or four branches
and three or four committers.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: QUESTION: Debian Policy: Manual pages

[Marvin Renich]

* Ian Jackson <[EMAIL PROTECTED]> [080224 09:18]:
> Bas Zoetekouw writes ("Re: QUESTION: Debian Policy: Manual pages"):
> > Why a recommends?  In order to satisfy the spirit of policy ("every
> > binary must have a man page") it would need to be a depends, imo.
> 
> I think the point of policy is to ensure the manpage exists, not to
> require that it be installed.
> 
> I think Suggests is the right dependency.  There is nothing wrong with
> installing a package without its documentation.
> 
> Ian.
> 

IANADD, but as a user, I disagree.  Policy [12.1] states:

  Each program, utility, and function should have an associated manual
  page included in the same package.

There is a big difference between a man page and more complete
documentation like a User Manual.

I _expect_ a man page for every executable.  A Depends, in my mind,
clearly satisfies the policy requirement, as the man page will be
available unless I use dpkg --force-* or some other drastic measure to
override the depends.  A Recommends may satisfy this (especially now
that apt defaults to installing them), but not quite as clearly.

Harshula, from your description it is not clear if c.tar.gz contains
substantial documentation beyond man pages.  If c.tar.gz contains very
little besides man pages and basic documentation, then Depend on c.deb,
and leave the man pages there.  If the tarball contains a lot of other
documentation, my preference as a user would be to have the man pages
moved into the binary a.deb and b.deb packages, and Recommend or Suggest
c.deb (without the man pages).

If you are making one source package with three binary packages, moving
the man pages to a different binary package is trivial.  If you are
making three separate source packages, I would still prefer to have the
man pages copied to the packages with their corresponding executable,
with a note in the README.Debian identifying the originating tarball.

I know this is more work (in the separate source package case), but as a
user I would appreciate not having to keep around a large documentation
package just to get man pages.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Practical solutions to: the new style "mass tirage" of bugs

[Stefano Zacchiroli]

On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
> If there are sets of usertags which are in common use by a reasonable
> number of diverse packages, and are something that would normally be
> put on the [EMAIL PROTECTED] user (that is to say, make them
> visible by default) then file a bug against bugs.debian.org askiing
> for that tag to be made a real tag.
> 
> That's the best way to standardize usertags which are currently not
> bts-wide tags.

Ack on the general principle.

However, the need which was pointed out to seemed to me more than a tag:
in my head it was distilled as "priority", as available in other bug
tracking systems. This is something that can be encoded with usertags,
but such an encoding does not have good properties such as mutual
exclusion of alternative priorities.

In this respect, if I were the one to ask something to be integrated in
the BTS, I would ask for the implementation of the priority feature,
which is more than just adding a new tag.

[ FWIW, I would second the proposers of such a feature, but right now
I'm offline and can't even check if it is already there as a feature
request, possibly marked as wontfix ... ]

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Henrique de Moraes Holschuh]

On Sun, 24 Feb 2008, Ian Jackson wrote:
> But for the reasons which were discussed at length on debian-dpkg in
> October, this is not a good idea.  Sadly I was not able to persuade
> Raphael.

Given that many of us work on the kernel, some of us are both upstream and
downstream in git, and therefore know *both* sides of the troubles and
advantages of git rebase quite well...  I can see why you'd have a tough
time convincing anyone to change his mind about it.  We will have lived it
ourselves and made up our minds about it a long time ago, already...

> One should not rebase a git branch which has had other branches taken
> from it, nor should one rebase a git branch which has ever been
> published (at least, unless it has been published with a warning
> announcing that it might be rebased).  Both of these practices lead to
> severe problems.

Correct.  Yet, rebasing is still routinely performed in the Linux kernel
development.  Indeed it should not be done for trivial reasons, as it does
cause more work downstream, so the question is: what is a non-trivial
reason?

In the Linux kernel, we (as downstream) will usually cope with the problems
it causes if it means clean history upstream.  IMO, such behaviour is much
better for the whole project later on.  Say, in five years or so, when a
different team will be working on dpkg.  Or when someone is trying to chase
down a bug, and has to look into the history to understand something.

Many of the important subsystems in the Linux kernel community lives with
this, it would not be done like that if rebasing was just a cosmetic thing.

For one, merging properly rebased branches makes it a *LOT* easier to
bissect, otherwise, you could find yourself bissecting a dpkg of two years
ago to test a recently-merged feature whose work branches were started that
long ago...

In fact, it is bad enough in the kernel already, even with so much rebasing
going on, because often the kernel you get while bissecting is just pure
crap because people don't test enough before they send merge requests :-)

> If the main git branch pulls a rebased version of my triggers branch
> rather than the original, or if the same thing is attempted with patch
> and diff, then attempts to merge the main head back into the flex
> parser branch fail with conflicts.  Raphael assured me that it would
> work just fine so I actually tried it, and so did Raphael later.  The
> results were a pile of conflicts to fix up, as I had predicted.

Yes.  One has to just tough it up and rebase everything (and so does one's
downstream).  Rebase often enough in key points, and it won't be such a big
pain to keep up with it.

> See the results of the workflow that Raphael is suggesting:
>  http://lists.debian.org/debian-dpkg/2007/10/msg00206.html
>
> You probably want to skip the discussion and look at the transcript,
> about two thirds of the way down.  Note that this is Raphael's message
> and the transcript he is presenting is what he apparently considers
> acceptable behaviour!

Sure he does.  We have a few thousand doing it in the kernel, why shouldn't
he consider it acceptable?  It is not done just for the kick of it.  Clean
history has a real benefit when it comes down to debugging and new
developers joining in.

Heck, some subsystems (like ACPI) have a rule where you have to *separate*
all your changes into *rebased and clean* topic branches, merge them over a
clean rebased branch from upstream, and submit the result of THAT merge. If
you don't do it, the upstream maintainer will do it for you by force (and
pick up your patches by email only, never pulling from you).

OTOH, if you don't care for clean history, then the point is moot and
rebasing is just a waste of everyone's effort.

> This can be avoided by using git properly.  It already knows how to
> track which changes have already been merged.  If you do it the right
> way (ie, just merge from my branch) then there are no conflicts.
> Everything is automatic; it just does the right thing.

That would require your branch to be very clean, and would still cause
issues when bissecting.

If you never do bissects, and you don't care for a mess here and there in
the history, indeed there is no good reason for rebasing.

> Of course you get a slightly messier revision history because the main
> dpkg revision history will then contains everything I actually did,
> rather than some sanitised rewrite of history.  I think this is good
> because I want to know the actual context of a change, but Raphael
> thinks it is a problem because he wants a clean and pretty revision
> log.

Yep.  The real question is: which one is useful to people doing debugging
and new developers joining in?  Is that worth the effort?

I vote for clean history and a bissectable tree, and I think it is worth the
effort.  But I am no dpkg developer, this is a thing you guys have to find
an agreement among yourselves.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  

Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor

[Sylvestre Ledru]

Le dimanche 24 février 2008 à 01:15 +0100, Michael Biebl a écrit :
> Guus Sliepen wrote:
> > On Sat, Feb 23, 2008 at 01:00:43PM +0100, Sylvestre Ledru wrote:
> > 
> >> I updated it:
> >> http://svn.debian.org/wsvn/pkg-scicomp/eficas/trunk/debian/control?op=file&rev=0&sc=0
> >> Is it ok for do you want me to develop this more ?
> > 
> >> Description: ASter Command FIle Editor
> > [...]
> > 
> > The long description looks fine now, but I'd write the following short
> > description instead:
> > 
> > Description: graphical editor for Code Aster command files
> > 
> 
> Well, ASter Command FIle Editor written backwards yields EFICAS, so I
> guess there is a reason why Sylvestre wrote the short description the
> way it is ;-)
To be precise, EFICAS stands for "Editeur de FIchiers de Commandes
ASter" which can be translated in English by ASter Command FIle
Editor ;)
It is a pun on the french word "efficace" which means
efficient/efficacious.

But I agree with Guss on the description, I updated it.

Sylvestre



signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#467258: Apologies

[Jeffrey Ratcliffe]

Apologies for messing around with this bug - I seem to be having a bit
of finger/brain trouble



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Robert Collins]

On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
> Yet, rebasing is still routinely performed in the Linux kernel
> development. 

What I find interesting and rather amusing here is Linus talking
negatively about rebase: in particular its propensity to turn tested
code (what you actually committed) into untested code (what you
committed + what someelse has done, in a version of a tree no human has
ever evaluated for correctness).

-Rob

-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: How to cope with patches sanely

[Guillem Jover]

On Sat, 2008-02-23 at 09:08:23 -0600, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said: 
> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
> 
> Currently vapourware, no?

I want to clarify this, as I've seen it mentioned several times on this
thread. dpkg-source supports extracting Wig&Pen since etch. The missing
bit is source package generation (I posted a proof of concept script to
convert quilted source packages to debian-dpkg [0]).

regards,
guillem

[0] 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Pierre Habouzit]

On Sun, Feb 24, 2008 at 06:49:10PM +, Ian Jackson wrote:
> Jarg Sommer writes ("Re: triggers in dpkg, and dpkg maintenance"):
> > Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > 24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email
> > >   address in my git commit logs, and so forth, allegedly
> > >   in order to make my changes easier to review.  At the
> > >   time I was reliably informed by git experts that
> > >   published branches should not be rebased.  As a rather
> > >   more experienced git user it seems clear to me now that
> > >   I was right to resist.
> > 
> > There's no problem starting a new branch and rebasing this.
> > 
> > % git branch trigger-new trigger
> > % git rebase master trigger-new
> 
> But for the reasons which were discussed at length on debian-dpkg in
> October, this is not a good idea.  Sadly I was not able to persuade
> Raphael.

  Raphael is wrong to ask you to rebase, he's _really_ wrong about that,
but *you* also are wrong to ask him to pull (aka fetch + merge). The
usual way is that _you_ merge the current state of dpkg in your work so
that _you_ solve the conflicts and issues, and _then_ mainline can see
how it looks and look at the cleansed diff.

  IOW, you have to merge master, preferably in a new branch than your
trigger-new one, like a master-pu-triggers or whatever, and if mainline
is pleased or can read that patch (that I'm sure isn't _that_ big) they
_then_ will be able to merge that branch that would just be a
fast-forward.

  Note that they may ask you to rework this merge if they had done some
further commits, but if you mkdir .git/rr-cache then git is able to use
recorded images of already solved conflicts so that merging the same
conflicts again and again doesn't costs you any time.

Cheers,
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpnqb1X6frq0.pgp
Description: PGP signature

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow <[EMAIL PROTECTED]> said: 

> On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>> Now, you are trying to make me go towards a mechanism I think is
>> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>> shaky linear patch series) as opposed to pure, independent feature
>> branches, for benefits I still think are dubious, so expect serious
>> push back.  Especially if for every upload I'll have to redo all the
>> integration work of the past; ain't gonna happen.
>> 
>> I am not trying to convince you of the error of your ways.  Please
>> desist trying to convince me of mine.

> No one, not me, nor anyone else in this thread that I've seen, is
> saying that you should abandon your sytem. What we want is a
> consistent method of dealing with differences from
> upstream. Currently, we have one giant .diff.gz, which people hack
> around either with patch systems or vcs's. If we switch to something
> other than a monolithic .diff.gz on top of a .orig.tar.gz, then we win
> because currently we just have a lot of chaos.

So far, this is OK. The devil, though, lies in the details.

> No matter what you want to say about your feature branches, you *must*
> apply them in a linear fashion to your final source tree that you ship
> in the package. This is no way around it.

But there is no such linearization, not in the way that quilt et
 al do it.  The state of such integration is not maintained in the
 feature branches; it is in the history of the integration branch.  As
 each feature branch was created or developed, if there were any
 conflicts, these conflicts were resolved in the integration branch. And
 the integration branch does not keep track of what changes come from
 which branch -- that is not its job. And it does not keep the
 integration patches up to date either -- that again is not its
 job. Details below.

There are only Two use cases I care about. A) Feed each pure
 feature to upstream as an up to date patch against current upstream --
 this is what the feature branch does. B) Have an integrated source of
 all features ready to compile for Debian -- and easy to keep updated
 with lates revisions.  This is the task of the integration branch.


> This idea, a linear stack of changes one on top of the other, is the
> commonality between every one of the different means of handling
> changes to upstream, be they maintained by a patch system or a
> vcs. What we want is to stanardize this concept so that our general
> tools like dpkg are aware of it.

This is where we start to differ. More on this below.

> Given what I know about your system, the only change you would have to
> make is that instead of integrating directly in a final branch, you
> generate a diff and throw that along with the diff's name in to
> debian/patches.

I do not think you have thought it through.  Let us try seeing
 how this will not work: Say I have have feature branches A-F.  When
 development happens on branch A that requires some conflict resolution
 on the integration branch, I do the resolution, and fix up the
 integration branch.  The fix applied depends on what order the features
 were merged in -- and this is not something I need to keep track of, so
 I do not.

 As more development happens, and non-overlapping
 changes in the same area occur, the patch would no longer apply.  Other
 feature branches may make changes in the area; and again, make the old
 patch obsolete.

The a new upstream version comes along, and more changes
 happen.  By this time, the old patch will not apply even to
 upstream. Now rinse and repeat -- the patch you blithely threw into
 ./debian/patches is just dead bit by now.

> That's it. It could be totally automated from your
> current setup without much work, if that's what you want.

I don't think this can be automated.  However, if you think you
 can solve the problem, I'll stand down my objections.  Love to see it
 demonstrated first.

Indeed, the only way to redo the information in the integration
 branch is to start with the original upstream, from several years ago,
 determine which feature branch was merged in what order, what order any
 improvements were applied, redo the conflict resolution patches, redo
 the upstream version updates in the correct order, and get to the
 current integration branch.

Heh. Good luck.

> This is not making you give up anything, it's about improving the base
> standard so everyone can get more information without learning a
> zillion different patch systems and vcs's. As a result, we can focus
> on improving the code itself instead of the process of managing the
> code.

> So, in summary, stop trying to act like you're being forced to do
> something that's going to hurt you. No one is taking away your toys.

Words. Lets us see some code, eh?

manoj
-- 
When a man knows no this shore, other

Re: dpkg-buildpackage now reorganizing debian/control Depends field??

[Joe Smith]

"David Paleino" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Il giorno Fri, 22 Feb 2008 10:04:52 -0300
Otavio Salvador <[EMAIL PROTECTED]> ha scritto:


As I said, for APT, the order has meaning _always_.

apt-get install foo bar

Is completely different of

apt-get install bar foo


Could you please elaborate on this? I know for sure that Pre-Depends exists
just for the cases where order _does_ matter. But I've never had problems 
in

installing packages in any order (or probably I've just been lucky).

David


I'm not sure, but I think the follwing indicates the problem.

Imagine that you have none of {foo, bar, baz, qux} installed.

Foo has "Depends: baz|qux"
and Bar has "Depends: qux|baz"

My understanding is that in that case

apt-get install foo bar

installs {foo, bar, baz} but

apt-get install bar foo

installs {foo, bar, qux}.

This is not always a major problem, and in most cases the end user will not 
notice
it, but under rare cases it is theoetically possible that the dependency 
chain with conflicts could cause problems. (At least it seems like that 
might be the case)






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467359: ITP: libisoburn -- libisoburn enables creation and expansion of ISO-9660 filesystems on all CD/DVD media by libburn

[Matthew Rosewarne]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libisoburn
Version: 0.1.0
Upstream Author: Vreixo Formoso <[EMAIL PROTECTED]>, Thomas Schmitt <[EMAIL 
PROTECTED]>
URL: http://libburnia-project.org
License: GPL
Description: ISO-9660 image manipulation wrapper library

"libisoburn is a frontend for libraries libburn and libisofs which enables
creation and expansion of ISO-9660 filesystems on all CD/DVD media supported
by libburn. This includes media like DVD+RW, which do not support
multi-session management on media level and even plain disk files or block
devices." (http://libburnia-project.org/wiki/Libisoburn)

The "xorriso" ISO-9660 image manipulation program is also included.


signature.asc
Description: This is a digitally signed message part.

Re: Bug#467038: RFP: pytrainer -- Free Sport Training Center

[Fiz Vazquez]

> Fiz, can you help me for this? Would you be interested, as upstream
> author, to help maintaining an *official* Debian package for your
> software?

It would be great for me :)

what files do you need?

How do you want me to send you the files? 


best regards



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Henrique de Moraes Holschuh]

On Mon, 25 Feb 2008, Robert Collins wrote:
> On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
> > Yet, rebasing is still routinely performed in the Linux kernel
> > development. 
> 
> What I find interesting and rather amusing here is Linus talking
> negatively about rebase: in particular its propensity to turn tested
> code (what you actually committed) into untested code (what you
> committed + what someelse has done, in a version of a tree no human has
> ever evaluated for correctness).

Yet, Linus himself is the one who refuses to merge anything with dirty
history :-)

It is a two-way knife.  You choose the side of it you prefer to hold to, but
you have to be careful with it *anyway*.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467368: ITP: gmyth-upnp -- The GObject based library for using a UPnP MythTV backend

[Mario Limonciello]

Package: wnpp
Severity: wishlist
Owner: Mario Limonciello <[EMAIL PROTECTED]>


* Package name: gmyth-upnp
  Version : 0.7
  Upstream Author : Alexsandro Jose Virginio dos Santos <[EMAIL PROTECTED]>
Hallyson Luiz de Morais Melo <[EMAIL PROTECTED]>
Leonardo Sobral Cunha <[EMAIL PROTECTED]>
Rosfran Lins Borges <[EMAIL PROTECTED]>
* URL : http://gmyth.sourceforge.net
* License : GPL,
  Programming Lang: C
  Description : The GObject based library for using a UPnP MythTV backend

 GMyth-UPnP is a library intended to access MythTV backend functionalities
 from a GLib/GObject perspective via UPnP. It includes access to the program 
 guide, recorded programs, scheduling, etc.

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-updates
  APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 
'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-8-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Pierre Habouzit]

On Sun, Feb 24, 2008 at 07:46:59PM +, Henrique de Moraes Holschuh wrote:
> On Sun, 24 Feb 2008, Ian Jackson wrote:
> > But for the reasons which were discussed at length on debian-dpkg in
> > October, this is not a good idea.  Sadly I was not able to persuade
> > Raphael.
> 
> Given that many of us work on the kernel, some of us are both upstream and
> downstream in git, and therefore know *both* sides of the troubles and
> advantages of git rebase quite well...  I can see why you'd have a tough
> time convincing anyone to change his mind about it.  We will have lived it
> ourselves and made up our minds about it a long time ago, already...

  For having worked quite a bit in git.git (I sent my 100th patch that
should go upstream on yesterday), I can tell that it's not true. I mean,
the very people designing git, are also the one using it in the kernel
developpement, and look at git history, it's a suite of topic branches
merges. For example, look at all the commits named 'merged branch
ph/...' that would be the branches that come from my work.

  And AFAICT, the kernel works in the very same way. What gets rebased
though, are the bugfixes patches that come by 2 or 3, and that add no
value when added as a specific branch. Usually those in git.git are
applied on top of the 'maint' branch (aka the maintenance branch) and
then merged back into master, and then back into 'next' (where the devel
happens).

  IOW, it depends, and if you work on a new _feature_ it's really rarely
rebased.

> OTOH, if you don't care for clean history, then the point is moot and
> rebasing is just a waste of everyone's effort.

  The question isn't about clean history, but a faithful one. When you
rebase a branch, you pretend that you developped it on top of where you
rebased it onto. Except that you didn't.

> > This can be avoided by using git properly.  It already knows how to
> > track which changes have already been merged.  If you do it the right
> > way (ie, just merge from my branch) then there are no conflicts.
> > Everything is automatic; it just does the right thing.
> 
> That would require your branch to be very clean, and would still cause
> issues when bissecting.
> 
> If you never do bissects, and you don't care for a mess here and there in
> the history, indeed there is no good reason for rebasing.

  You're totally on crack, git bissect works really well across merges,
and has really more chances to do so, because when you rebase, you
usually e.g. don't check that intermediates points build, only the top.
And an intermediate point that doesn't build is _WAY_ more likely to be
a PITA for bisecting than a merge point.

  FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the
issue you want to track down) really efficiently.

> I vote for clean history and a bissectable tree, and I think it is worth the
> effort.  But I am no dpkg developer, this is a thing you guys have to find
> an agreement among yourselves.

  You vote for the mad route. Sorry, but it makes absolutely no sense to
me. Ian's work was done at some point, tested from that point, and it
makes sense to remember that fact. Actually it's insane to forget that
fact. And rebasing is just pretending that fact never existed. It's just
wrong.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpjVM63Zimu3.pgp
Description: PGP signature

Debian Configuration Packaging System

[Timothy G Abbott]

Anders Kaseorg and I created a system of CDBS modules (which we've 
tentatively packaged as the config-package-dev package) for creating 
Debian configuration packages.  By configuration packages, we mean 
packages that configure an existing Debian system by applying dpkg-divert 
to configuration files.  Our configuration package system makes the 
process of creating configuration packages efficient.


Our system is targeted at site defaults (i.e. configuration for a 
university or a company), though it is useful for smaller scales as well. 
It has some support for multiple layers of site defaults, e.g. MIT, CSAIL 
(an MIT lab), and a research group within CSAIL might all use it to 
configure their machines [1].


The configuration package system is documented in detail at 
; there are links from there to 
the complete source code and compiled Debian packages.  The license is GPL 
(the same as that for CDBS itself).


Since this package is adding a new feature to Debian itself, we think our 
system should be discussed before we submit an ITP bug.  There are some 
changes to Debian that would enhance the effectiveness of this system, 
(such as having all packages include md5sums and making ucf interact well 
with dpkg-divert'ed configuration files), which should perhaps be 
discussed in this context as well.


We would appreciate any questions, comments, or feedback.

-Tim Abbott and Anders Kaseorg

[1] A version of config-package-dev has been in use as part of the 
Debathena Project (http://debathena.mit.edu/) at MIT for a few years now. 
Debathena is an enhanced port of Athena (MIT's cross-platform computing 
environment) from RHEL 4 and Solaris 10 to Debian (and Ubuntu).  It's been 
adopted by MIT's introductory computer science class and some small 
clusters; but has been particularly popular for private machines whose 
owners want to access Athena services easily (for example, AFS and 
Kerberos should "just work") on an existing Debian/Ubuntu machine that 
they are free to configure.  Athena is planning to migrate to Debathena 
later this year.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Ben Finney]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> David Nusinow <[EMAIL PROTECTED]> said:
> 
> > No matter what you want to say about your feature branches, you
> > *must* apply them in a linear fashion to your final source tree
> > that you ship in the package. This is no way around it.
> 
> But there is no such linearization, not in the way that
>  quilt et al do it. The state of such integration is not maintained
>  in the feature branches; it is in the history of the integration
>  branch.

Is this (the integration branch and its history of changes) not the
linear sequence of changes that David Nusinow is asking for?

>  And the integration branch does not keep track of what changes come
>  from which branch -- that is not its job.

Doesn't each commit message in the integration branch's history state
what merge you were performing at each revision? You've previously
described your workflow as one where you carefully integrate each
feature branch separately into the integration branch. Do your commit
messages in the integration branch not state what individual feature
branch you're merging in?

It seems to me that the analogue to a linear sequence of patches is
the revision history of your integration branch. Granted, this doesn't
give patches against a pristine upstream except from some initial
state.

-- 
 \ "Some mornings, it's just not worth chewing through the leather |
  `\  straps."  -- Emo Philips |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#467375: ITP: sakura -- a lightweight vte-based terminal emulator

[Andrew Lee]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee <[EMAIL PROTECTED]>

* Package name: sakura
  Version : 2.0.1
  Upstream Author : David Gómez Espinosa <[EMAIL PROTECTED]>
* URL : http://www.pleyades.net/david/sakura.php
* License : (GPL)
  Programming Lang: (C, C++)
  Description : a lightweight vte-based terminal emulator

 Sakura is a lightweight and easy to use terminal emulator with fewer 
 dependencies.
 Features:
  * Uses a notebook to provide several terminals in one window.
  * Adds a contextual menu with some basic options. No more no less.
 .
 For people that already know GNOME 2 terminal, Xfce4 terminal and are
 searching for a lighter but comparable replacement, sakura might be 
 the answer.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Re: Debian Configuration Packaging System

[Russ Allbery]

Timothy G Abbott <[EMAIL PROTECTED]> writes:

> Anders Kaseorg and I created a system of CDBS modules (which we've
> tentatively packaged as the config-package-dev package) for creating
> Debian configuration packages.  By configuration packages, we mean
> packages that configure an existing Debian system by applying
> dpkg-divert to configuration files.  Our configuration package system
> makes the process of creating configuration packages efficient.

It's generally accepted wisdom that dpkg-divert doesn't work properly with
configuration files and isn't safe.  I admit to have done something
similar in the past, but I have noticed odd things that didn't matter for
my particular use, but which meant that the support didn't work right.
That's likely to be an issue for a general package.  Fixing dpkg-divert to
work correctly with configuration files (if possible) would probably be a
good idea.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:

>> But there is no such linearization, not in the way that
>>  quilt et al do it. The state of such integration is not maintained
>>  in the feature branches; it is in the history of the integration
>>  branch.

> Is this (the integration branch and its history of changes) not the
> linear sequence of changes that David Nusinow is asking for?

Yes, but you don't, in the general case, completely develop some feature
on a branch and then merge it only once.  You do some work on one branch,
merge it, do some work on another branch, merge it, do more work on the
first branch and merge it again, import a new upstream and merge it into
all of your branches, do some more work on the feature and merge it
again

I can see Manoj's point.  It's not at all clear to me that there's a
useful linearization of the feature branches after that sort of workflow
has continued for a while.

(I'm now maintaining two of my packages using only Git and feature
branches without any patch system so that I can get some practical
experience with this and understand the workflow better.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Henrique de Moraes Holschuh]

On Mon, 25 Feb 2008, Pierre Habouzit wrote:
>   For having worked quite a bit in git.git (I sent my 100th patch that
> should go upstream on yesterday), I can tell that it's not true. I mean,
> the very people designing git, are also the one using it in the kernel
> developpement, and look at git history, it's a suite of topic branches
> merges. For example, look at all the commits named 'merged branch
> ph/...' that would be the branches that come from my work.

Of course branches are merged.  But some of them are *rebased* before the
merge request is sent.  And rebased a lot while being developed, too (I
count stgit and such tools usage as rebasing).

>   And AFAICT, the kernel works in the very same way. What gets rebased

No, it doesn't work always like that.  Of course, parts of the kernel
development are really patch-based (stgit, quilt, quilt-on-top-of-git, etc),
and get into git at the last step only, and that may well have a lot to do
with it.

Heck, some subsystems and maintainers get patches only over email, which
is the same as a rebase from the patch submitter's PoV.

> > OTOH, if you don't care for clean history, then the point is moot and
> > rebasing is just a waste of everyone's effort.
> 
>   The question isn't about clean history, but a faithful one. When you
> rebase a branch, you pretend that you developped it on top of where you
> rebased it onto. Except that you didn't.

That's a way to look at it, yes.

> > That would require your branch to be very clean, and would still cause
> > issues when bissecting.
> > 
> > If you never do bissects, and you don't care for a mess here and there in
> > the history, indeed there is no good reason for rebasing.
> 
>   You're totally on crack, git bissect works really well across merges,
> and has really more chances to do so, because when you rebase, you
> usually e.g. don't check that intermediates points build, only the top.
> And an intermediate point that doesn't build is _WAY_ more likely to be
> a PITA for bisecting than a merge point.

Only if you are a lazy ass.  Oh wait, that describes a LOT of developers out
there, in Debian and Linux alike ;-)   *I* checkpatch (argh), build, AND do
a light runtime-test at every point of a set I am sending upstream (and
that's after the heavy testing during development).  I can't speak for
others, though.

As for me being on crack, I better explain it a bit more what I mean,
apparently...

1. You start developing by branching from upstream (mainline)

2. Upstream fixes some critical bugs (maybe they are not critical for you,
   but they are for a third party we will call "tester"), after you branched
   from it.  You either ignore any updates in mainline while working on your
   branch, or (more likely, for long-lived branches) you merge from mainline
   back into your branch a number of times during development (always
   without rebasing).

3. You finish your work and ask upstream to pull from you.

How well will bissect work for the tester, now, if he is trying to find out
something that broke with the final merge between two points where something
*else* is broken in mainline?

I am not sure the above is something that happens on git or dpkg, but
happens all the time in the kernel.  Merge of recently-rebased subsystem
trees lessen that pain a lot.

This is all due not to bugs in git, it is dealing just fine with the merges
and branches and bissecting those.

>   FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the
> issue you want to track down) really efficiently.

Yes, it does. But that is NOT enough for certain projects. And very
long-lived branches are the most likely ones to cause such problems.

> > I vote for clean history and a bissectable tree, and I think it is worth the
> > effort.  But I am no dpkg developer, this is a thing you guys have to find
> > an agreement among yourselves.
> 
>   You vote for the mad route. Sorry, but it makes absolutely no sense to
> me. Ian's work was done at some point, tested from that point, and it
> makes sense to remember that fact. Actually it's insane to forget that
> fact. And rebasing is just pretending that fact never existed. It's just
> wrong.

There is no excuse for accepting untested code for merges in anything that
doesn't go at breakneck speed.  So I have to either assume it is going to be
completely tested right before the merge, or right after it.  Or both ;-)

If it is going to be tested by the submitter right before the merge, he
might as well do it properly and test it at every step of the changeset
(which is the right thing to do, if you want bissections to be easy) and at
that point, rebasing can't introduce new bugs.  In fact, it will let the
submitter find any new latent bugs due to mainline changes *before*
submitting a merge request, which is the right thing to do.

If the maintainer has to test everything the submitter did after he merges
news code, he might as well clean up any dirty history, because that will
help tes

Re: Debian Configuration Packaging System

[Tim Abbott]

I'll note that we wrap our dpkg-divert calls with a bunch of 
error-handling code that we found quite important for correctly recovering 
from people hitting ^C in the middle of installation (see 
 
for the code).  Earlier iterations that did not do this were plagued with 
problems whenever there were errors in installation.


We also ran into a few packages which will overwrite configuration files 
that they manage via debconf, overwriting our symlink every time the 
relevant package is upgraded.  But I think that's a bug in those Debian 
packages, since the same problem would occur for any manual changes to 
those configuration files as well (I think in the cases I've seen it is a 
failure to check whether an upgrade is occuring when generating the 
configuration file in postinst).


What other problems have you experienced?

-Tim Abbott

On Sun, 24 Feb 2008, Russ Allbery wrote:


Timothy G Abbott <[EMAIL PROTECTED]> writes:


Anders Kaseorg and I created a system of CDBS modules (which we've
tentatively packaged as the config-package-dev package) for creating
Debian configuration packages.  By configuration packages, we mean
packages that configure an existing Debian system by applying
dpkg-divert to configuration files.  Our configuration package system
makes the process of creating configuration packages efficient.


It's generally accepted wisdom that dpkg-divert doesn't work properly with
configuration files and isn't safe.  I admit to have done something
similar in the past, but I have noticed odd things that didn't matter for
my particular use, but which meant that the support didn't work right.
That's likely to be an issue for a general package.  Fixing dpkg-divert to
work correctly with configuration files (if possible) would probably be a
good idea.

--
Russ Allbery ([EMAIL PROTECTED])   


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[David Nusinow]

On Sun, Feb 24, 2008 at 05:10:16PM -0800, Russ Allbery wrote:
> Ben Finney <[EMAIL PROTECTED]> writes:
> > Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 
> >> But there is no such linearization, not in the way that
> >>  quilt et al do it. The state of such integration is not maintained
> >>  in the feature branches; it is in the history of the integration
> >>  branch.
> 
> > Is this (the integration branch and its history of changes) not the
> > linear sequence of changes that David Nusinow is asking for?
> 
> Yes, but you don't, in the general case, completely develop some feature
> on a branch and then merge it only once.  You do some work on one branch,
> merge it, do some work on another branch, merge it, do more work on the
> first branch and merge it again, import a new upstream and merge it into
> all of your branches, do some more work on the feature and merge it
> again
> 
> I can see Manoj's point.  It's not at all clear to me that there's a
> useful linearization of the feature branches after that sort of workflow
> has continued for a while.
> 
> (I'm now maintaining two of my packages using only Git and feature
> branches without any patch system so that I can get some practical
> experience with this and understand the workflow better.)

The problem is that you and Manoj assume that this is the only way to do
things. I don't believe this. Pierre Habouzit has been experimenting with
an alternative method of feature branches that exports to a linear stack of
diffs just fine. Just because Manoj is doing something one way right now
doesn't mean it's the only or even the correct way to do it.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Configuration Packaging System

[Russ Allbery]

Tim Abbott <[EMAIL PROTECTED]> writes:

> We also ran into a few packages which will overwrite configuration files
> that they manage via debconf, overwriting our symlink every time the
> relevant package is upgraded.  But I think that's a bug in those Debian
> packages, since the same problem would occur for any manual changes to
> those configuration files as well (I think in the cases I've seen it is
> a failure to check whether an upgrade is occuring when generating the
> configuration file in postinst).

Configuration files generated by debconf may not be manually changed
without running this risk, including by humans.  Generally, this is
documented in the file.  I have several of those in packages I maintain.
This is a pretty widely accepted way of dealing with configuration files,
and the right way to modify those files is with debconf pre-seeding rather
than by trying to overwrite the file, IMO.

I don't agree that this is a bug in the package in the general case,
although there may be packages that are more aggressive about overwriting
than need to be.

> What other problems have you experienced?

I've seen the diverted configuration file disappear, making it impossible
to undo the diversion, and never did track down why that happened.  I
haven't run into any problems in cases where the diversion is never
dropped, though.  (But renaming the package that manages the diversions is
something that dpkg-divert doesn't deal with at all well.)

We're using Puppet to handle this instead of Debian packages, and I'm much
happier with that solution.  I wouldn't recommend doing what you're doing,
but of course you may have improved the tools sufficiently that it's a
good idea.  :)  Also, I know that most of the alternatives involve some
central management system, and there are a lot of use cases that don't
allow for that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Russ Allbery]

David Nusinow <[EMAIL PROTECTED]> writes:

> The problem is that you and Manoj assume that this is the only way to do
> things. I don't believe this. Pierre Habouzit has been experimenting
> with an alternative method of feature branches that exports to a linear
> stack of diffs just fine. Just because Manoj is doing something one way
> right now doesn't mean it's the only or even the correct way to do it.

Well, I definitely don't think it's the only way to do things, and I've
been one of the people arguing in favor of quilt and exporting to a set of
patches.  :)  But the "native" Git workflow that people have previously
written up for Debian packages doesn't seem to me to linearize very
easily, and IMO one of the points here was to let maintainers keep using
their native workflows and use the package format for interchange.
Changing the workflow to allow easier export to a particular package
format seems to be going the wrong direction to me.

In other words, I still think a patch-based package format is a good idea
and would be very valuable for a lot of what's in Debian, but I have to
agree with Manoj's point, based on what I've seen so far, that converting
an arbitrary Git or Arch repository for Debian package maintenance to such
a package format isn't necessarily easy.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[David Nusinow]

On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
> David Nusinow <[EMAIL PROTECTED]> writes:
> 
> > The problem is that you and Manoj assume that this is the only way to do
> > things. I don't believe this. Pierre Habouzit has been experimenting
> > with an alternative method of feature branches that exports to a linear
> > stack of diffs just fine. Just because Manoj is doing something one way
> > right now doesn't mean it's the only or even the correct way to do it.
> 
> Well, I definitely don't think it's the only way to do things, and I've
> been one of the people arguing in favor of quilt and exporting to a set of
> patches.  :)  But the "native" Git workflow that people have previously
> written up for Debian packages doesn't seem to me to linearize very
> easily, and IMO one of the points here was to let maintainers keep using
> their native workflows and use the package format for interchange.
> Changing the workflow to allow easier export to a particular package
> format seems to be going the wrong direction to me.
> 
> In other words, I still think a patch-based package format is a good idea
> and would be very valuable for a lot of what's in Debian, but I have to
> agree with Manoj's point, based on what I've seen so far, that converting
> an arbitrary Git or Arch repository for Debian package maintenance to such
> a package format isn't necessarily easy.

Ok, that's fair. In the worst case then people who want to use this sort of
workflow could stick everything in a giant diff like we do now, so nothing
would be lost.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Manoj Srivastava]

On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> David Nusinow <[EMAIL PROTECTED]> said:
>> 
>> > No matter what you want to say about your feature branches, you
>> > *must* apply them in a linear fashion to your final source tree
>> > that you ship in the package. This is no way around it.
>> 
>> But there is no such linearization, not in the way that quilt et al
>> do it. The state of such integration is not maintained in the feature
>> branches; it is in the history of the integration branch.

> Is this (the integration branch and its history of changes) not the
> linear sequence of changes that David Nusinow is asking for?

No, it is not. I  Apply a update to feature A. The comes an
 upstream update. Then updates on feature B, a patch that needed
 conflict resoution, then patches on branches C, D, and A again. Another
 upstream change. 

At this point, none of the original patches to A, B, and C apply
 any more -- and then come another upstream update, and all the patches
 get even more bent out of shape.



>> And the integration branch does not keep track of what changes come
>> from which branch -- that is not its job.

> Doesn't each commit message in the integration branch's history state
> what merge you were performing at each revision?

It usually states what changes were made, not necessarily what
 feature branch I imported from.

> You've previously described your workflow as one where you carefully
> integrate each feature branch separately into the integration
> branch.

But not in order, since not all features are developed on the
 same time scale, or even in sequence. And so no, all feature branches
 do not get integrated nicely in separate chunks and for the same
 upstream version either.

> Do your commit messages in the integration branch not state what
> individual feature branch you're merging in?

Not  usually. I describe the changes as it affects the
 integration branch, and sometimes I mention which branch it came from.

> It seems to me that the analogue to a linear sequence of patches is
> the revision history of your integration branch. Granted, this doesn't
> give patches against a pristine upstream except from some initial
> state.

It does not even apply to the current version of upstream. If a
 feature branch was developed over the course of a dozen or so upstream
 versions, and intertwined with development on other feature branches,
 the integration branch might give the sequence of merges, but will not
 give a patch set that applies to any given upstream version, and you'll
 have to retrace the exact sequence of merges and upstream updates -- in
 other words, playing back the whole history of the package.

For make, for instance, the history stretches back over a decade.

manoj
-- 
I never vote for anyone.  I always vote against. W.C. Fields
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Configuration Packaging System

[Tim Abbott]

On Sun, 24 Feb 2008, Russ Allbery wrote:


Tim Abbott <[EMAIL PROTECTED]> writes:


We also ran into a few packages which will overwrite configuration files
that they manage via debconf, overwriting our symlink every time the
relevant package is upgraded.  But I think that's a bug in those Debian
packages, since the same problem would occur for any manual changes to
those configuration files as well (I think in the cases I've seen it is
a failure to check whether an upgrade is occuring when generating the
configuration file in postinst).


Configuration files generated by debconf may not be manually changed
without running this risk, including by humans.  Generally, this is
documented in the file.  I have several of those in packages I maintain.
This is a pretty widely accepted way of dealing with configuration files,
and the right way to modify those files is with debconf pre-seeding rather
than by trying to overwrite the file, IMO.


Many such files have configuration options other than those managed by 
debconf (/etc/krb5.conf would be a good example).  For those files, 
pre-seeding debconf doesn't suffice.



What other problems have you experienced?


I've seen the diverted configuration file disappear, making it impossible
to undo the diversion, and never did track down why that happened.  I
haven't run into any problems in cases where the diversion is never
dropped, though.  (But renaming the package that manages the diversions is
something that dpkg-divert doesn't deal with at all well.)


Renaming a package requires no special effort in our system (the new 
package and the old package will conflict because they divert the same 
file, and the old package will remove the diversion on prerm because it 
knows it is being removed, and then the new package will install the new 
diversion on postinst).


-Tim Abbott




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow <[EMAIL PROTECTED]> said: 

> On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
>> David Nusinow <[EMAIL PROTECTED]> writes:
>> 
>> > The problem is that you and Manoj assume that this is the only way
>> > to do things. I don't believe this. Pierre Habouzit has been
>> > experimenting with an alternative method of feature branches that
>> > exports to a linear stack of diffs just fine. Just because Manoj is
>> > doing something one way right now doesn't mean it's the only or
>> > even the correct way to do it.

I would be interested in details of this, and whether this
 approach works with pure feature branches where the features are being
 developed contemporaneously with each other an upstream development;
 and thus the branches overlap both temporally and in code space.

>> Well, I definitely don't think it's the only way to do things, and
>> I've been one of the people arguing in favor of quilt and exporting
>> to a set of patches.  :) But the "native" Git workflow that people
>> have previously written up for Debian packages doesn't seem to me to
>> linearize very easily, and IMO one of the points here was to let
>> maintainers keep using their native workflows and use the package
>> format for interchange.  Changing the workflow to allow easier export
>> to a particular package format seems to be going the wrong direction
>> to me.
>> 
>> In other words, I still think a patch-based package format is a good
>> idea and would be very valuable for a lot of what's in Debian, but I
>> have to agree with Manoj's point, based on what I've seen so far,
>> that converting an arbitrary Git or Arch repository for Debian
>> package maintenance to such a package format isn't necessarily easy.

> Ok, that's fair. In the worst case then people who want to use this
> sort of workflow could stick everything in a giant diff like we do
> now, so nothing would be lost.

Or have dpkg understand not just quilt, but git.

I mean, if we are making dpkg understand quilt-as-a-version-control
 system, why not also have it grok a modern SCM like git? (I know that
 trying to get it to understand arch is a lost cause).

Would joeyh's efforts to get dpkg v3 format be a got repo make a
 difference here?

manoj
-- 
Freedom begins when you tell Mrs. Grundy to go fly a kite.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Configuration Packaging System

[Russ Allbery]

Tim Abbott <[EMAIL PROTECTED]> writes:
> On Sun, 24 Feb 2008, Russ Allbery wrote:

>> Configuration files generated by debconf may not be manually changed
>> without running this risk, including by humans.  Generally, this is
>> documented in the file.  I have several of those in packages I
>> maintain.  This is a pretty widely accepted way of dealing with
>> configuration files, and the right way to modify those files is with
>> debconf pre-seeding rather than by trying to overwrite the file, IMO.

> Many such files have configuration options other than those managed by
> debconf (/etc/krb5.conf would be a good example).  For those files,
> pre-seeding debconf doesn't suffice.

And krb5.conf is not a configuration file managed in the way that you
describe for exactly that reason.  It uses a conservative approach, only
installing a file based on debconf prompts if the file doesn't already
exist and otherwise trying to do automated updates of only the configured
data where applicable.  (You can also make the file a symlink to disable
all automated modification.)

The ones that are overwritten completely that I'm aware of contain only
settings managed by debconf, or (as is the case for krb5-kdc and
krb5-admin-server) explicitly ask whether you want to manage the
configuration file through debconf or want to manage it manually so that
you can set more obscure options.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Practical solutions to: the new style "mass tirage" of bugs

[Don Armstrong]

On Sun, 24 Feb 2008, Stefano Zacchiroli wrote:
> On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
> > If there are sets of usertags which are in common use by a reasonable
> > number of diverse packages, and are something that would normally be
> > put on the [EMAIL PROTECTED] user (that is to say, make them
> > visible by default) then file a bug against bugs.debian.org askiing
> > for that tag to be made a real tag.
> > 
> > That's the best way to standardize usertags which are currently not
> > bts-wide tags.
> 
> Ack on the general principle.
> 
> However, the need which was pointed out to seemed to me more than a
> tag: in my head it was distilled as "priority", as available in
> other bug tracking systems. This is something that can be encoded
> with usertags, but such an encoding does not have good properties
> such as mutual exclusion of alternative priorities.

It almost sounds like you want a user setable severity-like field.
That could be implemented, but the problem is that it's far less
flexible than usertags because it would only have a single value.

In fact, assuming the assignment to usercategories was done properly,
it wouldn't matter if a bug had multiple "priority" tags, as a bug
that had the higest tag would be separated from the other tags even if
it still had a lower tag.

See

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debbugs;[EMAIL PROTECTED]

for an example of my segregation of the debbugs package.


Don Armstrong

-- 
To steal ideas from one person is plagiarism; to steal from many is
research.
 -- Steven Wright

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Manoj Srivastava]

Hi,

I think one of the differences that patch series mechanism has
 wrt to new development, either in a feature or upstream, is that it
 requires updates to the integration work doe every single upload. It
 also requires a strict ordering between each feature, making it harder
 to compile and test each feature independently.  It is nice that quilt
 helps keep the integration patch up to date; but this is extra work I
 am glad not to have to do.

An integration branch does the integration once, and does not
 bother to explicitly keep the integration patch updated for every
 upload -- but it does keep each feature branch  up to date, and the
 integration branch has a current set of features. This is reduced work
 load for each change; at the expense of stashing integration knowledge
 deep in the entrails of the integration branch.

I like the reduced work for each upload, and since it satisfies
 the use cases of being able to present upstream with a pure feature
 changeset; to be able to rapidly compare any feature branch against
 each other or upstream, and being able to maintain an integrated source
 tree for Debian packages, I am happy not to keep integration patches up
 to date.

Now, if there is indeed a mechanism that can automatically keep
 up the integration patches and convert feature branches to an
 integrated source tree via a patch series, I'll gladly eat crow and try
 to convert over.  But I still want to keep pure feature branches, and I
 do not want to have to worry about integration all over again at every
 upload.

Unless new information comes up on this thread, I am done.

manoj
-- 
Reinhart was never his mother's favorite -- and he was an only
child. Thomas Berger
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: news from mips?

[Charles Plessy]

Le Fri, Feb 22, 2008 at 09:55:08AM +0100, Florian Lohoff a écrit :
> 
> The mipsel buildd rem has a new disk and the buildd dir will be moved
> which will speed it up a lot (PIO vs DMA)

Dear Florian,

this is good news: we can see mipsel getting better on the buildd stats:

http://buildd.debian.org/stats/graph2-week-big.png

However, it does not give much help for packages to migrate in testing:
the queue on the mips buildd is still growing. Is there any plan to
solve this problem ? Some packages are blocked for almost a month, and
judging from the absence of buildd logs for mips(el) for some packages
that recently migrated, it seems that the best way to deal with the
problem is to upload binary built elsewnere…

I know that it is not pleasant to hear, but again: for the package I
care about and that are waiting to be built on mips, I have never had
any evidence that they have users on this port. I would be glad to be
proven wrong, but in the meantime, we are delaying service to our users
for no benefit at all.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Practical solutions to: the new style "mass tirage" of bugs

[Lucas Nussbaum]

On 24/02/08 at 20:41 +0100, Stefano Zacchiroli wrote:
> On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
> > If there are sets of usertags which are in common use by a reasonable
> > number of diverse packages, and are something that would normally be
> > put on the [EMAIL PROTECTED] user (that is to say, make them
> > visible by default) then file a bug against bugs.debian.org askiing
> > for that tag to be made a real tag.
> > 
> > That's the best way to standardize usertags which are currently not
> > bts-wide tags.
> 
> Ack on the general principle.
> 
> However, the need which was pointed out to seemed to me more than a tag:
> in my head it was distilled as "priority", as available in other bug
> tracking systems. This is something that can be encoded with usertags,
> but such an encoding does not have good properties such as mutual
> exclusion of alternative priorities.

For many users of other bug tracking systems such as bugzilla, the
meaning of priority vs severity is totally unclear. I don't think that
it would be a good idea to impose such a thing to all packages by
default.

As Don pointed, it is relatively easy to emulate priorities using
usertags and usercategories. Maybe the BTS could help by providing other
sorting orders by default (so viewing priorities would simply be a
matter of adding sort=priorities to pkgreport's URL), and/or by providing
more examples of custom sorts.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections

[martin f krafft]

also sprach Sam Hocevar <[EMAIL PROTECTED]> [2008.02.24.1316 +0100]:
>I also would like to spend some Debian money on a contest, similar to
> the FreeBSD logo contest [2], to create a friendly mascot for the Debian
> project (in a similar way to the Linux penguin or the GNU gnu) that we
> can use where the logo is not enough. More on this in a few days.

In the free software zoo, the Debian Swirl sticks out like no other
logo. Do we have to get a mascot?

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
plan to be spontaneous tomorrow.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: How to cope with patches sanely

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627 +0100]:
> I am not sure you have understood feature branches.  They are
>  independent, no matter what the overlap. Each feature branch tracks one
>  feature against upstream, no matter how the other features work.
> 
> The overlap management is done in the integration branch. This
>  is significantly different from a quilt series, as others have already
>  mentioned in this thread,which is a dependent series of
>  linearized patches; and a change in an earlier feature impacts all
>  subsequent patches (and  quilt is good at automating the handling of
>  that impact). [[duplicated so this can be archived on the vcs-package
>  mailing list as well]]

well, I know what feature branches are but I suppose I jumped the
gun. They are independent until you integrate them. But you will
integrate them, thus I tend to think of them as interdependent from
the start.

Anyway, we're not talking about developing with quilt. We are
talking about converting feature branches to quilt patches for the
sake of representation in the source package. I don't see why you
would oppose to that at all, to be honest.

> Or the patch manager does integration. *Shrug*.  Someone has to
>  do integration sometime.  That is the nature of the beast.  The trick is
>  to do it once, and never have to think about it again.

... except when one feature needs to change and then conflicts with
another feature on re-integration.

>  B) Development happens on the feature branch.
[...]
> 2) Development on one of the branches conflicts with one or more
>other features. Here, the human has to figure out the difference
>on the integration branch -- once.

No, every time you do development on the branch. And every time, you
have to remember which branch dependended/conflicted on the feature
branch you're currently working on, or figure it out by trial and
error. I don't consider this efficient. This is work that a computer
should be doing.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
windoze 98:  useless extension to a minor patch release for 32-bit
  extensions and a graphical shell for a 16-bit patch to an 8-bit
  operating system originally coded for a 4-bit microprocessor, written
  by a 2-bit company that can't stand for 1 bit of competition.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections

[Lars Wirzenius]

On su, 2008-02-24 at 19:48 +0100, martin f krafft wrote:
> also sprach Sam Hocevar <[EMAIL PROTECTED]> [2008.02.24.1316 +0100]:
> >I also would like to spend some Debian money on a contest, similar to
> > the FreeBSD logo contest [2], to create a friendly mascot for the Debian
> > project (in a similar way to the Linux penguin or the GNU gnu) that we
> > can use where the logo is not enough. More on this in a few days.
> 
> In the free software zoo, the Debian Swirl sticks out like no other
> logo. Do we have to get a mascot?

We had a chicken[1]. We spent years actively getting rid of it.

[1] Technically speaking it was a penguin. But it was a youthful
penguin, rebelling against its genetic heritage.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections

[Aníbal Monsalve Salazar]

On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote:
>
>We had a chicken[¹]. We spent years actively getting rid of it.
>
>[¹] Technically speaking it was a penguin. But it was a youthful
>penguin, rebelling against its genetic heritage.

LCA2009 has a tasmanian devil pretending to be penguin [²].

[²] https://linux.conf.au/


signature.asc
Description: Digital signature

Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections

[Manoj Srivastava]

On Mon, 25 Feb 2008 09:07:20 +0200, Lars Wirzenius <[EMAIL PROTECTED]> said: 

> On su, 2008-02-24 at 19:48 +0100, martin f krafft wrote:
>> also sprach Sam Hocevar <[EMAIL PROTECTED]> [2008.02.24.1316 +0100]:
>> >I also would like to spend some Debian money on a contest,
>> >similar to
>> > the FreeBSD logo contest [2], to create a friendly mascot for the
>> > Debian project (in a similar way to the Linux penguin or the GNU
>> > gnu) that we can use where the logo is not enough. More on this in
>> > a few days.
>> 
>> In the free software zoo, the Debian Swirl sticks out like no other
>> logo. Do we have to get a mascot?

> We had a chicken[1]. We spent years actively getting rid of it.

I loved the chicken. I had a character.

> [1] Technically speaking it was a penguin. But it was a youthful
> penguin, rebelling against its genetic heritage.

Youthful, but with taste. I thought it gave us a better logo than
 the somewhat blah swirl.  But I lost that vote 

manoj
-- 
If only you knew she loved you, you could face the uncertainty of
whether you love her.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627
> +0100]:
>> I am not sure you have understood feature branches.  They are
>> independent, no matter what the overlap. Each feature branch tracks
>> one feature against upstream, no matter how the other features work.
>> 
>> The overlap management is done in the integration branch. This is
>> significantly different from a quilt series, as others have already
>> mentioned in this thread,which is a dependent series of linearized
>> patches; and a change in an earlier feature impacts all subsequent
>> patches (and quilt is good at automating the handling of that
>> impact). [[duplicated so this can be archived on the vcs-package
>> mailing list as well]]

> well, I know what feature branches are but I suppose I jumped the
> gun. They are independent until you integrate them. But you will
> integrate them, thus I tend to think of them as interdependent from
> the start.

You have a strange definition of interdependent.  The majority
 of my feature branches are really orthogonal;  seldom on integration
 there is no conflict; so it is hard for me to think of them as somehow
 inter dependent. Sure, there are overlapping changes, sometimes, but
 these are mostly one time resolution issues.

> Anyway, we're not talking about developing with quilt. We are talking
> about converting feature branches to quilt patches for the sake of
> representation in the source package. I don't see why you would oppose
> to that at all, to be honest.

I am not opposed to it. If you can somehow magically create a
 tool that can linearize the feature branches, more power to you. I
 personally find the prospect highly unlikely; and I would like to see
 some code, please, before I grant that such a thing is possible.

>> Or the patch manager does integration. *Shrug*.  Someone has to do
>> integration sometime.  That is the nature of the beast.  The trick is
>> to do it once, and never have to think about it again.

> ... except when one feature needs to change and then conflicts with
> another feature on re-integration.

Sure. You can't integrate two features that fundamentally
 conflict with each other. No amount of smoke and mirrors can obscure
 that fundamental obstacle. This is independent of the tool set you
 use. 

>> B) Development happens on the feature branch.
> [...]
>> 2) Development on one of the branches conflicts with one or more
>> other features. Here, the human has to figure out the difference on
>> the integration branch -- once.

> No, every time you do development on the branch. And every time, you
> have to remember which branch dependended/conflicted on the feature
> branch you're currently working on, or figure it out by trial and
> error. I don't consider this efficient. This is work that a computer
> should be doing.

Strange. In all my years of using feature branches, I have never
 had to consider which branch depended on what. So no, I don't think I
 _have_ to remember any  such thing; trust me, I would have noticed.  I
 have 30+ packages, and have been using feature branches since  early
 this decade.

If you have a whole slew of features that depend on other
 features, then your feature set is very different from ones I have
 encountered. Dependent features do require more work; but not as much,
 in my opinion, as using quilt or dpatch; but your mileage may vary.

For the most part, I just develop on each branch independently.
 I compile, test, hack, compile, on each individual featre branch. And
 never ever worry about what the other feature branches are like, while
 doing so.

Once in a blue moon (more or less) I have to deconflict the
 integration branch; but mostly those are swiftly resolved issues. And
 once resoved, I tend to forget about them too.  All this worrying about
 branch conflicts seem to be more the realm of quilt and other patch
 series mechanisms; which is mostly my reason to dislike them.

manoj
-- 
(It is an old Debian tradition to leave at least twice a year ...) Sven
Rudolph
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Raphael Hertzog]

On Sun, 24 Feb 2008, Charles Plessy wrote:
> Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit :
> > 
> > > - When modifying a package that uses dpatch, quilt or simple-patchsys,
> > >   developpers have to find out by themselves if the target for patching
> > >   the sources is patch, apply-patches or apply-dpatches.
> > 
> > Once the new dpkg-source format is in standard use, those rules disappear
> > completely... because they are no more needed during build.
> 
> I must have missed something. I thought that the new format was to keep
> the debian directory in a tar.gz format. With this format, people who
> want to modify upstream sources will have to use a patch system. What is
> the plan to make the patch targets in debian/rules unneeded?

If the patch are applied by default, there's no need to apply them again
at build time. Then quilt/dpatch tools will only be used by the packager
to modify/updated its patch serie during maintenance but the tool won't be
needed during recompilation (and thus doesn't need to be in
Build-Depends).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to cope with patches sanely

[Raphael Hertzog]

Hi,

On Sun, 24 Feb 2008, Manoj Srivastava wrote:
> I like the reduced work for each upload, and since it satisfies
>  the use cases of being able to present upstream with a pure feature
>  changeset;

It doesn't satisfy it completely. You can always generate a patch for
a pure feature changeset but you can't guarantee that all those feature
patches apply at the same time.

Let's say you have 5 feature patches, the upstream maintainer wants to
integrate 3 of them. How can you submit 3 patches that would apply one
after the other? You have to redo some of your integration work that you
already did.

That said, even with a pure quilt set of patches, you can't guarantee it
either. If one of the wanted patch has some overlap with one of the
non-wanted ones...

All in all, I think we do all exagerate the problems. In my experience,
most of the patches applied to a Debian package are relatively independant
of each other and inter-relationships is the exception, not the rule.

But if we can come up with a solution that handles perfectly
inter-dependant patches, that would still be great. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]