Re: divergence from upstream as a bug

[Goswin von Brederlow]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow <[EMAIL PROTECTED]> [080518 16:09]:
>> The quilt extension is certainly a big improvement and will hopefully
>> unify a lot of patch system using packages after lenny.
>
> Though I guess there still needs to be a way to get such a patchset
> constructed from non-quilt based work models, especially with things
> centered on history. For example something to tag commits to git
> repository, so some package creating tool can put changes belonging
> together (like a modification and its updates for newer upstreams)
> into a single .diff of such a series. (be that meta-tags in the
> description, automatic utilisation of feature branches, extending the
> git format or whatever git experts can think of or consider worthwile)
> (or perhaps I'm just too stupid to find branch-hopping and manual
> merging manually convenient enough to actually do).

There are 2 distinctly different workflows:

1) stacked patches or branches

You base each patch or branch on the source with the previous patch
applied or branch merged in already. Then you have a nice linear
progression of changes that can be put into /debin/patches/.

If you want to use a RCS I suggest using stacked git or the mercurial
extension instead of actual branches.

2) feature branches

Each feature branche is based on upstream (with few exceptions) and
contains all changes for one feature.

Then you have an integration branche where all feature branches are
merged. The merging generally needs human interaction somewhere in the
history of the integration branch. Doesn't mean every merge needs it
though.

Unfortunately there seems to be no way to generate a patch series from
that other than one big patch for everything combined. The human
interaction stored in the integration branch can't be machine
transformed to make a patch series. It seems that that transformation
is just as difficult as the merge itself.


I think the divergence bugs would be most usefull there. The diff.gz
would not contain usefull patches as all features are mangled into one
patch there. But it would be easy to generate a patch for each feature
branch and send it to the BTS.

MfG
Goswin


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

Re: How to handle Debian patches

[Goswin von Brederlow]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
>> As a Debian package maintainer however I'm convinced that we'd be better
>> served by having only native + 3.0 quilt. The VCS comes _before_ the
>> source package and the source package is just an export from the VCS.
>
>> However I think that .git.tar.gz would be acceptable as replacement
>> for native packages (like debhelper for example). 
>
> Full ACK.

Full NACK.

I would rather have native packages in 3.0 quilt format. Initialy they
would have no patches but NMU uploads would automatically generate
one.

I mean what stops us from having foo_1.0-1.dsc contain:

foo_1.0.tar.gz
debian.tar.gz

MfG
Goswin


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

Re: divergence from upstream as a bug

[Raphael Hertzog]

On Mon, 19 May 2008, Charles Plessy wrote:
> Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds "To
> be merged upstream:" to the subject, and sends a message saying "This
> bug has been fixed by patching the original sources; we will forward
> this patch to the upstream authors and close this bug report when
> upgrading the Debian package to an upstream source in which the patch
> has been merged or obsoleted".

I don't really like the idea to have "Fixes:" and "Closes:" do different
things. It basically means the same thing and would lead to
very different results. That's not something that I'd like to implement in
dpkg-dev (with my dpkg maintainer hat).

I would suggest as alternative, that this information should be stored in
the fields preceding the patch. And dpkg-genchanges/dak shouldn't process
anything with respect to that.

However the tool that grabs the patch and publish it in patches.debian.org
should certainly tag the bug number with divergence. (And since that tool
could use real patches coming from 3.0 (quilt) packages or generated
patches coming from any other VCS-based source packages, everybody would
be happy)

Fix-Debian-Bug: 5
Forwarded-Upstream: http://bugzilla...
Author: Random Joe <[EMAIL PROTECTED]>
Comment: 
 The behaviour A was wrong when B. This patch makes sure to do C in that
 case as this is what the user expects.

[patch follows]

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: deactivated native samba support in mc

[Andreas Tille]

On Sun, 18 May 2008, Patrick Winnertz wrote:


If there is anybody who is interested in this feature please mail me, since
upstream is pretty dead there is no great chance that he will fix this in
a reasonable time. So if someone have good C skills and would like to help
to port mc to link dynamically against libsmbclient please start working
on it ;-)


And as I told you in private before: Waiting for unresponsive upstream
does not make sense and thus I would recommend starting a common effort
with maintainers of other distros to continue upstream development.  If
upstream is stubborn not to join this effort start a "High noon commander"
project or whatever you might call it. ;-)

There are so many people working with Midnight Commander - I can not
really believe that this effort to revitalise development should fail.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: divergence from upstream as a bug

[Lucas Nussbaum]

On 19/05/08 at 09:14 +0900, Charles Plessy wrote:
> 'morning Neil and everybody. So many mails to read for breakfast!
> 
> Le Sun, May 18, 2008 at 03:51:18PM +0100, Neil Williams a écrit :
> > proposal:
> > 
> > [EMAIL PROTECTED] | (Fixes: #nnn)
> > marks the bug as fixed by a patch added by Debian and
> > awaiting a new release upstream to be finally closed. 
> > nnn-fixed is ignored if the upstream tag is not already
> > set. Bugs can be fixed in the changelog of an upload using
> > (Fixes: #1234) in a similar manner to (Closes: #1234). The
> > principle usage of "fixed" is to denote points at which 
> > Debian diverges from upstream. Filenames of patch files must 
> > be clearly identified when using (Fixes: #1234) in the
> > changelog.
> 
> Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds "To
> be merged upstream:" to the subject, and sends a message saying "This
> bug has been fixed by patching the original sources; we will forward
> this patch to the upstream authors and close this bug report when
> upgrading the Debian package to an upstream source in which the patch
> has been merged or obsoleted".

Take a bug #111, severity:serious, affecting unstable,testing,stable.
The maintainer fixes the bug in unstable using a Debian patch. Following
your process, the bug is now downgraded to wishlist. Meaning that RC
#111 bug in stable suddenly became a wishlist bug. We don't want that!

Could someone summarize again the different features that we require for
the "BTS tracks patches sent upstream" thing? I can think of:
- the new features must not change the existing workflow, when not using
  the BTS to track upstream patches.
- the submitter should still know when the bug is fixed in Debian (=
  when he can upgrade the package and expect it to work as supposed)
- the maintainer and upstream need a way to list the patches that
  were submitted upstream but not integrated yet.
- the process must not break the tracking of bugs in other suites
Anything else?

The current solution proposed by Don is:
  add a divergence tags that can be used to mark bugs about patches sent
  upstream ; don't archive closed bugs tagged divergence.

This is good, because it avoids duplicating all the version-tracking for
a "fixed-with-a-patch" state that will only be useful for a few
packages. Those who don't need the feature won't see it.

Two additional changes could be made as well, to help with the process:
1) add parsing for Closes-with-patch: in changelog. This closes the
   bug normally, and also tags the bug + divergence. sounds
   non-disruptive.
2) slightly change behaviour of Closes:. do as usual, and if the bug
   is tagged divergence, remove the tag.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: How to handle Debian patches

[Raphael Hertzog]

On Mon, 19 May 2008, Goswin von Brederlow wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> 
> > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
> >> As a Debian package maintainer however I'm convinced that we'd be better
> >> served by having only native + 3.0 quilt. The VCS comes _before_ the
> >> source package and the source package is just an export from the VCS.
> >
> >> However I think that .git.tar.gz would be acceptable as replacement
> >> for native packages (like debhelper for example). 
> >
> > Full ACK.
> 
> Full NACK.

Please stop using "NACK" on public lists, it's badly connotated. It looks
like you're forbidding someone else to do something as if you had some
veto power.

> I would rather have native packages in 3.0 quilt format. Initialy they
> would have no patches but NMU uploads would automatically generate
> one.

If the maintainer decides to use a git-based format it's probably also
because he prefers receving NMU as git branch in a new upload instead of
a patch.

So I don't see why you would refuse that liberty to the maintainer.

It's not like the "native" package option will disappear...

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: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Mon, 19 May 2008, Bernd Eckenfels wrote:


I dont see a reason why the normal unpack action should spam the user.


If a user feels spammed there might be means to switch this off.  A command
line option that reduces the verbosity comes to mind even /dev/null might be
a place to foreward this stuff if you really feel spammed.


If
you care about the changes, just use the command. You can even have an alias
if you prefer that.

BTW:
+++ openssl-0.9.8g/Makefile
+++ openssl-0.9.8g/Configure
+++ ... (50 lines deleted)
+++ openssl-0.9.8g/util/pl/netware.pl


This is *exactly* what I want the user to see.  The information that the
source has *a lot* (53) files that are patched by the Debian maintainer
is no spam at all but might make the user aware that there might be reasons
to inspect the diff carefully and that it is not enough to look into
debian/patches (which might not exist in this case, did not checked).

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: divergence from upstream as a bug

[Don Armstrong]

On Mon, 19 May 2008, Lucas Nussbaum wrote:
> Two additional changes could be made as well, to help with the process:
> 1) add parsing for Closes-with-patch: in changelog. This closes the
>bug normally, and also tags the bug + divergence. sounds
>non-disruptive.

This should actually probably be done by the addition of an extension
to debcommit (or similar) to automatically add divergence when a
change is made which impacts a bug which involves a change not
(ultimately) inside of debian/; ideally even sending the patch to the
bts and marking it as a summary.[1]

[Or maybe some other command which does the same with a interdiff or
similar.]

Doing differently will require a manual step to actually extract the
patch which is involved in the divergence, and also requires changes
to dak et al.


Don Armstrong

1: Possibly even replacing tagpending...
-- 
In all matters of government, the correct answer is usually: "Do
nothing"
 -- Robert Heinlein _Time Enough For Love_ p428

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


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

Re: divergence from upstream as a bug

[Lucas Nussbaum]

On 19/05/08 at 08:48 +0200, Goswin von Brederlow wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> > and update the corresponding bug report, and it doesn't work with
> > version-tracking, which would need to be updated have 3 notions:
> > - notfound (already exist)
> 
> ???
> 
> > - fixed using a Debian specific patch
> 
> (Fixes: #1234) in changelog.
> 
> > - fixed in upstream
> 
> (Closes: #1234) in changelog
> 
> Or equivalent mails to control. Fixes would do version tracking just
> like closes does.

My point is: We don't want to change version-tracking to track this
"Fixes" notion in addition to the "Closes" notion. Version-tracking is
complex enough already.

(Btw, when quoting, you should be careful not to cut atomic entities,
like paragraphs usually, into smaller parts. I usually try to write one
idea per paragraph especially for that.)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: divergence from upstream as a bug

[Lucas Nussbaum]

On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
> Fix-Debian-Bug: 5

I think that:
  Fixes: http://bugs.debian.org/5
is better. The patch might fix a problem not reported in Debian. For
example, the Debian maintainer might monitor Ubuntu's bug tracker, see a
bug reported there, and fix it in the Debian package.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Patch license

[Charles Plessy]

Le Mon, May 19, 2008 at 07:12:43AM +0200, Lucas Nussbaum a écrit :
> Take a bug #111, severity:serious, affecting unstable,testing,stable.
> The maintainer fixes the bug in unstable using a Debian patch. Following
> your process, the bug is now downgraded to wishlist. Meaning that RC
> #111 bug in stable suddenly became a wishlist bug. We don't want that!

Good point: severity is not versionned.

By the way (and not answering to the rest of your mail, sorry), I just
realised that some package have a more restrictive license for the
packaging than for the packaged content (typically GPL vs BSD or MIT).
Probably because of the dh_make template. Unless stated otherwise, the
patches can therefore be licenced under terms that are unwelcome
upstream. I think that when the debian packaging is not using the same
license as the patched sources, it would be necessary to specify the
license through an optional field in the header.

Have a nice day,

-- 
Charles


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

Re: Mailing lsit code of conduct, again

[Bernhard R. Link]

* Martin Langhoff <[EMAIL PROTECTED]> [080518 22:02]:
> In this modern age of a mailman that lets subscribers configure their
> subscription to avoid duplicates, and procmail filters that help do
> the same at the client end (and some mail clients that have similar
> abilities of their own - ie gmail)... why does this funny and akward
> rule of debian lists persist?

Because it is the only rule that allows people to set their own
policies? Just because you do not distinguish between list mail and
list mail CCed to you, that is no reason to force everyone to do so.

> Frankly, I want to just use reply/reply-all normally on any of the
> many mailing lists I am sub'd to,

Then please do not use any mailing list I'm subscribed to.

> and if a few people in the thread
> are CC'd, I don't think it is a reasonable expectation that I have to
> decide whether each one of them wants or not the CC.

People already CCed are a different beast. But CCing the creator of
a mail by default is not reasonable.

> A funny side-effect of this is that I've seen subscribers of debian
> lists get in trouble in non debian lists because they use funny
> headers in lists with differnt expectations

Yes, just like they might get in trouble when they do not top-quote,
do not shout, or when they do not spit when speaking to a Klingon.

Bernhard R. Link


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

Re: How to handle Debian patches

[Goswin von Brederlow]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> On Mon, 19 May 2008, Goswin von Brederlow wrote:
>> Josselin Mouette <[EMAIL PROTECTED]> writes:
>> 
>> > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
>> >> As a Debian package maintainer however I'm convinced that we'd be better
>> >> served by having only native + 3.0 quilt. The VCS comes _before_ the
>> >> source package and the source package is just an export from the VCS.
>> >
>> >> However I think that .git.tar.gz would be acceptable as replacement
>> >> for native packages (like debhelper for example). 
>> >
>> > Full ACK.
>> 
>> Full NACK.
>
> Please stop using "NACK" on public lists, it's badly connotated. It looks
> like you're forbidding someone else to do something as if you had some
> veto power.
>
>> I would rather have native packages in 3.0 quilt format. Initialy they
>> would have no patches but NMU uploads would automatically generate
>> one.
>
> If the maintainer decides to use a git-based format it's probably also
> because he prefers receving NMU as git branch in a new upload instead of
> a patch.
>
> So I don't see why you would refuse that liberty to the maintainer.
>
> It's not like the "native" package option will disappear...
>
> Cheers,

Because the git format is imho conceptualy broken and the
implementation is far from completely thought out. The strongest
point against it is that the user has to learn git to use it.

The quilt format on the other hand can be used transparently instead
of v1 format. The user does not need to learn quilt to use it. That
aspect can be totally ignored unless you want to use it.


The maintainer can use whatever he likes. It is trivial to generate a
quilt format package from git/arch/hg/svn and I'm sure there will be a
RCS-build-package soon enough that does that. The maintainer can also
import the quilt patches a NMU would add to the deb to the RCS
repository. There is no real drawback in using quilt format even if
you use git.

MfG
Goswin


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

Re: How to handle Debian patches

[Miriam Ruiz]

2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:

> Because the git format is imho conceptualy broken and the
> implementation is far from completely thought out. The strongest
> point against it is that the user has to learn git to use it.

I'm curious about this. Why is it conceptualy broken and badly
implemented? Is there any public URL about that?

> The quilt format on the other hand can be used transparently instead
> of v1 format. The user does not need to learn quilt to use it. That
> aspect can be totally ignored unless you want to use it.
>
> The maintainer can use whatever he likes. It is trivial to generate a
> quilt format package from git/arch/hg/svn and I'm sure there will be a
> RCS-build-package soon enough that does that. The maintainer can also
> import the quilt patches a NMU would add to the deb to the RCS
> repository. There is no real drawback in using quilt format even if
> you use git.

I agree with you in this.

Miry


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

Re: Mailing list code of conduct, again

[Andrew Vaughan]

On Monday 19 May 2008 18:10, Bernhard R. Link wrote:
>
> People already CCed are a different beast. But CCing the creator of
> a mail by default is not reasonable.
>
Unfortunately that doesn't work with Kmail's reply-to-list, which means 
manual attention is needed when the thread is being intentionally cc-ed to 
eg a bug report.

I've seen too many arguments on this subject.  My 2 c as a Debian user / 
reader of Debian lists is that perhaps the CoC should be softened to say 
eg, "Note that it is considered best practice on Debian mailing lists to 
use the reply-to-list function of your email program, and to not cc someone 
who appears to be subscribed (unless they request otherwise)."

Andrew V. 


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

Re: How to handle Debian patches

[Mike Hommey]

On Mon, May 19, 2008 at 10:55:00AM +0200, Miriam Ruiz wrote:
> 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:
> 
> > Because the git format is imho conceptualy broken and the
> > implementation is far from completely thought out. The strongest
> > point against it is that the user has to learn git to use it.
> 
> I'm curious about this. Why is it conceptualy broken and badly
> implemented? Is there any public URL about that?

#477954, for one.

Mike


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

Re: Mailing lsit code of conduct, again

[Mark Brown]

On Mon, May 19, 2008 at 01:23:25PM +1000, Hamish Moffatt wrote:
> On Sun, May 18, 2008 at 07:21:29PM +0100, Mark Brown wrote:

> > Of course, MFT brings up the whole "it's not a standard, why should I
> > follow it, my MUA never heard of it" thing...  You can't win.

> Our code of conduct has the same problem - ours is different to many
> other communities where CCs are fine or even welcome, eg the kernel
> communities.

That's a separate problem - with the CCs it's just that there's no
agreement in general about how to handle CCs, and no real prospect of
ever getting global agreement.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: divergence from upstream as a bug

[Raphael Hertzog]

On Mon, 19 May 2008, Lucas Nussbaum wrote:
> On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
> > Fix-Debian-Bug: 5
> 
> I think that:
>   Fixes: http://bugs.debian.org/5
> is better. The patch might fix a problem not reported in Debian. For
> example, the Debian maintainer might monitor Ubuntu's bug tracker, see a
> bug reported there, and fix it in the Debian package.

That's why I integrated the distribution name, so that we can also have
Fix-Ubuntu-Bug for example. And it imposes no structure on the content
for each specific distribution.

But both solution are acceptable provided that you accept multiple "Fixes"
field. But in your case, it's best to allow URL only (for uniformity).

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 handle Debian patches

[Goswin von Brederlow]

"Miriam Ruiz" <[EMAIL PROTECTED]> writes:

> 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:
>
>> Because the git format is imho conceptualy broken and the
>> implementation is far from completely thought out. The strongest
>> point against it is that the user has to learn git to use it.
>
> I'm curious about this. Why is it conceptualy broken and badly
> implemented? Is there any public URL about that?

As for implementation see the bugreport in the other reply for some
tidbits.

Conceptually I think the following:

A Debian source package is a snapshot in time of the source. The
source at the specific time of the upload.

A git repository is the full history of the source with all edits,
pushes, pulls, merged, cherry-picking all documented in the log.


So people said that the git repository should be pruned to only
contain recent stuff. But you can not do that with feature branches
without loosing the history between the branches. You can't merge
changes in a feature branch into the integration branch with that
anymore. Which would make it rather pointless.

So lets not prune it. Then you put every single source version there
ever was into the debian source package. And it will grow and grow and
grow.


And what is the point? Anyone familiar with git can just use the git
repository directly without bothering with the debian source
package. You just duplicate the repository on every debian mirror out
there.

And that is not even mentioning that the workflow in a git repository
can greatly differ between maintainer. You can have many many branches
and how is poor user supposed to know which branch to edit?

And if the user just edits the source as is, figures out how to commit
that to git and create a patch then all you end up is a patch against
the integration branch and not any feature branch. With quilt format
you get exactly the same patch automatically generated without all the
extra hoops the user has to jump through for the git format.

MfG
Goswin


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

Re: divergence from upstream as a bug

[George Danchev]

On Sunday 18 May 2008, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The diff.gz contains all the changes including the debian dir. It is
> > by no means obvious if there are patches in there or not.
>
> I think reading a debian diff is the every day job of DD and DAs. And all
> of them learned to search for +++ and ignore debian/.

Well we can still have debian/patches/$diff easily extracted and separated, 
even without orig.tar.gz, since these are purely new files to be created by 
patch: zcat *.diff.gz | patch -p1 (--force for hooligan diff.gz who touch 
outside debian/ when applied, no debian/patches/ obviously)

> However I do agree, extractin that to a web repository would be nice, to
> make it linkable.

Well I guess it is no too much hassle for p.d.o to inspect the diff.gz's and 
publish the results without even unpacking orig.tar.gz in the following way 
(or similar):

Checks:

1) get the debian/patches/ directory ( if any ): 
zcat $diff.gz | patch -p1 --force   
2) perl regex to see if upstream code is touched outside debian/patches/:
while ( <$diff_handler> ) { print $_ if ( /^---\s[^\/]+(?!\/debian)\// ); }
/* could be better ? */

Conclusions:

* run 1) and if debian/patches/ doesn't exists 
* and 2) returns no matches 
=> $SUMMARY - no patches applied by Debian, nothing to publish

* run 1) and if debian/patches/ exists
* run 2) returns no matches
=> $SUMMARY - patched by debian/patches
=> $PATCHES/ - publish them as well

* run 1) and if debian/patches/ doesn't exists
* run 2) returns matches
=> $SUMMARY - not very cool, patched in a combined fashion, good luck 
inspecting diff.gz youself
=> $PATCHES/ - no useful bits to reveal

* run 1) and if debian/patches/ exists 
* and 2) returns matches 
=> $SUMMARY - too bad, patches applied both ways (inside/outside 
combination) - by debian/patches and in a combine fashion, good luck 
inspecting diff.gz youself
=> $PATCHES/ - no useful bits to publish



I'm not certain about url's, but:

p.d.o/$debian_source_package_name/$SUMMARY
p.d.o/$debian_source_package_name/$PATCHES/

would suffice.


-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: pwsafe and OpenSSL?

[Daniel Burrows]

On Fri, May 16, 2008 at 11:46:13PM +0200, Moritz Muehlenhoff <[EMAIL 
PROTECTED]> was heard to say:
> Daniel Burrows wrote:
> >   I notice that pwsafe is linked against openssl.  Is it affected by the
> > recent debacle and if so, how?  Do I need to regenerate all my
> > randomized passwords, or somehow re-encrypt the pwsafe database?
> 
> I've looked briefly into it: The Blowfish encryption key is constructed
> from a SHA1 built from an initial random value, two zero bytes and the
> passphrase. So if an unmodified database created using a broken libssl
> copy is exposed to an attacker, it's more open to brute forcing attempts,
> but still safe-guarded by the passphrase.
> 
> Fortunately the random part is renewed whenever the database is saved.
> By my understanding - I don't use pwsafe myself - this should happen
> whever an entry is added or modified.

  According to upstream, that's not enoguh :( -- you need to create a
new database and merge into it.  It looks like someone has put this
information into the wiki already.

  Also, that sinking feeling in my stomach was right: the random
passwords you generate in pwsafe were predictable with the broken
openssl.  So anyone who's relied on the randomization feature of pwsafe
needs to reset all their passwords.

  Daniel


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

Re: Mailing lsit code of conduct, again

[Russ Allbery]

Mark Brown <[EMAIL PROTECTED]> writes:
> On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote:

>> The solution to this problem is to fix the mailing list code of conduct
>> to stop creating this expectation.  We don't enforce it anyway, and all
>> this provision seems to do in practice is create these annoying
>> arguments periodically.

> In my experience it's helpful to have a convention - there always seems
> to be some exchange of ideas on the issue but if there's a convention
> then at least you can point at it and say "that's the way we do things
> round here".

We could document the convention without making it part of a code of
conduct, which implies that we somehow enforce it and will drop people
from mailing lists for not following it or something.  Codes of conduct
usually have consequences for violating them, which this clearly doesn't
(other than sparking 40-post threads every couple of months and annoyed
paragraphs at the top of replies that people generally ignore anyway).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Mailing lsit code of conduct, again

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Codes of conduct usually have consequences for violating them, which
> this clearly doesn't (other than sparking 40-post threads every
> couple of months and annoyed paragraphs at the top of replies that
> people generally ignore anyway).

Again, my experience differs from yours: people *don't* generally
ignore them, and I find most people respond positively when I point
out the "no-Cc-by-default" provision of the code of conduct. I suppose
the exceptions to this may draw your attention more.

-- 
 \ “Listen: we are here on Earth to fart around. Don't let |
  `\  anybody tell you otherwise.” —_Timequake_, Kurt Vonnegut |
_o__)  |
Ben Finney


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

Re: Mailing lsit code of conduct, again

[Raphael Hertzog]

On Mon, 19 May 2008, Russ Allbery wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:
> > On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote:
> 
> >> The solution to this problem is to fix the mailing list code of conduct
> >> to stop creating this expectation.  We don't enforce it anyway, and all
> >> this provision seems to do in practice is create these annoying
> >> arguments periodically.
> 
> > In my experience it's helpful to have a convention - there always seems
> > to be some exchange of ideas on the issue but if there's a convention
> > then at least you can point at it and say "that's the way we do things
> > round here".
> 
> We could document the convention without making it part of a code of
> conduct, which implies that we somehow enforce it and will drop people
> from mailing lists for not following it or something.  Codes of conduct
> usually have consequences for violating them, which this clearly doesn't
> (other than sparking 40-post threads every couple of months and annoyed
> paragraphs at the top of replies that people generally ignore anyway).

For the record, the "code of conduct" got modified to also avoid the other
extreme side which are public complaints about unwanted CC (which lead
to those annoying threads and discussions).

http://cvs.debian.org/webwml/english/MailingLists/index.wml?root=webwml&r1=1.37&r2=1.38&diff_format=h

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]

utilisation de ucf - paquet de configuration.

[Anthony]

bonjour,

j'ai créer un paquet debian pour installer une configuration générale 
d'authentification sur ldap.
pour cela j'ai utilisé "ucf" sur les fichiers /etc/pam_ldap.conf, 
nsswitch.conf, ldap.conf et conf pam.


je voudrais savoir comment je peux récupérer la configuration avant 
installation du paquet lorsque je supprime celui-ci.


c'est a dire :
a l'origine, j'ai conf1 (authentification locale)
apt-get install mon_paquet
je dispose donc maintenant de ma conf2  (authentification ldap : avec 
conf ldap pam et nss)

apt-get remove --purge mon_paquet
je me retrouve avec ma conf originelle...conf1

Est il possible de faire cela

J'ai pensé a utiliser les fichier.dpkg-old généré par ucf??!!

Y a t-il un autre moyen

merci

Anthony


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Manoj Srivastava]

On Mon, 19 May 2008 09:20:11 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> 
said: 

>> If you care about the changes, just use the command. You can even
>> have an alias if you prefer that.
>> 
>> BTW:
>> +++ openssl-0.9.8g/Makefile
>> +++ openssl-0.9.8g/Configure
>> +++ ... (50 lines deleted)
>> +++ openssl-0.9.8g/util/pl/netware.pl

> This is *exactly* what I want the user to see.  The information that
> the source has *a lot* (53) files that are patched by the Debian
> maintainer is no spam at all but might make the user aware that there
> might be reasons to inspect the diff carefully and that it is not
> enough to look into debian/patches (which might not exist in this
> case, did not checked).

In that case, I fail to see why you are only interested in this
 information if the maintainer did not use quilt. Seems like you should
 be concerned about changes made to upstream, period,  regardless of
 whether the changes are recorded in quilt or not.

Am I missing something?

manoj
-- 
Peace cannot be kept by force; it can only be achieved by
understanding. Albert Einstein
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 handle Debian patches

[Manoj Srivastava]

On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
<[EMAIL PROTECTED]> said:  

Hmm. You say things like this:
> Because the git format is imho conceptualy broken and the
> implementation is far from completely thought out. 

And then you go saying things like that:
> It is trivial to generate a quilt format package from git/arch/hg/svn
> and I'm sure there will be a RCS-build-package soon enough that does
> that. 

This can not happen without manual intervention, if the topic
 branches have overlap. And  Redoing the manual conflict resolution over
 and over and over again is a burden (the manual conflict resolution
 lives generally in the integration branch history, and can be done
 once, and mostly ignored from that point on).

Now, the quilt series has to be regenerated on every new
 version, or whenever any topic branch gets an input; and doing the
 manual conflict resolution every time might not result in the same
 output (and not just through human error). This brings into question
 the utility of the series: the quilt series is not what the package is
 built from, and might not accurately reflect the integration branch; so
 I am told that from a security review viewpoint the resulting quilt
 series is not that useful.


Allow me to illustrate:
 Suppose there is a file that has 10 lines:
--8<---cut here---start->8---
1
2
3
4
5
6
7
8
9
10
--8<---cut here---end--->8---

I have a topic branch called Odd:
--8<---cut here---start->8---
101
2
103
4
105
6
107
8
9
10
--8<---cut here---end--->8---
And another one called even:
--8<---cut here---start->8---
1
202
3
204
5
206
7
208
9
10
--8<---cut here---end--->8---

Every change in either branch  will result in a conflict when
 trying to apply the second patch, though in this example the conflict
 resolution is trivial.  Can you demonstrate a tool that will correctly
 generate a quilt series from these branches?

manoj
-- 
The meek are contesting the will.
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 handle Debian patches

[Pierre Habouzit]

On Mon, May 19, 2008 at 03:29:13PM +, Mike Hommey wrote:
> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> > <[EMAIL PROTECTED]> said:  
> > 
> > Hmm. You say things like this:
> > > Because the git format is imho conceptualy broken and the
> > > implementation is far from completely thought out. 
> > 
> > And then you go saying things like that:
> > > It is trivial to generate a quilt format package from git/arch/hg/svn
> > > and I'm sure there will be a RCS-build-package soon enough that does
> > > that. 
> > 
> > This can not happen without manual intervention, if the topic
> >  branches have overlap. And  Redoing the manual conflict resolution over
> >  and over and over again is a burden (the manual conflict resolution
> >  lives generally in the integration branch history, and can be done
> >  once, and mostly ignored from that point on).
> (...)
> 
> git has git rerere to deal with this.

  Even better, mkdir .git/rr-cache and it'll do it automatically for
you.

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


pgp9racu8kOBK.pgp
Description: PGP signature

Re: How to handle Debian patches

[Mike Hommey]

On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> <[EMAIL PROTECTED]> said:  
> 
> Hmm. You say things like this:
> > Because the git format is imho conceptualy broken and the
> > implementation is far from completely thought out. 
> 
> And then you go saying things like that:
> > It is trivial to generate a quilt format package from git/arch/hg/svn
> > and I'm sure there will be a RCS-build-package soon enough that does
> > that. 
> 
> This can not happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over
>  and over and over again is a burden (the manual conflict resolution
>  lives generally in the integration branch history, and can be done
>  once, and mostly ignored from that point on).
(...)

git has git rerere to deal with this.

Mike


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

Re: How to handle Debian patches

[Manoj Srivastava]

On Mon, 19 May 2008 17:29:13 +0200, Mike Hommey <[EMAIL PROTECTED]> said: 

> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
>> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
>> <[EMAIL PROTECTED]> said:
>> 
>> Hmm. You say things like this:
>> > Because the git format is imho conceptualy broken and the
>> > implementation is far from completely thought out.
>> 
>> And then you go saying things like that:
>> > It is trivial to generate a quilt format package from
>> > git/arch/hg/svn and I'm sure there will be a RCS-build-package soon
>> > enough that does that.
>> 
>> This can not happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over and over and over again is a burden (the manual conflict
>> resolution lives generally in the integration branch history, and can
>> be done once, and mostly ignored from that point on).
> (...)

> git has git rerere to deal with this.

Two comments:

A) This is great for git users. Is there a hg-rerere? svn-rerere?
   tla-rerere? bzr-rerere?  I am just as opposed to everyone must use
   git as I am to everyone must use quilt.

B) (This is an honest question). How many things can rerere remember? If
   I use rerere to record how to resolve current conflicts in feature
   branches, does the historical information get lost? (like, I use
   rerere to help merging the current upstream version, do we lose
   information about previous upstream versions?)

manoj

-- 
Many people feel that they deserve some kind of recognition for all the
bad things they haven't done.
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]

Bug#481929: ITP: libmath-algebra-symbols-perl -- Symbolic Algebra in pure perl

[Deepak Tripathi]

Package: wnpp
Severity: wishlist
Owner: Deepak Tripathi <[EMAIL PROTECTED]>


* Package name: libmath-algebra-symbols-perl
  Version : 1.21 
  Upstream Author : Philip R Brenan <[EMAIL PROTECTED]> 
* URL : http://search.cpan.org/dist/Math-Algebra-Symbols/ 
* License : Perl License 
  Programming Lang: Perl
  Description : Symbolic Algebra in pure perl

Math::Algebra::Symbols supplies a set of functions and operators to
manipulate operator expressions algebraically using the familiar Perl syntax.

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

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

-- 
Thanks & Regards,
Deepak Tripathi(DK)| GPG: 0xB9B0C9F2 | IRC: deepak
deepaktripathi.blogspot.com

E3 71V3 8Y C063 (We Live By Code)
--


signature.asc
Description: Digital signature

Re: Current build status of the mips port

[Luk Claes]

Hi Thiemo

Thanks for this status report.

Thiemo Seufer wrote:
> I went again through the mips build problems and collected the appended
> list which records the current state, with a few annotations added.

> Needs retry
> ---

All given back when still needed. Please don't include packages in such
a listing that have a sane wanna-build state: packages in Needs-Build or
Dep-Wait or Building (for a normal amount of time)...

> Maybe needs retry (TODO: check)
> ---
> -- Qt ABI, fix by waiting for next Qt version --
> kde4libs  # needs rebuild to fix ABI (or wait for new version)
> kdebase-runtime
> merkaartor
> universalindentgui
> sailcut
> psi
> ktoon # Broken qt ABI

Do they or do they not need wanna-build magick?

> -- ghc6 stuff --
> washngo   # vm exhausted, (arm armel mips mipsel powerpc)
> haskell-haskell-src # vm exhausted, (mips mipsel alpha)
> lhs2tex
> pandoc
> gtkrsync
> highlighting-kate
> haskell-happs-data
> haskell-happs-ixset
> haskell-happs-server
> haskell-happs-state
> haskell-happs-util
> haskelldb-hsql-mysql
> haskelldb-hsql-odbc
> haskelldb-hsql-postgresql
> haskelldb-hsql-sqlite3
> arch2darcs
> darcs-buildpackage
> hpodder

Will these probably build fine when retried?

> -- other --
> mlt   # (ia64 mips mipsel powerpc)
> vdr-plugin-live
> kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips 
> powerpc s390 sparc)
> mozart
> gpsdrive
> libgtk-java   # needs libcairo-java-dev
> qtnx  # needs libnxcl1
> tuxguitar
> music-applet  # needs libxml-parser-perl, (mips mipsel powerpc)
> mplayer   # (hppa mips mipsel powerpc sparc)
> edenmath.app
> gnome-chemistry-utils
> virt-manager
> gsynaptics
> ucspi-proxy
> epiphany-extensions

What does this list mean?

> Should be in in P-a-s (or not-for-us?)
> --

Did you contact P-a-s administrators (and buildd maintainers) about it?

Cheers

Luk


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Mon, 19 May 2008, Manoj Srivastava wrote:


   In that case, I fail to see why you are only interested in this
information if the maintainer did not use quilt. Seems like you should
be concerned about changes made to upstream, period,  regardless of
whether the changes are recorded in quilt or not.

   Am I missing something?


Yes.  You are missing the fact that anybody who inspects a package will
inspect the debian dir anyway.  If there is a patches directory it is
obvious that upstream files are patched and there is no need to explicitely
give a hint about this.  If patches are "hidden" anywhere in the upstream
code some developers fail to realise this and my suggestion might help
noticing this fact.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: Current build status of the mips port

[Thiemo Seufer]

Luk Claes wrote:
> Hi Thiemo
> 
> Thanks for this status report.
> 
> Thiemo Seufer wrote:
> > I went again through the mips build problems and collected the appended
> > list which records the current state, with a few annotations added.
> 
> > Needs retry
> > ---
> 
> All given back when still needed. Please don't include packages in such
> a listing that have a sane wanna-build state: packages in Needs-Build or
> Dep-Wait or Building (for a normal amount of time)...

FTR, this list was only meant as an overview, not as a means to prod
buildd admins or the release team to do something with it. :-)
I planned to request give-backs via mail to -release.

All the items below need further analysis.

> > Maybe needs retry (TODO: check)
> > ---
> > -- Qt ABI, fix by waiting for next Qt version --
> > kde4libs# needs rebuild to fix ABI (or wait for new version)
> > kdebase-runtime
> > merkaartor
> > universalindentgui
> > sailcut
> > psi
> > ktoon   # Broken qt ABI
> 
> Do they or do they not need wanna-build magick?

I believe they will need only retries once a new kde4libs is uploaded
to unstable (which will fix the current qreal/float/double ABI breakage
on mips/mipsel). That said, I haven't tested if that's enough.

> > -- ghc6 stuff --
> > washngo # vm exhausted, (arm armel mips mipsel powerpc)
> > haskell-haskell-src # vm exhausted, (mips mipsel alpha)
> > lhs2tex
> > pandoc
> > gtkrsync
> > highlighting-kate
> > haskell-happs-data
> > haskell-happs-ixset
> > haskell-happs-server
> > haskell-happs-state
> > haskell-happs-util
> > haskelldb-hsql-mysql
> > haskelldb-hsql-odbc
> > haskelldb-hsql-postgresql
> > haskelldb-hsql-sqlite3
> > arch2darcs
> > darcs-buildpackage
> > hpodder
> 
> Will these probably build fine when retried?

At least washngo still fails, I haven't tested the rest of it.

> > -- other --
> > mlt # (ia64 mips mipsel powerpc)
> > vdr-plugin-live
> > kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips 
> > powerpc s390 sparc)
> > mozart
> > gpsdrive
> > libgtk-java # needs libcairo-java-dev
> > qtnx# needs libnxcl1
> > tuxguitar
> > music-applet# needs libxml-parser-perl, (mips mipsel powerpc)
> > mplayer # (hppa mips mipsel powerpc sparc)
> > edenmath.app
> > gnome-chemistry-utils
> > virt-manager
> > gsynaptics
> > ucspi-proxy
> > epiphany-extensions
> 
> What does this list mean?

Those _may_ build now, but that's untested.

> > Should be in in P-a-s (or not-for-us?)
> > --
> 
> Did you contact P-a-s administrators (and buildd maintainers) about it?

I mail the P-a-s administrator about once a year, I never got a response.


Thiemo


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> give a hint about this.  If patches are "hidden" anywhere in the upstream
> code some developers fail to realise this and my suggestion might help
> noticing this fact.

The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).

Gruss
Bernd

PS: are we going to somehow react to the massive loss of trust into debian,
for example by publishing a new policy, a qa task force or anything? From
quite some discussions I know it is expected (however I dont claim to have a
practcable answer). I just wonder why we currently discuss Mailing List
netiqette instead of the current issue.


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

Re: divergence from upstream as a bug

[Michael Banck]

On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
> 2) feature branches
> 
> Each feature branche is based on upstream (with few exceptions) and
> contains all changes for one feature.
> 
> Then you have an integration branche where all feature branches are
> merged. The merging generally needs human interaction somewhere in the
> history of the integration branch. Doesn't mean every merge needs it
> though.
> 
> Unfortunately there seems to be no way to generate a patch series from
> that other than one big patch for everything combined. The human
> interaction stored in the integration branch can't be machine
> transformed to make a patch series. It seems that that transformation
> is just as difficult as the merge itself.

The following might work:

Try to git-format-patch (or whatever tool applies for the particular
DVCS) each feature branch, see whether they apply cleanly by
luck/accident.  If so, store them as a 3.0 (quilt) debian/patches.

If they do not apply cleanly, store them individually at
debian/patch-series or some other directory to be agreed upon, and make
patches.debian.org be aware of this, i.e. expose them similar to the
debian/patches patches, but mark them as overlapping/conflicting.

Another possibility would be to combine those feature branches which
conflict which each other, but put the others in seperate patches, still
using 3.0 (quilt); however, the combined patch of conflicting feature
branches might be quite meaningless, so not sure about this.


Michael


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

Bug#481973: ITP: libiptables-parse-perl -- Perl extension for parsing iptables firewall rulesets

[Franck Joncourt]

Package: wnpp
Severity: wishlist
Owner: Franck Joncourt <[EMAIL PROTECTED]>


* Package name: libiptables-parse-perl
  Version : 0.5 
  Upstream Author : Michael Rash <[EMAIL PROTECTED]>
* URL : http://www.cipherdyne.org/modules/
* License : GPL, Artistic
  Programming Lang: Perl
  Description : Perl extension for parsing iptables firewall rulesets

The "IPTables::Parse" package provides an interface to parse iptables
rules on Linux systems through the direct execution of iptables
commands, or from a file.

You can get the current policy applied to a table/chain, look for a specific
user-defined chain, check for a default DROP policy, or know whether or not
logging rules exist.




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

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
> > You're describing a situation where upstream is difficult or impossible
> > to communicate with. I can't solve that, nor can anyone except upstream.
> 
>   Except that once again, upstream that would benefit from our system
> the most are those kind of upstreams, with very large sources, huge user
> base, huge bugs lists, and massive amounts of patches floating around.

This does not imply that such upstreams (which I agree are those who
would benefit most from the improvements being discussed) are using
systems hard to communicate with.

I get your word that KDE and glibc are in such a category, but we need a
bit of numbers before concluding that "large packages" implies "sucky
BTSs". Do you perhaps have some kind of evidence of this from bts-link?
(If this is so, it wasn't clear to me from the post I'm replying to.)

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: divergence from upstream as a bug

[Stefano Zacchiroli]

On Sun, May 18, 2008 at 01:17:09AM +0200, Josselin Mouette wrote:
> That would be very nice. I think you could easily make giant
> improvements by reworking the bug listing pages. They would be much more
> useful with a table listing all bugs with one bug per line, color
> indicators for the severity, and a column on the left with icons
> indicating the tags and the Debian versions the bug applies to.

#434504 (though the bug subject is a bit misleading). At the end of the
report there are some CSS stylesheets which changes the output to a
trac-like bug listing. Help is needed to finish it up ...

-- 
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: divergence from upstream as a bug

[Stefano Zacchiroli]

On Sat, May 17, 2008 at 03:55:12PM -0700, Don Armstrong wrote:
> One of the wishlist features for the BTS that I've been contemplating
> setting up is a "summary" feature, whre the current summary of a bug
> is shown at the top, with the history continuing below.
> 
> This could be easily extended to having patch messages nominate
> themselves as the summary message.

How I'm reading the latter paragraph is that patch messages are
*alternative* as some non-patch summary message, am I wrong? I think the
two should be orthogonal: you can have or not a summary message, you can
have or not a patch.

But still this does not solve another problem we have with patch
management in the BTS: they are sometimes inlined, while sometimes the
are attached. Can't we fix attachment as the required format for
patches? (e.g. forcing an attachment if one wants to add +patch or
something similar). This + the forthcoming ability above to identify
*the* latest patch will give us the ability to automatically extract
patches from bug reports.

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: How to handle Debian patches

[Gunnar Wolf]

Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
> If I understand things correctly (but I'm really not sure I do), 3.0
> (quilt) won't really help with that: it won't prevent maintainers to
> directly modify files outside of debian/ , and generate a huge
> debian/patches/debian-changes-version.diff.
> 
> It seems to me that what we need to do is decide that using dpatch or
> quilt is the way to go (with properly commenting individual patches).
> It's a social problem, not a technical one.

But with some time put to it, we can end up including a "the
maintainer shuold not modify files outside of the debian/ directory
without a strong rationale", and provide lintian checks for packages
still directly modifying upstream code...

It can become a long transition, but a good one in the end, /methinks.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Mon, 19 May 2008, Bernd Eckenfels wrote:


The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).


Well, I'm DD for 10 years - I know this fact.  But did you read about
habits of other fellow developers in this thread.  Just reread and come back
if you are really sure that an extra hint about patches is really useless.


PS: are we going to somehow react to the massive loss of trust into debian,


No I just try to think about implementing what I regularly do and would
call a reasonable habit that might help others.


I just wonder why we currently discuss Mailing List
netiqette instead of the current issue.


I do so as well, but my 'd'-key works perfectly for this kind of subjects ...

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: Bug#481973: ITP: libiptables-parse-perl -- Perl extension for parsing iptables firewall rulesets

[gregor herrmann]

On Mon, 19 May 2008 22:38:16 +0200, Franck Joncourt wrote:

> * Package name: libiptables-parse-perl
 
> The "IPTables::Parse" package provides an interface to parse iptables
> rules on Linux systems through the direct execution of iptables
> commands, or from a file.

The package psad contains a file /usr/lib/perl5/IPTables/Parse.pm.

(http://www.cipherdyne.org/modules/ also mentions ".. provides ..
modules used by the psad, ...")

This potential clash should be sorted out before an upload.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Brook Benton: Thank You Pretty Baby


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Mon, May 19, 2008 at 09:40:09PM +, Stefano Zacchiroli wrote:
> On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
> > > You're describing a situation where upstream is difficult or impossible
> > > to communicate with. I can't solve that, nor can anyone except upstream.
> > 
> >   Except that once again, upstream that would benefit from our system
> > the most are those kind of upstreams, with very large sources, huge user
> > base, huge bugs lists, and massive amounts of patches floating around.
> 
> This does not imply that such upstreams (which I agree are those who
> would benefit most from the improvements being discussed) are using
> systems hard to communicate with.
> 
> I get your word that KDE and glibc are in such a category, but we need a
> bit of numbers before concluding that "large packages" implies "sucky
> BTSs". Do you perhaps have some kind of evidence of this from bts-link?
> (If this is so, it wasn't clear to me from the post I'm replying to.)

  It does not implies such a thing, it's not even a hard rule, though
it's common enough. KDE uses a huge BZ, Gnome does too, mozilla does
too, xorg does too, linux also has a BZ (even if I'm not sure it's the
preferred form of bug reporting, it's quite unclear depending on the
submodule), gcc, binutils and most of the toolchain packages have a BZ
(on sourceware.org), OOo has an issuezilla (which is a BZ in disguise), …

  Of course, vim uses a mailing list, TTBOMK emacs does too.

  You can have a look by yourself, the current list of BTSes bts-link
knows about is here:
http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=btslink.cfg;hb=HEAD
The sole decent BTS here is trac, that allow to report bugs in one form
only, no auth (except HTTP), no intermediate form, no nothing. I've had
to use every of the other ones (except mantis) and none are efficient
for reporting bugs massively like maintainers with thousands of bug
should do.

  Of course, bts-link don't know every BTS out there, bug it's fair to
assume I've been contacted by maintainers that find that dealing with
their upstream's BTS is a PITA (else they wouldn't have bothered sending
me a mail probably).

  Anyways, my point is that we should not really focus on how to "track"
patches, but how to ease reporting bugs/patches upstream, in a unified
_simple_ way. The current discussion is built on sand: Joey's proposal
stands on the assumption that maintainers do open bugs upstream for each
patch they have in their package. That isn't true, and for a good
reason: for many upstreams, this is way too long. Speaking from
experience, when I work on a Debian package, reason says that I should
only spend 30 minutes on it. 45 minutes later I'm still on it, and well,
when the patches I've written have to go to a BZ, I just don't forward
them because I'm already 15 minutes late, and that it's a one minute
story per patch. I just don't have that time for -15 minutes already.
When upstream uses a Mailing list, or anything where I can submit
patches sending a mail, it's merely a git-format-patch | mail, which is
3 seconds away, and I do it. And it's enough because my patches are
commented.

  Is it bad behavior ? Yes, it is. But that's the way it is, and I would
be more than surprised to be an isolate case. Just write a damn tool
that allow forwarding bugs with a unified _optimized_ (ergonomics-wise)
fashion, and tadaaa you'll see that many things will be way simpler, and
that we won't even need joey's proposal at all, or only for very seldom
cases.

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


pgpTzZDEf0WNz.pgp
Description: PGP signature

Re: How to handle Debian patches

[Pierre Habouzit]

On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
> B) (This is an honest question). How many things can rerere remember? If
>I use rerere to record how to resolve current conflicts in feature
>branches, does the historical information get lost? (like, I use
>rerere to help merging the current upstream version, do we lose
>information about previous upstream versions?)

  git-rerere keeps recorded conflicts resolution for 60 days by default,
and it's configureable, and it needs to use git-gc (or git rerere gc) to
cleanse it, so if you don't, it just won't disappear.

  git-rerere works by remembering versions of files before a conflict
and after its resolution, so that if this particular conflict is met
again, it just propose the last merge as a merge solution when a
conflict occurs. But it does not hides from you that you had a conflict,
it's just that instead of presenting to you a file with conflicts marks
in it, it replaced the hunks where there is a conflict with the previous
merge solution instead, so that in many cases you just have to {git
commit,git rebase --continue, ...} (depending on which action led you to
this conflict of course) without having to solve the conflict by hand.

  I'm not sure I answer your question wrt "history" but I'm not sure
it's a relevant question either.

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


pgpv9T4YynuDk.pgp
Description: PGP signature

Bug#481980: RFP: Jubler -- Jubler Subtitle Editor

[dpdt1]

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

--- Please fill out the fields below. ---

   Package name: Jubler
Version: 3.9.0
Upstream Author: [Panayotis Katsaloulis <[EMAIL PROTECTED]>]
URL: [http://www.jubler.org]
License: [GPL]
Description: [Subtitle Editor]

-- 
During times of universal deceit, telling the truth becomes a revolutionary 
act.



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

Re: How to handle Debian patches

[Ben Finney]

Mike Hommey <[EMAIL PROTECTED]> writes:

> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> > <[EMAIL PROTECTED]> said:  
> > > It is trivial to generate a quilt format package from
> > > git/arch/hg/svn and I'm sure there will be a RCS-build-package
> > > soon enough that does that.
> > 
> > This can not happen without manual intervention, if the
> >  topic branches have overlap. And Redoing the manual conflict
> >  resolution over and over and over again is a burden (the manual
> >  conflict resolution lives generally in the integration branch
> >  history, and can be done once, and mostly ignored from that point
> >  on).
> (...)
> 
> git has git rerere to deal with this.

Bazaar is soon to gain the "loom" feature, currently in development
http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt> which
also will deal with this issue.

-- 
 \ "Yesterday I parked my car in a tow-away zone. When I came back |
  `\   the entire area was missing."  -- Steven Wright |
_o__)  |
Ben Finney


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

Bug#481973: ITP: libiptables-parse-perl -- Perl extension for parsing iptables firewall rulesets

[Franck JONCOURT]

Hi,

> The package psad contains a file /usr/lib/perl5/IPTables/Parse.pm.
>
> (http://www.cipherdyne.org/modules/ also mentions ".. provides ..
> modules used by the psad, ...")
>
> This potential clash should be sorted out before an upload.

As a matter of fact, all packages from cipherdyne are being packaged
to avoid conflicts between psad, fwsnort and fwknop.

Talking with Daniel Gubser (psad maintainer), and Michael Rash 
(upstream author), we decided the best way to integrate the three main
packages, was to create : 

- libiptables-parse-perl
- libiptables-chainmgr-perl

So, right now, in my repository, I have :

- a rebuilt psad with new dependencies,
- fwsnort,
- libiptables-parse-perl (IPTables::Parse),
- libiptables-chainmgr-perl (IPTables::ChainMgr),
- fwknop under development.

Daniel is fairly busy, but I am working with M. Rash to get something 
nice until he has the time to take a look.

---
Franck Joncourt.



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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Michael Banck <[EMAIL PROTECTED]> writes:

> On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
>> 2) feature branches
>> 
>> Each feature branche is based on upstream (with few exceptions) and
>> contains all changes for one feature.
>> 
>> Then you have an integration branche where all feature branches are
>> merged. The merging generally needs human interaction somewhere in the
>> history of the integration branch. Doesn't mean every merge needs it
>> though.
>> 
>> Unfortunately there seems to be no way to generate a patch series from
>> that other than one big patch for everything combined. The human
>> interaction stored in the integration branch can't be machine
>> transformed to make a patch series. It seems that that transformation
>> is just as difficult as the merge itself.
>
> The following might work:
>
> Try to git-format-patch (or whatever tool applies for the particular
> DVCS) each feature branch, see whether they apply cleanly by
> luck/accident.  If so, store them as a 3.0 (quilt) debian/patches.

They will not except for trivial cases. And in trivial cases you can
probably seperate patches from on big patch reasonably well too.

Anyway, if you do have such a case you can just claim you have a
stacked branches setup. Such a setup would have some file giving the
order in which branches should be applied and any order would do.

> If they do not apply cleanly, store them individually at
> debian/patch-series or some other directory to be agreed upon, and make
> patches.debian.org be aware of this, i.e. expose them similar to the
> debian/patches patches, but mark them as overlapping/conflicting.

Which might be usefull for upstream but not for anyone working on the
package to fix a bug. As such I don't think that has anything to do in
the source package. For feature branches I would rather have
patches.debian.org fetch the diff from the RCS directly or just link
there.

> Another possibility would be to combine those feature branches which
> conflict which each other, but put the others in seperate patches, still
> using 3.0 (quilt); however, the combined patch of conflicting feature
> branches might be quite meaningless, so not sure about this.

I'm not sure if that is even worth it.

MfG
Goswin


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

Re: How to handle Debian patches

[Andreas Tille]

On Tue, 20 May 2008, Pierre Habouzit wrote:


 git-rerere keeps recorded conflicts resolution for 60 days by default,
and it's configureable, and it needs to use git-gc (or git rerere gc) to
cleanse it, so if you don't, it just won't disappear.


I admit I realy don't care what your favourite VCS of the day (yes I've
also read the hint about bazaar "loom" feature comming soon) if an

apt-get source 

which I regard THE method the obtain a Debian package source gives no
better hints about patches in the upstream source.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: How to handle Debian patches

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> <[EMAIL PROTECTED]> said:  
>
> Hmm. You say things like this:
>> Because the git format is imho conceptualy broken and the
>> implementation is far from completely thought out. 
>
> And then you go saying things like that:
>> It is trivial to generate a quilt format package from git/arch/hg/svn
>> and I'm sure there will be a RCS-build-package soon enough that does
>> that. 
>
> This can not happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over
>  and over and over again is a burden (the manual conflict resolution
>  lives generally in the integration branch history, and can be done
>  once, and mostly ignored from that point on).

A quilt format package with a single combined patch. Get the
integration branch, get orig.tar.gz, build. dpkg-buildpackage will
automatically create a debian_version.patch for you. It is easy.

I'm not saying you get a nice and shiny debian/patches/* out of
it. That indeed needs human interaction as already said elsewhere.

To the non git (even not quilt) experienced user the combined patch
will be usable in that he can edit the source and fix bugs. The git
format does not allow that.

Even with some git knowledge I think that most users that write a
patch won't follow the maintainers workflow. They won't find the right
feature branch a patch belongs to and how to merge that into an
integration branch. Instead they will just edit the source, git commit
and send the resulting patch. And that means you get a patch against
the integration branch. Same as you would with the quilt format.

Users that dig deeper into the source to find out the maintainers
workflow I would expect to be able to find the maintainers git
repository too and just use that directly. So the only use for the git
format is for people that can already use the original git
repository. Hence my view that it is a bad format.

MfG
Goswin


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

Re: How to handle Debian patches

[Goswin von Brederlow]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
>> B) (This is an honest question). How many things can rerere remember? If
>>I use rerere to record how to resolve current conflicts in feature
>>branches, does the historical information get lost? (like, I use
>>rerere to help merging the current upstream version, do we lose
>>information about previous upstream versions?)
>
>   git-rerere keeps recorded conflicts resolution for 60 days by default,
> and it's configureable, and it needs to use git-gc (or git rerere gc) to
> cleanse it, so if you don't, it just won't disappear.

If you have a feature branch that won't be accepted upstream then that
can be years old. And conflicts could have been resolved right at the
start of that time.

How does git-rerere dig out that years old conflict resolution?

How do you tell git-rerere to keep all conflict resolutions needed to
convert feature branches into a patch series but not others?

How sure are you that will actually work right and not misidentify
code at the wrong places? Ok, I guess you can compare the patch series
output against the integration branch and they should be identical.

MfG
Goswin


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

Re: How to handle Debian patches

[Goswin von Brederlow]

Gunnar Wolf <[EMAIL PROTECTED]> writes:

> Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
>> If I understand things correctly (but I'm really not sure I do), 3.0
>> (quilt) won't really help with that: it won't prevent maintainers to
>> directly modify files outside of debian/ , and generate a huge
>> debian/patches/debian-changes-version.diff.

Yes it will. Any modified file will end up in debian/patches/ instead
of modifying the file directly. It will not prevent patches but it
ensures they are used exclusively. So no packages that change some
files directly and use debian/patches/ for others.
 
>> It seems to me that what we need to do is decide that using dpatch or
>> quilt is the way to go (with properly commenting individual patches).
>> It's a social problem, not a technical one.
>
> But with some time put to it, we can end up including a "the
> maintainer shuold not modify files outside of the debian/ directory
> without a strong rationale", and provide lintian checks for packages
> still directly modifying upstream code...

Do you mean no debian/patches at all?

> It can become a long transition, but a good one in the end, /methinks.

MfG
Goswin


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Charles Plessy]

Le Mon, May 19, 2008 at 10:25:35PM +0200, Bernd Eckenfels a écrit :
> In article <[EMAIL PROTECTED]> you wrote:
> > give a hint about this.  If patches are "hidden" anywhere in the upstream
> > code some developers fail to realise this and my suggestion might help
> > noticing this fact.
> 
> The debian Diff is not hiding patches in the upstream code. It is the
> canonical place to publish them (at least for some (most?) of the debian
> packages following policy).

Hi all,

If we take openssl as an example, we can see that many .pl files are
modified. A quick inspection shows that for most of them the only change
is the path to Perl in the first line. The only way to know if it is the
case for all is to look at all of them one by one. The Debian diff.gz
file is a technical way to apply the Debian modifications to the
original sources, but it seems to me a very suboptimal way to publish
patches of the quality level that one would expect for his own software.
To keep on the openssl example, the patched .pl are dispersed within the
.diff.gz file. That is, different logical units are mixed, and to submit
one of them would necessitate to generate a new patch that is not a
contiguous extract of the original diff.gz. This is how I understand -
and agree with - the claim that patches are "hidden" in the diff.gz.

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: Bug#481973: ITP: libiptables-parse-perl -- Perl extension for parsing iptables firewall rulesets

[gregor herrmann]

On Tue, 20 May 2008 00:34:48 +0200, Franck JONCOURT wrote:

> > The package psad contains a file /usr/lib/perl5/IPTables/Parse.pm.
> As a matter of fact, all packages from cipherdyne are being packaged
> to avoid conflicts between psad, fwsnort and fwknop.

Sounds good, thanks for the clarification!
 
BTW: Just in case you don't know, there's the Debian Perl Group that
could help with the two lib*-perl packages:
http://wiki.debian.org/Teams/DebianPerlGroup

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-You're dead, Jim.  -- McCoy, "Amok Time", stardate 3372.7 


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

package config

[Anthony]

Hello, everybody

I have a little question about ucf (example with a package which
contains a file package_file.conf)

Can i use de package_file.conf.dpkg-old generate by the ucf utility?

I would like to know how can i restore the old conf files after use ucf.?

I have created a package which manage some files with ucf BUT when i
remove the package i would like to restore the files before the
installation .
I could rename the file package_file.conf.dpkg-old in package_file.conf
in postrm script (remove)


Thank you

Anthony


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