On 03/13/2014 01:37 PM, Scott Kitterman wrote:
> On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote:
>> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>>> What percentage of free software in Debian main do you expect then?
>>
>> Hi Scott,
>>
>> I expect 100 % in the bina
On 03/13/2014 01:21 PM, Charles Plessy wrote:
> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>>
>> What percentage of free software in Debian main do you expect then?
>
> Hi Scott,
>
> I expect 100 % in the binary packages.
>
> On the other hand, the "upstream" tarballs ar
Scott Kitterman writes:
> I think it's black and white if it's a bug. If it's worth investing the
> effort in fixing the bug is all kinds of shades of gray.
I don't think that's a horribly useful distinction for this conversation,
which is about what will be accepted into the archive or not. (
On Wednesday, March 12, 2014 22:23:02 Russ Allbery wrote:
> Scott Kitterman writes:
> > On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
> >> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> >>> SC§1 states that we want Debian to remain 100% free; the common
> >>> interpret
On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote:
> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
> > What percentage of free software in Debian main do you expect then?
>
> Hi Scott,
>
> I expect 100 % in the binary packages.
>
> On the other hand, the "upstream"
Scott Kitterman writes:
> On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
>> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
>>> SC§1 states that we want Debian to remain 100% free; the common
>>> interpretation of that is that one can download anything from Debian
>>> mai
Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>
> What percentage of free software in Debian main do you expect then?
Hi Scott,
I expect 100 % in the binary packages.
On the other hand, the "upstream" tarballs are becoming temporary cruft that
are not the preferred form fo
On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> > Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> > > If an interpretation of the DFSG suggests that we should be doing work
> > > which does not further those obj
On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> > If an interpretation of the DFSG suggests that we should be doing work
> > which does not further those objectives, then I think that
> > interpretation is a misreading.
>
> S
On Thu, Mar 13, 2014 at 08:06:14AM +0800, Paul Wise wrote:
> On Thu, Mar 13, 2014 at 6:14 AM, Mike Hommey wrote:
>
> > I guess it just unpacks, removes and repacks. Which also means it would
> > be quite annoying in my own workflow which involves unpacking/repacking
> > 700MB. The script I'm using
On Thu, Mar 13, 2014 at 6:14 AM, Mike Hommey wrote:
> I guess it just unpacks, removes and repacks. Which also means it would
> be quite annoying in my own workflow which involves unpacking/repacking
> 700MB. The script I'm using now does the filtering on the tar stream
> itself, without actually
Package: wnpp
Severity: wishlist
Owner: Pierre Rudloff
* Package name: mozjpeg
Version : 1.0
Upstream Author : Mozilla
* URL : https://github.com/mozilla/mozjpeg
* License : Custom free software license
Programming Lang: C
Description : Mozilla JPEG Enc
On Wednesday 12 March 2014 23:02:27 Joachim Breitner wrote:
> Hi,
>
> Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor
>
> Pérez Meyer:
> > > Do you (or anyone) know if it repacks the file consistently? I.e. will
> > > two developers, who both use uscan to get the original
On Wed, Mar 12, 2014 at 11:02:27PM +0100, Joachim Breitner wrote:
> Hi,
>
> Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor
> Pérez Meyer:
> > > Do you (or anyone) know if it repacks the file consistently? I.e. will
> > > two developers, who both use uscan to get the origi
Package: wnpp
Severity: wishlist
Owner: Jonas Genannt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: ruby-em-mongo
Version : 0.4.3
Upstream Author : Brenden Grace
* URL : https://github.com/bcg/em-mongo
* License : MIT
Programming Lang: Rub
Hi,
Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor
Pérez Meyer:
> > Do you (or anyone) know if it repacks the file consistently? I.e. will
> > two developers, who both use uscan to get the original tarball for the
> > same version and with the same File-Excluded get ident
Vincent Bernat writes:
> [A bundled, source version of the library] will just go out of sync.
> For upstream, the preferred form of "modification" is the minified
> version (modification is merely the update to a new version).
Yes, the cause of that is that upstream doesn't treat these files as
On Tuesday 11 March 2014 09:07:43 Joachim Breitner wrote:
> Hi,
>
> Am Dienstag, den 11.03.2014, 10:34 +0800 schrieb Paul Wise:
> > On Tue, Mar 11, 2014 at 1:27 AM, Joachim Breitner wrote:
> > > nor mess with tarball repackaging (which I consider ugly, a cludge, and
> > > to be avoided if possible
* Philipp Kern , 2014-03-12, 21:11:
I still think it should be acceptable given that it's an open source
project, it's clearly versioned from which source it comes and we
check by not using the file that no changes have been done to the
minification. I guess we could even go one step further an
❦ 12 mars 2014 21:11 CET, Philipp Kern :
> how bad would it be for those upstreams to just include an unused copy
> of the non-minified version? Clearly it'd never be used by anything in
> the upstream packaging because you almost always want to ship minified
> JS to browsers in production. But
On Wed, Mar 12, 2014 at 1:11 PM, Philipp Kern wrote:
> Hi,
>
>
> On 2014-03-11 00:09, Joachim Breitner wrote:
>>
>> Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
>>>
>>> as long as the code in question is not under a license that requires the
>>> full, non-minified source to be repr
Hi,
On 2014-03-11 00:09, Joachim Breitner wrote:
Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
as long as the code in question is not under a license that requires
the
full, non-minified source to be reproduced and if the copyright
notices
and license terms as potentially requir
On 12.03.2014 16:47, Paul Tagliamonte wrote:
> Also archive size, for what it's worth.
>
> Shipping GBs of DLLs, minified JS and other sourceless nonsense
> is totally a waste of everyone's time and storage space.
this is not a good argument, the best you can usually get out of
upstreams it to s
Quoting Ian Jackson (2014-03-12 13:58:51)
> If an interpretation of the DFSG suggests that we should be doing work
> which does not further those objectives, then I think that
> interpretation is a misreading. Conversely, if an interpretation of
> the DFSG suggests that we should tolerate a sit
Hi Ryo,
Le dimanche 11 août 2013 à 11:11 +0900, Ryo IGARASHI a écrit :
> Fortran90 -dev package may contain .mod files, which behave like
> header files for C/C++ program. However, .mod files are binary files,
> and compiler dependent, and what is worse, they are incompatible
> between every majo
Also archive size, for what it's worth.
Shipping GBs of DLLs, minified JS and other sourceless nonsense
is totally a waste of everyone's time and storage space.
On Wed, Mar 12, 2014 at 11:44 AM, Don Armstrong wrote:
> On Wed, 12 Mar 2014, Ian Jackson wrote:
> > No-one has come up with any prac
On Wed, 12 Mar 2014, Ian Jackson wrote:
> No-one has come up with any practical benefit from the repacking of
> source tarballs to remove nonfree files.
Non-free files in source files are distributed by Debian. They cannot be
modified, inspected, or easily patched. Removing them assures us that
th
Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> Didier 'OdyX' Raboud writes ("Re: jquery debate with upstream"):
> > I disagree: I don't think it's tolerable to ship a .exe freeware [0]
> > in a source package in main, just because it happens to be
> > redistributable; in my reading, co
Hi,
I've just uploaded postgresql-9.3 which includes a fix for a very old
bug: #314427.
For compatibility reasons long forgotten, we have been shipping some
"server" include files in libpq-dev in /usr/include/postgresql/ that
should rather only live in /usr/include/postgresql/9.3/server/. These
a
Didier 'OdyX' Raboud writes ("Re: jquery debate with upstream"):
> I disagree: I don't think it's tolerable to ship a .exe freeware [0] in
> a source package in main, just because it happens to be redistributable;
> in my reading, considering that the "source package" _is_ a component of
> the D
On 12/03/14 09:24, Christian Hofstaedtler wrote:
> * Simon McVittie [140311 12:21]:
>> Russ said
>>> I think we only want to do this check if the first line of the
>>> Changes file says UNRELEASED, since there are valid use cases
>>> for a mismatch otherwise.
>
> I have a package which branched
Package: wnpp
Severity: wishlist
Owner: Matthew Vernon
Package name: libowasp-esapi-java
Version : 2.1.0
Upstream Author : Jeff Williams
URL : https://code.google.com/p/owasp-esapi-java/
License : BSD (documentation CC-BY-SA-3.0)
Programming Lang: Java
* Simon McVittie [140311 12:21]:
> Russ said
> > I think we only want to do this check if the first line of the
> > Changes file says UNRELEASED, since there are valid use cases for a
> > mismatch otherwise.
>
> but I don't know what those valid use-cases are. BinNMUs in testing
> for a package u
Le mardi, 11 mars 2014, 19.02:55 Ian Jackson a écrit :
> Thomas Goirand writes ("Re: jquery debate with upstream"):
> > In one of my package, I had openssl.dll in the source tarball (it
> > was of course removed later on).
> >
> > Would you consider it ok as well to have it in a source package, as
34 matches
Mail list logo
