Bug#844996: ITP: rambo-k -- Read Assignment Method Based On K-mers
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: rambo-k Version : 1.21+r5 Upstream Author : Simon Tausch * URL : http://rambok.sourceforge.net/ * License : LGPL Programming Lang: Perl, Java Description : Read Assignment Method Based On K-mers RAMBO-K is a tool for rapid and sensitive removal of background sequences from Next Generation Sequencing data. . RAMBO-K is a reference-based tool for rapid and sensitive extraction of one organisms reads from a mixed dataset. It is based on a Markov chain implementation, which uses genomic characteristics of each reference to assign reads to the associated set. Remark: This package is maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/rambo-k.git
Re: OpenSSL 1.1.0
On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote: > Adrian Bunk schrieb: > > And/or get sponsorship from companies for supporting ChaCha20-patched > > 1.0.2 > > It's not a matter of whipping up some patch; anything less than an > official backport of chacha20 into a 1.0.2x release is not going > to be supportable. I am sure Redhat will be interested in that as well. So release now with 1.0.2 without ChaCha20 and upgrade openssl in a point release when/if 1.0.2 supports ChaCha20. That or delay the release by a few months. BTW, just because an openssl-using app/lib does not export an interface that allows access of openssl-related internals does not mean that no other lib or plugin messes with those internals. For example, for apache2 there is gridsite which uses mod_ssl private interfaces and a private copy of a header from the apache2 sources to get access to the SSL context. Finding all such issues in all packages will take time. Cheers, Stefan
Bug#845013: ITP: node-grunt-replace -- Replace text patterns with applause
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: node-grunt-replace Version : 1.0.1 Upstream Author : outaTiME (http://outa.im/) * URL : https://github.com/outatime/grunt-replace#readme * License : Expat Programming Lang: JavaScript Description : Replace text patterns with applause Grunt-replace uses the node-applause module to replace any text pattern with new text. . Node.js is an event-based server-side JavaScript engine. Node-grunt-replace is required to build node-chroma-js, and will be maintained within the Debian Javascript Team.
Bug#845017: ITP: node-grunt-contrib-internal -- Internal tasks for managing the grunt-contrib projects
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-internal Version : 1.2.2 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-internal#readme * License : Expat Programming Lang: JavaScript Description : Internal tasks for managing the grunt-contrib projects signature.asc Description: OpenPGP digital signature
Bug#845024: ITP: node-applause -- Pattern replacer that helps creating human-friendly replacements
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: node-applause Version : 1.2.2 Upstream Author : outaTiME (http://outa.im/) * URL : https://github.com/outatime/applause#readme * License : Expat Programming Lang: JavaScript Description : Pattern replacer that helps creating human-friendly replacements Node-applause helps matching text with patterns and replacing that text in a human-friendly way. . Node.js is an event-based server-side JavaScript engine Node-applause is a dependency of node-grunt-replace, and will be maintained within the Debian Javascript Team.
Bug#845025: ITP: node-file-sync-cmp -- Synchronous file comparison
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: node-file-sync-cmp Version : 0.1.1 Upstream Author : Martin Geisler (http://geisler.net/) * URL : https://github.com/mgeisler/file-sync-cmp/ * License : Expat Programming Lang: JavaScript Description : Synchronous file comparison Node-file-sync-cmp provides syncronous file comparison for Node.js. . Node.js is an event-based server-side JavaScript engine. Node-file-sync-cmp is a dependency of node-grunt-replace, and will be maintained within the Debian Javascript Team.
Bug#845027: ITP: node-cson-parser -- Safe parsing of CSON files
Package: wnpp
Severity: wishlist
Owner: Ross Gammon
* Package name: node-cson-parser
Version : 1.3.4
Upstream Author : Groupon
* URL : https://github.com/groupon/cson-parser
* License : BSD-3-Clause
Programming Lang: JavaScript
Description : Safe parsing of CSON files
Node-cson-parser is a minimalistic CSON parser which offers:
- A strict subset of CSON that allows only data
- Interface is identical to JSON.{parse,stringify}
- Does not run the code, free of intermediate string representations
- Sane parse error messages with line/column
- Regular Expressions are considered data and will be accepted as well
.
In addition of pure data it allows for simple arithmetic expressions like
addition and multiplication. This allows more readable configuration
of numbers.
.
Node.js is an event-based server-side JavaScript engine.
Node-cson-parser is a dependency of node-applause, and will be maintained
within the Debian Javascript Team.
Bug#845028: ITP: node-grunt-contrib-nodeunit -- Run Nodeunit unit tests
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-nodeunit Version : 1.0.0 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-nodeunit#readme * License : Expat Programming Lang: JavaScript Description : Run Nodeunit unit tests signature.asc Description: OpenPGP digital signature
Re: Multi-Arch: allowed
On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > The -dbg package is Multi-Arch same. It Depends on the packages for > which it provides debugging symbols, some of which are Multi-Arch: > allowed. That Depends seems wrong, there's no reason a -dbg package needs a dependency on anything, AFAICT. Cheers, Julien
Re: Multi-Arch: allowed
On Sat, Nov 19, 2016 at 05:53:04PM +0100, Julien Cristau wrote: > On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > > > The -dbg package is Multi-Arch same. It Depends on the packages for > > which it provides debugging symbols, some of which are Multi-Arch: > > allowed. > > That Depends seems wrong, there's no reason a -dbg package needs a > dependency on anything, AFAICT. A -dbg package only works with the exact version of the package it provides the debug symbols for. > Cheers, > Julien cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: OpenSSL 1.1.0
On 11/17/2016 12:40 AM, Kurt Roeckx wrote: > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote: >> >> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1], >> but that sort of assumes that you are only interested in openssl 1.1 for >> ChaCha20 (and not the other changes). > > I'm not willing to maintain such a patch. Understandable. Did you talk to upstream about the issue? What do they say? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: OpenSSL 1.1.0
On Sat, Nov 19, 2016 at 06:30:06PM +0100, Bernd Zeimetz wrote: > On 11/17/2016 12:40 AM, Kurt Roeckx wrote: > > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote: > >> > >> The alternative for ChaCha20 would be to adopt Cloudflare's patches[1], > >> but that sort of assumes that you are only interested in openssl 1.1 for > >> ChaCha20 (and not the other changes). > > > > I'm not willing to maintain such a patch. > > Understandable. Did you talk to upstream about the issue? What do they say? Chacha20 would be a new feature. Following the policy that can't be added in a 1.0.2 version, only bugs get fixed in it. We made a new release with new features, that version is 1.1.0. Kurt
Re: OpenSSL 1.1.0
Hi, 2016-11-19 21:06 GMT+01:00 Kurt Roeckx : > Chacha20 would be a new feature. Following the policy that can't > be added in a 1.0.2 version, only bugs get fixed in it. > yep, they don't add new feature, but break API between 1.1.0b->c release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366 https://github.com/openssl/openssl/issues/1903 https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e Really nice. Please revert this transition and try again with buster, thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: OpenSSL 1.1.0
On Nov 19, Stefan Fritsch wrote: > plugin messes with those internals. For example, for apache2 there is > gridsite > which uses mod_ssl private interfaces and a private copy of a header from the > apache2 sources to get access to the SSL context. Finding all such issues in > all packages will take time. We call this "broken by design" and a "FPOS program". -- ciao, Marco signature.asc Description: PGP signature
Re: OpenSSL 1.1.0
Hi, On 19.11.2016 23:07, Marco d'Itri wrote: >> plugin messes with those internals. For example, for apache2 there is >> gridsite >> which uses mod_ssl private interfaces and a private copy of a header from >> the >> apache2 sources to get access to the SSL context. Finding all such issues in >> all packages will take time. > We call this "broken by design" and a "FPOS program". The problem with OpenSSL is that these things are often necessary. In KiCad, we explicitly link against OpenSSL in order to initialize a struct that contains lock/unlock functions, in case the libcurl we use is linked against OpenSSL, so it doesn't keel over when asked to perform two HTTPS requests at the same time. The git history of OpenSSL doesn't exactly give me a lot of confidence either, and stable branches are apparently not even compile tested after backporting fixes (as evidenced by compile failures on KiCad's Jenkins server). My dream solution at this point would be to organize a week-long hackfest somewhere where we move everything to GnuTLS if possible. Simon signature.asc Description: OpenPGP digital signature
Re: testing OpenSSL 1.1.0 on jessie
On 2016-11-18 15:53:20 [+0100], Daniel Pocock wrote: > Is this correct? I have thrown it on sbuild with a Jessie environment and I got more header files. There is a build log [0] around and this directory cointains also the resulting .deb files. [0] https://breakpoint.cc/openssl-110c-rebuild-for-jessie/openssl_1.1.0c-1~0_amd64.build Sebastian
Re: OpenSSL 1.1.0
On Sat, Nov 19, 2016 at 10:32:58PM +0100, Ondrej Novy wrote: > Hi, > > 2016-11-19 21:06 GMT+01:00 Kurt Roeckx : > > > Chacha20 would be a new feature. Following the policy that can't > > be added in a 1.0.2 version, only bugs get fixed in it. > > > > yep, they don't add new feature, but break API between 1.1.0b->c release: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366 > https://github.com/openssl/openssl/issues/1903 This is being fixed. Kurt
Bug#845063: ITP: html2canvas -- Take screenshots of webpages directly in the browser
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: html2canvas Version : 0.5.0~beta4 Upstream Author : 2012-2016 Niklas von Hertzen * URL : https://github.com/niklasvh/html2canvas * License : Expat Programming Lang: JS Description : Take screenshots of webpages directly in the browser html2canvas allows you to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM and as such may not be 100% accurate to the real representation as it does not make an actual screenshot, but builds the screenshot based on the information available on the page. It renders the current page as a canvas image, by reading the DOM and the different styles applied to the elements. It does not require any rendering from the server, as the whole image is created on the clients browser. However, as it is heavily dependent on the browser, this library is not suitable to be used in nodejs. It doesn't magically circumvent any browser content policy restrictions either, so rendering cross-origin content will require a proxy to get the content to the same origin. It is still in a very experimental state, so the author doesn't recommend using it in a production environment nor start building applications with it yet, as there will be still major changes made.
Let's stop using CVS for debian.org website
(CC-ing to debian-devel for a larger audience. But please, use debian-www instead of debian-devel for the discussion to avoid the crossposting hell.) Hi all, As a newcomer who wants to contribute to the Debian website, I was shocked when I heard that debian.org website is still using CVS to manage the source code. I know there is a saying that "If things ain't broken, don't fix it.". But this is nearly 2017 today, not 2007 or 1997. CVS is seriouly outdated and largely replaced by SVN (or even Git). If we continue to use CVS in the website source management, the disadvantages are clear: * All the shortcomings that exist in CVS but solved by SVN or Git. * Fewer and fewer people know how to manipulate with CVS, and most of the others won't be willing to learn it. * Difficulty in setting up modern web interface. (Compare viewvc with GitHub, or for free software, GitLab or even cgit.) * Difficulty in mirroring. * ...which means the number of new content contributor would decrease. Needless to say there are various tools that can help convert a CVS repo into a SVN repo or Git repo and they handle this job properly. I know the migration to other version control system would not be trivial and hurt the current workflow, but I strongly suggest that we set up a timetable or future plan. So will debian.org continue to use CVS to manage its source code? If yes, when will we re-analyze this choice? If not, when will we do the migration? Thanks! Sincerely, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#845070: ITP: node-loader-utils -- utils for webpack loaders
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-loader-utils Version : 0.2.16 Upstream Author : Tobias Koppers @sokra * URL : https://github.com/webpack/loader-utils#readme * License : Expat Programming Lang: JavaScript Description : utils for webpack loaders signature.asc Description: OpenPGP digital signature
Bug#845071: ITP: node-core-js -- Javascript Standard library
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-core-js Version : 2.4.1 Upstream Author : FIX_ME upstream author * URL : https://github.com/zloirock/core-js#readme * License : Expat Programming Lang: JavaScript Description : Javascript Standard library
Re: Let's stop using CVS for debian.org website
On Sun, Nov 20, 2016 at 10:45 AM, Boyuan Yang wrote: > Needless to say there are various tools that can help convert a CVS repo into > a SVN repo or Git repo and they handle this job properly. This idea comes up every few years but we haven't yet found someone with the time, skills and motivation to implement it. Some historical documents and discussions are in these links: https://lists.debian.org/20130516005223.gv26...@rzlab.ucr.edu https://wiki.debian.org/WebsiteVCSEvaluation https://wiki.debian.org/WebsiteSVNTransition -- bye, pabs https://wiki.debian.org/PaulWise
Re: OpenSSL 1.1.0
On 11/19/2016 11:59 PM, Simon Richter wrote: > My dream solution at this point would be to organize a week-long > hackfest somewhere where we move everything to GnuTLS if possible. Are you sure that makes things better? I've seen too many weird issues with GnuTLS. What about LibreSSL? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
