> I have been coordinating the resolution of the bugs about the PHP media types
> with the different players including you and the release team, and we reached
> a
> consensus. Then you suddenly changed your mind overnight, and went for
> another
> solution without contacting all the parties.
I
On Sat, Aug 25, 2012 at 12:08:54PM +0900, Charles Plessy wrote:
> Le Fri, Aug 24, 2012 at 04:38:13PM +0200, Andreas Tille a écrit :
> >
> > 1. If (and only if) the debian/copyright file is
> >
> > Format:
> > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>
> I think th
On Sat, Aug 25, 2012 at 01:03:03PM +0900, Charles Plessy wrote:
> > So would be nice to check that the implementation properly includes all
> > of the following items:
> >
> > Format:
> > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > Source: http://susy.oddbird.net/
> >
Russ Allbery writes:
> Ben Finney writes:
>
> > It seems to me that the primary objection to the presence of these
> > files without source is that they are then distributed as part of
> > Debian, in the source package. That violates our social contract.
>
> The counter-argument from affected ma
m...@linux.it (Marco d'Itri) writes:
> On Aug 25, Ben Finney wrote:
>
> > Upholding the social contract – that Debian, as distributed by the
> > Debian project, remain 100% free – is sufficient reason to remove these
> > files without corresponding source.
> As I said, this is a religious argumen
m...@linux.it (Marco d'Itri) writes:
> On Aug 25, Ben Finney wrote:
>
> > Upholding the social contract – that Debian, as distributed by the
> > Debian project, remain 100% free – is sufficient reason to remove these
> > files without corresponding source.
> As I said, this is a religious argumen
> On 12-08-22 at 09:39am, Paul Wise wrote:
> >
> > In comparison to the current method for repacking (debian/rules
> > get-orig-source), this doesn't allow per-file-set comments about why
> > the file-set is being removed. I often use this to document in more
> > detail why I am removing files. So
Hi,
I just finished the awesome book "The D programming language" from Andrei
Alexandrescu and totally felt in love with D.
People already started to work on D for Debian, but the mailing lists and wiki
sites are very quiet recently:
http://wiki.debian.org/D
http://lists.alioth.debian.org/cgi-
Le Mon, Oct 17, 2011 at 05:31:35PM +0200, Olivier Berger a écrit :
>
> Again, in case you'd doubt it, RDF is just a model, which can be written
> in a number of different formats (not only XML), but the key here is the
> embedded identification of the reference of the ontologies/prefixes
> which r
On Aug 25, Ben Finney wrote:
> Upholding the social contract – that Debian, as distributed by the
> Debian project, remain 100% free – is sufficient reason to remove these
> files without corresponding source.
As I said, this is a religious argument.
It's OK, billions of people have a faith and y
Ben Finney writes:
> It seems to me that the primary objection to the presence of these files
> without source is that they are then distributed as part of Debian, in
> the source package. That violates our social contract.
The counter-argument from affected maintainers is that we *do* have the
Ian Jackson writes:
> I don't think this should be fixed by changing the DFSG. The DFSG is
> correct - sourceless minified js files, GFDL docs with invariant
> sections, gimp-generated pixmaps without the original gimp source,
> etc., are all Not Free Software.
I agree entirely with that paragra
Le Sat, Aug 25, 2012 at 12:46:33AM +, Christoph Anton Mitterer a écrit :
>
> Maybe the mime-support maintainer(s) can set these as goals for
> jessie :)
> Syncing with IANA and cleaning up unofficial definitions. :)
Sorry to be in bad mood, but I do not think that I need more reminders to kee
On Fri, 2012-08-24 at 23:28 +0200, Ondřej Surý wrote:
> Also I don't think you have a definitive say in what associations are
> needed in mime-support package. It's up to individual "users" of
> mime-support package (read individual packages) to define what they
> need for correct functionality. I
Le Fri, Aug 24, 2012 at 11:28:33PM +0200, Ondřej Surý a écrit :
>
> Also I don't think you have a definitive say in what associations are
> needed in mime-support package. It's up to individual "users" of
> mime-support package (read individual packages) to define what they
> need for correct func
On Fri, Aug 24, 2012 at 6:36 PM, Thomas Goirand wrote:
> On 08/24/2012 10:04 PM, Charles Plessy wrote:
>> Dear all,
>>
>> I note that neither Fedora nor Ubuntu systems associate the text/x-php
>> and text/x-php-source media types to .php files by default.
Fedora uses IANA as an authoritative sour
Hi.
FYI, I've been working on adding some RDF descriptions of source
packages to the PTS (committed in SVN, not yet in production).
The RDF models :
- a source packaging "project" for each source package
- the different revisions of the source known by the PTS
- for the one in unstable (as the PT
Hi Charles, et all.
On Fri, 2012-08-24 at 23:04 +0900, Charles Plessy wrote:
> I note that neither Fedora nor Ubuntu systems associate the text/x-php
> and text/x-php-source media types to .php files by default.
>
> Today, a rogue NMU on the mime-support package added these associations in
> Debi
I'm not positive whether this properly belongs here; if it would be more
appropriate on another mailing list, just let me know which one.
I'm a long-time user of e16, which has been removed from Debian, per bug 619707.
The reasons cited for removal are that it has been replaced by e17, that it i
On 08/24/2012 10:04 PM, Charles Plessy wrote:
> Dear all,
>
> I note that neither Fedora nor Ubuntu systems associate the text/x-php
> and text/x-php-source media types to .php files by default.
>
> Today, a rogue NMU on the mime-support package added these associations in
> Debian. I intend to re
On Fri, Aug 24, 2012 at 04:18:12PM +0200, Andrew Shadura wrote:
> Hello,
>
> On Fri, 24 Aug 2012 15:03:49 +0100
> Ben Hutchings wrote:
>
> > There is, it's called the kernel.
>
> No, there isn't, and there can't possibly be, as interface's
> configuration isn't only what ifconfig/route/ip repor
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
> > Some of the information is machine-readable, and some is not. This is
> > obviously necessary in the gen
Hi,
On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
> upstream source (Was: Minified javascript files)"):
> > On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> > > Andreas Tille writes ("Re: Enabli
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> > Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
> > upstream source (Was:
Package: devscripts
Version: 2.10.69+squeeze2
Severity: wishlist
Tags: patch
Hi,
in a (bit longish) thread on debian-devel@l.d.o[1] there was some
discussion about enabling uscan to remove files from upstream archives
according to some information given in some control file. There was no
real co
Hello,
On Fri, 24 Aug 2012 15:03:49 +0100
Ben Hutchings wrote:
> There is, it's called the kernel.
No, there isn't, and there can't possibly be, as interface's
configuration isn't only what ifconfig/route/ip reports to you (which
is what kernel knows about it).
--
WBR, Andrew
signature.asc
Dear all,
I note that neither Fedora nor Ubuntu systems associate the text/x-php
and text/x-php-source media types to .php files by default.
Today, a rogue NMU on the mime-support package added these associations in
Debian. I intend to revert that change unless there there is a solid
explanation
On Fri, 2012-08-24 at 10:44 +0200, Andrew Shadura wrote:
> Hello,
>
> On Mon, 20 Aug 2012 14:51:27 +0100
> Ben Hutchings wrote:
>
> > What I mean is that this still happens:
>
> > # ifup eth0
> > ...
> > # ifconfig eth0 down
> > # ifup eth0
> > ifup: interface eth0 already configured
>
> Why s
Hi,
On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
> upstream source (Was: Minified javascript files)"):
> > 1. The new field Files-Excluded in debian/copyright contains
>
> I don't think debian/copyright sh
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> 1. The new field Files-Excluded in debian/copyright contains
> a space separated list of regular expressions.
> The deletion process will loop over every express
Raphael Hertzog writes ("Re: Minified javascript files"):
> I agree with you that it's useless work. But the ftpmasters believe that
> Debian is made of source and binary packages and that the content of the
> source package should respect DFSG #2 “The program must include source
> code[...]”.
>
>
Bernd Zeimetz writes ("Re: Minified javascript files"):
> On 08/16/2012 08:59 PM, Marco d'Itri wrote:
> > On Aug 16, Vincent Bernat wrote:
> >
> >> I know this is tedious but what others think about this matter?
> > This is another case in which the DFSG has become a religion to be
> > followed
On Fri, Aug 24, 2012 at 01:06:14PM +0200, Stefano Zacchiroli wrote:
> > Above means inventing a *new* syntax for files, instead of reusing the
> > existing one from Files: paragraphs.
>
> debian/control, which is 822-like, already supports #-comments. So,
> strictly speaking, we will just reusing
On Fri, Aug 24, 2012 at 12:42:43PM +0200, Jonas Smedegaard wrote:
|| On 12-08-24 at 11:31am, Andreas Tille wrote:
|| > when working on patches for uscan to implement the removal of files I
|| > stumbled upon one problem: What to do with dirty tarballs (which are
|| > unpacking all their files
On Fri, Aug 24, 2012 at 12:33:09PM +0200, Jonas Smedegaard wrote:
> > Files-Excluded:
> > # ignore copy of lua
> > lua_5.1.4/
[…]
> Above means inventing a *new* syntax for files, instead of reusing the
> existing one from Files: paragraphs.
debian/control, which is 822-like, already supp
On 12-08-24 at 11:31am, Andreas Tille wrote:
> when working on patches for uscan to implement the removal of files I
> stumbled upon one problem: What to do with dirty tarballs (which are
> unpacking all their files straight to the unpack directory and do not
> create a subdirectory). When I wr
On 12-08-24 at 11:16am, Andreas Tille wrote:
> Hi Paul,
>
> On Wed, Aug 22, 2012 at 09:39:00AM +0800, Paul Wise wrote:
> > On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
> >
> > > Any further hints / remarks?
> >
> > In comparison to the current method for repacking (debian/rules
> > get-
On Fri, 24 Aug 2012, Andreas Tille wrote:
> do not create a subdirectory). When I write get-orig-source tarballs
> I always create a - directory and unpack the content
> to this. Should this be implemented as well or do you think it is
> better to change as less as possible?
You can always creat
On 12-08-24 at 11:28am, Andreas Tille wrote:
> On Fri, Aug 24, 2012 at 10:59:10AM +0200, Jonas Smedegaard wrote:
> > > Anyway, I thought I wanted a separate file, but then I remembered that
> > > uscan already uses 'debian/watch' for configuration. The syntax of a
> > > watch file is pretty awkw
Hi,
when working on patches for uscan to implement the removal of files
I stumbled upon one problem: What to do with dirty tarballs (which
are unpacking all their files straight to the unpack directory and
do not create a subdirectory). When I write get-orig-source tarballs
I always create a - d
On Fri, Aug 24, 2012 at 10:59:10AM +0200, Jonas Smedegaard wrote:
> > Anyway, I thought I wanted a separate file, but then I remembered that
> > uscan already uses 'debian/watch' for configuration. The syntax of a
> > watch file is pretty awkward, being based on (logical) lines rather
> > than
On Thu, Aug 23, 2012 at 05:15:35PM -0500, Peter Samuelson wrote:
> Well, two reasons not to bundle it into DEP-5 format files. First,
> there may be a lot of people like me who would find value in a
> config-file-driven 'get-orig-source' but who do not find any value in
> maintaining debian/copyri
Hi Paul,
On Wed, Aug 22, 2012 at 09:39:00AM +0800, Paul Wise wrote:
> On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
>
> > Any further hints / remarks?
>
> In comparison to the current method for repacking (debian/rules
> get-orig-source), this doesn't allow per-file-set comments about wh
On 12-08-23 at 05:15pm, Peter Samuelson wrote:
>
> > > Automating get-orig-source is a fine idea, but tying it to DEP-5
> > > would be unfortunate.
>
> [Jonas Smedegaard]
> > You mean that you prefer a separate file for this info?
> >
> > What should be its name? What should be its syntax?
> >
Hello,
On Mon, 20 Aug 2012 16:21:18 +0200
Mike Hommey wrote:
> > People talk about how ifupdown works well with other configuration
> > tools, unlike Network Manager. But it doesn't, it only knows how to
> > undo the configuration specified in /etc/network/interfaces.
> ifupdown should be the
Hello,
On Mon, 20 Aug 2012 14:51:27 +0100
Ben Hutchings wrote:
> What I mean is that this still happens:
> # ifup eth0
> ...
> # ifconfig eth0 down
> # ifup eth0
> ifup: interface eth0 already configured
Why should it happen otherwise? You did *NOT* deconfigure the interface.
> People talk ab
On Thu, Aug 23, 2012 at 12:38:14PM -0500, Peter Samuelson wrote:
> ...Or add the exclude list to a file called 'debian/watch'.
I struggle to see why. I suppose because uscan reads debian/watch, but
the point of that file is to document where to find upstream sources,
the name implies that, and put
47 matches
Mail list logo
