-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 21, 2016 at 07:26:43AM +0200, Vincent Bernat wrote:
> It would be as easy for the security team to modify the unminified version
> than the "upper" upstream version of the source.
The release team has just decided that "browserified" files
Scott Kitterman writes ("Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff
(knot-resolver-module-http: please package embedded epoch.js separately)"):
> It would be nice if the language police could give it a rest.
> Personally, I don't see that as being signifi
Quoting Vincent Bernat (2016-10-21 07:26:43)
> ❦ 21 octobre 2016 00:20 +0200, Joerg Jaspert :
>
>>> #!/bin/sh
>>> # I absolutely new nothing about gulp, coffeescript, sass and uglify 15
>>> minutes ago...
>>> [...]
>>> If you insist I can add build.sh script to the missing-source, but
>>
>> No, y
❦ 21 octobre 2016 00:20 +0200, Joerg Jaspert :
>> #!/bin/sh
>> # I absolutely new nothing about gulp, coffeescript, sass and uglify 15
>> minutes ago...
>> [...]
>> If you insist I can add build.sh script to the missing-source, but
>
> No, you do not put it in missing-source foo. You use it duri
On Fri, Oct 21, 2016, at 00:20, Joerg Jaspert wrote:
> On 14466 March 1977, Ondřej Surý wrote:
>
> > to stop you from bickering on and on, the build script can be
> > reconstructed
> > just from reading gulpfile.js and would consist of installing ruby-sass,
> > coffeescript and node-uglify and run
Ondřej Surý writes:
> Gentlemen (arguing over and over) and ladies (watching this thread),
Can we not characterise entire genders inaccurately, please? Preferably,
not at all, since it seems entirely irrelevant to the discussion.
--
\ “To punish me for my contempt of authority, Fate has m
On October 20, 2016 7:15:45 PM EDT, Ian Jackson
wrote:
>Joerg Jaspert writes ("Re: [Pkg-dns-devel] Bug#833309: "Browserified"
>stuff (knot-resolver-module-http: please package embedded epoch.js
>separately)"):
>> On 14466 March 1977, Ondřej Surý wrote:
&g
Joerg Jaspert writes ("Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff
(knot-resolver-module-http: please package embedded epoch.js separately)"):
> On 14466 March 1977, Ondřej Surý wrote:
> > If you insist I can add build.sh script to the missing-source, but
On 14466 March 1977, Ondřej Surý wrote:
> to stop you from bickering on and on, the build script can be
> reconstructed
> just from reading gulpfile.js and would consist of installing ruby-sass,
> coffeescript and node-uglify and running:
> #!/bin/sh
> # I absolutely new nothing about gulp, coffe
Quoting Ian Jackson (2016-10-20 17:45:54)
> Ondřej Surý writes ("Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff
> (knot-resolver-module-http: please package embedded epoch.js separately)"):
> > Gentlemen (arguing over and over) and ladies (watching this t
Quoting Scott Kitterman (2016-10-20 16:35:22)
> On Thursday, October 20, 2016 04:06:10 PM Jonas Smedegaard wrote:
> > Quoting Ondřej Surý (2016-10-20 15:48:08)
> >
> > > to stop you from bickering on and on, the build script can be
> > > reconstructed just from reading gulpfile.js and would consis
Ondřej Surý writes ("Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff
(knot-resolver-module-http: please package embedded epoch.js separately)"):
> Gentlemen (arguing over and over) and ladies (watching this thread),
>
> [as code speaks more than words...]
>
On Thursday, October 20, 2016 04:06:10 PM Jonas Smedegaard wrote:
> Quoting Ondřej Surý (2016-10-20 15:48:08)
>
> > to stop you from bickering on and on, the build script can be
> > reconstructed just from reading gulpfile.js and would consist of
>
> > installing ruby-sass, coffeescript and node-
Quoting Ondřej Surý (2016-10-20 15:48:08)
> to stop you from bickering on and on, the build script can be
> reconstructed just from reading gulpfile.js and would consist of
> installing ruby-sass, coffeescript and node-uglify and running:
Fine.
Now, to get back to the original dispute whether s
Gentlemen (arguing over and over) and ladies (watching this thread),
[as code speaks more than words...]
to stop you from bickering on and on, the build script can be
reconstructed
just from reading gulpfile.js and would consist of installing ruby-sass,
coffeescript and node-uglify and running:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 19, 2016 at 09:07:26AM +0200, Vincent Bernat wrote:
> gulp is just a glorified make and doesn't compile anything on its own.
If make wouldn't be in main, any program using it in its build process would
also not be allowed in main. The opt
❦ 14 octobre 2016 10:49 +0200, "W. Martin Borgert" :
> Let's say I need a special tool to compile it, e.g.
> bison-priscus, and I don't want to package it for Debian?
[...]
>> No. You as the maintainer have to guarantee that the file is
>> buildable with tools available in main. You can't if
>> On 14458 March 1977, W. Martin Borgert wrote:
>> > If I package a compiler and put y.tab.c in the package, drop
>> > grammar.y in d/m-s/, would it be OK or not?
>> If you come up with a good reason for it, yes. But I doubt you would
>> find one here.
> Let's say I need a special tool to compile
Mike Hommey:
> On Thu, Oct 13, 2016 at 05:48:00AM +, Niels Thykier wrote:
>> [...]
>> This should happen on its own as people convert their packages to
>> debhelper compat 10.
>
> which is not possible for everyone who cares about backporting their
> packages.
>
> Mike
>
FTR, debhelper/10.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 14, 2016 at 10:49:06AM +0200, W. Martin Borgert wrote:
> On 2016-10-13 22:39, Joerg Jaspert wrote:
> > On 14458 March 1977, W. Martin Borgert wrote:
> > > If I package a compiler and put y.tab.c in the package, drop
> > > grammar.y in d/m-s
On 2016-10-13 22:39, Joerg Jaspert wrote:
> On 14458 March 1977, W. Martin Borgert wrote:
> > If I package a compiler and put y.tab.c in the package, drop
> > grammar.y in d/m-s/, would it be OK or not?
>
> If you come up with a good reason for it, yes. But I doubt you would
> find one here.
Let's
On 14457 March 1977, Martín Ferrari wrote:
>> It is not useless, and contrib is way different than any random
>> repository out there.
> I am not sure about that. We discourage people from using contrib, and
> don't promise much support. Whereas upstream can offer the latest
> package always.
> T
On 14458 March 1977, W. Martin Borgert wrote:
>> Dunno. It would be great if the line wasn't challenged just to prove a
>> point
> I don't think tincho nor myself want to challenge a line, we
> would like to know where it is :~)
> If I package a compiler and put y.tab.c in the package, drop
> gra
On 10/13/2016 08:03 AM, Mike Hommey wrote:
> On Thu, Oct 13, 2016 at 05:48:00AM +, Niels Thykier wrote:
>> W. Martin Borgert:
>>> On 2016-10-12 21:41, Vincent Bernat wrote:
❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
> I had always understood that rebuilding from source was a hard
On Thu, Oct 13, 2016 at 05:48:00AM +, Niels Thykier wrote:
> W. Martin Borgert:
> > On 2016-10-12 21:41, Vincent Bernat wrote:
> >> ❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
> >>> I had always understood that rebuilding from source was a hard
> >>> requirement. Is this not the case any m
❦ 12 octobre 2016 23:27 CEST, "W. Martin Borgert" :
> If I package a compiler and put y.tab.c in the package, drop
> grammar.y in d/m-s/, would it be OK or not? If I don't even
> check that bison actually can process the file, would it
> still be OK?
I can't say for sure but as it is "easy" to
W. Martin Borgert:
> On 2016-10-12 21:41, Vincent Bernat wrote:
>> ❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
>>> I had always understood that rebuilding from source was a hard
>>> requirement. Is this not the case any more?
>>
>> This has never been the case. Since the beginning, there was n
On Thu, Oct 13, 2016 at 6:16 AM, Ben Finney wrote:
> How will we know that those are the corresponding source for the work
> Debian installs?
The maintainer could have verified it before uploading.
> One way is to actually use that exact source, to build the package.
That is the only realistic
"W. Martin Borgert" writes:
> There are some packages, that currently have only generated JS files
> without the original sources (not only SASS and CoffeeScript, but also
> large JS libraries, that are bundled from many source files), which
> seems not in line with DFSG.
>
> No need to eject the
On 2016-10-12 21:41, Vincent Bernat wrote:
> ❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
> > I had always understood that rebuilding from source was a hard
> > requirement. Is this not the case any more?
>
> This has never been the case. Since the beginning, there was no
> requirements to rege
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 12, 2016 at 10:09:12PM +0200, Martín Ferrari wrote:
> On 12/10/16 21:41, Vincent Bernat wrote:
> >> I don't think that shipping a binary compiled upstream should be
> >> allowed, so where's the line drawn?
Technically it would be allowed,
On 2016-10-12 21:22, Adam Borowski wrote:
> On Wed, Oct 12, 2016 at 09:00:50PM +0200, W. Martin Borgert wrote:
> > Who cares about yaccs and
> > bisons?
>
> You're thinking small. Why not ship a pre-compiled ELF, built with some
> paid version of ICC (screw silly sods on AMD chips like me[1]).
I
On 12/10/16 21:41, Vincent Bernat wrote:
>> I don't think that shipping a binary compiled upstream should be
>> allowed, so where's the line drawn?
>
> Dunno. It would be great if the line wasn't challenged just to prove a
> point and eject a lot of packages from main while DFSG#2 is correctly
>
❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
> I might have forgotten some important parts, or I missed the
> announcements when I was inactive for a while. But I am confused by
> these 2 statements, and would love to get some pointers to learn more:
>
>
>> On 2016-10-11 15:28, Vincent Bernat
On Wed, Oct 12, 2016 at 09:00:50PM +0200, W. Martin Borgert wrote:
> Quoting Martín Ferrari :
> >I had always understood that rebuilding from source was a hard
> >requirement. Is this not the case any more?
> >
> >I don't think that shipping a binary compiled upstream should be
> >allowed, so where
Quoting Martín Ferrari :
I had always understood that rebuilding from source was a hard
requirement. Is this not the case any more?
I don't think that shipping a binary compiled upstream should be
allowed, so where's the line drawn?
This is an interesting question indeed.
If it is allowed for
I might have forgotten some important parts, or I missed the
announcements when I was inactive for a while. But I am confused by
these 2 statements, and would love to get some pointers to learn more:
> On 2016-10-11 15:28, Vincent Bernat wrote:
>> Those specific sources are buildable from tools i
On 2016-10-11 15:28, Vincent Bernat wrote:
> Those specific sources are buildable from tools in main (aka
> coffeescript compiler, sass compiler, cat + uglifyjs). There is no hard
> requirement to rebuild from source when building the package.
(While I wonder how one can be sure that a software is
❦ 11 octobre 2016 15:03 CEST, Paul Wise :
>> Fine, I'll bundle them as well.
>
> Bundling the actual source instead of prebuilt files still doesn't
> solve the problem of not being able to build from source because the
> build tools are missing from Debian.
Those specific sources are buildable
On Tue, Oct 11, 2016, at 15:03, Paul Wise wrote:
> On Tue, Oct 11, 2016 at 8:56 PM, Ondřej Surý wrote:
>
> > Fine, I'll bundle them as well.
>
> Bundling the actual source instead of prebuilt files still doesn't
> solve the problem of not being able to build from source because the
> build tools
On Tue, Oct 11, 2016 at 8:56 PM, Ondřej Surý wrote:
> Fine, I'll bundle them as well.
Bundling the actual source instead of prebuilt files still doesn't
solve the problem of not being able to build from source because the
build tools are missing from Debian. It has always been ftp-master
policy t
Fine, I'll bundle them as well. Just don't make me maintain a package in
a language more horrible than PHP (in my eyes :-P).
O.
--
Ondřej Surý
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC)
On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote:
> Anybody is free to package epoch.js into separate package and I'll
> switch to using it, just don't shove more work by using BTS severities.
epoch.js upstream publishes their build info, so it looks like the
first step would be to finish the p
On 10/10/16 21:40, Joerg Jaspert wrote:
> It is not useless, and contrib is way different than any random
> repository out there.
I am not sure about that. We discourage people from using contrib, and
don't promise much support. Whereas upstream can offer the latest
package always.
This is serve
On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote:
> Definitely not serious here, as I do ship original sources from within
> the package:
>
> $ find . -name 'epoch*'
> ./modules/http/static/epoch.css
> ./modules/http/static/epoch.js
> ./debian/missing-sources/epoch.css
> ./debian/missing-sources
On 10/10/16 16:35, Bas Wijnen wrote:
> So the decision is that this code in its current form does not belong in main.
> If I understand your position correctly, you do not dispute this, but you seem
> to advocate that it should be allowed in main anyway, to avoid demoralizing
> the
> developers (i
Control: severity -1 wishlist
Definitely not serious here, as I do ship original sources from within
the package:
$ find . -name 'epoch*'
./modules/http/static/epoch.css
./modules/http/static/epoch.js
./debian/missing-sources/epoch.css
./debian/missing-sources/epoch.js
Anybody is free to package
severity 833309 serious
thanks
It looks like such issues are considered serious now:
https://lists.debian.org/debian-devel/2016/10/msg00138.html
(Btw. having a properly packaged epoch.js in Debian would
be nice. It is a wonderful charting library.)
On 14456 March 1977, Martín Ferrari wrote:
> On 09/10/16 23:56, Adam Borowski wrote:
>
>> Another issue is, as mentioned in the TC discussion, the inability to fix
>> any non-trivial security bugs in stable. I can't quite imagine the Security
>> Team hunting for a specific old version of grunt and
On 14455 March 1977, Adam Borowski wrote:
> On Sat, Oct 08, 2016 at 10:45:08PM +0200, Joerg Jaspert wrote:
>> we had a discussion inside the FTP Team about the "browserified js"
>> issue. We understand that "browserified" refers to various changes to
>> the original source, from concatenating multi
Quoting Bas Wijnen :
1. Package the tools that are required for building from source.
1a: It might not even be necessary to package the tools used by upstream.
In some cases, adhoc tools to perform similar tasks are sufficient.
Antonio Terceiro did this with jQuery successfully (debian/
On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote:
> On 09/10/16 23:56, Adam Borowski wrote:
> > Another issue is, as mentioned in the TC discussion, the inability to fix
> > any non-trivial security bugs in stable. I can't quite imagine the Security
> > Team hunting for a specific ol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote:
> Prometheus being in contrib basically means the work I have done for the
> past year is worthless, as users could as well just grab unofficial
> packages from other places. I am not sayi
On Mon, Oct 10, 2016 at 03:08:17PM +0200, Martín Ferrari wrote:
> Prometheus being in contrib basically means the work I have done for the
> past year is worthless, as users could as well just grab unofficial
> packages from other places.
contrib packages are not "unofficial".
--
WBR, wRAR
sig
On 09/10/16 23:56, Adam Borowski wrote:
> Another issue is, as mentioned in the TC discussion, the inability to fix
> any non-trivial security bugs in stable. I can't quite imagine the Security
> Team hunting for a specific old version of grunt and all of its extensive
> dependencies to rebuild t
On Sat, Oct 08, 2016 at 10:45:08PM +0200, Joerg Jaspert wrote:
> we had a discussion inside the FTP Team about the "browserified js"
> issue. We understand that "browserified" refers to various changes to
> the original source, from concatenating multiple (local and remotely
> fetched) files togeth
severity 817092 serious
thanks
Hi
we had a discussion inside the FTP Team about the "browserified js"
issue. We understand that "browserified" refers to various changes to
the original source, from concatenating multiple (local and remotely
fetched) files together, arbitary transformations (down
57 matches
Mail list logo
