On Fri, 20 Aug 1999, Joey Hess wrote:
Amendments
FHS-compliant location of compiled examples (#42849)
* Under discussion.
* Proposed by Joey Hess; seconded by Julian Gilbey and Chris Waters.
* This is a proposal for
On Fri, Apr 27, 2012 at 11:29:17AM +0200, Olivier Sallou wrote:
Le 4/27/12 11:01 AM, Charles Plessy a écrit :
Dear Russ, Joey, Debian Med team and evrybody,
...
As proposed in 2010 (http://bugs.debian.org/190753#98), I would like to ask
the
Technical Comittee to reconsider our
Package: debian-policy
Severity: minor
Hello,
there was some discussion on debian-devel@l.d.o about enabling uscan to
remove files from an upstream tarball automatically. In this discussion
(first mentioning was here:
http://lists.debian.org/debian-devel/2012/08/msg00406.html
) the idea
On Tue, Aug 21, 2012 at 09:59:28PM +0900, Charles Plessy wrote:
user debian-pol...@packages.debian.org
usertags 685506 normative discussion
retitle 685506 copyright-format: new Files-Excluded field
thanks
Thanks for enhancing the metadata.
At this moment, I would recommend to look how the
On Tue, Aug 21, 2012 at 04:54:13PM +0200, gregor herrmann wrote:
On Tue, 21 Aug 2012 14:34:50 +0200, Andreas Tille wrote:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
--- 8 -
Files-Excluded
Hi,
On Wed, Jan 16, 2013 at 05:47:13PM +0100, gregor herrmann wrote:
I guess it boils down to how much detail we need (your Rationale);
while I understand your point, so far I was quite happy with writing
one free-form line in a (Header) Comment field and be done with it.
Finally if you
Hi,
I was redirected by Lars Wirzenius to discuss this on debian-policy
list. Please add me in CC since I'm not subscribed.
I have proposed a new field Files-Excluded here:
https://wiki.debian.org/UscanEnhancements
On this Wiki page I have given a summary of the discussion on
debian-devel
Hi Charles,
On Wed, Dec 04, 2013 at 11:12:33AM +0900, Charles Plessy wrote:
Le Tue, Dec 03, 2013 at 07:19:23PM +0100, Andreas Tille a écrit :
I have proposed a new field Files-Excluded here:
https://wiki.debian.org/UscanEnhancements
On this Wiki page I have given a summary
Hi Joachim,
On Fri, Mar 21, 2014 at 01:56:43PM +0100, Joachim Breitner wrote:
Personally I’d find
File-Excluded: foo/bar.js
to exclude
* foo/bar.js (in case of a dirty tarball)
* pkg-1.0/foo/bar.js (as in your implementation) as well as
* pkg-1.0/docs/foo/bar.js
Hi Joachim,
On Fri, Mar 21, 2014 at 04:59:49PM +0100, Joachim Breitner wrote:
Hi,
Am Freitag, den 21.03.2014, 14:17 +0100 schrieb Andreas Tille:
BTW, we should create a mothur-Package like test-case. I just tested
your last commit and I can not get the __MACOSX go away. :-(
My
Hi,
On Fri, Mar 21, 2014 at 10:42:35PM +0100, Joachim Breitner wrote:
Did you check Mothur.1.33.3.tar.xz or mothur_1.33.3+dfsg.orig.tar.xz – a
mistake I also did earlier today:
see below ...
$ apt-get source mothur
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Hi Joachim,
On Fri, Mar 21, 2014 at 11:27:16PM +0100, Joachim Breitner wrote:
debian/rules get-orig-source
(which does the same as you above). BTW, I personally see no point in
keeping a non-stripped archive - it is perfectly fine to have only the
result of the stripped download.
Andreas.
On Sat, Mar 22, 2014 at 12:01:37AM +0100, Joachim Breitner wrote:
Hi,
Am Freitag, den 21.03.2014, 23:31 +0100 schrieb Andreas Tille:
So, we actually are using the same command with different results which
is really strange.
so starting in an empty directory (maybe
Hi,
On Sat, Mar 22, 2014 at 12:01:37AM +0100, Joachim Breitner wrote:
$ tar taf ../Mothur.1.33.3.tar.xz|wc -l
$ tar taf ../mothur_1.33.3+dfsg.orig.tar.xz|wc -l
what do you get?
the mothur issue is settled but I think there is a new problem with
ordinary *.tgz files now: Please try:
Hi,
I realised that the latest devscripts upload now also includes the
--compression option. Thanks for all your work on this. While I think
that even the previous version fixed #685506 I wonder whether you kept
this bug open intentionally. From my point of view it can be closed.
I have
On Tue, May 13, 2014 at 08:24:46AM +0900, Charles Plessy wrote:
I think that you closed the wrong bug: this one is about documenting the
Files-Excluded field in the specification of machine-readable debian/copyright
files, which is probably the next thing to do now that it has been implemented
Hi Charles,
On Tue, Aug 19, 2014 at 07:44:19AM +0900, Charles Plessy wrote:
Le Thu, Aug 14, 2014 at 09:36:50PM +0900, Charles Plessy a écrit :
Package: debian-policy
Version: 3.9.5
Severity: wishlist
Hi Guillem and everybody,
thanks for adding direct support for the Testsuite
On Tue, Aug 19, 2014 at 07:35:22PM -0300, Antonio Terceiro wrote:
Anybody Developer who thinks that 1) the Policy is useful and 2) the
Testsuite
field is useful, can participate. What is needed is to read the text
below,
verify that it reflects the facts, and if yes, send an email
Package: debian-policy
Version: 3.7.2.2
Severity: minor
Hi,
according to
http://lists.debian.org/debian-devel/2007/10/msg00316.html
there exists a menu-2 format since eight years. This should
be regarded in the menu policy.
Kind regards and thanks for maintaining debian policy
On Tue, 4 Dec 2007, Bill Allombert wrote:
The menu entry format is not documented in the menu policy, so this
discard #447389.
Well, you are right that policy should not _describe_ the menu format,
but policy should definitely _mention_ that there are at least two formats
and should give an
On Mon, 28 Jan 2008, Cyril Brulebois wrote:
How are ?dfsg?, ?debian?, or ?ds? extensions? It's in the very middle of
the tarball name, and the extension would rather be ?((orig.)tar.)gz?
(there's the revision in the way, also).
It'd be clearer to talk about the string to include in version
On Mon, 28 Jan 2008, Russ Allbery wrote:
We went back and forth on this several times on debian-mentors and I think
everyone finally agreed that debian/copyright is the correct place to
explain any repackaging of the upstream source. Since debian/copyright is
the standard place to explain
Hi,
as you can read in my lightning talk at DebConf
http://people.debian.org/~tille/talks/200808_lightning/
I did some investigation on who is frequently posting
on our mailing lists. I now created graphs until
end of last year and write a short summary for
those lists I regard worth a
On Thu, 16 Apr 2009, Manoj Srivastava wrote:
Manoj Srivastava wrote:
- Ability to recognize and render the following logical entities, in
decreasing order of importance:
+ unordered lists
+ ordered lists
really needed?
I would think these are the guts of this proposal. Or
On Sat, 18 Apr 2009, Manoj Srivastava wrote:
Frankly, I have no idea where this trade is going.
IMHO the problem is that you assume our suggestions are in contrast to
each other - but they are not. I wanted to iron out suggestions how
to format the input in a standardised way. What
On Wed, 22 Apr 2009, Manoj Srivastava wrote:
And this is like 6 lines of Pseudo code, and less in compact
languages like Perl. A fairly trivial exercise in basic CS logic.
Please do not insist on the number of lines. I mentioned in my
mail [1] that you need a bit more. I did not said
On Thu, 23 Apr 2009, Manoj Srivastava wrote:
While I can't speak for the policy team (I have not been
re-delegated yet), I suspect the answer might be to get a working
implementation out in the wild (it does not have to be packages.d.o or
anything official -- even a standalone software
On Sun, 26 Apr 2009, Stefano Zacchiroli wrote:
I've on purpose not looked at Andreas implementation, in order to see
if we have mutually thought at different issues. That also means that
it can be utterly buggy, you have been warned :-)
At short look I have the following diff:
---
On Sun, 26 Apr 2009, Stefano Zacchiroli wrote:
Library OCaml which provide a set of needed and useful macros for developing.
Modules and functionality are the follows :
.
- Configuration_files: Allow to get information from configuration files
- Environments: Environments are useful for
On Tue, Dec 22, 2009 at 10:05:10AM +0100, Stefano Zacchiroli wrote:
In the past I've found packages which does use README.source for that
and apparently Charles (Cc-ed) already tried to advance such a
proposal. In essence, it would just boil down to amend the description
of the purpose of
Package: debian-policy
Version: 3.5.9.0
Severity: minor
Hello,
the thread on debian-devel about
Generally accepted cut-off limit for -doc packages
starting with
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00218.html
showed that we need some policy about a
On Fri, 21 Nov 2003, Raphael Goulais wrote:
On Thursday 20 November 2003 23:49, Andreas Metzler wrote:
This is no Copyright statements but the means to have a link to the
upstream homepage on http://packages.debian.org/packagename
This is a damn good reason to put the url in the long
On Sat, Aug 05, 2017 at 04:22:03PM -0400, gregor herrmann wrote:
> > So, if you want to count votes: I am working in teams (mainly Debian
> > Astro), and I would favour keeping it --
>
> Perfectly fine, thanks for adding your point of view.
>
> (And just to be sure: The proposal is not to
us discussion seem to show a tendency that this bug will
be at best tagged wontfix which for the moment prevents me from
calling reportbug right now.
Kind regards
Andreas.
> On Tue, Jul 03 2018, Andreas Tille wrote:
>
> > Since this does not exist any more I'm afraid we w
On Wed, Jul 04, 2018 at 10:26:20PM +0100, Sean Whitton wrote:
> >Provide get-orig-source target if (and only if) uscan would fail.
> >
> > The previous discussion seem to show a tendency that this bug will be
> > at best tagged wontfix which for the moment prevents me from calling
> >
Hi Russ,
On Thu, Jul 05, 2018 at 10:49:29AM -0700, Russ Allbery wrote:
> Andreas Tille writes:
>
> > My main point is that README.source is just text and no code that I can
> > run and test. That's different from my proposal.
>
> I can definitely see the merits of clea
On Sun, Apr 08, 2018 at 10:58:53AM +0200, Ole Streicher wrote:
> >
> > Imho Sean's last mail sums it up pretty well
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94
>
> I have read this, but it does not convince me. My rule to get the
> upstream packagage was always: use uscan, if
On Sat, Sep 18, 2021 at 05:54:59PM +0200, Mattia Rizzolo wrote:
> On Fri, Sep 17, 2021 at 03:58:55PM -0700, Sean Whitton wrote:
> > > Gentle ping to Policy editors for that seconding :-) It would be really
> > > nice to move this info from tribal knowledge to documentation.
> >
> > There's no
Am Sat, Nov 13, 2021 at 11:21:26PM -0500 schrieb Joe Nahmias:
> Well, it took me longer than I anticipated to get around to this;
> nevertheless,
> below is my first draft at a patch to document Files-Excluded. It's my first
> time writing for Debian Policy, so please let me know if I didn't use
Hi,
Am Thu, Jan 27, 2022 at 02:52:18PM -0700 schrieb Sean Whitton:
>
> We don't remove files for the sole reason that they're intended for use
> on other platforms. It's typically only done if the files are huge. So
> please remove this one from the list.
>
> How about just saying: we always
Hi,
Am Thu, Jan 27, 2022 at 11:25:31PM +0100 schrieb Bill Allombert:
> > > +
> > > +These types of files, or any others that Debian does not want to
> > > +include in our archive, must be stripped from the upstream
> > > tarball
> > > +prior to uploading. The
Hi Bill,
Am Fri, Jan 28, 2022 at 10:00:36AM +0100 schrieb Bill Allombert:
> On Fri, Jan 28, 2022 at 09:08:17AM +0100, Andreas Tille wrote:
> > > It should be possible to use it with the plain old copyright format too,
> > > otherwise we are kind of renegating on our pro
Am Fri, Jan 28, 2022 at 12:56:56PM +0100 schrieb Bill Allombert:
> > What I'm actually imagine is that the time I need to write this kind of
> > mails I could perfectly use to convert 2-3 d/copyright files from old
> > format to DEP5. And now I'm wondering why I'm not doing so ...
>
> Do not
43 matches
Mail list logo
