Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-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 are not source.
Please stop suggesting that they are just a different kind of source; if you
really want to claim that, start a GR over it to overrule the release team.
(Please don't; it'd be a waste of time because AFAICS it stands no chance of
passing, in fact I'd be surprised if you'd get enough seconds.)

> I suppose that (like me), Ondřej Surý does not want to deal with the
> complexity of building JS from the "upper" source for the benefit of
> people that don't exist.

Aside from the fact that those people don't need to exist, as stated in another
email, they do.  I'm one of them.  The fact that I can retrieve the source of
the software I'm using and it will actually build from that source is one of
the main features that I like Debian for.  And when I make changes, I want to
send them back upstream, so "browserified" files are not good enough for me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYDbqYAAoJEJzRfVgHwHE64SIP/RpZOrqwXyvWRKyqE1+2rBiz
GRxe0NLHK5OBGkg64P3jwQyz+FrH44U5OQ3GrJgOzRkaqFCb37guZYy+fhpFa7DX
HwxT/fB+woQwry5dOs0jicmT8xEp+mQqBKRI8jM/BX73LVfInsOb6XVzSFEMkvSj
O8L7+0Q7lmHOHizmPCbM311fNkWYkdVzabSUb4/1vnQZYqZKVp6wr+W0f6mZi040
ULHstz6HhcjWXEKnbxc3Ey6biDZNSF71vP/N3rTN5Kkk/kJ9/dr0NInzF3Uzw2su
8y803eh0uucEE+LXxe1BoD3KOi7FEZX37wC5ogSvWCHvq1mddYZPxIUgf/4lZRdp
JalQ1XvUyNB+nW/p7L/9+Tn6aYSyCQ84Kas9Y9PaymzTuBa2XrCuhY2h2k6/v+SX
t+PmyzX3oeBVscPWq/aP3Ee/uf3g3y6YNuIBjaLD9gFipvz2g/E7mZ58f41LdPWd
V+bYptYtv+essnldA/0Pck+fRA9mpSWrJ8PR98CuAgdZ11n9LkgS/xmYwvXWDOZZ
y7VslGA8LkO8Pn8tWSVMKSBSPjwHqKixWgG41zq7PKqVdT4b37cWAMCGgGwJRIwC
rWInHvmDDtw5RoT7JVFZcUnxw2RWuOcIeRLyHlKmFOZNls0bTlFbre00KYAp7zXP
mkD0wNL6TxTu/HDH4MQf
=p3i7
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ian Jackson]

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 significantly different than
> "signed image malarkey" (to quote from another thread).

I have just looked up "malarkey" in Wiktionary and when I used that
word I didn't mean the very negative connotations I see there.  So I
apologise.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Jonas Smedegaard]

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, you do not put it in missing-source foo. You use it during the 
>> build of your package, thats the correct thing to do.
>
> This is likely to introduce Debian-only bugs. For example, on the next 
> update, the version of epoch.js is updated to add an additional file. 
> The build process is not updated and we get a Debian-only bug in the 
> application that may be hard to detect because this only happens in 
> some part of the applications.

Obviously whatever you do custom for a Debian package compared to 
upstream, you will need to ensure keep working.  If upstream does not 
provide a testsuite that you can rely on for that, you might consider 
adding appropriate tests yourself.  Simplest example I can think of 
specifically for bypassing upstream build routine is to add a rule that 
fails if an md5 checksum of files involved in said upstream build 
routine changes.


>>> that's a new information for me that we are now doing distro just 
>>> for hipsters that can't read and write more than one twitter message 
>>> at the time, and can't read a simple makefile.
>>
>> Silly, you forgot later updates to the package not done by you. There 
>> is no reason why a security team should have to learn the above 
>> steps. They should edit the source and just build the package and 
>> that should do the right thing. Not needing to dig up whatever crap 
>> may be needed for todays hip sillyscript transformation.
>
> It would be as easy for the security team to modify the unminified 
> version than the "upper" upstream version of the source.
>
> I suppose that (like me), Ondřej Surý does not want to deal with the 
> complexity of building JS from the "upper" source for the benefit of 
> people that don't exist.

There are likely no Debian users on lonely islands either.  That is not 
an acceptable reason for weakening the quality of our packages.


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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Vincent Bernat]

 ❦ 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 during the build
> of your package, thats the correct thing to do.

This is likely to introduce Debian-only bugs. For example, on the next
update, the version of epoch.js is updated to add an additional
file. The build process is not updated and we get a Debian-only bug in
the application that may be hard to detect because this only happens in
some part of the applications.

>> that's a new information for me that we are now doing distro
>> just for hipsters that can't read and write more than one twitter
>> message at the time, and can't read a simple makefile.
>
> Silly, you forgot later updates to the package not done by you. There is
> no reason why a security team should have to learn the above steps. They
> should edit the source and just build the package and that should do the
> right thing. Not needing to dig up whatever crap may be needed for
> todays hip sillyscript transformation.

It would be as easy for the security team to modify the unminified version
than the "upper" upstream version of the source.

I suppose that (like me), Ondřej Surý does not want to deal with the
complexity of building JS from the "upper" source for the benefit of
people that don't exist.
-- 
Too much is just enough.
-- Mark Twain, on whiskey


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ondřej Surý]

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 running:
> 
> > #!/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 during the build
> of your package, thats the correct thing to do.

Here you are just making things as you go. I am done with this thread,
so if you are not please bring it to tech-ctte.

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) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ben Finney]

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 made me an |
  `\   authority myself.” —Albert Einstein, 1930-09-18 |
_o__)  |
Ben Finney

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Scott Kitterman]

On October 20, 2016 7:15:45 PM EDT, Ian Jackson 
<ijack...@chiark.greenend.org.uk> 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:
>> > 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 during the
>build
>> of your package, thats the correct thing to do.
>
>I agree almost completely.  (You missed out an apostrophe.)
>
>> > that's a new information for me that we are now doing distro
>> > just for hipsters that can't read and write more than one twitter
>> > message at the time, and can't read a simple makefile.
>> 
>> [You] forgot later updates to the package not done by you. There is
>> no reason why a security team should have to learn the above steps.
>They
>> should edit the source and just build the package and that should do
>the
>> right thing.
>
>I agree - modulo your use of an insult, which I have redacted (see
>below).
>
>> Not needing to dig up whatever crap may be needed for
>> todays hip sillyscript transformation.
>
>However, I think this kind of language is is really beyond the pale at
>least for debian-devel.  If you want to rant like that please keep it
>to places where the people you are insulting are absent.
>
>I recommend bars.  (Having just got back from the pub myself, where we
>had some good times ranting about various crap.)
>
>Thanks,
>Ian.

It would be nice if the language police could give it a rest.  Personally, I 
don't see that as being significantly different than "signed image malarkey" 
(to quote from another thread).

Scott K

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ian Jackson]

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
> 
> No, you do not put it in missing-source foo. You use it during the build
> of your package, thats the correct thing to do.

I agree almost completely.  (You missed out an apostrophe.)

> > that's a new information for me that we are now doing distro
> > just for hipsters that can't read and write more than one twitter
> > message at the time, and can't read a simple makefile.
> 
> [You] forgot later updates to the package not done by you. There is
> no reason why a security team should have to learn the above steps. They
> should edit the source and just build the package and that should do the
> right thing.

I agree - modulo your use of an insult, which I have redacted (see
below).

> Not needing to dig up whatever crap may be needed for
> todays hip sillyscript transformation.

However, I think this kind of language is is really beyond the pale at
least for debian-devel.  If you want to rant like that please keep it
to places where the people you are insulting are absent.

I recommend bars.  (Having just got back from the pub myself, where we
had some good times ranting about various crap.)

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

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, 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 during the build
of your package, thats the correct thing to do.

> that's a new information for me that we are now doing distro
> just for hipsters that can't read and write more than one twitter
> message at the time, and can't read a simple makefile.

Silly, you forgot later updates to the package not done by you. There is
no reason why a security team should have to learn the above steps. They
should edit the source and just build the package and that should do the
right thing. Not needing to dig up whatever crap may be needed for
todays hip sillyscript transformation.

-- 
bye, Joerg

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Jonas Smedegaard]

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 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:
> > 
> > #!/bin/sh
> > # I absolutely new nothing about gulp, coffeescript, sass and uglify 15
> > minutes ago...
> 
> This is great.
> 
> > If you insist I can add build.sh script to the missing-source, but
> > that's a new information for me that we are now doing distro
> > just for hipsters that can't read and write more than one twitter
> > message at the time, and can't read a simple makefile.
> 
> I don't understand why we don't just put that build process in
> debian/rules.

Neither do I.  For cases this simple, that is.

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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Jonas Smedegaard]

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 consist of
> > 
> > > installing ruby-sass, coffeescript and node-uglify and running:
> > Fine.
> > 
> > Now, to get back to the original dispute whether serious or not:
> > 
> > *Not* doing above (which in some cases, as you just proved, is simple)
> > but instead relying on upstream doing it for us using tools not in
> > Debian, is a serious bug in the packaging.
> > 
> > Just as a typo in an argument to ./configure can cause FTBFS which is a
> > serious issue.
> > 
> > Severity of bugs is ortogonal to how difficult they are to fix.
> 
> Since you're claiming 'serious', which policy shall requires it?

§4.2 describes as a "must" declaring the build-dependencies needed to 
"produce working binaries".


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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ian Jackson]

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...]
> 
> 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, coffeescript, sass and uglify 15
> minutes ago...

This is great.

> If you insist I can add build.sh script to the missing-source, but
> that's a new information for me that we are now doing distro
> just for hipsters that can't read and write more than one twitter
> message at the time, and can't read a simple makefile.

I don't understand why we don't just put that build process in
debian/rules.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Scott Kitterman]

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-uglify and running:
> Fine.
> 
> Now, to get back to the original dispute whether serious or not:
> 
> *Not* doing above (which in some cases, as you just proved, is simple)
> but instead relying on upstream doing it for us using tools not in
> Debian, is a serious bug in the packaging.
> 
> Just as a typo in an argument to ./configure can cause FTBFS which is a
> serious issue.
> 
> Severity of bugs is ortogonal to how difficult they are to fix.

Since you're claiming 'serious', which policy shall requires it?

Scott K

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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Jonas Smedegaard]

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 serious or not:

*Not* doing above (which in some cases, as you just proved, is simple) 
but instead relying on upstream doing it for us using tools not in 
Debian, is a serious bug in the packaging.

Just as a typo in an argument to ./configure can cause FTBFS which is a 
serious issue.

Severity of bugs is ortogonal to how difficult they are to fix.


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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ondřej Surý]

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:

#!/bin/sh
# I absolutely new nothing about gulp, coffeescript, sass and uglify 15
minutes ago...

coffee -b -c \
src/epoch.coffee \
src/core/context.coffee \
src/core/util.coffee \
src/core/d3.coffee \
src/core/format.coffee \
src/core/chart.coffee \
src/core/css.coffee \
src/data.coffee \
src/model.coffee \
src/basic.coffee \
src/basic/*.coffee \
src/time.coffee \
src/time/*.coffee \
src/adapters.coffee \
src/adapters/*.coffee

cat \
src/epoch.js \
src/core/context.js \
src/core/util.js \
src/core/d3.js \
src/core/format.js \
src/core/chart.js \
src/core/css.js \
src/data.js \
src/model.js \
src/basic.js \
src/basic/*.js \
src/time.js \
src/time/*.js \
src/adapters.js \
src/adapters/*.js \
> dist/js/epoch.js

uglifyjs dist/js/epoch.js > dist/js/epoch.min.js

sass -t compact sass/epoch.scss > dist/css/epoch.css
sass -t compressed sass/epoch.scss > dist/css/epoch.css

If you insist I can add build.sh script to the missing-source, but
that's a new information for me that we are now doing distro
just for hipsters that can't read and write more than one twitter
message at the time, and can't read a simple makefile.

Cheers,
-- 
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) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Thu, Oct 20, 2016, at 11:17, Bas Wijnen wrote:
> -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 options would be to package make, or to
> change the build system so it works without it.
> 
> It doesn't matter if the tool is complex.  If it's used and it isn't in
> main,
> the program cannot be in main.
> 
> (And "I don't use it, because upstream did it for me" means you're not
> building
> from source, which is a problem itself.)
> 
> Thanks,
> Bas
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBAgAGBQJYCIusAAoJEJzRfVgHwHE68wgP/2zsqzThuWkOCRSnXBrcuk40
> jm/dp67lSfVfNuCF/767SyGPknBoEcBlHkM08dbIx6rhG9ZdJ9FmWhl8a6eAQQeB
> jo4UQE3rSGhtfw7zxl8K39inQnpv+HyotOEZ6JWXzoUf+997uknAsB5OYHr2obZn
> 9tlg/oaMoHfCX/oXZU6sqL2yFeDhomO/zOf0rbhdWcBYwRSdTHkU+UtrkronqHjM
> afFk0mt8y+c/PNQvs1NVpLSaLTEwoIYJCqxDywlnEkGw3gNXGmthM768bK7sVM/o
> fZH9B0f2jDj5+2zyN/GcjxZw6aYD8ckyCZT90jpfA5wcUsPbYxOjo9iyxp9acFSr
> D02upguz1tVJn4ksJvzX/hYVecKnO/8VdqPWTh75Kse3Pmsip/17S/+ICoII8rT5
> +yzzUJF1NRh6Uuxs2tP5a6QLLBdecZ4l17SYrHNoOAevGFCcLHYNH+Dyn0AAoAxG
> TtwTnFxFQx31Is5Gh3KWWO43ooMA42svCDMrcx3N1cOGrPpHS5RfU2BeFa1kkMUx
> YR5gU4M+tt1D7HQ73hEm73pu56h23DLdv7QL4FjP+xlHUNF29c5G4dPYyQD8tNcW
> 7nRZP78n2pxdO7Xbi0HNzTbEyrhPmwT6cj9mCUzPJCQEsRKCM2v/kSLz7RGgSw3H
> nHusejCreSzSKL7EL8Mq
> =7iSp
> -END PGP SIGNATURE-
> 

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-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 options would be to package make, or to
change the build system so it works without it.

It doesn't matter if the tool is complex.  If it's used and it isn't in main,
the program cannot be in main.

(And "I don't use it, because upstream did it for me" means you're not building
from source, which is a problem itself.)

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYCIusAAoJEJzRfVgHwHE68wgP/2zsqzThuWkOCRSnXBrcuk40
jm/dp67lSfVfNuCF/767SyGPknBoEcBlHkM08dbIx6rhG9ZdJ9FmWhl8a6eAQQeB
jo4UQE3rSGhtfw7zxl8K39inQnpv+HyotOEZ6JWXzoUf+997uknAsB5OYHr2obZn
9tlg/oaMoHfCX/oXZU6sqL2yFeDhomO/zOf0rbhdWcBYwRSdTHkU+UtrkronqHjM
afFk0mt8y+c/PNQvs1NVpLSaLTEwoIYJCqxDywlnEkGw3gNXGmthM768bK7sVM/o
fZH9B0f2jDj5+2zyN/GcjxZw6aYD8ckyCZT90jpfA5wcUsPbYxOjo9iyxp9acFSr
D02upguz1tVJn4ksJvzX/hYVecKnO/8VdqPWTh75Kse3Pmsip/17S/+ICoII8rT5
+yzzUJF1NRh6Uuxs2tP5a6QLLBdecZ4l17SYrHNoOAevGFCcLHYNH+Dyn0AAoAxG
TtwTnFxFQx31Is5Gh3KWWO43ooMA42svCDMrcx3N1cOGrPpHS5RfU2BeFa1kkMUx
YR5gU4M+tt1D7HQ73hEm73pu56h23DLdv7QL4FjP+xlHUNF29c5G4dPYyQD8tNcW
7nRZP78n2pxdO7Xbi0HNzTbEyrhPmwT6cj9mCUzPJCQEsRKCM2v/kSLz7RGgSw3H
nHusejCreSzSKL7EL8Mq
=7iSp
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Vincent Bernat]

 ❦ 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 you don't ever
>> check this.
>
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

This is exactly not the situation you describe above as gulp is just a
glorified make and doesn't compile anything on its own. As I said
previously, in the case of knot-resolver-module-http, the "compile" tool
is coffeescript and sassc/ruby-sass. Both of them are in main.

I am happy you said a few posts ago that you didn't want to challenge
the line, otherwise I would have thought that your goal was just to make
the life of some maintainers miserable.
-- 
Writing is turning one's worst moments into money.
-- J.P. Donleavy


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

>> 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 it, e.g.
> bison-priscus, and I don't want to package it for Debian?

Seriously, the question in this thread? Where the initial mail is the
answer of the question?

>> > If I don't even check that bison actually can process the file, would
>> > it still be OK?
>> No.
>> You as the maintainer have to guarantee that the file is buildable with
>> tools available in main. You can't if you don't ever check this.
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

Yes, thats what contrib is for. "require stuff outside main to build or
function".

-- 
bye, Joerg

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Niels Thykier]

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.2~bpo8+1 is as of today in backports-new.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-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/, 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 it, e.g.
> bison-priscus, and I don't want to package it for Debian?

Then the build tool is not in Debian, which means that the program can be in
contrib, but not in main.

> > > If I don't even check that bison actually can process the file, would
> > > it still be OK?
> >
> > No.
> > You as the maintainer have to guarantee that the file is buildable with
> > tools available in main. You can't if you don't ever check this.
> 
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

Yes, until the build tool is packaged (or replaced by something that is
packaged, such as cat) that is true.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYALUsAAoJEJzRfVgHwHE6pPgP+wQQwLEQWvQMYcJt9OmEpss/
JdZ4buIe3TsBipIk1yJh9n6YpkWxsPd8tkwfISbNedW4Cy2AsZe8T7lktI4G6jqr
XeDsGUtu8IIU5V6s3LRQX/0eurN9jKuUVhoY0V4LgHTC4MwPR8mFmZ9a9PicWZNx
C16N453qwiuM7fT5xpsssIzcpF30jrxQj+oNRpyonavu2k0q8n790cvz4pWHjNe0
Kzq1soPOGgcftOR6PXHL+ypPma6KUN2IaXyGkZB6QPXiYsiJWKN/xKom+/UzkiXd
G6B4D1J0jLk3PX2mvTd7nzJY+U5S1Jn8z5s9Z5/5BhOd94ZxjH2RlBHwv8Y/PBTe
tp+ZLpo0obIkkgWh8a6IxkmsHmpYF++Zz6wa21UYx0Rr0emAmfkl22cIlDByLUpp
XhfAuxG6DtDffV686otrSjNagx5PTr8E3aZFqCXMbaeD2zMQFN/auS14HYH/jRDN
IJWl30s2zjIiyVCHgOl6WZXGTwJbGeKYka60lo13RXRaLS3pICYRybJYykY39+Qi
EV78FKBjx+jO9e1exw8A/CTj6mI2zXjnEmIURKIaxS6lUyF8icPK91WBdh4OxV56
P66OriG7s+Lz1TcLFP6LG6y3+hW/8eLJytav0MFQV6Y67aZG/hztJPG56aGYKKGw
7+V7MkoG0YptzSPaW9HH
=C/8Z
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[W. Martin Borgert]

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 say I need a special tool to compile it, e.g.
bison-priscus, and I don't want to package it for Debian?

> > If I don't even check that bison actually can process the file, would
> > it still be OK?
>
> No.
> You as the maintainer have to guarantee that the file is buildable with
> tools available in main. You can't if you don't ever check this.

IIUC, this is exactly the situation of epoch.js in
knot-resolver-module-http. I assume, it has not been build from
its original *.coffee sources, because the make tool (gulp) is
not in Debian. So the package must go into contrib?

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

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

> If I don't even check that bison actually can process the file, would
> it still be OK?

No.
You as the maintainer have to guarantee that the file is buildable with
tools available in main. You can't if you don't ever check this.

> 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 them from main, however, because maintainers
> can just add the missing sources in the way they like.

If they don't then there sure is a reason to eject it from main.

-- 
bye, Joerg
http://meta.wikimedia.org/wiki/How_to_win_an_argument

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Christian Seiler]

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
> requirement. Is this not the case any more?

 This has never been the case. Since the beginning, there was no
 requirements to regenerate autoconf stuff.
>>>
>>> I personally see auto* more critical than minified JS.
>>> The chance that it is impossible to rebuild is higher :~)
>>>
>>> Quoting https://wiki.debian.org/Autoreconf:
>>> "Autoreconfing on build is good practice in Debian."
>>> Not required, but recommended.
>>>
>>> [...]
>>>
>>
>> Personally, I am hoping we will soon reach critical mass on
>> "autoreconf'ing" and will be able to flip the "Not required" to "Required".
>>   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.

I just backported a compat 10 package to Jessie (open-isns), the
debhelper version in backports already supports that. The only
thing I'd like to see is to have the current debhelper in testing
be backported, so that I don't have to change the B-D from
debhelper (>= 10~) to debhelper (>= 9.20160403~) anymore and can
simply do a no-change backport.

Only people wanting to backport to wheezy-backports-sloppy can't
use compat 10. (But they can still use dh-autoreconf explicitly
together with a lower compat.)

Regards,
Christian

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Mike Hommey]

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 more?
> >>
> >> This has never been the case. Since the beginning, there was no
> >> requirements to regenerate autoconf stuff.
> > 
> > I personally see auto* more critical than minified JS.
> > The chance that it is impossible to rebuild is higher :~)
> > 
> > Quoting https://wiki.debian.org/Autoreconf:
> > "Autoreconfing on build is good practice in Debian."
> > Not required, but recommended.
> > 
> > [...]
> > 
> 
> Personally, I am hoping we will soon reach critical mass on
> "autoreconf'ing" and will be able to flip the "Not required" to "Required".
>   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

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Vincent Bernat]

 ❦ 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 run yacc and regenerate the
file, I think it won't be OK. Of course, I have no real say in the
matter.
-- 
Big book, big bore.
-- Callimachus


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Niels Thykier]

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 no
>> requirements to regenerate autoconf stuff.
> 
> I personally see auto* more critical than minified JS.
> The chance that it is impossible to rebuild is higher :~)
> 
> Quoting https://wiki.debian.org/Autoreconf:
> "Autoreconfing on build is good practice in Debian."
> Not required, but recommended.
> 
> [...]
> 

Personally, I am hoping we will soon reach critical mass on
"autoreconf'ing" and will be able to flip the "Not required" to "Required".
  This should happen on its own as people convert their packages to
debhelper compat 10.

Thanks,
~Niels

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

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 way to know.

> Do you know of another way which provides that level of confidence that
> we in fact have the complete corresponding source for a work, and that
> this remains true as the source package changes over time?

(Reproducible) builds from source (with continuous rechecking) is the
only way to have enough confidence that a Debian user has the freedoms
promised to them by the Debian social contract.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ben Finney]

"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 them from main, however, because maintainers can just
> add the missing sources in the way they like.

How will we know that those are the corresponding source for the work
Debian installs?

One way is to actually use that exact source, to build the package.

Do you know of another way which provides that level of confidence that
we in fact have the complete corresponding source for a work, and that
this remains true as the source package changes over time?

-- 
 \   “Know what I hate most? Rhetorical questions.” —Henry N. Camp |
  `\   |
_o__)  |
Ben Finney

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[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 no
> requirements to regenerate autoconf stuff.

I personally see auto* more critical than minified JS.
The chance that it is impossible to rebuild is higher :~)

Quoting https://wiki.debian.org/Autoreconf:
"Autoreconfing on build is good practice in Debian."
Not required, but recommended.

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

> and eject a lot of packages from main while DFSG#2 is correctly
> met.

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 them from main, however, because maintainers
can just add the missing sources in the way they like.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-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, but because it is pretty much impossible to
prove that the binary was indeed compiled with a compiler in Debian and from
the provided source, it is probably rejected unless the packager has a good
reason for doing it this way.

By the way, that isn't impossible: xburst-tools contains a boot loader for a
mips device, which is included as binary in the package.  On everything except
mips a cross compiler would be required to build it.  Those haven't been in
Debian for a long time (but I think they are now), so shipping a binary that
could only be rebuilt on mips is acceptable in such a case.  But note that the
compiler _is_ in Debian; it may just not be usable on every arch.

> > 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
> > met.
> 
> It is really not in my plans to challenge that line. It is just that I
> would like to understand the rules properly.

It's not about DFSG#2.  Packages in contrib _do_ meet the entire DFSG, but
require or recommend a non-free component for some major functionality.  We
require packages to be buildable from source, so if they require packages
outside of main for that, they cannot be in main themselves.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX/qM6AAoJEJzRfVgHwHE6mA8P+gNPxycBMWPKCgV7N+hHSB60
2J+HDvLG40d4+YL7japyWIzovY7senVobl5Dz4IfjEqJovbkgprXLRxK3OqTn2EQ
pOk9ca2MM8IpYCvOGPfPVulDt2JYgalcj76kxYIzrIJnTAuylvohrz2R0kFIG4sQ
IkhSJxhOj4MlocRMrS6tWSDnJ6BbvXZRFiLtYdwEax4Hm/EsJHQlFkTZqJemetZ+
sQ/OKOC21Cv9HNC1I9Om4oKJnxX06yb1VGxWLP5qCZk8/skwZurJlG4LqnCzf5/H
cKTQeVnalWFo3HuFmFOAfZPeFMxmfIrK91vCkzynFKapqz3tN7yMilFk0Asr8bfH
Gjvq6q2SBoKUl2HPgm9de33TOUPkDsM9jQJz/JeDUpY2uwUsqqZHphIJvW0VsdfB
UCfaSlRpTgvh8axjVW3hWvKaQ1dgLwctedcIWRDzgdndFm8dYhKQOHimVVyVXji4
C8xZYoCGC32sODhW8slBBypx/3jBMN5XOUSCRN1lPzS6A/PERckFp7XQFG8sp4Qs
VFE80QUBRigW0XXgmzSvWozrUf492FnVXBOb/t1YDNptTNDiGeUJl6d+yn6FVF6m
k/aDJv5Epxi0IIhvXrXUEjTMeQxtMed6xl+jjfVO0dVGpf/y094SkOjSOoQRLRvi
dFNMwAFWlQhfv7SsBVhl
=Lk3u
-END PGP SIGNATURE-

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Martín Ferrari]

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

It is really not in my plans to challenge that line. It is just that I
would like to understand the rules properly.

I prefer not to play Mao while packaging :-)

-- 
Martín Ferrari (Tincho)

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Vincent Bernat]

 ❦ 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 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.
>
> 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 regenerate autoconf stuff.

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

>> It remains the originally reported problem, that the sources
>> (*.coffee and *.scss) are not under debian/missing-sources/.
>> Probably a normal bug, not serious nor wishlist.
>
> I have never heard of debian/missing-sources. What is the
> policy/documentation regarding this? I have repackaged tarballs many
> times to add missing sources, I did not think there was another way to
> do it!

Source packages are considered as a whole. So, it is possible to put the
sources in the debian/ directory instead of in orig.tar.gz. Repack is
only needed if you want to remove stuff.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

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

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?


On 11/10/16 23:04, W. Martin Borgert wrote:
> It remains the originally reported problem, that the sources
> (*.coffee and *.scss) are not under debian/missing-sources/.
> Probably a normal bug, not serious nor wishlist.

I have never heard of debian/missing-sources. What is the
policy/documentation regarding this? I have repackaged tarballs many
times to add missing sources, I did not think there was another way to
do it!


Thanks.
-- 
Martín Ferrari (Tincho)

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[W. Martin Borgert]

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 buildable
from source without actually trying, this is an issue we should
not discuss in this bug report.)

It remains the originally reported problem, that the sources
(*.coffee and *.scss) are not under debian/missing-sources/.
Probably a normal bug, not serious nor wishlist.

Btw., the gulp build tool used by upstream to compile epoch is
not in Debian. In the case of epoch gulp could be emulated
easily by cat, I assume :~)

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Vincent Bernat]

 ❦ 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 from tools in main (aka
coffeescript compiler, sass compiler, cat + uglifyjs). There is no hard
requirement to rebuild from source when building the package.
-- 
The human race is a race of cowards; and I am not only marching in that
procession but carrying a banner.
-- Mark Twain


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

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 that source must be buildable on Debian and the latest mail
from them just reiterates that and states that yes, this does apply to
everything, including JavaScript.

https://lists.debian.org/debian-devel/2016/10/msg00138.html

> Just don't make me maintain a package in
> a language more horrible than PHP (in my eyes :-P).

Some day browsers will support WebAssembly so you can write in any
language that can compile to that. I'm sure people will start writing
web front-end code in PHP once it gets an LLVM backend ;P

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ondřej Surý]

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) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Tue, Oct 11, 2016, at 14:41, Paul Wise wrote:
> 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/epoch.js
> 
> These are not the source, these are:
> 
> https://github.com/epochjs/epoch/tree/master/sass/**.scss
> https://github.com/epochjs/epoch/tree/master/src/**.coffee
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

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 packaging of gulp. Once that is done
there are a number of gulp plugins to be packaged.

https://github.com/epochjs/epoch/
https://github.com/epochjs/epoch/blob/master/gulpfile.js
https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Paul Wise]

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/epoch.js

These are not the source, these are:

https://github.com/epochjs/epoch/tree/master/sass/**.scss
https://github.com/epochjs/epoch/tree/master/src/**.coffee

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Ondřej Surý]

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 epoch.js into separate package and I'll
switch to using it, just don't shove more work by using BTS severities.

Cheers,
-- 
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) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Tue, Oct 11, 2016, at 12:33, W. Martin Borgert wrote:
> 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.)
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel