Re: What can Debian do to provide complex applications to its users?

[Michael Meskes]

> Michael Meskes dijo [Sat, Feb 17, 2018 at 01:57:53PM +0100]:
> > I disagree, it is not maintainable source code, yes, but source
> > code
> > nonetheless. According to wikipedia source code is:
> > ...
> 
> Some others have answered to this claim. As I understand it, source
> code should ideally be the author's preferred form of
> modification. That is clearly different from what a minified
> representation is.
> ...

It's amazing how my email seems to have been understood differs from
what I wanted to say. I thought it was clear from the "not
maintainable" part that I did not suggest we use minified source as
source code. I was merely pointing out that it technically still was
source code in the sense that the same compiler/interpreter yields the
same result with the minified code as with the original one.

For all practical manners this is irrelevant.


> > I get your point, I just don't accept the consequence that we
> > should
> > not package these applications.
> 
> Well, try to find somebody with time and motivation to _properly_ do
> the packaging, and to keep it up for several years...

I absolutely agree with you that it does not work with our current way
of packaging, but that's what this discussion about. IMO it would be
great if we found a way to offer these applications to our users.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

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

Re: What can Debian do to provide complex applications to its users?

[Paul Wise]

On Sun, Feb 18, 2018 at 2:59 AM, Thorsten Alteholz wrote:

> Other javascript libraries like libjs-* and *.js even don't get a CVE. So
> either they are secure or nobody cares.

We also miss out on some JS vulnerabilities because NodeSecurity don't
systematically participate in the CVE system and we don't
systematically import their issues.

https://nodesecurity.io/advisories

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: What can Debian do to provide complex applications to its users?

[Paul Wise]

On Sat, Feb 17, 2018 at 9:20 PM, Paul Wise wrote:

> It may be code but it is definitely not source in the sense of DFSG
> item 2 or the GPL.

Also, non-minified JavaScript can also not be source code, for example
in the case it was generated from CoffeeScript or some other language.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

回覆： What can Debian do to provide complex applications to its users?

[David Zhan]

  原始訊息  
寄件者： Colin Watson
已傳送： Sonntag, 18. Februar 2018 10:15
收件者： debian-devel@lists.debian.org
主旨： Re: What can Debian do to provide complex applications to its users?

On Sat, Feb 17, 2018 at 07:22:05PM +0100, Tollef Fog Heen wrote:
> I think there's at least two types of vendoring you're referring to
> here, and they're substantially different.
> 
> One is how Go currently does (but my understanding is that this is
> changing in newer versions). Here, the source code of dependencies are
> shipped together with the source code for the application. This leads
> to trees like
> https://github.com/kubernetes/kubernetes/tree/master/vendor where any
> one of those dependencies might be a released version or tag, or it
> might just be a random git snapshot, and there's not really any way to
> know.
> 
> The other (you refer to this as freezing dependencies) is how
> Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
> does it. In those cases, you have some file specifying the versions of
> libraries the application needs, usually as «this version of this
> gem/crate/package» and there is somewhere those packages live by
> default. Quite often, there's also a lock file of some sort which lists
> out the exact versions used, recursively, which ensures you can deploy
> the exact same code multiple times.
> 
> The second method means you can reason about what versions of code are
> included where.

This is an excellent point. (In fact, I think you can do some of that
reasoning for the first method too; it's just going to take more effort.
For example, you could run "govendor sync" or whatever and check that
the output tree actually matches what's promised. In some ways this is
similar to the question of "is this package's .orig.tar actually the
version it claims to be?".)

It's worth remembering that this isn't just some lazy upstreams not
getting round to keeping their dependencies up to date:

* Often they need newer versions of dependencies than are in Debian
stable, because retaining compatibility back to whatever version we
shipped for a half-million-line web application and actually testing
the result is a combinatorially-hard problem.

* Often the existence of packaged web applications in Debian itself
makes it harder to upgrade the libraries they depend on. Take
Django, for instance: it has really remarkably good documentation of
what you need to do to upgrade an application to a newer version and
a very clear deprecation policy, but you still have to do it and
keeping your application compatible with more than two or three
Django versions (by which I mean 1.8, 1.9, 1.10, etc.) before the
newest one you support is likely to be pretty painful. Now package
half a dozen Django applications and suddenly the library package
maintainers have a heck of a time keeping everything working. [1]

* And yes, sometimes an upstream can end up with out-of-date
dependencies that are going to take significant effort to resolve,
but there's something to be said for making it possible to shift the
upgrade effort to a time when it's convenient to do so, even though
there's obviously a trade-off with the possibility that you might end
up putting it off indefinitely. Not to mention that if they did
upgrade their dependencies, they might end up being incompatible with
the versions in Debian stable, and as it is that doesn't help our
users of packaged applications very much either. The lockstep
problem is really nasty.

* Packaging individual libraries that aren't especially useful on the
client side can be pretty boring work and is often not very socially
valued (the people trying to deal with JavaScript dependencies in
Debian have taken a lot of flak, for instance).

And yet ... it can be really nice to have some of these things packaged
in a common format. I know roughly nothing about PHP, and I don't want
to have to learn yet another packaging stack or another upstream's
favourite container technology, so it's great that Icinga Web 2 is
packaged so that I can just install it without having to learn that. I
want it to be as easy as possible for the security team and the people
who care about it to keep it up to date. For the case where something
depends on OpenSSL, it's mostly pretty obvious where the trade-offs lie.
For the case where something depends on 80 npm libraries and a security
update to the application might require updating 10 of those and maybe
breaking some other packaged application in the process, it's not so
clear that it even serves our developers let alone our users.

[1] Disclaimer: I only do in-house development at work of Django
applications that aren't packaged in Debian, and I'm not involved in
Django's Debian maintenance, so this is an outside view and I may
have some details wrong.

> You might still have to patch five versions of libvulnerable, but at
> least it's possible to find which five versions are in use, and get
> those fixed in a central place and then rebuild everyt

Re: Suddenly U2F doesn't work on sid

[Hideki Yamane]

Hi,

On Sat, 17 Feb 2018 13:10:50 -0500
Robert Edmonds  wrote:
> I ran into the same problem. It looks like it was due to #889665 being
> fixed and not having the libu2f-udev package installed.

 This fixes the problem, thanks Robert!


On Sat, 17 Feb 2018 19:32:09 +0100
Bastian Blank  wrote:
> And chromium does not recommends that at all.

 Really? What's wrong with it, I'm curious.
 And hope Firefox also supports U2F in the future.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: What can Debian do to provide complex applications to its users?

[Colin Watson]

On Sat, Feb 17, 2018 at 07:22:05PM +0100, Tollef Fog Heen wrote:
> I think there's at least two types of vendoring you're referring to
> here, and they're substantially different.
> 
> One is how Go currently does (but my understanding is that this is
> changing in newer versions).  Here, the source code of dependencies are
> shipped together with the source code for the application.  This leads
> to trees like
> https://github.com/kubernetes/kubernetes/tree/master/vendor where any
> one of those dependencies might be a released version or tag, or it
> might just be a random git snapshot, and there's not really any way to
> know.
> 
> The other (you refer to this as freezing dependencies) is how
> Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
> does it.  In those cases, you have some file specifying the versions of
> libraries the application needs, usually as «this version of this
> gem/crate/package» and there is somewhere those packages live by
> default.  Quite often, there's also a lock file of some sort which lists
> out the exact versions used, recursively, which ensures you can deploy
> the exact same code multiple times.
> 
> The second method means you can reason about what versions of code are
> included where.

This is an excellent point.  (In fact, I think you can do some of that
reasoning for the first method too; it's just going to take more effort.
For example, you could run "govendor sync" or whatever and check that
the output tree actually matches what's promised.  In some ways this is
similar to the question of "is this package's .orig.tar actually the
version it claims to be?".)

It's worth remembering that this isn't just some lazy upstreams not
getting round to keeping their dependencies up to date:

 * Often they need newer versions of dependencies than are in Debian
   stable, because retaining compatibility back to whatever version we
   shipped for a half-million-line web application and actually testing
   the result is a combinatorially-hard problem.

 * Often the existence of packaged web applications in Debian itself
   makes it harder to upgrade the libraries they depend on.  Take
   Django, for instance: it has really remarkably good documentation of
   what you need to do to upgrade an application to a newer version and
   a very clear deprecation policy, but you still have to do it and
   keeping your application compatible with more than two or three
   Django versions (by which I mean 1.8, 1.9, 1.10, etc.) before the
   newest one you support is likely to be pretty painful.  Now package
   half a dozen Django applications and suddenly the library package
   maintainers have a heck of a time keeping everything working. [1]

 * And yes, sometimes an upstream can end up with out-of-date
   dependencies that are going to take significant effort to resolve,
   but there's something to be said for making it possible to shift the
   upgrade effort to a time when it's convenient to do so, even though
   there's obviously a trade-off with the possibility that you might end
   up putting it off indefinitely.  Not to mention that if they did
   upgrade their dependencies, they might end up being incompatible with
   the versions in Debian stable, and as it is that doesn't help our
   users of packaged applications very much either.  The lockstep
   problem is really nasty.

 * Packaging individual libraries that aren't especially useful on the
   client side can be pretty boring work and is often not very socially
   valued (the people trying to deal with JavaScript dependencies in
   Debian have taken a lot of flak, for instance).

And yet ... it can be really nice to have some of these things packaged
in a common format.  I know roughly nothing about PHP, and I don't want
to have to learn yet another packaging stack or another upstream's
favourite container technology, so it's great that Icinga Web 2 is
packaged so that I can just install it without having to learn that.  I
want it to be as easy as possible for the security team and the people
who care about it to keep it up to date.  For the case where something
depends on OpenSSL, it's mostly pretty obvious where the trade-offs lie.
For the case where something depends on 80 npm libraries and a security
update to the application might require updating 10 of those and maybe
breaking some other packaged application in the process, it's not so
clear that it even serves our developers let alone our users.

[1] Disclaimer: I only do in-house development at work of Django
applications that aren't packaged in Debian, and I'm not involved in
Django's Debian maintenance, so this is an outside view and I may
have some details wrong.

> You might still have to patch five versions of libvulnerable, but at
> least it's possible to find which five versions are in use, and get
> those fixed in a central place and then rebuild everything that's
> vulnerable, recursively.  Not the most fun job in the world,

Re: What can Debian do to provide complex applications to its users?

[Andreas Tille]

On Sat, Feb 17, 2018 at 10:32:09AM -0700, Sean Whitton wrote:
> > So if you are claiming we have no manpower that's pretty much our own
> > fault since we do not actively care.  There are ways to attract gifted
> > and interested people if we would only try.
> 
> I was making a more specific claim -- we don't and will never have the
> manpower to provide security support for multiple different versions of
> hundreds of little JavaScript libraries.

I agree that guessing from past experience chances are good that your
statement is true.  But my claim was that we do not even try to find the
according manpower (for several urgent jobs that need to be done).
 
> I don't doubt that we could have far more volunteers for other work if
> we made it easier to get involved.

So it would be good to try. :-)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Repackaging upstream source with file modifications?

[Colin Watson]

On Mon, Feb 12, 2018 at 10:28:33AM +, Colin Watson wrote:
> Does this seem like a reasonable way forward, or should I instead just
> apply the backport as an ordinary patch and override
> license-problem-non-free-RFC for the patch file?

Thanks for the feedback, everyone.  While I do like Raphaël's automated
replacement approach, I kind of want to have to write and test as little
code as possible, and the fact that there are tools that already support
the simple Files-Excluded approach is appealing; plus most people seem
to prefer the latter.  So, despite the fact that it's a little more work
to manage in git, I've gone with a grub2_2.02+dfsg1.orig.tar.xz that
simply removes the encumbered files, and inserted an initial patch with
replacement implementations.

Hopefully my upstream patch will be accepted so that this is irrelevant
for later versions!

-- 
Colin Watson   [cjwat...@debian.org]

Re: What can Debian do to provide complex applications to its users?

[Colin Watson]

On Sat, Feb 17, 2018 at 08:42:44PM +0100, Adam Borowski wrote:
> Binary code that has debug symbols isn't that bad.  I don't think you can
> have those for minified JS.

JavaScript source maps have been around for a few years and AIUI are
pretty much exactly that.

-- 
Colin Watson   [cjwat...@debian.org]

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Michael Meskes dijo [Sat, Feb 17, 2018 at 01:57:53PM +0100]:
> > Minification is quite comparable to compilation. I will give you some
> > examples from my frustration with Drupal8 in this answer. This can no
> > longer be seen as source code:
> > ...
> 
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
> 
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.
> 
> I guess minified source code does qualify. However, this discussion is
> mood since the bigger lies in the modules that get included without any
> real documentation.

Some others have answered to this claim. As I understand it, source
code should ideally be the author's preferred form of
modification. That is clearly different from what a minified
representation is.

Even adjusting this a bit... Maybe not a preferred form of
modification, but a plausible form for performing support? Well, even
leaving the obvious change from a readable, indented set of
instructions to a single line with no comments nor anything to aid
humans to understand it, it also does not cut the bill. Minification
preserves function (and thus, calls to the stdlib and such are
discernible), but function and variable names are mangled. That is a
_huge_ obstacle for being able to fix anything but the most trivial
details. Of course, we cannot push our patches upstream.

> > But packaging the precise version that is required in each little
> > bump
> > is just impossible.
> 
> I get your point, I just don't accept the consequence that we should
> not package these applications.

Well, try to find somebody with time and motivation to _properly_ do
the packaging, and to keep it up for several years...


signature.asc
Description: PGP signature

Bug#890710: node-date-time write the Debian package description

[kurianbkk]

Package: wnpp
Severity: wishlist
Owner: Kurian Benoy 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-date-time
  Version : 2.1.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/date-time#readme
* License : Expat
  Programming Lang: JavaScript
  Description : A pretty way to print the time

date-time is an awesome date time library to print time . This is a npm5 
package which I was metored by Mr Praveen

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: Updating the Maintainer field in preparation for Alioth's shutdown?

[Andreas Tille]

Hi Raphael,

On Sat, Feb 17, 2018 at 08:36:41PM +0100, Raphael Hertzog wrote:
> > A mailing list is not just helpful to distribute e-mails to certain
> > people.  The mail archive feature is a very valuable thing to refer to
> > previous mails which as far as I understand is not provided by
> > tracker.d.o.  That's why I do not consider tracker.d.o as a full
> > replacement.
> 
> I know this, but this specific sub-thread was for the case if the team
> has gotten a list on lists.debian.org (so with public archives already).
> Using the tracker team for automated mail only is fine. 

I have something like ftpmaster REJECT mails in mind.  This is not
really automated and perfectly belongs to the maintainers list.  What is
your opinion about this kind of mails (and its responsed).
 
> And we can consider adding a mail archive to the tracker, it's a matter
> of someone putting the required work mainly. formorer even wanted us to
> have a GSOC on integrating the package tracker with hyperkitty to add such
> a mail archive. Unfortunately I don't have the time to play mentor for the
> GSOC.

I like that idea but I just registered a different GSoC project.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#890709: ITP: node-stream-iterate -- Iterate through the values in a stream

[nirmalkv]

Package: wnpp
Severity: wishlist
Owner: NIRMAL K V 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : node-stream-iterate
 Version : 1.2.0
 Upstream Author : Mathias Buus (@mafintosh)
* URL : https://github.com/mafintosh/stream-iterate
* License : Expat
 Programming Lang: JavaScript
 Description : Iterate through the values in a stream

 stream-iterate module recursively iterate through each item in the stream.
 stream is a user defined list of objects. This module can be used to implement
 things like a streaming merge sort.
 .
 Node.js is an event-based server-side JavaScript engine. This package is a
 a dependency of NPM 5.6
 .
 I would like to consistently maintain this package in debian as a part
 of javascript maintainers team. Pirate praveen has agreed to sponser
 this package.

Bug#890706: ITP: node-ansi-wrap -- Create ansi colors by passing the open and close codes

[Arjun Lal]

Package: wnpp
Severity: wishlist
Owner: ARJUN LAL 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-ansi-wrap
  Version : 0.1.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/ansi-wrap
* License : Expat
  Programming Lang: JavaScript
  Description : Create ansi colors by passing the open and close codes

 This package helps to easily create colors by passing the open and close
codes
 for your required ansi color. This package is used in a lot of projects
like a
 nsi-reset, ansi-bold, ansi-dim, ansi-strikethrough, ansi-cyan to name a
few.
 .
 Node.js is an event-based server-side JavaScript engine.

 Many other packages (like ansi-reset, ansi-strikethrough, ansi-inverse,
ansi-ma
 genta to name a few) depend on this package. No such package already
exists.

 This package is a useful dependency of NPM 5.6.

 I am planning to maintain this package as part of the javascript
maintainers
 team.

 Pirate Praveen has agreed to sponsor this package.

Bug#890705: ITP: node-binaryextensions -- Array of binary file extensions

[Sreeraj Menon]

Package: wnpp
Severity: wishlist
Owner: SREERAJ R MENON 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-binaryextensions
  Version : 2.1.1
  Upstream Author : 2013+ Bevry Pty Ltd  (http://bevry.me)
* URL : https://github.com/bevry/binaryextensions
* License : Expat
  Programming Lang: JavaScript
  Description : Array of binary file extentions

 A package that contains an array of every single file extension
 there is for binary files

 .
 Node.js is an event-based server-side JavaScript engine.

 This package is a dependency for NPM 5.

 I plan to maintain this package as part of a javascript maintainers
 team and Pirate Praveen has agreed to be my sponsor.

Re: What can Debian do to provide complex applications to its users?

[Adam Borowski]

On Sat, Feb 17, 2018 at 01:24:30PM -0500, Sergio Durigan Junior wrote:
> On Saturday, February 17 2018, Michael Meskes wrote:
> > I disagree, it is not maintainable source code, yes, but source code
> > nonetheless. According to wikipedia source code is:
> >
> > In computing, source code is any collection of computer instructions,
> > possibly with comments, written using[1] a human-readable programming
> > language, usually as plain text.
> 
> You can disagree, but you still can't edit and maintain the minified JS.
> This is basically what is expected from a source code (and it doesn't
> really matter whether Wikipedia's definition is different).  If you've
> had to deal with minified JS, then you know it's the same as dealing
> with binary code.

Binary code that has debug symbols isn't that bad.  I don't think you can
have those for minified JS.

(I can read adequately only x86 assembly, but reading other archs isn't
a rare skill.)


-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Bug#890702: ITP: node-module-not-found-error -- Generate a module_not_found_error

[peacerebel]

Package: wnpp
Severity: wishlist
Owner: Bipin B Narayan 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-module-not-found-error
   Version : 1.0.1
   Upstream Author : Ben Drucker  (bendrucker.me)
* URL : https://github.com/bendrucker/module-not-found-error
* License : Expat
   Programming Lang: JavaScript
   Description : Generate a module_not_found error
    Returns an error with the appropriate message and code, if a
    module name or path passed to 'require' is not found.
    .
    Node.js is an event-based server-side JavaScript engine.

Re: Updating the Maintainer field in preparation for Alioth's shutdown?

[Raphael Hertzog]

Hi,

On Sat, 17 Feb 2018, Andreas Tille wrote:
> On Fri, Feb 16, 2018 at 02:10:30PM +0100, Raphael Hertzog wrote:
> > On Fri, 19 Jan 2018, Jeremy Bicha wrote:
> > > 3. If a team manages to get a lists.debian.org address, it's
> > > recommended that they switch the Maintainer fields in their packages
> > > from the Alioth list address to that address, right?
> > 
> > It depends on your choice. But I would not recommend this. I would largely
> > prefer if teams relied on tracker.debian.org to get all the automated
> > mails, that way lists on lists.debian.org contain only generic
> > discussions.
> 
> A mailing list is not just helpful to distribute e-mails to certain
> people.  The mail archive feature is a very valuable thing to refer to
> previous mails which as far as I understand is not provided by
> tracker.d.o.  That's why I do not consider tracker.d.o as a full
> replacement.

I know this, but this specific sub-thread was for the case if the team
has gotten a list on lists.debian.org (so with public archives already).
Using the tracker team for automated mail only is fine. 

And we can consider adding a mail archive to the tracker, it's a matter
of someone putting the required work mainly. formorer even wanted us to
have a GSOC on integrating the package tracker with hyperkitty to add such
a mail archive. Unfortunately I don't have the time to play mentor for the
GSOC.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Raphael Hertzog]

Hello,

On Tue, 26 Dec 2017, Mehdi Dogguy wrote:
> For example, have a look at the following packages:
> - https://tracker.debian.org/pkg/siridb-server
> - https://tracker.debian.org/pkg/libcleri
> 
> The maintainer box is not even shown. I guess this might be a bug to file
> against tracker.debian.org.

So Pierre-Elliot Bécue investigated this and it's unrelated to the
maintainer field. It's because the packages have a Vcs-Browser field
but not the associated Vcs-Git entry which was not really expected by the
codebase.

> I think that realistic proposals should build upon the notion of teams in
> tracker.d.o or in gitlab (or both?). Both tools have a notion of a "team"
> or a "group" and could provide an email alias for member subscribed or
> member of those groups. I believe this would address the need of most teams,
> to have a single point of contact. Such aliases would help us to avoid bug
> notifications and alike on discussion MLs.

Indeed. 

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#890697: ITP: webext-proxy-switcher -- Modify Proxy Settings for your Browser

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: webext-proxy-switcher
  Version : 
  Upstream Author : 
* URL : https://github.com/rNeomy/proxy-switcher
* License : 
  Programming Lang: Javascript
  Description : Modify Proxy Settings for your Browser

 Proxy Switcher lets you change your browser proxy settings (preferences) from
 a toolbar panel in a familiar UI. The panel allows you to access all proxy
 related settings and it also stores your configurations in different profiles
 for easy access. The extension supports importing and exporting feature in case
 profiles need to be used in another browser instance or you want to switch to a
 new clean profile.

I've been using this as a replacement for the old xul-ext-* proxy extension for
quite a while and it works flawlessly for my needs.

Re: What can Debian do to provide complex applications to its users?

[Sergio Durigan Junior]

On Saturday, February 17 2018, Michael Meskes wrote:

>> Minification is quite comparable to compilation. I will give you some
>> examples from my frustration with Drupal8 in this answer. This can no
>> longer be seen as source code:
>> ...
>
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.
>
> I guess minified source code does qualify. However, this discussion is
> mood since the bigger lies in the modules that get included without any
> real documentation.

You can disagree, but you still can't edit and maintain the minified JS.
This is basically what is expected from a source code (and it doesn't
really matter whether Wikipedia's definition is different).  If you've
had to deal with minified JS, then you know it's the same as dealing
with binary code.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#890695: ITP: node-callsites -- Get callsites from the V8 stack trace API

[anupamasok]

Package: wnpp
Severity: wishlist
Owner: Anupam Asok 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : node-callsites
 Version : 2.0.0
 Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/callsites#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Get callsites from the V8 stack trace API

 Get callsites from the V8 stack trace API
 This gets callsites from V8 stack trace API.
 Returns an array of callsite objects with the methods like
 getTypeName, getFunctionName, getMethodName, getFileName etc.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependancy of npm (5.5.1).

I would like to maintain this package as part of the JavaScript packaging
team. Praveen has offered to sponsor this package.

Bug#890694: ITP: node-fast-json-stable-stringify -- Deterministic JSON.stringify()

[Adarsh P.S.]

Package: wnpp
Severity: wishlist
Owner: Adarsh P S 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-fast-json-stable-stringify
  Version : 2.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL :
https://github.com/epoberezkin/fast-json-stable-stringify
* License : Expat
  Programming Lang: JavaScript
  Description : Deterministic JSON.stringify()

 Deterministic JSON.stringify()
 .
 It comes with custom sorting to get deterministic hashes from stringified
results.
 .
 It is a faster version of json-stable-strigify without jsonify.
 .
 Node.js is an event-based server-side JavaScript engine.

It's a dependency of npm.

Mr.Praveen Agreed to sponsor this package.

Bug#890692: ITP: node-agentkeepalive -- http.Agent for having keepalive mode in http requests

[Visakh S]

Package: wnpp
Severity: wishlist
Owner: VISAKH S 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-agentkeepalive
  Version : 3.3.0
  Upstream Author : fengmk2  (https://fengmk2.com)
* URL : https://github.com/node-modules/agentkeepalive#readme
* License : Expat
  Programming Lang: JavaScript
  Description : http.Agent for having keepalive mode in http requests

 http.Agent for having keepalive mode in http requests
 .
 The Node.js's missing keep alive http.Agent. It supports http and https.
 .
 What's different from original http.Agent?
  *keepAlive=true by default
  *Disable Nagle's algorithm: socket.setNoDelay(true)
  *Add free socket timeout: avoid long time inactivity socket leak in the
   free-sockets queue.
  *Add active socket timeout: avoid long time inactivity socket leak in the
   active-sockets queue.
 .
 Node.js is an event-based server-side JavaScript engine.
 .
 This package is a useful dependancy of NPM 5.0
 .
 I am planning to maintain this package as part of a javascript
maintainers team.
 Pirate Praveen has agreed to sponser this package.

Re: What can Debian do to provide complex applications to its users?

[Thorsten Alteholz]

Hi Sean,

On Sat, 17 Feb 2018, Sean Whitton wrote:

I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.


please have a look at for example CVE-2017-18077 [1] in the security 
tracker. This CVE affects one little JavaScript library and is marked as 
. There is also a note attached, saying: "nodejs not covered 
by security support"


Basically all other CVEs for node-modules are marked as  as 
well. So we do track all Javascript issues, but we don't create DSAs for 
them and don't include them in point releases (as you can see for example 
in CVE-2016-1000236 [2][3][4]).


Other javascript libraries like libjs-* and *.js even don't get a CVE. So 
either they are secure or nobody cares.


From a security manpower point of view, there is no difference whether we 
have hundreds of little JavaScript libraries in only one or in multiple 
versions.


   Thorsten


[1] https://security-tracker.debian.org/tracker/CVE-2017-18077
[2] https://security-tracker.debian.org/tracker/CVE-2016-1000236
[3] https://nodesecurity.io/advisories/134
[4] https://tracker.debian.org/pkg/node-cookie-signature

Bug#890690: ITP: node-mithril -- Javascript framework for building Single Page Applications

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: node-mithril
  Version : 1.1.6
  Upstream Author : Leo Horie  and others
* URL : https://github.com/MithrilJS/mithril.js
* License : MIT
  Programming Lang: Javascript
  Description : Javascript framework for building Single Page Applications

 Mithril is a modern client-side Javascript framework for building Single Page
 Applications. It's small (< 8kb gzip), fast and provides routing and XHR
 utilities out of the box.

I need this as a build dependency and will thus take care of it, but wouldn't
mind seeing it end up in the appropriate javascript group.

Michael

Re: Suddenly U2F doesn't work on sid

[Bastian Blank]

On Sat, Feb 17, 2018 at 01:10:50PM -0500, Robert Edmonds wrote:
> I ran into the same problem. It looks like it was due to #889665 being
> fixed and not having the libu2f-udev package installed.

And chromium does not recommends that at all.

Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

Bug#890688: ITP: node-clear-require -- trace the caller path using javascript packaging.

[Dhawal Negi]

Package: wnpp
Severity: wishlist
Owner: Dhawal Negi 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-clear-require
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/clear-require#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Clear a module from the `require` cache
 Require a module bypassing the cache. In node.js when you require() a module,
 node stores a cached version of the module, so that all subsequent calls to
 require() do not have to reload the module from the filesystem.
 .
 Node.js is an event-based server-side JavaScript engine.
 clear-require()is the build dependency of is-ci and ci-info.


Regards,

Dhawal Negi
BMSIT cse 4th sem/a

Re: What can Debian do to provide complex applications to its users?

[Tollef Fog Heen]

]] Russ Allbery 

> Paul Wise  writes:
> 
> > I think the discussion we are having here is orthogonal to
> > containers/flatpaks.
> 
> > If Debian were to have a repository of containers/flatpaks, then it
> > should meet Debian standards. We cannot just say "here are some
> > containers, completely unsupported and might not up to our standards".
> > To achieve that, I think it would be best to automatically convert it
> > from Debian binary packages. Also, since we are already doing packaging
> > work, it makes sense to base any container efforts on that, just like
> > our cloud efforts have been.
> 
> I agree with this.
> 
> Putting aside completely missing licenses or completely missing source
> code (these are sometimes more fixable problems, since those are
> considered suspect practices even in the upstream communities), the root
> problem here is vendored dependencies.  Most modern languages, not just
> Java and Node, are switching to vendored dependencies with some mechanism
> for freezing the dependencies for a project.  See Rust, Go, and
> increasingly, Python and Ruby, and I would expect to see the same for any
> new, popular programming language.

I think there's at least two types of vendoring you're referring to
here, and they're substantially different.

One is how Go currently does (but my understanding is that this is
changing in newer versions).  Here, the source code of dependencies are
shipped together with the source code for the application.  This leads
to trees like
https://github.com/kubernetes/kubernetes/tree/master/vendor where any
one of those dependencies might be a released version or tag, or it
might just be a random git snapshot, and there's not really any way to
know.

The other (you refer to this as freezing dependencies) is how
Node.js/npm/yarn, Ruby/gem, (to some extent) Python/pip, and Rust/cargo
does it.  In those cases, you have some file specifying the versions of
libraries the application needs, usually as «this version of this
gem/crate/package» and there is somewhere those packages live by
default.  Quite often, there's also a lock file of some sort which lists
out the exact versions used, recursively, which ensures you can deploy
the exact same code multiple times.

The second method means you can reason about what versions of code are
included where.  You might still have to patch five versions of
libvulnerable, but at least it's possible to find which five versions
are in use, and get those fixed in a central place and then rebuild
everything that's vulnerable, recursively.  Not the most fun job in the
world, but it's at least possible to automate somewhat.

I'm curious what, if anything, we can do to better support the second
model. In particular because (as you note) it's very much in vogue with
lots of upstreams those days.

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

Re: Suddenly U2F doesn't work on sid

[Robert Edmonds]

Hideki Yamane wrote:
> Hi,
> 
>  Today, I've tried to login salsa.debian.org, 2FA doesn't work well
>  (and on github, too). It works several days ago.
> 
>  The message on salsa is
> >>There was a problem communicating with your device. (error code: 1)
> 
>  On my desktop (sid)
>  - chrome / chromium / chrome-unstable doesn't work
>  - with other user account, it doesn't work, too
>  - tried to use another U2F device, both of them don't work
>  - boot with Fedora27, it works (so, it's not hardware issue, IMO)
> 
>  On my laptop (sid)
>  - chrome / chromium works
> 
>  Now I can login to salsa on my laptop, but I usually do my work on
>  desktop, so I want to solve it.
> 
>  Both of them run Debian sid and updated. 
>  Any suggestions, or ideas?

Hi, Hideki:

I ran into the same problem. It looks like it was due to #889665 being
fixed and not having the libu2f-udev package installed.

-- 
Robert Edmonds
edmo...@debian.org

Bug#890684: ITP: node-js-string-escape -- Escape strings for use as JavaScript string literals

[Subin]

Package: wnpp
Severity: wishlist
Owner: Subin Siby 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-js-string-escape
  Version : 1.0.1
  Upstream Author : Jo Liss 
* URL : https://github.com/joliss/js-string-escape#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Escape strings for use as JavaScript string literals

 Escape any string to be a valid JavaScript string literal
 between double quotes or single quotes.
 .
 If you need to generate JavaScript output, this library will
 help you safely put arbitrary data in JavaScript strings.

This package is a dependency of ava 


I did this as part of a debian packaging hackathon. I'll try to maintain this 
package
in the future too. This package is sponsored by Praveen 
I'm not a member of JavaScript maintainers team.

Re: What can Debian do to provide complex applications to its users?

[Michael Meskes]

> On Sat, Feb 17, 2018 at 01:51:38PM +0100, Michael Meskes wrote:
> > Then I guess the question is, what is Debian?
> > 
> > Does a different and additional package format change the project?
> 
> It seems like you're not reading what other people have said--tt has 

Well I try, but I'm certainly not perfect. Assuming this is not a
personal attack you might want to point me to whatever I missed.

> nothing to do with the packaging format, it has to do with providing
> a 
> stable base of software that interoperates. A collection of
> unrelated 
> independent modules which must be dynamically built off the latest
> git 
> repository may be interesting, but it's not a coherent distribution. 

I thought we were talking about packages for some big applications that
a lot of people want to use nowadays.

> Other people are already trying to do that thing, it isn't clear
> what 
> value debian would add. Conversely, we know what the current debian 

How about making it available from the same reliable source? And having
it well integrated with the rest of the system?

> distribution provides, why throw that out to chase some new shiny
> thing?

Sorry I still don't get this. Why would adding some (as Moritz
suggested probably less than 50) packages in a different format (Maybe
flatpak as Sean suggested) equal to throwing out what Debian provides
now?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: What can Debian do to provide complex applications to its users?

[Russ Allbery]

Paul Wise  writes:

> I think the discussion we are having here is orthogonal to
> containers/flatpaks.

> If Debian were to have a repository of containers/flatpaks, then it
> should meet Debian standards. We cannot just say "here are some
> containers, completely unsupported and might not up to our standards".
> To achieve that, I think it would be best to automatically convert it
> from Debian binary packages. Also, since we are already doing packaging
> work, it makes sense to base any container efforts on that, just like
> our cloud efforts have been.

I agree with this.

Putting aside completely missing licenses or completely missing source
code (these are sometimes more fixable problems, since those are
considered suspect practices even in the upstream communities), the root
problem here is vendored dependencies.  Most modern languages, not just
Java and Node, are switching to vendored dependencies with some mechanism
for freezing the dependencies for a project.  See Rust, Go, and
increasingly, Python and Ruby, and I would expect to see the same for any
new, popular programming language.

For better or worse, there's a general consensus upstream of us in a lot
of language communities that API backward compatibility and continuous
upgrades are simply too hard, and breaking changes (ideally with semver)
plus freezing and vendoring dependencies are the best solution.  We can
certainly disagree with this, but this approach has a ton of momentum
behind it, and we're swimming upstream right now.  We convince some folks,
but not many, and the Node ecosystem in particular is so firmly committed
to this approach that it's hard to imagine them backing away from it.

So, where does that leave us?

The reason why Debian in general doesn't like to support vendored source
is because of the security implications: when there's a security
vulnerability in one of the vendored libraries, updating the relevant
packages becomes a nightmare.  It's a logistical challenge even if the
vendored source can be safely upgraded, but of course it usually can't
since that's the whole point of vendoring the source.  So we would be
faced with backporting security fixes to every vendored version of the
package, and we don't have the resources to do this.

Note that this is not a *Debian* problem, this is an *ecosystem* problem.
No one *else* has the resources to do this either, and generally what
happens out there in the world is that this is just not done.  Those
applications blithely continue running with vulnerable versions of their
dependencies, and aren't updated.

I think it's important to note here that we're not wrong.  Our approach is
substantially more secure because we can patch software.  Vendoring
everything is substantially less secure since you're relying on the
application developer to re-vendor fixed versions, and they may not even
know there was a vulnerability.  (High-quality vulnerability feeds for a
lot of these ecosystems are very hard to come by.)  It's not that someone
else is succeeding where we're failing; it's that lots of other people
have decided to just blow off security in the name of convenience and hope
they don't get bitten by this.

Using flatpak therefore doesn't really change the equation.  It *does*
provide some jailing by default, which can protect some against a certain
type of vulnerabilities (and which we could provide in other ways as well;
flatpak just makes it easier).  But it does nothing against the more
common problems of, say, XSS vulnerabilities in some Javascript library
used for the web front end of the application.

It's hard to avoid the feeling that we have two choices with these sorts
of applications:

1. Lower our security standards and provide whatever the application
   developer provides, relying on them to re-vendor for security updates.
   This would probably mean not releasing these packages with stable
   releases or immediately adding them to the unsupported security list,
   unless we're going to significantly relax the normal security
   guarantees we provide.

2. Maintain our security standards, reject packages with large amounts of
   vendored software, and therefore, in practice, ask our users to
   separately install such software via whatever means the application
   developer provides.  Users who choose to do this won't be any more
   secure (they'll probably be somewhat less secure since those updates
   won't be hooked into their normal system update process), but at least
   they have to make a conscious choice to opt in to that behavior, and a
   Debian installation with pure Debian packages is relatively secure by
   default.

So far, we've defaulted in option 2, which means we're not packaging a lot
of very useful software.  But I don't think this is due to some obvious
error on our part.  The only practical alternative appears to be 1, and 1
is really not very appealing.  It does make things more convenient for our
users, but at a substantial cost to our 

Re: What can Debian do to provide complex applications to its users?

[Sean Whitton]

Hello Paul,

On Sat, Feb 17 2018, Paul Wise wrote:

> I think the discussion we are having here is orthogonal to
>containers/flatpaks.
>
> If Debian were to have a repository of containers/flatpaks, then it
> should meet Debian standards. We cannot just say "here are some
> containers, completely unsupported and might not up to our standards".
> To achieve that, I think it would be best to automatically convert it
> from Debian binary packages. Also, since we are already doing
> packaging work, it makes sense to base any container efforts on that,
> just like our cloud efforts have been.
>
> There is flathub, dockerhub etc for containers/flatpaks that may or
> may not meet Debian standards.

I should have been more specific.  What I was suggesting was that
providing a repository of containers/flatpaks/whatever would enable us
to provide different versions of libraries which would not receive
security support.

By having them in flatpaks/etc. we would mitigate somewhat the need for
this security support, and also draw a clear line between "this is the
stuff that we provide security support for" and "this is the stuff we
don't, but we've wrapped it up so it's a bit safer".

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Sean Whitton]

Hello Andreas,

On Sat, Feb 17 2018, Andreas Tille wrote:

> On Fri, Feb 16, 2018 at 11:51:20AM -0700, Sean Whitton wrote:
>> We do not, and probably never will have, the required manpower.
>
> So if you are claiming we have no manpower that's pretty much our own
> fault since we do not actively care.  There are ways to attract gifted
> and interested people if we would only try.

I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.

I don't doubt that we could have far more volunteers for other work if
we made it easier to get involved.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#890682: ITP: node-fill-keys --FILL KEYS in a destination that are defined on the source

[daltonfury42]

Package: wnpp
Severity: wishlist
Owner: PAVITHRA  
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-fill-keys
  Version : 1.0.2
  Upstream Author : Ben Drucker  (bendrucker.me)
* URL : https://github.com/bendrucker/fill-keys#readme
* License : Expat
  Programming Lang: JavaScript
  Description : FILL KEYS in a destination that are defined on the source

 Fill keys in a destination that are defined on the source.
 .
 Fill-keys will copy descriptors. It will also copy the source.prototype 
propert ies onto destination.prototype if both destination and source are 
functions.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency for npm.

I would like to maintain this package as a part of teh JavaScript packaging 
team.Praveen has offered to sponsor this package.

Suddenly U2F doesn't work on sid

[Hideki Yamane]

Hi,

 Today, I've tried to login salsa.debian.org, 2FA doesn't work well
 (and on github, too). It works several days ago.

 The message on salsa is
>>There was a problem communicating with your device. (error code: 1)

 On my desktop (sid)
 - chrome / chromium / chrome-unstable doesn't work
 - with other user account, it doesn't work, too
 - tried to use another U2F device, both of them don't work
 - boot with Fedora27, it works (so, it's not hardware issue, IMO)

 On my laptop (sid)
 - chrome / chromium works

 Now I can login to salsa on my laptop, but I usually do my work on
 desktop, so I want to solve it.

 Both of them run Debian sid and updated. 
 Any suggestions, or ideas?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: What can Debian do to provide complex applications to its users?

[Michael Stone]

On Sat, Feb 17, 2018 at 01:51:38PM +0100, Michael Meskes wrote:

Then I guess the question is, what is Debian?

Does a different and additional package format change the project?


It seems like you're not reading what other people have said--tt has 
nothing to do with the packaging format, it has to do with providing a 
stable base of software that interoperates. A collection of unrelated 
independent modules which must be dynamically built off the latest git 
repository may be interesting, but it's not a coherent distribution. 
Other people are already trying to do that thing, it isn't clear what 
value debian would add. Conversely, we know what the current debian 
distribution provides, why throw that out to chase some new shiny thing?


Mike Stone

Re: What can Debian do to provide complex applications to its users?

[Moritz Mühlenhoff]

Raphael Hertzog  schrieb:
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?

There's clearly a set of software which is of high quality, but where
upstream's development practices are not usefully aligned with our
existing distro model. This goes beyond web applications, we're also
missing out top quality server software (e.g. elasticsearch which
also turned out to be incompatible, see the PTS for details)

Many of those upstreams provide custom debs or have people install
locally instead, but IMO we should still strive to accomodate these
packages:
- by providing a well-maintained common base stack underneath
(Java, core system services, PHP, Curl etc. pp.)
- by ensuring our usual high standards of FLOSS compliance

One way would be to create a new archive section which is based on
the latest stable release, which
- follows upstream releases/branches independant of the Debian
lifetime (for users of such software it's common to have releases
being supported for only a year or so and being forced to upgrade
more often)
- allows maintainers to release updates independant of the stable
release managers and the security team
- allows bundling some classes within the specific packages if
those need to be more recent than what the stable base provides
(we can track code copies etc)

I don't think this section would contain more than, say 50 packages,
but would Debian to sensibly provide packages for say Nextcloud,
the Elastic stack or Grafana (or even gitlab, while packaged
in stretch, salsa also follows upstream and even backporting
the first set of security fixes isn't done after a month (#888508).

Cheers,
Moritz

Re: What can Debian do to provide complex applications to its users?

[W. Martin Borgert]

On 2018-02-17 13:57, Michael Meskes wrote:
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.

I disagree with the wikipedia definition. The "source" (Quelle,
fuente) is the "origin" that is the form of code that is not
only readable but also writable. In general any generated file,
even if readable and in text form, is not source code.

Direktoriaus kontaktai - tai Jūsų klientas

[Gautas pranešimas]

Laba diena,


Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos 
įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys 
veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.
 
Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, 
transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.
 
Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.
 
 
Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:
 
1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė 
tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai 
bendrausite su direktoriais, komercijos vadovais.
 
2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus 
kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės 
skolingos Sodrai.
 
3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus 
galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių 
siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.
 
 
Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )
 
Parašykite, kurias veiklas išsirinkote 
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti



Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041


Veiklos.xlsx
Description: Binary data

Re: What can Debian do to provide complex applications to its users?

[Paul Wise]

On Sat, Feb 17, 2018 at 8:57 PM, Michael Meskes wrote:

> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.
>
> I guess minified source code does qualify. However, this discussion is
> mood since the bigger lies in the modules that get included without any
> real documentation.

It may be code but it is definitely not source in the sense of DFSG
item 2 or the GPL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: What can Debian do to provide complex applications to its users?

[Philip Hands]

On Sat, 17 Feb 2018, Michael Meskes  wrote:
>> Minification is quite comparable to compilation. I will give you some
>> examples from my frustration with Drupal8 in this answer. This can no
>> longer be seen as source code:
>> ...
>
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless.

The settled opinion of the FTP team (and the TC for that matter) is:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#235

that for our purposes it is not source code.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Samuel Thibault]

Michael Meskes, on sam. 17 févr. 2018 13:57:53 +0100, wrote:
> > Minification is quite comparable to compilation. I will give you some
> > examples from my frustration with Drupal8 in this answer. This can no
> > longer be seen as source code:
> > ...
> 
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
> 
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.

And according to the GPL, it is

“
The source code for a work means the preferred form of the work for
making modifications to it.
”

minified source is definitly not that.

That's not something one can maintain anyway, so really not source code.

You could as well claim that you can modify binary ELF files: for the
processor, it's source code.

Samuel

Re: What can Debian do to provide complex applications to its users?

[Michael Meskes]

> I don't know where you got figures to support this case, but I have
> the
> inverse feeling (and no figures either). Arch is taking away our
> desktop
> users, Ubuntu is taking away our cloud users, Alpine is taking away
> our
> container users and CoreOS/Atomic Host are taking away users
> interested
> by container orchestration solutions.

Not sure about those details, but yes, this is my gut feeling, too. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

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

Re: What can Debian do to provide complex applications to its users?

[Michael Meskes]

> Minification is quite comparable to compilation. I will give you some
> examples from my frustration with Drupal8 in this answer. This can no
> longer be seen as source code:
> ...

I disagree, it is not maintainable source code, yes, but source code
nonetheless. According to wikipedia source code is:

In computing, source code is any collection of computer instructions,
possibly with comments, written using[1] a human-readable programming
language, usually as plain text.

I guess minified source code does qualify. However, this discussion is
mood since the bigger lies in the modules that get included without any
real documentation.

> And it's far from the ugliest example I can quote. Of course, I
> needed
> to ship sources for all of them - Take a look at:
> 
> https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb
> ian/missing-sources/README
> 
> And, of course, think about the huge diff that is to be created for
> all of the files in debian/missing-sources.

Agreed this is ugly and I'm all in if we can find a better solution.
but just not having all these applications does not strike me as a
better solution.

> Take this as an example of what is needed for a moderately complex
> PHP
> webapp with lots of JS in it:
> 
> https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb
> ian/copyright
> 
> Of course, it was all hand-generated and validated.

And your point being?

> But packaging the precise version that is required in each little
> bump
> is just impossible.

I get your point, I just don't accept the consequence that we should
not package these applications.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

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

Re: What can Debian do to provide complex applications to its users?

[Michael Meskes]

Am Freitag, den 16.02.2018, 17:22 -0500 schrieb Michael Stone:
> On Fri, Feb 16, 2018 at 10:01:53PM +0100, Michael Meskes wrote:
> > True, that's why I think we should look for a different solutions.
> 
> There are different solutions, but the result isn't debian, it's 
> something else with a different set of expectations.

Then I guess the question is, what is Debian?

Does a different and additional package format change the project?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#890656: ITP: python3-antlr3 -- ANother Tool for Language Recognition - Python 3 bindings

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python3-antlr3
  Version : 3.5.2
  Upstream Author : Terence Parr 
* URL : https://github.com/antlr/antlr3
* License : BSD-3-clause
  Programming Lang: Python
  Description : ANother Tool for Language Recognition - Python 3 bindings

 ANTLR, ANother Tool for Language Recognition, (formerly PCCTS) is a language
 tool that provides a framework for constructing recognizers, compilers, and
 translators from grammatical descriptions containing C++ or Java actions (You
 can use PCCTS 1.xx to generate C-based parsers).
 .
 Computer language translation has become a common task. While compilers and
 tools for traditional computer languages (such as C or Java) are still being
 built, their number is dwarfed by the thousands of mini-languages for which
 recognizers and translators are being developed. Programmers construct
 translators for database formats, graphical data files (e.g., PostScript,
 AutoCAD), text processing files (e.g., HTML, SGML).  ANTLR is designed to
 handle all of your translation tasks.

Note: Upstream is keeping the Python3 source code in a separated folder as
the Python2 version, and therefore, a 2nd source package must exist. This
package is part of the OpenStack team effort to get rid of Python2.

Re: What can Debian do to provide complex applications to its users?

[Andreas Tille]

On Fri, Feb 16, 2018 at 11:51:20AM -0700, Sean Whitton wrote:
> We do not, and probably never
> will have, the required manpower.

Since 2012 I'm maintaining a survey in wiki[1] where developers are
giving reasons why they entered Debian.  I presented the result in
several talks the first time at FOSDEM 2013[2].  It boils down to the
very simple statement:  A project like Debian Med which is de factor
very special and thus not very important to Debian was able to attract
more then one percent of the existing active Debian developers (we are
currently close to 2% five years later).

So if you are claiming we have no manpower that's pretty much our own
fault since we do not actively care.  There are ways to attract gifted
and interested people if we would only try.

In the actual topic: If we simple hunting for adding random JS libraries
to the Debian package pool we will definitely fail technically and in
terms of attracting people who are working on the issue.  If we in
contrast try to form a solid group which is reaching out to upstream and
try to get them actively involved we will be certainly able to solve the
issues we are facing today.

BTW, in the JS case I would rather take teams like Debian Perl team as
an example but they probably have not made a poll like the Debian Med
team.

Kind regards

Andreas.

[1] https://wiki.debian.org/DebianMed/Developers
[2] https://people.debian.org/~tille/talks/201302_fosdem_distro/
see page 
https://people.debian.org/~tille/talks/201302_fosdem_distro/debian-med_distro.pdf#page=51

-- 
http://fam-tille.de

Re: What can Debian do to provide complex applications to its users?

[Vincent Bernat]

 ❦ 16 février 2018 17:25 GMT, Holger Levsen  :

>> Well, strictly speaking Debian does not actually need to be involved
>> then, applications are already doing that. But it's indeed a sign that
>> Debian is losing relevance, which is concerning and Debian could have to
>> do something about it.
>  
> I very much disagree that Debian is loosing relevance, like many software 
> projects Debian usage is still growing. and other projects grow as well. 
> Debian was just again voted best linux distro by linux journal. Debian
> (and other traditional distros) surely lost relevance in the "web
> hosting plattform" "niche" but even there, in numbers we're still
> growing. just container based solutions are much more popular today and
> they ease installing crap^wstrange bundles.

I don't know where you got figures to support this case, but I have the
inverse feeling (and no figures either). Arch is taking away our desktop
users, Ubuntu is taking away our cloud users, Alpine is taking away our
container users and CoreOS/Atomic Host are taking away users interested
by container orchestration solutions.

>> Or we could try to embrace the multiple-library-versions-in-the-same-root
>> issue like distributions such as NixOS and Guix do. 
>
> you can use their package managers, and thus these features, on Debian
> today. there's also docker containers and other options if you want to
> use bundled "stuff".

With the small drawback that Docker is only in Sid (and outdated).
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Updating the Maintainer field in preparation for Alioth's shutdown?

[Andreas Tille]

Hi Raphael,

On Fri, Feb 16, 2018 at 02:10:30PM +0100, Raphael Hertzog wrote:
> On Fri, 19 Jan 2018, Jeremy Bicha wrote:
> > 3. If a team manages to get a lists.debian.org address, it's
> > recommended that they switch the Maintainer fields in their packages
> > from the Alioth list address to that address, right?
> 
> It depends on your choice. But I would not recommend this. I would largely
> prefer if teams relied on tracker.debian.org to get all the automated
> mails, that way lists on lists.debian.org contain only generic
> discussions.

A mailing list is not just helpful to distribute e-mails to certain
people.  The mail archive feature is a very valuable thing to refer to
previous mails which as far as I understand is not provided by
tracker.d.o.  That's why I do not consider tracker.d.o as a full
replacement.

Kind regards

   Andreas.

-- 
http://fam-tille.de