Re: Enabling uscan to simply remove files from upstream source

[Jon Dowland]

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 putting lists of files to strip into it would
seem counter-intuitive to me.


-- 
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/20120824083627.GA19780@debian

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

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 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.

...and NM can't do anything at all which it doesn't know about.

How do you suppose it's possible to undo arbitrary network
configuration done by arbitrary set of tools when there's no central
place to hold such information (and can't possibly be)?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

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 only way to configure network interfaces.
> Debian should get rid of NM, ifconfig, ip, and all the other heretic
> programs that break ifupdown.

Haha, how clever and funny. And now please go and write you own
NetConfNG which handles all the possible situations, ever. Or maybe you
know any which does that already? I'm not aware of it.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Enabling uscan to simply remove files from upstream source

[Jonas Smedegaard]

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?
> > 
> > ...and why start from scratch with this - or does something else 
> > already exist, comparable to the work of DEP-5?
> 
> 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/copyright in DEP-5 format.  Tying the two together 
> basically means I probably won't use it, as managing my own .orig 
> generation seems easier than having to maintain a DEP-5 file.  By 
> making me choose to migrate to DEP-5 in order to get the uscan 
> feature, you're making the feature less useful.
> 
> Second, debian/copyright isn't a config file.  I'd rather see 
> configuration in a config file.  Perhaps the DEP-5 mindset is such 
> that you do see debian/copyright as a config file now, but I think its 
> purpose has always been documentation, not configuration.  I guess you 
> can tell I never really cared for "literate programming"
> 
> 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 stanzas, and using "opts=foo=1,bar=2" instead of something like 
> "foo=1 bar=2", but it does seem like the right place to put additional 
> uscan configuration.  And the watch file format can presumably be 
> fixed, as it is explicitly versioned.

Sounds sensible.

How about, in addition to looking for excludes in DEP-5 copyright files, 
have uscan also support an exclude option, so that e.g. 
compass-susy-plugin could alternatively have this debian/watch file:

version=4
opts=dversionmangle=s/\~dfsg.*// \
exclude="docs/source/fonts/* \ 
docs/source/javascripts/jquery-1.7.1.min.js \ 
docs/source/javascripts/modernizr-2.5.3.min.js" \
https://github.com/ericam/susy/tags .*/tarball/v?(\d[\d\.]+)



> > > Unrelated: when I've repacked tarballs, I add a file 
> > > "README.Debian-tarball" to the top level source directory, 
> > > explaining what I did.  Nobody ever suggested this to me, it just 
> > > seems like common sense that information about the new tarball 
> > > should be, well, in the new tarball.  Not just in the .diff.gz.
> > 
> > Nowadays such info is commonly put into README.source
> 
> I know, but that's typically not in the orig.tar.gz.  If someone grabs 
> foo_1.0+dfsg.orig.tar.gz by itself, I think it is useful to have a 
> README in there that explains how it is different from an upstream 
> foo-1.0.tar.gz.
> 
> Hence if you're going to automate repacking, I just wanted to suggest 
> generating a README file to put into the repacked tarball.  And as I 
> said, I haven't heard of anyone else doing this, so perhaps I'm the 
> only one who thinks it makes sense.

Sorry, I missed the detail of it being in the tarball.  I find adequate 
the common practice of renaming the tarball (and then documenting the 
why it was done externally from the tarball), so let's just agree to 
disagree on this one :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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 why
> the file-set is being removed. I often use this to document in more
> detail why I am removing files. So I view this spec as a downgrade
> from what we have now.

Besides the suggestion of Jonas which I like in principle and would be
the easiest way to implemet it came to my mind that we could be free to
ignore everything past '#' to make these strings valid:

Files-Excluded:
# ignore copy of lua
lua_5.1.4/
sqlite3.* # we use Debian's own sqlite
#  The dada files are that long that there is no point in leaving
#  them so the complete directory is removed
data/samples/
*.pdf # We do not have the source of the pdfs

I have some preference for Jonas' suggestion using
Files-Excluded-Comment because it looks cleaner - but both should
solve your problem.

Kind regards

  Andreas.

-- 
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/20120824091622.ge10...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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/copyright in DEP-5 format.

Cool reason to make people switch to DEP5. ;-)

> > > Unrelated: when I've repacked tarballs, I add a file 
> > > "README.Debian-tarball" to the top level source directory, explaining 
> > > what I did.  Nobody ever suggested this to me, it just seems like 
> > > common sense that information about the new tarball should be, well, 
> > > in the new tarball.  Not just in the .diff.gz.
> > 
> > Nowadays such info is commonly put into README.source
> 
> I know, but that's typically not in the orig.tar.gz.  If someone grabs
> foo_1.0+dfsg.orig.tar.gz by itself, I think it is useful to have a
> README in there that explains how it is different from an upstream
> foo-1.0.tar.gz.

I admit that I see some point in documenting the removal of files
*inside* the orig.tar.gz.
 
> generating a README file to put into the repacked tarball.  And as I
> said, I haven't heard of anyone else doing this, so perhaps I'm the
> only one who thinks it makes sense.

+1

Kind regards

   Andreas.

-- 
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/20120824092021.gf10...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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 stanzas, and using "opts=foo=1,bar=2" instead of something like 
> > "foo=1 bar=2", but it does seem like the right place to put additional 
> > uscan configuration.  And the watch file format can presumably be 
> > fixed, as it is explicitly versioned.
> 
> Sounds sensible.

Uhmm, that's the first case in my memory that you drifted away from one
of your reasonable proposals. ;-)
 
> How about, in addition to looking for excludes in DEP-5 copyright files, 
> have uscan also support an exclude option, so that e.g. 
> compass-susy-plugin could alternatively have this debian/watch file:
> 
> version=4
> opts=dversionmangle=s/\~dfsg.*// \
> exclude="docs/source/fonts/* \ 
> docs/source/javascripts/jquery-1.7.1.min.js \ 
> docs/source/javascripts/modernizr-2.5.3.min.js" \
> https://github.com/ericam/susy/tags .*/tarball/v?(\d[\d\.]+)

While I suggested in my initial proposal a separate file (not actually
debian/watch but this solution seems to be comparable to a separate
file) I think we are lacking the feature of documentation what was
removed and what not and from my (and Jonas' previous point of view
debian/copyright is a very good place to do this).
 
> > Hence if you're going to automate repacking, I just wanted to suggest 
> > generating a README file to put into the repacked tarball.  And as I 
> > said, I haven't heard of anyone else doing this, so perhaps I'm the 
> > only one who thinks it makes sense.
> 
> Sorry, I missed the detail of it being in the tarball.  I find adequate 
> the common practice of renaming the tarball (and then documenting the 
> why it was done externally from the tarball), so let's just agree to 
> disagree on this one :-)

In my practice (several years ago) I used the *.orig.tar.gz files from a
Debian mirror to build my own system inside $HOME on a HP-UX machine.
The advantage of using the Debian mirror was that you find everything
you need in one place.  For this purpose it would have been helpful to
have a short notice what was changed right inside the changed tarball.
I admit that is a rare use case these days - but it might be nice anyway.

Kind regards

  Andreas.

-- 
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/20120824092810.gg10...@an3as.eu

How to handle dirty tarballs (Was: Enabling uscan to simply remove files from upstream source)

[Andreas Tille]

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 - 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?

Kind regards

  Andreas.

-- 
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/20120824093155.gh10...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Jonas Smedegaard]

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 awkward, being based on (logical) lines rather 
> > > than stanzas, and using "opts=foo=1,bar=2" instead of something like 
> > > "foo=1 bar=2", but it does seem like the right place to put additional 
> > > uscan configuration.  And the watch file format can presumably be 
> > > fixed, as it is explicitly versioned.
> > 
> > Sounds sensible.
> 
> Uhmm, that's the first case in my memory that you drifted away from one
> of your reasonable proposals. ;-)

Sorry if I was too brief: sensible, even if I do not agree.

I find the argument sensible that not all are comfortable with using 
machine-readable copyright file for expressing information to be 
readable by machines.

I am still a big fan of DEP-5.  I won't use an eventual alternative 
uscan syntax.

...or, since it was later pointed out that "uscan" is narrowly for 
scanning for upstream source, not repackaging it, such alternative newly 
invented syntax could instead be stuffed into a brand new 
debian/exclude-from-uscan or whatever.



> > How about, in addition to looking for excludes in DEP-5 copyright files, 
> > have uscan also support an exclude option, so that e.g. 
> > compass-susy-plugin could alternatively have this debian/watch file:
> > 
> > version=4
> > opts=dversionmangle=s/\~dfsg.*// \
> > exclude="docs/source/fonts/* \ 
> > docs/source/javascripts/jquery-1.7.1.min.js \ 
> > docs/source/javascripts/modernizr-2.5.3.min.js" \
> > https://github.com/ericam/susy/tags .*/tarball/v?(\d[\d\.]+)
> 
> While I suggested in my initial proposal a separate file (not actually 
> debian/watch but this solution seems to be comparable to a separate 
> file) I think we are lacking the feature of documentation what was 
> removed and what not and from my (and Jonas' previous point of view 
> debian/copyright is a very good place to do this).

Yes, I am perfectly aware of that.  I was simply trying to play along 
with the "DEP-5 is wrong, uscan is adequate" mindset.

I'll leave it to fans of that mindset to drive it further...


> > > Hence if you're going to automate repacking, I just wanted to 
> > > suggest generating a README file to put into the repacked tarball.  
> > > And as I said, I haven't heard of anyone else doing this, so 
> > > perhaps I'm the only one who thinks it makes sense.
> > 
> > Sorry, I missed the detail of it being in the tarball.  I find 
> > adequate the common practice of renaming the tarball (and then 
> > documenting the why it was done externally from the tarball), so 
> > let's just agree to disagree on this one :-)
> 
> In my practice (several years ago) I used the *.orig.tar.gz files from 
> a Debian mirror to build my own system inside $HOME on a HP-UX 
> machine. The advantage of using the Debian mirror was that you find 
> everything you need in one place.  For this purpose it would have been 
> helpful to have a short notice what was changed right inside the 
> changed tarball. I admit that is a rare use case these days - but it 
> might be nice anyway.

I find that it is an argument of putting the notice inside the box 
instead of aside it (in the debian tarball/diff).  Good luck driving 
that further.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: How to handle dirty tarballs (Was: Enabling uscan to simply remove files from upstream source)

[Henrique de Moraes Holschuh]

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 create the directory, unpack the tarball there, and
repack at the same level, so it will retain the same folder structure as
the original tarball.

That said, since you're already messing with the tarball anyway, IMO you
might as well make it sane.

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


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

Re: Enabling uscan to simply remove files from upstream source

[Jonas Smedegaard]

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-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 I view this spec as a downgrade
> > from what we have now.
> 
> Besides the suggestion of Jonas which I like in principle and would be
> the easiest way to implemet it came to my mind that we could be free to
> ignore everything past '#' to make these strings valid:
> 
> Files-Excluded:
> # ignore copy of lua
> lua_5.1.4/
> sqlite3.* # we use Debian's own sqlite
> #  The dada files are that long that there is no point in leaving
> #  them so the complete directory is removed
> data/samples/
> *.pdf # We do not have the source of the pdfs
> 
> I have some preference for Jonas' suggestion using
> Files-Excluded-Comment because it looks cleaner - but both should
> solve your problem.

Above means inventing a *new* syntax for files, instead of reusing the 
existing one from Files: paragraphs.

If really sensible to use hash for comments, then let's relax the 
general format, instead of inventing new formats for each use case!

Personally I am fine using 822-style paragraphs for comments in an 
822-style file.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: How to handle dirty tarballs (Was: Enabling uscan to simply remove files from upstream source)

[Jonas Smedegaard]

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 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?

he he, now you are hitting the dirty details ;-)

I seem to recall there also being tarballs having all in one subdir, but 
then including additional subdirs not really used for anything (by us at 
least). Or maybe only additional files in root dir, not more subdirs.

To answer your question: Yes, I find it reasonable to "normalize" when 
repackaging.


You may get some inspiration from the CDBS repackaging routines in 
/usr/share/cdbs/1/rules/upstream-tarball.mk.

I didn't succeed in that, but it should be possible to generate tarballs 
that produce identical checksum, if carefully sorting the files and 
preserving timestamps when feeding to tar.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

[Stefano Zacchiroli]

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 supports #-comments. So,
strictly speaking, we will just reusing a (meta-)syntax that already
exists elsewhere among debian/* files.

Note, however, that #-comments in debian/control must *start* the line,
so the above example wouldn't work.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: How to handle dirty tarballs (Was: Enabling uscan to simply remove files from upstream source)

[Vincent Zweije]

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 straight to the unpack directory and 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?
||
||  he he, now you are hitting the dirty details ;-)
||
||  I seem to recall there also being tarballs having all in one subdir, but
||  then including additional subdirs not really used for anything (by us at
||  least). Or maybe only additional files in root dir, not more subdirs.
||
||  To answer your question: Yes, I find it reasonable to "normalize" when
||  repackaging.

... keeping in mind that it would be a nice property if the package
also builds when the normalized .orig.tar.gz is replaced with the true
upstream .tar.gz.
-- 
Vincent Zweije| "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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 a (meta-)syntax that already
> exists elsewhere among debian/* files.
> 
> Note, however, that #-comments in debian/control must *start* the line,
> so the above example wouldn't work.

I'm perfectly fine with just not inventing the new syntax because this
would cause myself more work for something I personally would not use
anyway.  The '#' inside the paragraph just came to my mind - so if
somebody really want this he is free to discuss + implement it but I'll
leave it untouched for now.

Kind regards

   Andreas.

-- 
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/20120824114324.gi10...@an3as.eu

Re: Minified javascript files

[Ian Jackson]

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 in a literalist interpretation instead of a tool to be used
> > for the purpose of advancing software freedom.
> 
> I rarely share Marco's opinion, but this time I do.

I agree.  There are good reasons for being cautious about non-free
stuff in source packages, but the way we do things now is pointless
make-work.

Better would be if we could teach dpkg-source to remove undesirable
things, present in the original source tarball, from the unpacked
source tree.  Then they wouldn't be distracting/confusing and there
would be no risk of using them by mistake but we wouldn't have to prat
about rebuilding archives which might otherwise remain pristine.

Doing it this way would also prevent accidental reintroduction of the
undesired files into the source tree visible to Debian, which can
happen if someone uploading a new upstream version forgets to launder
the upstream source.

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/20535.29144.610789.729...@chiark.greenend.org.uk

Re: Minified javascript files

[Ian Jackson]

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[...]”.
> 
> Maybe we should fix DFSG #2 to say “The program must include source code
> for all the files that gets installed in the Debian binary packages [...]“.

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.

The question is simply a practical one: is it actually worth our while
to repackage upstream sources to remove unused non-free (but
redistributable) elements.  Who does this benefit ?

If it enhances anyone's freedom (or to put it another way, if failing
to do it would risk harming anyone's freedom) then that would be a
good reason to do it, but at the moment I don't see where that risk
comes from.  The effect is just to make us do work.

The main objection, it seems to me, to the presence of these files is
that removing them is the only sure way to make sure that the actual
package build doesn't use them somehow.  But that objective could be
met by some kind of filtering by dpkg-source at unpack time.

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/20535.29720.103031.195...@chiark.greenend.org.uk

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

[Ian Jackson]

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 expression
> 
>   rm -rf ${MAIN_SOURCE_DIR}/

I don't think debian/copyright should be an controlling input to the
build process.  It's supposed to be semi-machine-readable
documentation.

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/20535.30078.862723.84...@chiark.greenend.org.uk

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

[Andreas Tille]

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 should be an controlling input to the
> build process.  It's supposed to be semi-machine-readable
> documentation.

Sorry, could you please define the term "semi-machine-readable"?

Kind regards

Andreas.

-- 
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/20120824135224.gj10...@an3as.eu

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

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 should it happen otherwise? You did *NOT* deconfigure the interface.

It certainly isn't in the state that 'ifup' put it the first time.  I
want it back in that state now, why won't it do that?

> > 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.
> 
> ...and NM can't do anything at all which it doesn't know about.
> 
> How do you suppose it's possible to undo arbitrary network
> configuration done by arbitrary set of tools when there's no central
> place to hold such information (and can't possibly be)?

There is, it's called the kernel.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.


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

About the media types text/x-php and text/x-php-source

[Charles Plessy]

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 why we should single out ourselves from the major distributions
in our field.

Have a nice day,

-- 
Charles Plessy
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/20120824140448.gc18...@falafel.plessy.net

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

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
Description: PGP signature

Bug#685787: devscripts: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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 consensus about what control file to use.  The implementation below
is based on using debian/copyright but is easy to switch to other files
in case some other consensus might be reached.

The attached patch does the following:

 1. If (and only if) the debian/copyright file is

 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

and if it contains a non-empty field Files-Excluded containing a
space separated list of globs (as used by find and for specifying
file lists in machine readable debian/control files). The deletion
process will loop over every expression and is using the find
command to delete the according globs.

 2. If files matching are contained in the source tarball this will
be repackaged except if the option --no-exclusion is given at
uscan command line or if USCAN_NO_EXCLUSION is set in
/etc/devscripts.conf or ~/.devscripts.  The removal is implemented
for all tar compression methods as well as for zip archives (which
are unpackaged using unzip).  This means if the conditions for
file exclusion as given above are fullfilled the patch below
works similar as --repack.

 3. If the tarball did not contained any of the globs in
debian/copyright::Files-Excluded it will be left untouched.

 4. In case something was removed the version string will be appended by
'+dfsg' to express the fact that the content of the original source
was changed.  Note: There was no real consensus whether to use this
suffix or rather '~dfsg'.  This could be solved by some additional
configuration option that could be added later.  For some moment I
also had the idea to obtain the suffix which is "wanted" by the
maintainer either from debian/watch:dversionmangle or
debian/changelog but I droped this idea because I did not found
a reliable method to make a safe guess.

 5. Sometimes upstream tarballs are dirty and unpack a load of files
into the current directory.  The patch tries to behave reasonable
and checks whether it could move those files into a dir named
  $pkg-$newversion
(in case no such file or directory just exists in such a dirty
tarball).  Also some non-dirty but quite generically named
directories (like "source") are renamed to "$pkg-$newversion".

I have tested the code with five different packages in Debian Med
repository which show different problematic directory structures and
also different compression methods.  The according copyright files
including Files-Excluded are commited to the following locations:

  Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/ampliconnoise/trunk/
  Vcs-Svn: 
svn://svn.debian.org/debian-med/trunk/packages/conquest-dicom-server/trunk/
  Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/imagej/trunk/
  Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/saint/trunk/
  Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/tm-align/trunk/

When applying the patch and using `uscan --verbose --force-download`
I get the actual resulting orig.tar.gz as I want it to be.

Remark:
Regarding the implementation there was some uncertainity about the
actual Perl module to use.  In the patch below script I decided to
stick to Dpkg::Control and left the code for Parse::DebControl as a
comment which could pretty easily could replace the other parser.

Please consider applying this patch after possibly further discussion on
debian-devel@l.d.o.

Kind regards

  Andreas.

PS: Some more skilled Perl programmer might see some room for enhancing
the code - just be warned that Perl is not my native language.

[1] http://lists.debian.org/debian-devel/2012/08/msg00380.html

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: 6.0.5
Architecture: i386 (i686)

Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages devscripts depends on:
ii  dpkg-dev   1.15.8.12 Debian package development tools
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 

Versions of packages devscripts recommends:
pn  at (no description available)
ii  bsd-mailx [mailx]  8.1.2-0.20100314cvs-1 simple mail user agent
ii  curl   7.21.0-2.1+squeeze2   Get a file from an HTTP, HTTPS or 
ii  dctrl-tools2.14.5Command-line tools to process Debi
pn  debian-keyring (no descripti

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

[Ian Jackson]

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:   Minified javascript files)"):
> > >  1. The new field Files-Excluded in debian/copyright contains
> > 
> > I don't think debian/copyright should be an controlling input to the
> > build process.  It's supposed to be semi-machine-readable
> > documentation.
> 
> Sorry, could you please define the term "semi-machine-readable"?

Some of the information is machine-readable, and some is not.  This is
obviously necessary in the general case for a description of
software's licensing status, since licences are written in human
natural languages and might be arbitrary in form.

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/20535.40565.407187.655...@chiark.greenend.org.uk

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

[Andreas Tille]

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: 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 should be an controlling input to the
> > > build process.  It's supposed to be semi-machine-readable
> > > documentation.
> > 
> > Sorry, could you please define the term "semi-machine-readable"?
> 
> Some of the information is machine-readable, and some is not.  This is
> obviously necessary in the general case for a description of
> software's licensing status, since licences are written in human
> natural languages and might be arbitrary in form.

Same for debian/control with the Description field.  We are using it to
control several processes anyway.  I do not see any reason to invent an
(at least so-called) machine readable file format ([1] does not say
anything from semi-machine-readable) and then refraining from using this
feature.

Kind regards

   Andreas.

[1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

-- 
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/20120824153559.ga21...@an3as.eu

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

[Ian Jackson]

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 general case for a description of
> > software's licensing status, since licences are written in human
> > natural languages and might be arbitrary in form.
> 
> Same for debian/control with the Description field.

Yes.

>  We are using it to control several processes anyway.  I do not see
> any reason to invent an (at least so-called) machine readable file
> format ([1] does not say anything from semi-machine-readable) and
> then refraining from using this feature.

AFAICT the machine-readability is being used by a QA post-hoc process
to spot problems, not to control infrastructure.

But on the other hand I think Russ's argument about having all the
information in the same place is very cogent.

So on reflection I withdraw my objection.

Thanks,
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/20535.41256.531057.581...@chiark.greenend.org.uk

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

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 reports to you (which
> is what kernel knows about it).

What elements of interface state are you thinking of, then?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120824161942.gr29...@decadent.org.uk

Re: About the media types text/x-php and text/x-php-source

[Thomas Goirand]

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 revert that change unless there there is a solid
> explanation on why we should single out ourselves from the major distributions
> in our field.
>
> Have a nice day,
>
>   
Hi,

This might have something to do with #674089.
I believe Ondrej (hereby Cc:) must know.

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/5037ad96.3090...@debian.org

Restoring the removed e16 package

[The Wanderer]

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 is
orphaned, and that it is RC-buggy due to toolchain issues.

I have tried out e17, and after some consideration, have concluded that it does
not constitute a suitable replacement for e16 for my purposes. As e16 is also
still maintained upstream (albeit not by the original developer AFAICT), this
invalidates that reason for removal as far as I am concerned.

I am not familiar with what the cited toolchain issues are, or what the
consequent bugs might be. How might I find this out, short of manually searching
through closed bugs against the e16 package in case the information is there?


As e17 does not constitute a suitable replacement for e16 for my purposes, I
have an interest in seeing e16 continue to be available via Debian. What would I
need to do to get this package added back in?

I would be willing to assume maintainership of the e16 Debian package if that is
what it would take, although I do not know whether I have the skill to be able
to do a good job of it.

I am reading the Debian New Maintainers' Guide to educate myself on what would
be involved with maintaining a package, beyond the obvious, and on how to go
about getting a package added to Debian. However, since this package was
previously in the repository and has been removed, it seems likely that there
would be additional considerations beyond those associated with a new package.

Given the previous removal of this package, the reasons cited for that removal,
and the (I infer) relative imminence of a new stable release, what further
requirements and/or deadlines would I need to keep in mind as I work on this,
and what possible further procedures (beyond those in the new-package
documentation) would I need to follow?

--
  The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/5037b36e.80...@fastmail.fm

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

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
> Debian.  I intend to revert that change unless there there is a solid
> explanation on why we should single out ourselves from the major distributions
> in our field.

I was so nasty and reopened the bug, for which Ondrej did the NUM
(because this shouldn't go as is in wheezy).


For the reasons outlaid in my comment to the bug, I suggest we use
application/x-php
instead.

Using text/* for scripts/interpreted languages has been deprecated by
IETF.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Early source package modeling in RDF - Was: Re: Advocating the use of RDF for Debian's published metadata

[Olivier Berger]

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 PTS does), links to the upstream and
  debian versions and the source package files
- a description of the upstream project (would need more than the
  Homepage: link or name to match against)
- pointers to the Ubuntu packaging couterpart and revision known by the
  PTS.

You'll hopefully see a coloured version of an example for apache2 in [1].

More details on debian-qa, in Message-ID:
<878vd4b7gw@inf-8657.int-evry.fr> (thread at [0]).

Maybe we should really create this RDF metadata of Debian project on
alioth or somewhere else to coordinate ?

Who would be interested to participate ?

Best regards,

[0] https://lists.debian.org/debian-qa/2012/08/msg00099.html
[1] 
http://www-public.it-sudparis.eu/~berger_o/weblog/2012/08/24/generating-rdf-description-of-debian-package-sources-with-adms-sw/

Olivier Berger  writes:

> I think it would help here, to adopt standards for more interoperability
> of Debian's metadata with others'. 
> The "package metadata" could even be delivered on the Web of Data
> (Linked Open Data), right from the Debian servers, to allow any
> application to be created, that would consume such metadata.
>
> If RDF/XML (as seems to be proposed by SPDX, to be verified once the
> Linux Foundation site is back) is not suitable, then another format
> would be great as long as it relies on some explicit prefix+suffix
> combination, in order to allow for extensibility, for instance some JSON
> variant of RDF like Turtle [1].
>
> If a package can both be described with some generic purpose
> "ontology"/standard/schema (for instance the one you envisioned
> initially in DEP 11), and also, depending on context (embedded or
> science, for instance) with another set of metadata (spdx or whatever
> else), you'd be able to mix in the same file, metadata relating to
> different contexts.
>
> Still, I'm not sure RFC822-style is perfectly compliant with the habit
> of RDF to separate prefix and suffix with a column character ':'. Maybe
> '_' could act as such a separator (must say I haven't checked the RFC
> for allowed tokens in the grammar) ?
>
> Let's try with an example (btw, the DEP
> http://wiki.debian.org/AppStreamDebianProposal *lacks* examples IMHO) :
>
> In turtle representation format for RDF, one would have a document that
> looks like this :
> @prefix rdf: .
> @prefix dep11: .
> @prefix debbugs: .
> @prefix spdx: .
> 
>  
>   a dep11:DebianPackage;
>   dep11:application "Iceweasel";
>   dep11:package "iceweasel";
>   spdx:license "MPL-1.1"
>   debbugs:bugs .
>
> (Maybe I didn't understand very well the Application and Package
> meanings in your DEP11 proposal, btw.)
>
> Anyway, as you can see, here we could have several "domains" of metadata
> sources (ontologies / prefixes) to describe the same package combined in
> a single document.
> 
> In RFC822-style, this could be something like :
>
> DEP11_Application: Iceweasel
> DEP11_Package: iceweasel
> spdx_license: MPL-1.1
> debbugs_bugs: http://bugs.debian.org/iceweasel
>
> etc.
>
> But clearly, not reinventing the wheel should be a goal, and adopting
> existing standards for meta-data representation would be my choice, i.e.
> Semantic Web standards (namely RDF).
>
>
> Of course, translators from/to different syntaxes will be trivial to
> develop, but if, from the source, a proper standard is used, it can be
> readily delivered to the Web without any transformation needed. Such an
> approach (often called Linked Data), clearly favors interoperability
> (more at http://linkeddata.org/guides-and-tutorials if I failed to make
> my point).
>
>
> 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 render the documents self described and extensible, out of the
> box.
>
> Note that the same rationale stands for all metadata to be eventually
> published on the Web by Debian servers.
>
> Hope this helps.
>
> Best regards,
>
> [0] http://www.w3.org/RDF/
> [1] http://www.w3.org/TeamSubmission/turtle/
> -- 
> Olivier BERGER 
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingénieur Recherche - Dept INF
> Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPG

Re: About the media types text/x-php and text/x-php-source

[Ondřej Surý]

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 source and our mime-types are way behind:

$ diff -uw mime.types.debian mime.types.fedora | diffstat
 mime.types.fedora | 1693 +-
 1 file changed, 1187 insertions(+), 506 deletions(-)

Eg. there are 1693 differences between Fedora and Debian mime.types file.

And something from other side, there is no text/x-python in Fedore
mime.types files...

Ubuntu pull the packages from Debian unstable:

 * Merge from Debian unstable. Remaining changes:
   - Add "cautious-launcher" for handling execution of files that are
 outside /usr and /opt (LP: #506702).
   - Fix typo in cautious-launcher dialog.

That really proves nothing.

BTW Gentoo has even different mime.types file:

 mime.types | 1298 +++--
 1 file changed, 929 insertions(+), 369 deletions(-)


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 think of mime-support like kind of
"support" package.

>> Today, a rogue NMU on the mime-support package added these associations in
>> Debian.

There was nothing rogue about NMU, which fixed RC bug (well, three)
with major impact on PHP users which were opened for more than a half
year.

>> I intend to revert that change

I suggest you explain first how you intend to fix the RC bugs in
mime-support package if you are going to revert the change which fix
confirmed RC bugs.

I think the release team should have a say in that.

Also please write technical reasons why text/x-php (or
application/x-php whatever) is wrong. Unless you can come up with
technical reasons (f.e. it breaks something) please leave it in the
place, as it fixes critical bug (a regression) in processing PHP files
inside apache (and maybe also in other places).

>> unless there there is a solid explanation

It's explained in #670945:

> If mod_negotiation requires some mime-type for .php to work, then the
> obvious solution would be to add a non-magic type, for example
> "application/x-php".

Manifestations of this bug are also described in #661240, #664691.

This is a major regression from squeeze.

It's always good to stick to technical arguments and I say that this
fixes mod_negotiation processing inside an Apache (and possibly other
places), and it fixes major RC bug(s).

> This might have something to do with #674089.

Only vaguelly, in fact it's a separate issue with same cause.

>> on why we should single out ourselves from the major distributions in our 
>> field.

We already single out ourselves (Ubuntu really doesn't count).

> I believe Ondrej (hereby Cc:) must know.

Thanks, Tomas.

> Please do not use:
> text/x-php
> but replace it with:
> application/x-php
>
> The use of text/ for interpreted languages (scripts) is discouraged
> already by IETF and things like javascript/ecmascript are already
> migrated to application/*, the legacy text/* definitions being
> deprecated.

Chris, this is surely not critical severity. I have cloned your bug
report, assigned it a right severity and retitled it to "mime-support:
use of text/ for interpreted languages is discouraged" since we have
several interpreted languages in our mime.types

text/x-perl
text/x-python
text/x-tcl
text/x-sh
text/x-java
text/x-haskell
[...]

Fedora has already moved perl to application/x-perl, so basically I
agree with you, but I would suggest we keep all the languages in sync
and move them post release. I would be quite a huge change to mingle
with existing MIME-Types in the freeze.

We might start by syncing MIME-Types with IANA since we are missing
too many new MIME-Type definitions, but again I think it's already too
late in the release cycle to think about that, but again I do not
speak for release team.

O.
-- 
Ondřej Surý 


--
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/caljhhg8ukz9ujn-ac7lkjby_clcbxbwc93zw1dohtwznx6j...@mail.gmail.com

Re: About the media types text/x-php and text/x-php-source

[Charles Plessy]

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 functionality. I think of mime-support like kind of
> "support" package.

Ondřej,

Please talk to the maintainers before uploading.  NMUs are for helping people.
You gave me less than three days to say that yours is not helpful.  I have been
working regularly on the issue since I became co-maintainer of mime-support
(after sorting out what needed to be done about PDF associations).  Please read
again the advices in the Developers Reference, they were written to avoid such
situations to happen.  
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

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.  In that context, I do not trust
the relevance of your changes and will revert them.

The purpose of mime-support is not to cirumvent other maintainers unwillingness
to integrate their work with the work of others.  If you want to add
application/x-php in /etc/mimes.types, please provide an explanation of why it
is not possible to use in Debian the same way as in other distributions which
do not require that media type association by default.  In particular, in
http://bugs.debian.org/670945#26, the suggestion is from an Apache maintainer
to do the file association with application/x-php through the PHP configuration
file, not to add it in /etc/mime.types.  Please explain why it is not suitable
for you, and please also provide some hints that there will not be side
effects, such as (but not limited to) annoying all Subversion users by suddenly
having their PHP code considered binary and unsuitable for diffs, etc.

Cheers,

-- 
Charles Plessy
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/20120824233920.ga1...@falafel.plessy.net

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

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 think of mime-support like kind of
> "support" package.
I personally, think, we can add unofficial definitions (*/x-*)... if,
and only if, they are needed / used by people, i.e. when there's a
strong demand (what ever this is ;) ).
Otherwise, we can start to add definitions for basically all file types
out there.

And adding x-* types (when there is no real strong need for them) also
has its disadvantage,... people will get used to it and depend on an
unofficial definition.


I haven't checked the details of the requesting bug, but at least with
respect to webserving I'd say a */x-php type makes perhaps little sense,
as php is in most cases interpreted (where we have now a better
solution :) ).


> Also please write technical reasons why text/x-php (or
> application/x-php whatever) is wrong. Unless you can come up with
> technical reasons (f.e. it breaks something) please leave it in the
> place, as it fixes critical bug (a regression) in processing PHP files
> inside apache (and maybe also in other places).


> It's explained in #670945:
Ok I looked into it... now:
Maybe well need to go that way now for wheezy... but IMHO... it's
generally a bad idea to use negotiation with any interpreted files.
Actually I'd even prefer to disable negotiation altogether (per
default)... is has many (intended) side effects,... and should therefore
be intentionally enabled.


> > Please do not use:
> > text/x-php
> > but replace it with:
> > application/x-php
> >
> > The use of text/ for interpreted languages (scripts) is discouraged
> > already by IETF and things like javascript/ecmascript are already
> > migrated to application/*, the legacy text/* definitions being
> > deprecated.
> 
> Chris, this is surely not critical severity. I have cloned your bug
> report, assigned it a right severity and retitled it to "mime-support:
> use of text/ for interpreted languages is discouraged" since we have
> several interpreted languages in our mime.types
Ooops... forgive me,... I forgot that the original bug hat that
priority.
Thanks for cloning out... :)
Anyway, we should try to get it with application/ in wheezy,.. otherwise
people will start using it...



> text/x-perl
> text/x-python
> text/x-tcl
> text/x-sh
> text/x-java
> text/x-haskell
> [...]
You're right,... eventually they should all go,.. but apparently this
has the potential for breaking many things...



> Fedora has already moved perl to application/x-perl, so basically I
> agree with you, but I would suggest we keep all the languages in sync
> and move them post release. I would be quite a huge change to mingle
> with existing MIME-Types in the freeze.
Definitely...


> We might start by syncing MIME-Types with IANA since we are missing
> too many new MIME-Type definitions, but again I think it's already too
> late in the release cycle to think about that, but again I do not
> speak for release team.
Well I (but of course neither I speak for them),... would leave the ones
with text/* that were already in.
Using text/ for interpreted scripts is not strictly forbidden (e.g.
text/ecmascript is still defined),... it's just deprecated.

Maybe the mime-support maintainer(s) can set these as goals for
jessie :)
Syncing with IANA and cleaning up unofficial definitions. :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: About the media types text/x-php and text/x-php-source

[Charles Plessy]

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 keep
the package up to date after the freeze.  There is already #573518 on that
topic.

We have been working sequencially for the moment, first with the dispute on PDF
media types, making sure we are ready to take action in case we are asked to
make changes in Wheezy, and then with the confusion about the PHP media types.

If all of this is resolved in a way that makes it unlikely that an update will
be necessary, I hope to push some basic packaging updates to remove Lintian
errors and warnings from the radar, merge Ubuntu's additions, and then work on
#573518 and a possible cleanup of the media types at the same time.

For people who want to have the updates coming faster, please take action by
making contributions that will accelerate the release.

Have a nice week-end,

-- 
Charles Plessy
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/20120825014152.ga2...@falafel.plessy.net

Re: Minified javascript files

[Ben Finney]

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 paragraph.

> The main objection, it seems to me, to the presence of these files is
> that removing them is the only sure way to make sure that the actual
> package build doesn't use them somehow.

That is one which has been discussed. I don't think it's the most
compelling one though.

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.

This objection is unrelated to what our build process does with those
files, or even whether the build process ignores them. By remaining in
the source package, we are distributing them as part of Debian.

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.

-- 
 \  “Isn't it enough to see that a garden is beautiful without |
  `\  having to believe that there are fairies at the bottom of it |
_o__) too?” —Douglas Adams |
Ben Finney


-- 
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/87k3wng29r@benfinney.id.au

Re: Minified javascript files

[Russ Allbery]

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
source.  It just happens to be in a different source package.  We even
know that, because when we build the binary package we use the version of
the Javascript library derived from that other source package.

There is therefore no *actual* violation of the social contract here, just
an inadequacy of bookkeeping.

-- 
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/87ipc7ra6q@windlord.stanford.edu

Re: Minified javascript files

[Marco d'Itri]

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 your one appears to be 
literally following the DFSG.
But let's not pretend that this in some way helps software to be more 
free, because it does not.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Advocating the use of RDF for Debian's published metadata - Was: Re: Proposal for additional metadata in Debian archives (DEP-11)

[Charles Plessy]

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 render the documents self described and extensible, out of the
> box.
> 
> Note that the same rationale stands for all metadata to be eventually
> published on the Web by Debian servers.

Hi Olivier,

I think that this is the key point: what is important is not the format, but
the ontology.  Even in the absence of an implementation for the format,
we should make sure that new terms are not added in our control files without
having checked for prior art, and coordinate accordinlgy.

Is there a simple web page that lists the terms of ADMS.SW ?

Have a nice week-end,

-- 
Charles Plessy
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/20120825025617.gc2...@falafel.plessy.net

The D programming language

[Thomas Koch]

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-bin/mailman/listinfo/pkg-d-commits
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-d-devel

Why not come over on pkg-d-devel, introduce yourself and share your 
experiences, hopes and plans with D on the list?


That's enough for debian-devel,

regards,

Thomas Koch, http://www.koch.ro


-- 
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/201208250527.49300.tho...@koch.ro

Re: Enabling uscan to simply remove files from upstream source

[Charles Plessy]

> 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 I view this spec as a downgrade
> > from what we have now.
> 

Le Wed, Aug 22, 2012 at 10:09:38AM +0200, Jonas Smedegaard a écrit :
>
> 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/
>   Repackaged, excluding non-DFSG licensed fonts and source-less
>   JavaScript
> Files-Excluded:
>   docs/source/javascripts/jquery-1.7.1.min.js
>   docs/source/javascripts/modernizr-2.5.3.min.js
> Files-Excluded-comment: Exlude source-less JavaScript
> Files-Excluded: foo/bar
>   docs/source/fonts/*
>   baz
>   boom/boom/
> Files-Excluded-comment: Exlude non-DFSG licensed fonts and more
>  Just for demonstration purpose, this paragraph has multiple
>  lines.

Hi all,

a paragraph must not contain multiple instances of the same field.  Perhaps
the example above suggests that the Files-Excluded field is not well suited
for the header paragraph ?  In that case, even if the current specification
does not allow it, maybe you can explore the possibility to make 
Files-Excluded paragraphs, like in the following:

Files-Excluded:
  docs/source/javascripts/jquery-1.7.1.min.js
  docs/source/javascripts/modernizr-2.5.3.min.js
Comment: Exlude source-less JavaScript

Files-Excluded: foo/bar
  docs/source/fonts/*
  baz
  boom/boom/
Comment: Exlude non-DFSG licensed fonts and more
 Just for demonstration purpose, this paragraph has multiple
 lines.

This will only cause problems if existing parsers are detecting paragraph type
by exclusion, like for instance inferring that a paragraph is a stand-alone
License paragraph because 1) it is not a Header paragraph and 2) it does not
contain a Files field.

I also think that the current proposal would be a good opportunity to transfer
the information about source location and excluded files in a separate file
that would be parsed by uscan and others, and which format would be easier than
debian/watch.

However, for the moment packages.debian.org or the PTS do not display arbitrary
information from files in the source packages, so the easiest way to present
the information to our users is through the Debian copyright file.  Altogether,
no solution is entirely satisfactory.  Things may become easier once we have a
solid distribution of all our package metadata, both on-line and as an off-line
copy for the roaming or disconnected systems.

Have a nice day,

-- 
Charles Plessy
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/20120825040303.ge2...@falafel.plessy.net

Re: Minified javascript files

[Ben Finney]

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 argument.

You'll need to explain better what you mean, then, because the argument
makes no reference to any supernatural entities.

> It's OK, billions of people have a faith and your one appears to be 
> literally following the DFSG.

I don't know why you bring faith into this.

-- 
 \   “Nothing is so common as to imitate one's enemies, and to use |
  `\   their weapons.” —Voltaire, _Dictionnaire Philosophique_ |
_o__)  |
Ben Finney


pgp2I6oJgR9W4.pgp
Description: PGP signature

Re: Minified javascript files

[Ben Finney]

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 argument.

You'll need to explain better what you mean, then, because the argument
makes no reference to any supernatural entities.

> It's OK, billions of people have a faith and your one appears to be 
> literally following the DFSG.

I don't know why you bring faith into this, if not as a vague smear
without addressing any points.

-- 
 \   “Nothing is so common as to imitate one's enemies, and to use |
  `\   their weapons.” —Voltaire, _Dictionnaire Philosophique_ |
_o__)  |
Ben Finney


pgp1hJzJ8KcHz.pgp
Description: PGP signature

Sourceless files in source package (was: Minified javascript files)

[Ben Finney]

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 maintainers is that we *do* have
> the source. It just happens to be in a different source package. We
> even know that, because when we build the binary package we use the
> version of the Javascript library derived from that other source
> package.

Ah, yes, for the minified Javascript libraries. I was responding to a
broader claim from Ian Jackson about files without source, from
Message-ID: <20535.29720.103031.195...@chiark.greenend.org.uk>:

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.

and the subject field had not yet changed to match. My apologies, I've
fixed that here.

> There is therefore no *actual* violation of the social contract here,
> just an inadequacy of bookkeeping.

In the case of files where the source is in another source package, yes.

-- 
 \  “Life does not cease to be funny when people die any more than |
  `\  it ceases to be serious when people laugh.” —George Bernard Shaw |
_o__)  |
Ben Finney


-- 
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/876287ft78.fsf...@benfinney.id.au

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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/
> >   Repackaged, excluding non-DFSG licensed fonts and source-less
> >   JavaScript
> > Files-Excluded:
> >   docs/source/javascripts/jquery-1.7.1.min.js
> >   docs/source/javascripts/modernizr-2.5.3.min.js
> > Files-Excluded-comment: Exlude source-less JavaScript
> > Files-Excluded: foo/bar
> >   docs/source/fonts/*
> >   baz
> >   boom/boom/
> > Files-Excluded-comment: Exlude non-DFSG licensed fonts and more
> >  Just for demonstration purpose, this paragraph has multiple
> >  lines.
> 
> Hi all,
> 
> a paragraph must not contain multiple instances of the same field.

I can confirm that I tried this yesterday and it really fails (just
forgot to report this here).

> Perhaps
> the example above suggests that the Files-Excluded field is not well suited
> for the header paragraph ?

Hmmm, even if the suggestion for a commenting feature for single entries
is a bit spoiled technically - logically I would expect this information
somehow in the header.

> I also think that the current proposal would be a good opportunity to transfer
> the information about source location and excluded files in a separate file
> that would be parsed by uscan and others, and which format would be easier 
> than
> debian/watch.

I guess you mean your DEP12 proposal, right?[1]

I admit this alternative came to my mind yesterday once Ian had trouble
with debian/copyright but later he has withdrawn his objection and I had
not seen any need to bring in this idea any more.

>From my perspective the debian/copyright file is the ideal file because:

  1. Content wise the information is license / DFSG related and it
 is a close to perfect way to document the removal here inside
 the copyright file.
  2. Technically it is perfectly possible (see #685787).
  3. The unability to comment every single exclusion in the current
 form is not as important enough (to me) to seek actively for
 a different solution (even if I made some similar comments in
 some get-orig-source scripts)

Kind regards

Andreas.

[1] http://lists.debian.org/debian-project/2012/06/msg00164.html 

-- 
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/20120825052406.gc21...@an3as.eu

Re: Bug#685787: devscripts: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

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 that this is too strict.  For instance, if the format specification is
> updated to incorporate the Files-Excluded field, then its version number will
> increase and then uscan will stop removing excluded files from the package
> where the Format field has been updated accordingly.

You are right here.
 
> Perhaps we should try to find a consensus on the version scheme, for instance
> proposing that there will be no backwards-incompatible change without 
> increasing
> the major version number, or perhaps you can ignore the version number 
> completely
> for the moment ?

I guess you mean something like this:

$ git diff
diff --git a/scripts/uscan.pl b/scripts/uscan.pl
index e118142..270fc3e 100755
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -1448,7 +1448,7 @@ EOF
 $data->load('debian/copyright');
 # my $parser = new Parse::DebControl(1);
 # my $data = $parser->parse_file('debian/copyright', 
{discardCase=>1,singleBlock=>1,});
-my $okformat = 
qr'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0';
+my $okformat = 
qr'http://www.debian.org/doc/packaging-manuals/copyright-format/[.\d]+';
 if ($data->{'format'} =~ m{^$okformat/?$} and 
$data->{'files-excluded'} ) {
 my $tempdir = tempdir ( "uscan", TMPDIR => 1, CLEANUP => 1 );
 my $globpattern = "*";


That's perfectly fine for me - thanks for the hint.

Kind regards

Andreas.

-- 
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/20120825052859.gd21...@an3as.eu

Re: About the media types text/x-php and text/x-php-source

[Ondřej Surý]

> 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 did not change my mind, it's a _different_ regression. Although you
have merged them in BTS before and they have a same cause - removal of
(magic) PHP media types, they are different bugs with different
impact.

* The fix for first bug #674089 (e.g. with impact on PHP CGI) is still
in the place in the php5 package (5.4.4-5).

* The fix for second bug #670945 (e.g. http://localhost/file not
caught by mod_negotiation) was fixed in mime-support 3.52-1.1.

> In that context, I do not trust the relevance of your changes and will revert 
> them.

Again please give a technical reasons for the revert. Using feeling
(or trust) as a base for decisions is not very helpful. You didn't
provided any technical reason why _not_ fix this in mime-support
package, although I have politely asked you.

When there's disagreement between maintainers, it's always good to
stick to technical arguments.

> If you want to add application/x-php in /etc/mimes.types, please provide an 
> explanation of why it is not possible to use in Debian the same way as in 
> other distributions which do not require that media type association by 
> default.

Maybe they don't support mod_negotiation for PHP, maybe whoever know,
Debian differs in so many ways from other distributions that I don't
really see a need for this explaination. And I personally don't care
about distributions, I care about our users who are experiencing
regression from squeeze.

Also you keep repeating this, but I have already shown you that we
significantly differ from other distributions; Fedora for example
doesn't have text/x-python and yet you don't required python
maintainers to explain why it's needed.

> [...snip the part about adding PHP MIME-Type just to Apache 2...]
> Please explain why it is not suitable for you,

Because it fixes this bug only in Apache 2, but addition in
mime-support would provide the mapping in all other places which uses
mime.types file.

I don't see a reason[*] why we would want to fix this only in Apache
when we can fix on system wide level. (* - e.g. any breakage this will
cause). I would willingly accept removal if you can show me that the
addition of (text|application)/x-php will cause some bad side effect.

> and please also provide some hints that there will not be side effects, such 
> as (but not limited to) annoying all Subversion users by suddenly having 
> their PHP code considered binary and unsuitable for diffs, etc.

mime-support package had the application/x-httpd-php* mappings up to
3.52-1 for a long time and nobody complained, right? I am pretty
confident that adding different MIME-Type won't break anything (which
wasn't already broken before elsewhere and nobody really noticed - or
there would be a bug report).

O.
-- 
Ondřej Surý 


--
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/CALjhHG_VP4sKx4NrsZmAcLfNhmjr4mVKi0J=qf95fvk+5gg...@mail.gmail.com