Re: Using debian/upstream to document things about Upstream with “umegaya”.

[Charles Plessy]

Le Tue, Jan 17, 2012 at 08:09:25AM +0800, Paul Wise a écrit :
>
> I would encourage you to merge your efforts with DEP-11 so that the
> upstream metadata can also be made available via apt.
> 
> Personally I never understood why you decided to use a file separate
> to debian/control for this metadata.

Dear Paul,

thanks for the comments.

I think that debian/control should not be used for fields that will not be
exported to Debian source control, Debian binary control or Debian changes
files.  In line with this, such fields would need to be always prefixed to
prevent dpkg rejecting the file.  Also, I prefer to have a separate namespace,
in order to standardise as much as possible on existing formats such as DOAP
without having to worry about dpkg and the Debian Policy.

The data gathered would definitely be available for projects such as DEP 11,
either directly or through the UDD, although I wonder if our projects have a
too different granularity (source package for upstream metadata, applications
for apt).  Actually I still do not understand well the information flow for DEP
11.  For me, it looks that the ideal carriers for DEP 11 are the FreeDesktop
menu entry files; and this has the advantage that is a good mechanism to share
the metadata between distributions by sending patches upstream.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120117074843.gn24...@merveille.plessy.net

Re: Bug#656142: ITP: duff -- Duplicate file finder

[martin f krafft]

also sprach Kamal Mostafa  [2012.01.17.0049 +0100]:
> In my humble opinion, that would be an unreasonable pre-condition for
> inclusion in Debian.  Our standard for inclusion should not be that a
> new package must be "vastly better" than other similar packages.  That
> would deny a new package the opportunity to build a user base and
> possibly someday evolve to become the "vastly better" alternative
> itself.

Right, but I'd say it needs to be better and the maintainer needs to
be able to argue how it is better.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"die zeit für kleine politik ist vorbei.
 schon das nächste jahrhundert
 bringt den kampf um die erdherrschaft."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Using debian/upstream to document things about Upstream with “umegaya”.

[Andreas Tille]

On Tue, Jan 17, 2012 at 08:09:25AM +0800, Paul Wise wrote:
> I would encourage you to merge your efforts with DEP-11 so that the
> upstream metadata can also be made available via apt.
> 
> Personally I never understood why you decided to use a file separate
> to debian/control for this metadata.

There are enough people who are considering debian/control overloaded
even these days.  The current use case for upstream metadata file is
gathering bibliographic information which is connected to the software
in question.  This will be used

  a) At tasks pages like med-bio[1] (see string "Please cite")
 This feature makes some upstream developers *very* happy about
 Debian.
  b) Creating a common BibTeX file (see proposal at [2])

There are a lot of people which would raise reasons against keeping such
information in debian/control (please prove me wrong with answers
explicitely wanting bibliographic information in debian/control).

IMHO the information in the debian/control file should make sense for
the majority of packages inside Debian.  For instance most of the
packages are featuring a homepage.  Please remember how long it took
to at least accept this feature in debian/control.

Moreover if this kind of data needs mentioning in packaging
documentation and might blur this and thus confuse newcomers.

Finally from the side of an application which tries to gather
bibliographic information from all Debian packages it would need to
parse all control files but only less than 0.1% of packages do contain
this information.  It would be way more performant to just look for a
debian/upstream file and parse this if existent.

So while I'm in principle not against having all information collected
in one file I found myself perfectly valid reasons to not to do this.
Those people who are not happy about a lot of information in
debian/control will find additional ones.  And I want a solution now
without endless discussion without a foreseeable result.

(I might have missunderstood DEP-11 but can not check
  http://dep.debian.net/deps/dep11
 seems to be hosted on vasks as well, right?)

Kind regards

Andreas.

[1] http://debian-med.alioth.debian.org/tasks/bio
use this link for the moment as long as vasks is down
http://debian-med.debian.net/tasks/bio
[2] http://wiki.debian.org/DebianScience/ProblemsToWorkOn

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120117070851.gd21...@an3as.eu

Re: from / to /usr/: a summary

[Paul Wise]

On Fri, Jan 6, 2012 at 4:56 AM, Romain Beauxis wrote:
> 2012/1/5 Paul Wise :
>> In my opinion it is a pretty ugly hack that we should discourage where 
>> possible.
>
> There is a trade-off to consider between patching every single webapp,
> having no writable location at all and placing files where they belong
> to. I consider that a good one (trade-off).

Hence the "where possible"

>> The right way to do things is something like how things are done with
>> django-based applications.
>
> It would probably be more convincing if you'd take the time to explain
> what is done there..

Web server configuration that tells the app where to find its
configuration. App configuration tells the app where to find its data,
plugins etc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HpLV+Jwvze5GFZNftycdzUty+ghRzpRuNPnV1v01_=l...@mail.gmail.com

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Russ Allbery]

Thomas Goirand  writes:

> Also, does this mean that you've patched the policy, that lintian would
> soon more aggressively complain about lacks of patch comments, and that
> we'll have a new Standard-Version?

No.  DEP-3 is an optional standard.

I'm not sure if it should be incorporated into Policy or not.  It's
probably not a bad idea, although we should deal with DEP-5 first and see
if that provides a reasonable precedent for how to do so.

> BTW, what's the status of DEP5?

One of the DEP drivers is not yet happy with the level of specificity and
detail provided to ensure that the results are interoperable, and I'd like
to see those concerns resolved before including it in Policy.  (Which is
currently being worked on, as I understand it.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ty3vqffk@windlord.stanford.edu

Re: Using debian/upstream to document things about Upstream with “umegaya”.

[Paul Wise]

I would encourage you to merge your efforts with DEP-11 so that the
upstream metadata can also be made available via apt.

Personally I never understood why you decided to use a file separate
to debian/control for this metadata.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6h+jndhqwrwwfs6nnhyu+wsyko1hd7jmckkxadbqup...@mail.gmail.com

Using debian/upstream to document things about Upstream with “umegaya”.

[Charles Plessy]

Dear all,

I have already promoted a couple of times on this list the idea of gathering
(meta) data about Upstream in the source package, more precisely in the
repository where the source package is developed.

  http://wiki.debian.org/UpstreamMetadata

There was not much progress in 2011, but work is restarting.  We are working
towards the first proof of principle, to use this data through the UDD to
populate some templates for the Debian Med pure blend ‘tasks’ pages.  I will
not go further for the sake of brievty, but you can refer to the above link for
more information.

For the moment, I would like to ask if there were objections if we would start
to use the file name debian/upstream instead of the current name
debian/upstream-metadata.yaml, which is a typing mistake honeypot.  We maintain
a couple hundreds of packages in the Debian Med project, and if we start to use
debian/upstream for this purpose, it will make it unavailable for other current
or planned purposes.

Can we take ‘upstream’ in the ‘debian/’ namespace ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120117000236.gd9...@merveille.plessy.net

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Charles Plessy]

Le Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog a écrit :
> 
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
> 
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/

Bonjour Raphaël,

with my DEP admin hat on, I congratulate and thank you for homing this DEP
to completion.

In my understanding of the process, DEP 3 will not be changed anymore.  The
format it defines has been implemented in different tools, and this is the
achievement of DEP 3.  Modifications of the format are of course possible, as a
new DEP (taking as inspiration the RFCs 822, 2822 and then 5322), or outside
the DEP process.

Have a nice day,

-- 
Charles Plessy
Debian Enhancement Process team,
http://dep.debian.net
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116235059.gc9...@merveille.plessy.net

Re: Bug#656142: ITP: duff -- Duplicate file finder

[Kamal Mostafa]

On Mon, 2012-01-16 at 23:07 +0100, Joerg Jaspert wrote:
> >> What is it the benefit over fdupes, rdfind, ...?
> > ..., hardlink, ...
> finddup from perforate

After a quick evaluation of the various "find dupe files" tools, I was
attracted to try duff because:

1. It looked easier to use than the others.
2. This quote from its website[1] was exactly what I was looking for:
"Note that duff itself never modifies any files, but it's designed to
play nice with tools that do."  The other dupe cleaner utilities left me
worried that they might trash something important if I got my command
line options wrong or forgot a --dry-run flag.


> > Was thinking about packaging it myself already, so I may also sponsor
> > Kamal's package when it's ready.

Thanks Axel, but I'm a DD myself, so won't need a sponsor.


> You just listed the third duplicate (and me no. 4), and still go blind
> right on "ohoh, i sponsor it". Why? I hope its conditional on it being
> vastly better than any of the others (speed, functionality, ...)

In my humble opinion, that would be an unreasonable pre-condition for
inclusion in Debian.  Our standard for inclusion should not be that a
new package must be "vastly better" than other similar packages.  That
would deny a new package the opportunity to build a user base and
possibly someday evolve to become the "vastly better" alternative
itself.

 -Kamal

ka...@whence.com
ka...@debian.org

[1] http://duff.sourceforge.net/



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

Re: How mature is Pkg-format 3.0 (git), yet?

[Paul Wise]

2012/1/17 Björn Esser:

> I just wanted to ask how mature Package-format 3.0 (git) became until now.

It is not currently accepted by the Debian archive:

http://bugs.debian.org/642801

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6ejwrhbrszhfshjjaqwolx8xxqgwtjodhy2-tyh6+r...@mail.gmail.com

Re: Bug#656142: ITP: duff -- Duplicate file finder

[Joerg Jaspert]

>> What is it the benefit over fdupes, rdfind, ...?
> ..., hardlink, ...

finddup from perforate

> Was thinking about packaging it myself already, so I may also sponsor
> Kamal's package when it's ready.

You just listed the third duplicate (and me no. 4), and still go blind
right on "ohoh, i sponsor it". Why? I hope its conditional on it being
vastly better than any of the others (speed, functionality, ...) and not
just "because".

Contrary to some common believe, Debian is not the dump for NIH, and
even if a little redundancy can't hurt, too much is just waste. Of our
time, of our mirrors (space and bandwidth), ...

-- 
bye, Joerg
Contrary to common belief, Arch:i386 is *not* the same as Arch: any.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hazvb8sg@gkar.ganneff.de

How mature is Pkg-format 3.0 (git), yet?

[Björn Esser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi there!

I just wanted to ask how mature Package-format 3.0 (git) became until now.

BR,

Björn.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk8Une4ACgkQ3u1SIc8s7PWuXgEAhXSGrJOhx93UjUU3OmQZ9toY
mRxOJ+99KX9TJHDQGPUA/0eKvCuWDdVM3vSBC4u3Gn7qE4WZXAsS7mVh0sfb5WZW
=v5pK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f149def.7090...@googlemail.com

Re: Bug#656142: ITP: duff -- Duplicate file finder

[Axel Beckert]

Hi,

Samuel Thibault wrote:
> > * Package name: duff
> >   Version : 0.5
> >   Upstream Author : Camilla Berglund 
> > * URL : http://duff.sourceforge.net/
> > * License : Zlib
> >   Programming Lang: C
> >   Description : Duplicate file finder
> > 
> > Duff is a command-line utility for identifying duplicates in a given set of
> > files.  It attempts to be usably fast and uses the SHA family of message
> > digests as a part of the comparisons.
> 
> What is it the benefit over fdupes, rdfind, ...?

..., hardlink, ...

Some of my coworkers prefer duff over the tools available in Debian,
too. I'm though no more sure why, but it's possible that speed was one
argument, because they ran it over several TB of data. Will check
what exactly was the reason back then.

Was thinking about packaging it myself already, so I may also sponsor
Kamal's package when it's ready.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116213236.gy2...@sym.noone.org

Re: Bug#656142: ITP: duff -- Duplicate file finder

[Samuel Thibault]

Kamal Mostafa, le Mon 16 Jan 2012 12:58:13 -0800, a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Kamal Mostafa 
> 
> 
> * Package name: duff
>   Version : 0.5
>   Upstream Author : Camilla Berglund 
> * URL : http://duff.sourceforge.net/
> * License : Zlib
>   Programming Lang: C
>   Description : Duplicate file finder
> 
> Duff is a command-line utility for identifying duplicates in a given set of
> files.  It attempts to be usably fast and uses the SHA family of message
> digests as a part of the comparisons.

What is it the benefit over fdupes, rdfind, ...?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116210316.gs4...@type.famille.thibault.fr

Bug#656142: ITP: duff -- Duplicate file finder

[Kamal Mostafa]

Package: wnpp
Severity: wishlist
Owner: Kamal Mostafa 


* Package name: duff
  Version : 0.5
  Upstream Author : Camilla Berglund 
* URL : http://duff.sourceforge.net/
* License : Zlib
  Programming Lang: C
  Description : Duplicate file finder

Duff is a command-line utility for identifying duplicates in a given set of
files.  It attempts to be usably fast and uses the SHA family of message
digests as a part of the comparisons.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120116205813.24274.12515.reportbug@localhost6.localdomain6

Re: status of DEP5: Machine-readable debian/copyright (was: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status)

[Thomas Goirand]

On 01/17/2012 01:44 AM, Steve Langasek wrote:
> On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
>   
>> FTR given that I got no reports of problems with DEP-3, that it's already
>> well established, I just changed the state of the DEP-3 from CANDIDATE
>> to ACCEPTED.
>>
>> Of course this does not mean that the DEP-3 can't be extended or improved
>> (in particular when it doesn't break backwards compatibility)
>> but it does mean that this format is ready for widespread usage. Use it to
>> document the patches that you add to Debian packages:
>> http://dep.debian.net/deps/dep3/
>> 
> +1 for moving this to accepted.
>   
Steve, since you're marked as "|Drivers" at:
http://dep.debian.net/deps/dep5/

could you tell what's blocking DEP5 status from
switching to ACCEPTED? Are there any more ongoing
discussions on it?

Cheers,

Thomas

P.S: Hoping that Raphael wont mind too much that
I'm a bit hijacking his thread! :)

|


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f148bab.7010...@debian.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Thomas Goirand]

On 01/17/2012 01:56 AM, Mehdi Dogguy wrote:
> On 16/01/12 18:33, Thomas Goirand wrote:
>>
>> Also, does this mean that you've patched the policy, that lintian
>> would soon more aggressively complain about lacks of patch comments,
>> and that we'll have a new Standard-Version?
>>
>
> Lintian already complains when a quilt patch doesn't contain a
> description, fwiw.

I know that, but it's currently just warnings, not hard errors.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1489d4.5080...@debian.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Raphael Hertzog]

On Tue, 17 Jan 2012, Thomas Goirand wrote:
> I'm really not sure what makes you authoritative for it though,
> and I'd like to understand (which doesn't conflict with the fact
> I'm happy dep3 is in state ACCEPTED, and that you decided to
> do it!).

I just did it as the DEP driver because I believe that there's a
consensus that the implementation has been a success and that's the
criteria set in DEP-0.

Since the goal was only to provide a format to standardize the
meta-information and that many people are successfully using this
format to document their patch, I think we can assert that the DEP
has been successful.

I have not counted how many patches embed those standardized fields so I
can't say how widely it is used but I know from the interaction with
various DD / teams that it's relatively well accepted (the quilt
maintainer even recently added a --dep3 option to "quilt header").

> Also, does this mean that you've patched the policy, that lintian
> would soon more aggressively complain about lacks of patch
> comments, and that we'll have a new Standard-Version?

No, the policy is not the proper place for this, but I believe that a
recommendation in the developers-reference would be appropriate.

Lintian already recommends the usage of DEP3 in the long description of
the relevant "informative" tags it has:
http://lintian.debian.org/tags/dpatch-missing-description.html
http://lintian.debian.org/tags/quilt-patch-missing-description.html

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116194919.ge15...@rivendell.home.ouaza.com

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Ian Jackson]

Jon Dowland writes ("Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED 
status"):
> Who should have that authority, then? The DEP-0 proposers?  Since
> the whole DEP process itself is still in CANDIDATE, we could end up
> in an interesting situation if/when it comes to migrate *that* to
> ACCEPTED ☺

I think the DPL should appoint a dictator who will rule on when
consensus has been achieved on a DEP.

If the dictator gets it wrong then insofar as a DEP is a technical
policy for Debian (which DEP-3 definitely is) the Technical Committee
could overrule the decision, as could a GR of course.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20244.26459.605817.973...@chiark.greenend.org.uk

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jakub Wilk]

* Raphael Hertzog , 2012-01-16, 12:14:
FTR given that I got no reports of problems with DEP-3, that it's 
already well established, I just changed the state of the DEP-3 from 
CANDIDATE to ACCEPTED.


Does a DEP-3 parser exist? And why not?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116181507.ga2...@jwilk.net

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Mehdi Dogguy]

On 16/01/12 18:33, Thomas Goirand wrote:


Also, does this mean that you've patched the policy, that lintian
would soon more aggressively complain about lacks of patch comments,
and that we'll have a new Standard-Version?



Lintian already complains when a quilt patch doesn't contain a
description, fwiw.

See http://lintian.debian.org/tags/quilt-patch-missing-description.html

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1464df.5000...@dogguy.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Thomas Goirand]

On 01/16/2012 07:14 PM, Raphael Hertzog wrote:
> Hello,
>
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
>
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/
>
> Cheers,
>   
IMHO, that's a very good thing if we can improve Debian, and
don't hold back proposals indefinitively, especially when most of
us are already implementing such DEP.

I'm really not sure what makes you authoritative for it though,
and I'd like to understand (which doesn't conflict with the fact
I'm happy dep3 is in state ACCEPTED, and that you decided to
do it!).

Also, does this mean that you've patched the policy, that lintian
would soon more aggressively complain about lacks of patch
comments, and that we'll have a new Standard-Version?

BTW, what's the status of DEP5?
I'm already always uploading DEP5 compliant copyright files
myself, and I'd be happy to see it go in the policy. Having them
parsable is, IMHO, a very good thing, so that we can make
statistics about what license we have, and do all sorts of
incompatibility checks (like, who's using GPL and badly
mixing it with MPL or OpenSSL for example...).

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f145f83.5050...@debian.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Steve Langasek]

On Mon, Jan 16, 2012 at 12:14:26PM +0100, Raphael Hertzog wrote:
> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.
> 
> Of course this does not mean that the DEP-3 can't be extended or improved
> (in particular when it doesn't break backwards compatibility)
> but it does mean that this format is ready for widespread usage. Use it to
> document the patches that you add to Debian packages:
> http://dep.debian.net/deps/dep3/

+1 for moving this to accepted.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jonathan Wiltshire]

On 2012-01-16 16:43, Tanguy Ortolo wrote:

Jonathan Wiltshire, 2012-01-16 17:01+0100:

It is only a small thing but I did not realise DEP-3 was still a
candidate or I would have spoken earlier. A CVE field, mandatory if 
a
CVE has been published for this patch and is the major component of 
this

patch, would allow easy tracing of patches back to CVE publications
later (for review perhaps, or by other distributions).


Then it would be better to make it independant from CVE, since they
are not the only security vulnerability database.


Ack; but we (in the security team) only track CVE really. The Debian 
bug number is useful but only within Debian, the CVE identifier is 
cross-distribution.




--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2e6c5e69749b3b03b3cf91bcdc007...@hogwarts.powdarrmonkey.net

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Tanguy Ortolo]

Jonathan Wiltshire, 2012-01-16 17:01+0100:
> It is only a small thing but I did not realise DEP-3 was still a 
> candidate or I would have spoken earlier. A CVE field, mandatory if a 
> CVE has been published for this patch and is the major component of this 
> patch, would allow easy tracing of patches back to CVE publications 
> later (for review perhaps, or by other distributions).

Then it would be better to make it independant from CVE, since they
are not the only security vulnerability database.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer
 \_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jf1k4a$27a$1...@dough.gmane.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jonathan Wiltshire]

On 2012-01-16 15:02, Stefano Zacchiroli wrote:

Does anyone have further comments about DEP-3?  If so, please state
them.  Otherwise, let's forget about the process details (no matter 
if
they could have been better or not) and rejoice for a nice standard 
way

of adding useful metadata to patches in the Debian archive.


It is only a small thing but I did not realise DEP-3 was still a 
candidate or I would have spoken earlier. A CVE field, mandatory if a 
CVE has been published for this patch and is the major component of this 
patch, would allow easy tracing of patches back to CVE publications 
later (for review perhaps, or by other distributions).


Such a field should probably be comma-separated if more than one CVE 
identifier is relevant to the patch.



--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e9846bdb29accb9445e617d2fa272...@hogwarts.powdarrmonkey.net

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Raphael Hertzog]

Hi,

On Mon, 16 Jan 2012, Bernd Zeimetz wrote:
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.

We did have lots of discussion when we were designing it. People commented
and reacted.

Remember that this format is there to help and is not mandatory (although
it's likely to be considered as a best practice in terms of packaging).

So if you find it a waste of time, ignore it.

But it's already widely used (I have used it for my own packages, Ubuntu
is recommending it too), it has been designed following an open process to
let everybody participate and ensure it fits as many scenario as possible.
It's lightweight and compatible with many of Git's convention.

And I have been asked about moving it to ACCEPTED by someone else already
(I think it was zack but I no longer remember). And the reason why I post
here is precisely so that people can object _if needed_.

So do you have a reason to object to the ACCEPTED status of this DEP
or was this pure rhetoric ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116145824.ga2...@rivendell.home.ouaza.com

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jon Dowland]

On Mon, Jan 16, 2012 at 03:07:08PM +0100, Bernd Zeimetz wrote:
> just because that you didn't get any reports you should not set a status
> to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
> least not without asking on common lists first. No reaction on your DEP
> could just mean that people consider it as a waste of time or don't like
> your format.

Who should have that authority, then? The DEP-0 proposers?  Since the whole DEP
process itself is  still in CANDIDATE, we could end up in an interesting
situation if/when it comes to migrate *that* to ACCEPTED ☺

DEP-0 merely says

> consensus exists that the implementation has been a success

Perhaps that needs unpacking.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116144947.GB9047@pris

Bug#656101: O: stereograph - stereogram generator

[Peter Palfrader]

Package: wnpp
Severity: normal

Hey,

I'm letting go of stereograph, a stereogram generator - i.e. the things
you might know from _The Magic Eye_ book that was hip several years
back, pictures that contain a 3-D image if you squit and it just right.

Hasn't had a new upstream release in almost a decade, has a popcon count
of about 130, and a FTBFS bug with a patch in the BTS.

If nobody wants to take it within a month or so I'll probably just ask
for removal from the archive.

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116141130.ga18...@anguilla.noreply.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Bernd Zeimetz]

Hi,

> FTR given that I got no reports of problems with DEP-3, that it's already
> well established, I just changed the state of the DEP-3 from CANDIDATE
> to ACCEPTED.

just because that you didn't get any reports you should not set a status
to ACCEPTED. IMHO the driver of a DEP should not do that at all, at
least not without asking on common lists first. No reaction on your DEP
could just mean that people consider it as a waste of time or don't like
your format.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f142f0c.40...@bzed.de

Du får 10% garantiavkastning och 50% kursskydd

[Blackshield AB]

Detta utskick är skapat i HTML, ditt e-postprogram stöder inte detta.


Läs brevet på nedanstående adress:

http://www.epmf.se/300084/open/r.asp?k=98851&i=4&c=54PLLEE1LL&h=8

Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Raphael Hertzog]

Hello,

FTR given that I got no reports of problems with DEP-3, that it's already
well established, I just changed the state of the DEP-3 from CANDIDATE
to ACCEPTED.

Of course this does not mean that the DEP-3 can't be extended or improved
(in particular when it doesn't break backwards compatibility)
but it does mean that this format is ready for widespread usage. Use it to
document the patches that you add to Debian packages:
http://dep.debian.net/deps/dep3/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120116111426.ga...@rivendell.home.ouaza.com