Bug#646697: Considering support for a "Refs: bug numbers" header in .changes files

2011-10-26 Thread Enrico Zini 
Package: dpkg-dev
Version: 1.16.1.1
Severity: wishlist

Hello,

from my experience with other issue trackers, I sometimes feel the wish
of adding a 'Refs: #nn' mention in debian/changelog that would post
about the upload in that bug without closing it.

Possible use cases for this: uploading dependencies for an ITP,
uploading a change that half-fixes another bug report, and generally
reporting progress when fixing complex issues that require a coordinated
effort.

The ITP case is probably not a good use case, since it could already be
handled by quickly creating ITP bugs for all the dependencies, setting
them as blocking the main ITP bug, and then closing them in the upload,
although there's quite a bit of latency involved in getting that done.

Better examples can be found among the kind of bugs assigned to
'general': something like #195481 or #601455 can benefit from receiving
mentions of related new features as they get uploaded to the archive.

The idea seems worthwile to me, but I've added X-Debbugs-Cc to
debian-devel to try and gather better use cases. If we do not get a
stronger case for this idea, at the current stage this bug can probably
be closed by saying "in order to do this, open a proper bug, set it as
blocking the one you want to Ref:, then just use a Closes: mention.

I'm filing the bug to dpkg-dev after discussion in #debian-devel, where
it was found that, for this to be implemented, dpkg-genchanges needs to
add a 'Refs: ' field to the .changes file, which can then
easily be picked by dak and processed accordingly.

Thank you for your work on dpkg-dev!


Ciao,

Enrico

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii  base-files6.5  
ii  binutils  2.21.90.20111004-2   
ii  bzip2 1.0.5-7  
ii  libdpkg-perl  1.16.1.1 
ii  make  3.81-8.1 
ii  patch 2.6.1-2  
ii  xz-utils  5.1.1alpha+20110809-2

Versions of packages dpkg-dev recommends:
ii  build-essential  11.5 
ii  fakeroot 1.18.1-1 
ii  gcc [c-compiler] 4:4.6.1-3
ii  gcc-4.4 [c-compiler] 4.4.6-11 
ii  gcc-4.5 [c-compiler] 4.5.3-9  
ii  gcc-4.6 [c-compiler] 4.6.1-15 
ii  gnupg1.4.11-3 
ii  gpgv 1.4.11-3 
ii  libalgorithm-merge-perl  0.08-2   

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2011.08.07

-- no debconf information



-- 
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/20111026102243.19031.50350.report...@viaza.enricozini.org

Re: A debian/rules target to rebuild pre-built stuff?

2011-10-26 Thread Henrique de Moraes Holschuh 
On Tue, 25 Oct 2011, Bernhard R. Link wrote:
> > As a rule, you are supposed to get rid of all autogenerated files and
> > rebuild them from scratch when packaging for Debian.  AM_MAINTAINER_MODE
> > changes nothing in that case, as you will readly notice any upstream
> > breakage when you try to build the package after importing a new upstream
> > release.
> 
> As another rule, you are not supposed to derivate much from upstream
> without a reason. Using build scripts generated with a different version
> is such a derivation.

We will have to agree to disagree, there.  The build system is not the end
product, and in fact one often has to fix or enhance the thing to adequate
the build to either Debian's or the package's requirements.

Besides, the chances of upstream using exactly the same arch toolchain (gcc,
binutils...) as you do are small, and that fact alone will seldom either fix
or introduce bugs in the resulting binary when compared to the prebuilt
stuff from upstream.

Obviously, any non-Debian-specific fixes and enhancements to the build
system should be sent upstream.

> Libtool is quite a beast, much different to autoconf and automake.

Issues with autoconf and automake macros do happen, and get fixed.  And bit
rot is a real concern for autoconf/automake rules (and therefore for the
resuling build scripts/makefiles).

> When using libtool I guess it makes sense to retool it, but I think
> without libtool it depends how much changes you want to do to the
> build system.

No, it actually depends entirely on what upstream used to do the tooling on
that particular upstream release, and you will have to keep an eye on that
if you don't retool.

-- 
  "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/20111026121810.ga24...@khazad-dum.debian.net

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Raphael Hertzog 
On Sun, 23 Oct 2011, Paul Wise wrote:
> More automated and manual testing can help here I guess.

Sure, but I don't expect Debian maintainers to write a test suite
when upstream hasn't created one. And testing an interactive web
application is a rather difficult problem.

> Also hopefully maintainers are using the packages they maintain and
> will therefore notice when they are broken by newer JavaScript
> libraries.

I do but I'm not using all the features all the time and I don't test
them for each upload.

For instance I just noticed that we can't install new widgets with the
current wordpress package due to some javascript related problem. I'm not
familiar enough with the codebase to investigate it easily. I can't
ask upstream about it because it works with the version of the libraries
that they are shipping.

While I would also love that all upstreams would be more aware of the
fact that they are maintaining libraries and that they must take
compatibility seriously, I can't really change that. Furthermore
many of them are not using a Linux system and have a (vastly) different
culture.

Giving all this I plan to put into practice the opportunistic replacement
idea that I suggested and to add lintian overrides for all the javascript files
where this opportunistic replacement is in place.

Does this sound reasonable enough ?

(I see quite a few overrides already for such files)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
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/20111026143143.ga26...@rivendell.home.ouaza.com

blueman-applet input/output error

2011-10-26 Thread J. Bakshi 
Package: blueman
Version: 1.21-4.1+b1
Severity: normal

--- Please enter the report below this line. ---


blueman-applet has some problem in debian box. I have blueman 1.21-4.1+b1 
installed with
debian wheezy. Obviously I have added the user at bluetooth group; dbus is also 
working. I can on/off as
well as search new bluetooth devices through blueman-applet but when try to
add or pair I get a I/O error. 

``
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 702, in 
_message_cb
retval = candidate_method(self, *args, **keywords)
File "", line 2, in CreateDevice
File "/usr/lib/python2.7/dist-packages/blueman/plugins/applet/DBusService.py", 
line 135, in CreateDevice
agent = TempAgent(self.Applet.Plugins.StatusIcon, agent_path, time)
File "/usr/lib/python2.7/dist-packages/blueman/main/applet/BluezAgent.py", line 
255, in __init__
CommonAgent.__init__(self, status_icon, path)
File "/usr/lib/python2.7/dist-packages/blueman/main/applet/BluezAgent.py", line 
52, in __init__
Agent.__init__(self, path)
File "/usr/lib/python2.7/dist-packages/blueman/bluez/Agent.py", line 68, in 
__init__
dbus.service.Object.__init__(self, dbus.SystemBus(), obj_path)
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 480, in __init__
self.add_to_connection(conn, object_path)
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 571, in 
add_to_connection
self._fallback)
KeyError: "Can't register the object-path handler for 
'/org/blueman/agent/temp/0017E352E31E': there is already a handler"
```

Please suggest how to fix it. Bluetooth operation is completely impossible in 
debian now.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.3.acer

Debian Release: wheezy/sid
  500 unstableignorantguru.users.sourceforge.net 
  500 testing security.debian.org 
  500 testing ftp.it.debian.org 
  500 testing debian-multimedia.org 
  500 testing deb.opera.com 
  500 stable  dl.google.com 
  500 maverickppa.launchpad.net 
  500 lucid   ppa.launchpad.net 
  500 all liveusb.info 

--- Package information. ---
Depends(Version) | Installed
-+-
libbluetooth3  (>= 4.91) | 4.96-3
libc6   (>= 2.4) | 2.13-21
libcairo2 (>= 1.2.4) | 1.10.2-6.1
libgdk-pixbuf2.0-0   (>= 2.22.0) | 2.24.0-1
libglib2.0-0 (>= 2.14.0) | 2.28.6-1
libgtk2.0-0(>= 2.14) | 2.24.6-2
libpango1.0-0(>= 1.14.0) | 1.29.4-1
libstartup-notification0(>= 0.4) | 0.12-1
python  (<< 2.8) | 2.7.2-9
python  (>= 2.7) | 2.7.2-9
python-central   (>= 0.6.11) | 0.6.17
dbus | 1.4.16-1
bluez  (>= 4.25) | 4.96-3
obex-data-server  (>= 0.4.3) | 0.4.5-1+b2
python-gtk2(>= 2.12) | 2.24.0-2
python-dbus  | 0.84.0-2
python-gobject   | 2.28.6-5
python-notify| 0.1.1-3
notification-daemon  | 
librsvg2-common  | 2.34.1-2
hicolor-icon-theme   | 0.12-1


Recommends   (Version) | Installed
==-+-===
python-gconf   | 2.28.1-3
policykit-1| 0.102-1
libpulse-mainloop-glib0| 1.0-4


Package's Suggests field is empty.



-- 
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/201110261409.p9qe8wci001...@vm-mailsafe-02.soltecsis.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Jakub Wilk 

* Raphael Hertzog , 2011-10-26, 16:31:
Also hopefully maintainers are using the packages they maintain and 
will therefore notice when they are broken by newer JavaScript 
libraries.


I do but I'm not using all the features all the time and I don't test 
them for each upload.


For instance I just noticed that we can't install new widgets with the 
current wordpress package due to some javascript related problem. I'm 
not familiar enough with the codebase to investigate it easily. I can't 
ask upstream about it because it works with the version of the 
libraries that they are shipping.


Why you can't? Do they bite if you do?

--
Jakub Wilk


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

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Raphael Hertzog 
Hi,

On Wed, 26 Oct 2011, Jakub Wilk wrote:
> * Raphael Hertzog , 2011-10-26, 16:31:
> >For instance I just noticed that we can't install new widgets with
> >the current wordpress package due to some javascript related
> >problem. I'm not familiar enough with the codebase to investigate
> >it easily. I can't ask upstream about it because it works with the
> >version of the libraries that they are shipping.
> 
> Why you can't? Do they bite if you do?

For the very same reason we don't like Ubuntu bugs that have not been
reproduced on Debian.

Obviously I can ask but it's unlikely to lead to any fruitful discussion
if I don't come up with a patch that supports both versions at the same
time.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
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/20111026164702.gc28...@rivendell.home.ouaza.com

Minified files and source code requirement

2011-10-26 Thread Raphael Hertzog 
Hi,

On Sun, 23 Oct 2011, Paul Wise wrote:
> One of the other problems with embedded JavaScript libraries is that
> often only the pre-compiled/obfuscated/minified version is
> distributed, which would be a violation of DFSG item 2.

I did not reply on this at first but since Jakub filed #646729 using
a similar reasoning, I would like to discuss this here.

I don't agree that minified files are a violation of DFSG #2. If the
library is under the GPL then it would be a problem because it's not the
preferred form of modification.

But with more liberal licenses, we should certainly accept that the
minified files are their own sources much like we accept any other blob of
data under a free license. For instance we know that almost none of the
firmwares are hand-crafted yet I think we have many firmware under
DFSG-free licenses (and we adequately pointed out that GPL firmwares were
not ok).

(Furthermore there are tools which can reindent such minified files, while
this doesn't restore variable names and the like, it really helps if one
wants to analyze this code.)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
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/20111026170814.ga28...@rivendell.home.ouaza.com

Re: Minified files and source code requirement

2011-10-26 Thread Julien Cristau 
On Wed, Oct 26, 2011 at 19:08:14 +0200, Raphael Hertzog wrote:

> Hi,
> 
> On Sun, 23 Oct 2011, Paul Wise wrote:
> > One of the other problems with embedded JavaScript libraries is that
> > often only the pre-compiled/obfuscated/minified version is
> > distributed, which would be a violation of DFSG item 2.
> 
> I did not reply on this at first but since Jakub filed #646729 using
> a similar reasoning, I would like to discuss this here.
> 
> I don't agree that minified files are a violation of DFSG #2. If the
> library is under the GPL then it would be a problem because it's not the
> preferred form of modification.
> 
Just because it's not GPL doesn't mean DFSG can be ignored.

> But with more liberal licenses, we should certainly accept that the
> minified files are their own sources much like we accept any other blob of
> data under a free license. For instance we know that almost none of the

We... don't?

> firmwares are hand-crafted yet I think we have many firmware under
> DFSG-free licenses (and we adequately pointed out that GPL firmwares were
> not ok).

And we ship that non-GPL, sourceless firmware in non-free.

> (Furthermore there are tools which can reindent such minified files, while
> this doesn't restore variable names and the like, it really helps if one
> wants to analyze this code.)
> 
Just like there's disassemblers for ELF.  That doesn't make ELF files
source.

Cheers,
Julien


-- 
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/20111026174508.gk3...@radis.liafa.jussieu.fr

Re: Minified files and source code requirement

2011-10-26 Thread Raphael Hertzog 
On Wed, 26 Oct 2011, Julien Cristau wrote:
> On Wed, Oct 26, 2011 at 19:08:14 +0200, Raphael Hertzog wrote:
> > I don't agree that minified files are a violation of DFSG #2. If the
> > library is under the GPL then it would be a problem because it's not the
> > preferred form of modification.
>
> Just because it's not GPL doesn't mean DFSG can be ignored.

Well, minified or not, my point is that it's "code". And DFSG#2 refers to
source code not to "preferred form of modification".

> > But with more liberal licenses, we should certainly accept that the
> > minified files are their own sources much like we accept any other blob of
> > data under a free license. For instance we know that almost none of the
> 
> We... don't?
> 
> > firmwares are hand-crafted yet I think we have many firmware under
> > DFSG-free licenses (and we adequately pointed out that GPL firmwares were
> > not ok).
> 
> And we ship that non-GPL, sourceless firmware in non-free.

I stand corrected on this specific example. I don't have any other example
to use where "source code" would be involved.

We have the case of PDF files without the original document used
to generate that PDF but it doesn't really count since DFSG#2 only
applies to "source code". Although it would be relevant for the "preferred
form of modification" in the case of the GPL.

I would be leaning to be less tolerant for minified files of external
libraries that have been modified, but in the case of external libraries
that are just copied/embedded unmodified, I don't really see the point of
it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


-- 
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/20111026190026.ga29...@rivendell.home.ouaza.com

Bug#646751: ITP: libcgi-application-plugin-actiondispatch-perl -- attribute extension for CGI::Application

2011-10-26 Thread Nicholas Bamber 
Package: wnpp
Owner: Nicholas Bamber 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcgi-application-plugin-actiondispatch-perl
  Version : 0.98
  Upstream Author : Jason Yates 
* URL :
http://search.cpan.org/dist/CGI-Application-Plugin-ActionDispatch/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : attribute extension for CGI::Application

CGI::Application::Plugin::ActionDispatch adds attribute based support for
parsing the PATH_INFO of the incoming request. The interface is inspired by
Catalyst. This plugin is plug and play and will interrupt the default
behavior
of CGI::Application and works with mod_perl.



-- 
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/4ea85ed7.3080...@periapt.co.uk

Bug#646757: ITP: mrmpi -- Implements MapReduce operation on top of standard MPI message

2011-10-26 Thread Mathieu Malaterre 
Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: mrmpi
  Version : 1.0
  Upstream Author : Steve Plimpton and Karen Devine
* URL : http://www.cs.sandia.gov/~sjplimp/mapreduce.html
* License : BSD
  Programming Lang: C++
  Description : Implements MapReduce operation on top of standard MPI 
message

 The MapReduce-MPI (MR-MPI) library is open-source software that implements the
 MapReduce operation popularized by Google on top of standard MPI message
 passing.
 .
 The MR-MPI library is written in C++ and is callable from hi-level langauges
 such as C++, C, Fortran. A Python wrapper is also included, so MapReduce
 programs can be written in Python, including map() and reduce() user callback
 methods. A hi-level scripting interface to the MR-MPI library, called OINK, is
 also included which can be used to develop and chain MapReduce algorithms
 together in scripts with commands that simplify data management tasks. OINK has
 its own manual and doc pages.

---

  MapReduce-MPI is currently a convenient library shipped within VTK 5.8
  Current package is at:
  http://anonscm.debian.org/viewvc/debian-science/packages/mrmpi/trunk/



-- 
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/20111026194023.25808.93125.report...@hpdesk.malat.net

Re: Minified files and source code requirement

2011-10-26 Thread Adam D. Barratt 
On Wed, 2011-10-26 at 21:00 +0200, Raphael Hertzog wrote:
> On Wed, 26 Oct 2011, Julien Cristau wrote:
> > Just because it's not GPL doesn't mean DFSG can be ignored.
> 
> Well, minified or not, my point is that it's "code". And DFSG#2 refers to
> source code not to "preferred form of modification".

It also doesn't define "source" (or "code", for that matter, hence
several attempts in the past to clarify the language).

My understanding has always been that, for want of a better definition
and in the absence of anything more formal, Debian has basically treated
the two terms as interchangeable.  See #383465 for instance; the old nv
driver definitely wasn't GPLed.  (Yes, it's not a great example, but it
also doesn't involve interminable threads on debian-legal).

> We have the case of PDF files without the original document used
> to generate that PDF but it doesn't really count since DFSG#2 only
> applies to "source code".

The FTP team certainly appear to be of the opinion that it's a serious
enough issue to make a package unacceptable for the archive - see the
penultimate entry in the "direct reject" table on
http://ftp-master.debian.org/REJECT-FAQ.html

Regards,

Adam


-- 
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/1319658490.11486.7.ca...@hathi.jungle.funky-badger.org

Re: Minified files and source code requirement

2011-10-26 Thread Tollef Fog Heen 
]] Raphael Hertzog 

Hi,

| On Wed, 26 Oct 2011, Julien Cristau wrote:
| > On Wed, Oct 26, 2011 at 19:08:14 +0200, Raphael Hertzog wrote:
| > > I don't agree that minified files are a violation of DFSG #2. If the
| > > library is under the GPL then it would be a problem because it's not the
| > > preferred form of modification.
| >
| > Just because it's not GPL doesn't mean DFSG can be ignored.
| 
| Well, minified or not, my point is that it's "code". And DFSG#2 refers to
| source code not to "preferred form of modification".

Do you have a more useful definition of source code than «preferred form
for modification»?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87obx37cvc@qurzaw.varnish-software.com

Re: Minified files and source code requirement

2011-10-26 Thread Michael Gilbert 
On Wed, Oct 26, 2011 at 1:08 PM, Raphael Hertzog wrote:
> Hi,
>
> On Sun, 23 Oct 2011, Paul Wise wrote:
>> One of the other problems with embedded JavaScript libraries is that
>> often only the pre-compiled/obfuscated/minified version is
>> distributed, which would be a violation of DFSG item 2.
>
> I did not reply on this at first but since Jakub filed #646729 using
> a similar reasoning, I would like to discuss this here.
>
> I don't agree that minified files are a violation of DFSG #2. If the
> library is under the GPL then it would be a problem because it's not the
> preferred form of modification.

This isn't a problem if you use the system library (e.g. jquery.min.js
that exists in the jquery package thanks to yui-compressor).  The real
solution to this problem (as already discussed) is to devise a
javascript versioning policy that causes breakages when APIs change,
so that any such change has to have a transition plan.

Best wishes,
Mike


-- 
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/CANTw=MM64fqG9it-h7gM1B5QCg=Lq-CJ73Dm4mFh8eHw=az...@mail.gmail.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Zygmunt Krynicki 

W dniu 24.10.2011 01:20, Ben Finney pisze:

I would very much like that to change – that programmers should expect a
single instance of a Javascript library to be useable across the OS, and
that a Javascript library without a dependable ABI should be shunned by
most application writers, and for applications to declare the library
versions they expect in a standardised, automated way. But I don't know
what to do to get there.


Hi.

I'd like to throw a few comments here. I speak both as an web 
application developer, debian packager (well, packaging my application 
for debian-based systems) and deployment/ops engineer.


Asking for this is *highly* unrealistic and will only further alienate 
developers from Debian's way of doing things. Current best practice is 
to use CDNs that distribute a particular or latest version of a library 
(jQuery for example has several such networks available) or to bundle 
the library directly.


The reason for this is simple: quality control and portability (across 
hosting systems)


Another thing to point out is that unlike traditional applications where 
linking is explicit and done before actual startup here the linking 
happens at another machine, the one of the user of the web application. 
The actual library can come from a yet another system. The key issue to 
point out here is that this is not really linking the way we think about 
it. Here it is not code but data.


If anything, having one version of a javascript library *hurts* 
Debian-as-a-platform. I would encourage a different approach altogether: 
explicit mutli-versioning (ideally for all upstream releases or for all 
upstream releases that are known to introduce features and are not 
emergency bug/security fixes) and explicit version dependency that 
matches upstream. That later requirement may be ignored if uptream is 
not responding or the application is known to work correctly with 
another version of a library.


This approach will allow web application developers to use Debian in the 
way they expect systems to work.


At the end of the day I cannot use Debian's jQuery because I must 
control what goes out to ensure quality. Multiply this problem by 
co-hosting many applications and you get the answer.


As long what I described above is the prevailing point of view or 
motivation of web application developers then packaged javascript 
libraries will only fill a niche where someone deploys a packaged 
wiki/bug tracker/something else for their small team/co workers.


More complicated web applications will be deployed outside the packaging 
system, without any reuse of packaged libraries, without any advantages 
that Debian brings to the table.


Thanks
Zygmunt Krynicki

PS: re-sending from subscribed email, if you get a dupe please excuse 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/4ea889cb.4070...@canonical.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Zygmunt Krynicki 

W dniu 24.10.2011 01:20, Ben Finney pisze:

I would very much like that to change – that programmers should expect a
single instance of a Javascript library to be useable across the OS, and
that a Javascript library without a dependable ABI should be shunned by
most application writers, and for applications to declare the library
versions they expect in a standardised, automated way. But I don't know
what to do to get there.


Hi.

I'd like to throw a few comments here. I speak both as an web 
application developer, debian packager (well, packaging my application 
for debian-based systems) and deployment/ops engineer.


Asking for this is *highly* unrealistic and will only further alienate 
developers from Debian's way of doing things. Current best practice is 
to use CDNs that distribute a particular or latest version of a library 
(jQuery for example has several such networks available) or to bundle 
the library directly.


The reason for this is simple: quality control and portability (across 
hosting systems)


Another thing to point out is that unlike traditional applications where 
linking is explicit and done before actual startup here the linking 
happens at another machine, the one of the user of the web application. 
The actual library can come from a yet another system. The key issue to 
point out here is that this is not really linking the way we think about 
it. Here it is not code but data.


If anything, having one version of a javascript library *hurts* 
Debian-as-a-platform. I would encourage a different approach altogether: 
explicit mutli-versioning (ideally for all upstream releases or for all 
upstream releases that are known to introduce features and are not 
emergency bug/security fixes) and explicit version dependency that 
matches upstream. That later requirement may be ignored if uptream is 
not responding or the application is known to work correctly with 
another version of a library.


This approach will allow web application developers to use Debian in the 
way they expect systems to work.


At the end of the day I cannot use Debian's jQuery because I must 
control what goes out to ensure quality. Multiply this problem by 
co-hosting many applications and you get the answer.


As long what I described above is the prevailing point of view or 
motivation of web application developers then packaged javascript 
libraries will only fill a niche where someone deploys a packaged 
wiki/bug tracker/something else for their small team/co workers.


More complicated web applications will be deployed outside the packaging 
system, without any reuse of packaged libraries, without any advantages 
that Debian brings to the table.


Thanks
Zygmunt Krynicki


--
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/4ea887a6.4060...@ubuntu.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Michael Gilbert 
On Wed, Oct 26, 2011 at 6:29 PM, Zygmunt Krynicki wrote:
> If anything, having one version of a javascript library *hurts*
> Debian-as-a-platform. I would encourage a different approach altogether:
> explicit mutli-versioning (ideally for all upstream releases or for all
> upstream releases that are known to introduce features and are not emergency
> bug/security fixes) and explicit version dependency that matches upstream.
> That later requirement may be ignored if uptream is not responding or the
> application is known to work correctly with another version of a library.

There isn't any real technical factor limiting the number of versions
to one.  Theoretically, there could both jquery1.4 and jquery1.6
source packages coexisting (as long as the binary files are
appropriately versioned as well).  Thus if wordpress only works with
1.4, then it can use that temporarily until it gets updated to support
1.6 (or whatever the problem it was that started this discussion).

Anyway, it's all solvable (given volunteers actually interested in
doing the work to do it).

Best wishes,
Mike


-- 
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/CANTw=mozqneaukugzdvf1eowpcmt9dglarqwrkwm3_3w-wk...@mail.gmail.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Zygmunt Krynicki 

W dniu 27.10.2011 00:46, Michael Gilbert pisze:

On Wed, Oct 26, 2011 at 6:29 PM, Zygmunt Krynicki wrote:

If anything, having one version of a javascript library *hurts*
Debian-as-a-platform. I would encourage a different approach altogether:
explicit mutli-versioning (ideally for all upstream releases or for all
upstream releases that are known to introduce features and are not emergency
bug/security fixes) and explicit version dependency that matches upstream.
That later requirement may be ignored if uptream is not responding or the
application is known to work correctly with another version of a library.


There isn't any real technical factor limiting the number of versions
to one.  Theoretically, there could both jquery1.4 and jquery1.6
source packages coexisting (as long as the binary files are
appropriately versioned as well).  Thus if wordpress only works with
1.4, then it can use that temporarily until it gets updated to support
1.6 (or whatever the problem it was that started this discussion).

Anyway, it's all solvable (given volunteers actually interested in
doing the work to do it).


Is there anyone that would like to mentor me for a while to help me get 
started? I'm quite interested in solving this problem.


Best regards
Zygmunt Krynicki


--
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/4ea88ffe.3030...@canonical.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Zygmunt Krynicki 

W dniu 27.10.2011 00:29, Zygmunt Krynicki pisze:

W dniu 24.10.2011 01:20, Ben Finney pisze:

I would very much like that to change – that programmers should expect a
single instance of a Javascript library to be useable across the OS, and
that a Javascript library without a dependable ABI should be shunned by
most application writers, and for applications to declare the library
versions they expect in a standardised, automated way. But I don't know
what to do to get there.


Hi.

I'd like to throw a few comments here. I speak both as an web



Another thing to point out is that unlike traditional applications where
linking is explicit and done before actual startup here the linking
happens at another machine, the one of the user of the web application.
The actual library can come from a yet another system. The key issue to
point out here is that this is not really linking the way we think about
it. Here it is not code but data.


Replying to myself, this obviously does not include server-side 
javascript libraries for things like nodejs. Perhaps we should 
explicitly differentiate those?


Best regards
ZK


--
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/4ea890e5.10...@canonical.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Ian Jackson 
Michael Gilbert writes ("Re: Dealing with embedded javascript libraries"):
> There isn't any real technical factor limiting the number of versions
> to one.  Theoretically, there could both jquery1.4 and jquery1.6
> source packages coexisting (as long as the binary files are
> appropriately versioned as well).  Thus if wordpress only works with
> 1.4, then it can use that temporarily until it gets updated to support
> 1.6 (or whatever the problem it was that started this discussion).

The difficulty is that if we end up with ten different versions of
some random javascript library, when it turns out to have a security
vulnerability we need to somehow backport the patch to each of those
ten versions.

And here "we" means the security team, not the people who uploaded the
ten versions in the first place.

So this is rather unpalatable.

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

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Michael Gilbert 
On Wed, Oct 26, 2011 at 6:55 PM, Zygmunt Krynicki wrote:
> Is there anyone that would like to mentor me for a while to help me get
> started? I'm quite interested in solving this problem.

You can certainly work on anything in Debian (including this) and
present your work to mentors [0] and/or the maintainers of the
package.

Best wishes,
Mike

[0] http://mentors.debian.net


-- 
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/CANTw=MOgQF6o5Vj-xHQ6KQhcNCfJMpCP48kAu=1-vasmqpw...@mail.gmail.com

Re: Minified files and source code requirement

2011-10-26 Thread Charles Plessy 
Le Wed, Oct 26, 2011 at 07:08:14PM +0200, Raphael Hertzog a écrit :
> 
> But with more liberal licenses, we should certainly accept that the
> minified files are their own sources much like we accept any other blob of
> data under a free license.

Hello Raphaël and everybody,

one of the problem with minified JavaScript libraries is that it is difficult
to know what they really do.  Are they really what the upstream author thinks
they are, or was he tricked in cut-and-pasting a fake version containing a
spyware ?

On the other hand, if the minified file you would like to distribute matches
exactly a minified file that has been distributed by Debian in the past, then
indeed, why not running that version ?  You are an experienced developer and I
trust you to understand, balance and negociate the costs and benefits on a
case-by-case basis.

For the compliance with DFSG – and this is the main message here – we could
reach it considering all the packages that are part of the same release, by
using the dpkg source format 3.0 (git), which would be an efficient way to
distribute past source versions and point at the preferred one at the same
time.

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/20111027010312.gd30...@merveille.plessy.net

Failed to make a .deb package of PECL uploadprogress on squeeze. Any solution?

2011-10-26 Thread Jaisen 
Hi,

I was trying to make a .deb package of uploadprogress-1.0.3.1.tgz,
(downloaded from PECL - http://pecl.php.net/package/uploadprogress)
using dh-make-php, on Squeeze.

Followed the instructions given in the link:
http://freestylesystems.co.uk/blog/installing-pecl-uploadprogress-extension-drupal-filefield-30-module#install-unix

I stuck in the middle, as it need both php5-dev and php4-dev.
But there is no php4-dev in squeeze repo.

What I have done is pasted below.

As I am new to make a .deb package, I don't know how to resolve this. Any way?


--
$sudo apt-get install dh-make-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
dh-make-php is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$pecl download uploadprogress
downloading uploadprogress-1.0.3.1.tgz ...
Starting to download uploadprogress-1.0.3.1.tgz (9,040 bytes)
.done: 9,040 bytes
File /home/jaisen/drupal/uploadprogress-1.0.3.1.tgz downloaded
$cd drupal/
$dh-make-pecl uploadprogress-1.0.3.1.tgz
PHP Notice:  Undefined index: date in
/usr/share/dh-make-php/phppkginfo on line 60
PHP Notice:  Undefined index: date in
/usr/share/dh-make-php/phppkginfo on line 60
Creating debian source package: php-uploadprogress-1.0.3.1
Upstream is: Christian Stocker, Ben Ramsey
Guessing Maintainer: jaisen 
$ cd php-uploadprogress-1.0.3.1/
$ fakeroot dpkg-buildpackage -b
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin:
vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags
(origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags
(origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin:
vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package php-uploadprogress
dpkg-buildpackage: source version 1.0.3.1-1
dpkg-buildpackage: source changed by jaisen 
dpkg-buildpackage: host architecture i386
dpkg-source --before-build php-uploadprogress-1.0.3.1
dpkg-checkbuilddeps: Unmet build dependencies: php4-dev
dpkg-buildpackage: warning: Build dependencies/conflicts
unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
$ fakeroot dpkg-buildpackage -d
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): 
-g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: 
vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin:
vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): 
-g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package php-uploadprogress
dpkg-buildpackage: source version 1.0.3.1-1
dpkg-buildpackage: source changed by jaisen 
dpkg-buildpackage: host architecture i386
 dpkg-source --before-build php-uploadprogress-1.0.3.1
 debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp* configure-stamp*
# Add here commands to clean up after the build process.
(cd uploadprogress-1.0.3.1; \
/usr/bin/make clean; \
/usr/bin/phpize4 --clean)
make[1]: Entering directory
`/home/jaisen/drupal/php-uploadprogress-1.0.3.1/uploadprogress-1.0.3.1'
make[1]: *** No rule to make target `clean'.  Stop.
make[1]: Leaving directory
`/home/jaisen/drupal/php-uploadprogress-1.0.3.1/uploadprogress-1.0.3.1'
/bin/sh: /usr/bin/phpize4: not found
make: *** [clean-v4] Error 127
dpkg-buildpackage: error: debian/rules clean gave error exit status 2
$


-- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
- നെടുമ്പാല ജയ്സെന്‍ -
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
    (`'·.¸(`'·.¸^¸.·'´)¸.·'´)
«´¨`·* .  Jaisen . *..´¨`»
    (¸.·'´(`'·.¸ ¸.·'´)`'·.¸)
    ¸.·´^.`'·.¸ ¸.·'´
     ( `·.¸`·.¸
      `·.¸ )`·.¸
     ¸.·(´ `·.¸
    ¸.·(.·´)`·.¸
      ( `v´ )
        `v´


--
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/caknl019hntajjtu-y-c_1guua-v5hxha2kdukpcfyusxmf9...@mail.gmail.com

Bug#646776: ITP: kiwiirc -- Web based IRC client

2011-10-26 Thread Antoine Beaupré 
Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré" 

* Package name: kiwiirc
  Version : 0~20111004
  Upstream Author : Darren
* URL : https://github.com/prawnsalad/KiwiIRC
* License : AGPL
  Programming Lang: Javascript
  Description : Web based IRC client

Kiwiirc is a web-based IRC client written in Node JS.



--
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/20111027025703.26339.70540.report...@marcos.anarcat.ath.cx

Re: Minified files and source code requirement

2011-10-26 Thread Paul Wise 
On Thu, Oct 27, 2011 at 1:08 AM, Raphael Hertzog wrote:

> I don't agree that minified files are a violation of DFSG #2. If the
> library is under the GPL then it would be a problem because it's not the
> preferred form of modification.

I think this is exactly the same as xserver-xorg-video-nv, which
contained obfuscated C code instead of the actual source code. I
personally considered that a DFSG violation but I guess you would not?

> But with more liberal licenses, we should certainly accept that the
> minified files are their own sources much like we accept any other blob of
> data under a free license. For instance we know that almost none of the
> firmwares are hand-crafted yet I think we have many firmware under
> DFSG-free licenses (and we adequately pointed out that GPL firmwares were
> not ok).

What is the preferred form for modification for a work (aka source) is
highly context-dependent.

For example:

A TTF font file might be source or FontForge .sfd files might be the source.

A PNG image might be source or the SVG or XCF it was rendered from
might be the source.

A firmware blob might be written using a hex editor or it might be
built from assembly code or C compiler. There are cases of both in the
firmware-free package.

An ELF executable might be written using a hex editor (haven't seen
that yet) or compiled from assembly, C or other code.

Just accepting what we are given is not enough to actually know what
the source actually is (here I'm thinking of MegaGlest).

Further than that, some forms that are currently used as source might
be better converted to other forms. For example given a hand-crafted
binary firmware file, we should suggest that upstream convert that to
assembler and use that instead.

> (Furthermore there are tools which can reindent such minified files, while
> this doesn't restore variable names and the like, it really helps if one
> wants to analyze this code.)

Thats irrelevant, it will not restore the original source, just like
ELF or Java decompilers cannot.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6G0H0jxA5dD9YWqKTuQQMjTx4sPkjMxw3JiN=F=J_=q...@mail.gmail.com

Re: Dealing with embedded javascript libraries

2011-10-26 Thread Paul Wise 
On Thu, Oct 27, 2011 at 7:28 AM, Ian Jackson wrote:

> The difficulty is that if we end up with ten different versions of
> some random javascript library, when it turns out to have a security
> vulnerability we need to somehow backport the patch to each of those
> ten versions.
>
> And here "we" means the security team, not the people who uploaded the
> ten versions in the first place.

I would assume the security team would just file bugs and let the
maintainer deal with it, unless the issue is embargoed?

> So this is rather unpalatable.

Agreed with that part.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HPVjkcLdnKv9zLMcab=L3m63ogSp7OtiA-V=jvcpl...@mail.gmail.com

Re: Minified files and source code requirement

2011-10-26 Thread Russ Allbery 
Paul Wise  writes:

> What is the preferred form for modification for a work (aka source) is
> highly context-dependent.

I'd like to poke a little bit at the assumption that these two things are
the same and that Debian necessarily uses the GPL term as our definition
of source.

To me, the source of something is *a* form suitable for modification of
the work.  This is *not* necessarily the same thing as the GPL's "the
preferred form of the work for making modifications to it."  I think
Debian's term means that the form has to be suitable for modification by a
reasonable "average person" who is technically skilled enough to be able
to modify the work.  I think it's a bit of a leap that it necessarily
means that it has to be whatever form that the author of the work
personally prefers, and even more of a leap that it has to be the form
that the author of the work used originally.

For example, suppose I include an image in a piece of software that I
generated by taking a digital photograph of something in RAW, manipulating
it in Photoshop, and then exporting it as a JPEG.  What's the source?  In
the GPL sense, one can make an argument that the original RAW image is the
preferred form for modification, since if I had it available I'd probably
use it rather than the JPEG to make further changes.  However, I think the
JPEG is perfectly reasonable source from the Debian perspective: there is
nothing about the JPEG that prevents people from making further
transformations and changes and creating a derivative work.  It may not be
ideal, similar to how working with source without the revision history
from the original VCS repository isn't ideal, but it's certainly
*possible* and even reasonable.

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

Re: Minified files and source code requirement

2011-10-26 Thread Paul Wise 
On Thu, Oct 27, 2011 at 1:33 PM, Russ Allbery  wrote:

> To me, the source of something is *a* form suitable for modification of
> the work.  This is *not* necessarily the same thing as the GPL's "the
> preferred form of the work for making modifications to it."  I think
> Debian's term means that the form has to be suitable for modification by a
> reasonable "average person" who is technically skilled enough to be able
> to modify the work.  I think it's a bit of a leap that it necessarily
> means that it has to be whatever form that the author of the work
> personally prefers, and even more of a leap that it has to be the form
> that the author of the work used originally.

I completely disagree with this because I thought free software was
about equality.

Free software licenses bring back the equality broken by copyright law.

These licenses are completely irrelevant if we do not have equality of
access to the source form of a work.

> For example, suppose I include an image in a piece of software that I
> generated by taking a digital photograph of something in RAW, manipulating
> it in Photoshop, and then exporting it as a JPEG.  What's the source?  In
> the GPL sense, one can make an argument that the original RAW image is the
> preferred form for modification, since if I had it available I'd probably
> use it rather than the JPEG to make further changes.  However, I think the
> JPEG is perfectly reasonable source from the Debian perspective: there is
> nothing about the JPEG that prevents people from making further
> transformations and changes and creating a derivative work.  It may not be
> ideal, similar to how working with source without the revision history
> from the original VCS repository isn't ideal, but it's certainly
> *possible* and even reasonable.

The ideal source for that is obviously RAW + manipulation instructions
+ JPEG export settings.

Given just a JPEG I would consult upstream to find out what the source is.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6G_3cpFhNv9tjLqaPofxf7vS=LR3BYSUsS=ttdkoy4...@mail.gmail.com

Re: Minified files and source code requirement

2011-10-26 Thread Russ Allbery 
Paul Wise  writes:

> I completely disagree with this because I thought free software was
> about equality.

> Free software licenses bring back the equality broken by copyright law.

> These licenses are completely irrelevant if we do not have equality of
> access to the source form of a work.

I think the full implications of that belief would render most of the
archive non-free.  The typical free software project has a ton of
supporting resources of moderate to mild use in making further
modifications that are not generally available to anyone wanting to modify
it, ranging from accumulated internal documentation to personal email
archives to test suites to manipulation tools to version control
repositories with substantial code history.  Most are not released with
the source; many are non-free (usually by omission; no one ever even
thought to put a license on them).

Insofar as those things can be made available, I think that's great, and
something to be encouraged, but I think it's far, far too aggressive, and
faintly absurd in its implications, to say that something is not free
software unless everyone has an equal ability to modify it as the original
author.

It feels to me like people keep trying to reduce the requirement for
source to absolute rules, since absolute rules are easy to enforce and
reason about, but this particular area is simply not amenable to absolute
rules.  We only have a clear grasp of the definition of "source" for code,
and even there it's hazy given some code production tactics (such as
starting with autogenerated code from some tool and then editing it
manually, possibly over the years losing the original tool so that the
process couldn't be reproduced even if one wanted to).  Once we move
beyond code, this is just a hard problem and doesn't have simple answers,
and applying hard-line rules achieves little other than alienating Debian
from upstream developers.

In other words, given the haziness in this area and the wildly divergent
practices of people when creating non-code works, I think we should look
at whether the provided "source" provides reasonable opportunity to meet
the core definition of free software, namely the ability to study and
adopt the work for one's own purposes and republish one's modifications,
and not get too hung up on whether the exact tools and steps the original
author took are included.

We don't require that C source come complete with the author's preferred
editor and macros.

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