Bug#843016: ITP: node-meow -- Command-line interface app helper
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-meow Version : 3.7.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/meow#readme * License : Expat Programming Lang: JavaScript Description : Command-line interface app helper
Re: openssl transition
On 27/10/16 07:39 AM, Antti J ä rvinen wrote: Jörg Frings-Fürst writes: > I have read the discussion about the openssl transition here again. Possibly referring to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 ?? > - The parallel use of release 1.0 and 1.1 will not be pursued? Might be highly problematic, having purposefully 2 different versions of the same library in same process isn't the brightest idea. Real world example is any application that links openssl and qt library. Should you link different openssl version than the one used by qt will ..produce interesting results :) Well, depends how they are used. OpenSSL has versioned symbols, so using binaries that are linked via both is not an issue. For example, a.out - liba + openssl 1.0.2 - libb + openssl 1.1.0 should work fine. The problem is that quite a bit of software probably uses OpenSSL via dlopen interface and not via linking. This could result in problems. Qt can be patched/rebuild to only look for the 1.0.2 library and resolve symbols there. What about other cases? - Adam
Re: OpenSSL 1.1.0
On miércoles, 2 de noviembre de 2016 9:15:13 P. M. ART Kurt Roeckx wrote: > On Wed, Nov 02, 2016 at 02:02:52PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > On miércoles, 2 de noviembre de 2016 10:00:43 A. M. ART Bernhard Schmidt > > > > wrote: > > > Kurt Roeckx wrote: > > > > > > Hi, > > > > > > > There might also be packages for which the changes are more > > > > involved and that can't be fixed in time for the release. If you > > > > want to stay with OpenSSL 1.0.2 you need to change your Build-Depends > > > > from libssl-dev to libssl1.0-dev. > > > > > > Almost expected, this fails where another build-dep pulls in libssl-dev, > > > i.e. adjusting build-dep for src:asterisk > > > > Today we the Qt/KDE team were hit but this same thing in the middle of our > > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS. > > > > *Not impliying bad faith here:* moreoever when we started the transition > > we > > depended upon libssl-dev so I don't know why the ssl transition got > > started. Possibly a human mistake, which is fair. > > > > It would have been much more simple if libssl1.1-dev was provided and > > libssl- dev be kept as it was. > > > > Can this be considered? > > I don't think having libssl1-1-dev vs libssl1.0-dev is going to > make much differences in the end. The build conflicts will always > have to be sorted out. But wouldn't have broken packages that didn't did the switch, like qt5. Another story would habe been if this had happened much earlier in the stretch cycle, or in the next cycle. But oh well, I guess it's worthless to discuss this now, let's use the energy to get things working. -- All of us have bad luck and good luck. The man who persists through the bad luck - who keeps right on going - is the man who is there when the good luck comes - and is ready to receive it. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.1.0
On Wed, Nov 02, 2016 at 02:02:52PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On miércoles, 2 de noviembre de 2016 10:00:43 A. M. ART Bernhard Schmidt > wrote: > > Kurt Roeckx wrote: > > > > Hi, > > > > > There might also be packages for which the changes are more > > > involved and that can't be fixed in time for the release. If you > > > want to stay with OpenSSL 1.0.2 you need to change your Build-Depends > > > from libssl-dev to libssl1.0-dev. > > > > Almost expected, this fails where another build-dep pulls in libssl-dev, > > i.e. adjusting build-dep for src:asterisk > > Today we the Qt/KDE team were hit but this same thing in the middle of our > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS. > > *Not impliying bad faith here:* moreoever when we started the transition we > depended upon libssl-dev so I don't know why the ssl transition got started. > Possibly a human mistake, which is fair. > > It would have been much more simple if libssl1.1-dev was provided and libssl- > dev be kept as it was. > > Can this be considered? I don't think having libssl1-1-dev vs libssl1.0-dev is going to make much differences in the end. The build conflicts will always have to be sorted out. Kurt
Re: OpenSSL 1.1.0
On miércoles, 2 de noviembre de 2016 6:44:46 P. M. ART Sebastian Andrzej Siewior wrote: > On 2016-11-02 14:02:52 [-0300], Lisandro Damián Nicanor Pérez Meyer wrote: > > Today we the Qt/KDE team were hit but this same thing in the middle of our > > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS. > > https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/commit/?id=8b5 > 39fcb3e093a521c095e70bdfa76887217b89f And let's pray we don't find more of those. This is just qtbase, the full stack is 17+ packages + binNMUs. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#842977: ITP: teiler -- Little script for screenshots and screencasts utilizing rofi, maim, ffmpeg
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: teiler Version : 3.0 Upstream Author : Rasmus Steinke * URL : https://carnager.github.io/teiler/ * License : GPL-3 Programming Lang: Bash Description : Little script for screenshots and screencasts utilizing rofi, maim, ffmpeg teiler uses or rofi to draw a menu which lets you choose between screenshots or screencasts. Features: * screenshots fullscreen/monitor/area * delay of screenshots * screencasts of monitor/area * upload screenshots/screencasts - teiler can also upload your files via scp, imgur or filebin, ix (for pastes) and amazon s3. * History of Images and Videos with support for + Viewing + Editing + Uploading * Commandline interface for direct access to all features. Useful for hotkeys
Bug#842975: ITP: xininfo -- Small helper program for monitor layouts
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: xininfo Version : 0.14.11 Upstream Author : Dave Davenport * URL : https://github.com/DaveDavenport/xininfo * License : MIT Programming Lang: C Description : Small helper program for monitor layouts xininfo is an X11 utility to query the current layout and size of each configured monitor. It is designed to be used by scripts. I am packaging this as a dependency for teiler.
Bug#842974: ITP: slop -- queries for a selection from the user and prints the region to stdout.
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: slop Version : 4.3.21 Upstream Author : Dalton Nell * URL : https://github.com/naelstrof/slop * License : GPL-3 Programming Lang: C++ Description : queries for a selection from the user and prints the region to stdout. slop (Select Operation) is an application that queries for a selection from the user and prints the region to stdout. It grabs the mouse and turns it into a crosshair, lets the user click and drag to make a selection (or click on a window) while drawing a pretty box around it, then finally prints the selection's dimensions to stdout. Features: * Hovering over a window will cause a selection rectangle to appear over it. * Clicking on a window makes slop return the dimensions of the window. * Clicking and dragging causes a selection rectangle to appear, renders pretty well (compared to scrot). And will return the dimensions of that rectangle in absolute screen coords. * On startup it turns your cursor into a crosshair, then adjusts the cursor into angles as you drag the selection rectangle. * Supports simple arguments: * Change selection rectangle border size. * Select X display. * Set padding size, even negative padding sizes! * Set click tolerance for if you have a shaky mouse. * Set the color of the selection rectangles to match your theme! (Even supports transparency!) * Remove window decorations from selections. * Supports OpenGL hardware acceleration. * Supports textured themes. * Supports programmable shaders. * Supports a magnifying glass.
Re: OpenSSL 1.1.0
On 2016-11-02 14:02:52 [-0300], Lisandro Damián Nicanor Pérez Meyer wrote: > Today we the Qt/KDE team were hit but this same thing in the middle of our > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/commit/?id=8b539fcb3e093a521c095e70bdfa76887217b89f Sebastian
Re: OpenSSL 1.1.0
On 2016-11-02 11:16:18 [+0100], Ondřej Surý wrote: > On Tue, Nov 1, 2016, at 23:49, Kurt Roeckx wrote: > > All the filed bugs already contain a link to the porting guide. > > Is this https://wiki.openssl.org/index.php/1.1_API_Changes a migration > guide? > This is a very *poor* migration guide and sentences like "In other > words, > look at the 1.1 code and add the missing functions into your source. " > are not > very helpful to a person who is just a maintainer and not a full > upstream > developer who worked with OpenSSL before. If you look at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org there are few bugs tagged patch and others which are forwarded + fixed-upstream and also point to a patch. Would this help? If you compile and the build fails you would see what is missing and one of the patches should fall into the pattern. If you look at the unbound patch [0] and compare it with the socat [1] then they are not that different. And then openssh [2] but it more more more places. If you need help with a particular package just let us know. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=828584;filename=0001-get-it-compiled-againt-openssl-1.1.0.patch;msg=26 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=828550;filename=0001-socat-2-port-to-openssl-1.1.0.patch;msg=12 [2] https://github.com/openssh/openssh-portable/pull/48 > Cheers, Sebastian
Re: OpenSSL 1.1.0
On miércoles, 2 de noviembre de 2016 10:00:43 A. M. ART Bernhard Schmidt wrote: > Kurt Roeckx wrote: > > Hi, > > > There might also be packages for which the changes are more > > involved and that can't be fixed in time for the release. If you > > want to stay with OpenSSL 1.0.2 you need to change your Build-Depends > > from libssl-dev to libssl1.0-dev. > > Almost expected, this fails where another build-dep pulls in libssl-dev, > i.e. adjusting build-dep for src:asterisk Today we the Qt/KDE team were hit but this same thing in the middle of our transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS. *Not impliying bad faith here:* moreoever when we started the transition we depended upon libssl-dev so I don't know why the ssl transition got started. Possibly a human mistake, which is fair. It would have been much more simple if libssl1.1-dev was provided and libssl- dev be kept as it was. Can this be considered? -- Sólo porque un mensaje pueda no ser recibido no implica que no valga la pena enviarlo. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#842958: ITP: r-cran-sourcetools -- tools for reading, tokenizing and parsing R code
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-sourcetools Version : 0.1.5 Upstream Author : Kevin Ushey * URL : https://cran.r-project.org/package=sourcetools * License : MIT Programming Lang: R Description : tools for reading, tokenizing and parsing R code Tools for the reading and tokenization of R code. The 'sourcetools' package provides both an R and C++ interface for the tokenization of R code, and helpers for interacting with the tokenized representation of R code. Remark: This package is needed to upgrade r-cran-shiny to its latest version. It will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-sourcetools/trunk/
Lua [Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)]
On Tue, Nov 01, 2016 at 10:54:33PM +0200, Adrian Bunk wrote: > LUA The language is named "Lua", which means "moon" in Portuguese. https://www.lua.org/about.html#name LUA is an acronym for "Lua Uppercase Accident" ;-). Peter
Re: Lots and lots of tiny node.js packages
Hello Ian,
This is not a personal response to you, I am just pigging back on your
email.
On Tue, Nov 01, 2016 at 08:50:38PM +, Ian Jackson wrote:
> Sruthi Chandran writes ("Bug#840937: ITP: node-kind-of -- Get the native type
> of a value"):
> > * URL : https://github.com/jonschlinkert/kind-of
>
> Pirate Praveen writes ("Bug#842129: ITP: node-path-type -- Check if a path is
> a file, directory, or symlink"):
> > * URL : https://github.com/sindresorhus/path-type#readme
>
> I picked these two almost at random.
>
> I appreciate you're working hard to package up all this web
> application infrastructure. This is an area that Debian is doing
> rather poorly in and it is good to see efforts to improve it.
>
> But:
>
> These are tiny packages and there seem to be lots and lots and lots of
> them.
>
> Every new source package and binary package is (or causes):
> * An entry in Sources and Packages that everyone, even everyone
>who doesn't use it, needs to download
> * A database entry in each of our package management systems
>(the DAK db, the BTS, the PTS/tracker, buildds, etc.)
> * Processing overhead for every Debian system everywhere on
>the planet, while parsing packaging databases, representing
>package graphs
> * A mail like these ITPs
> * Human effort to review it separately in NEW, ITPs, sponsorship (if
>applicable), etc., which would be easier if aggregated
> * Corresponding edges in the Debian dependency graphs
> * Probably several separate git repositories
>
> Our systems are not really set up for so many packages. They were
> designed with the assumption that a package would represent a
> substantial amount of upstream work, so that the Debian overhead is
> modest by comparison.
>
> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?
>
> I don't think it matters very much exactly what the aggregation
> boundaries are but I think given the size of these packages when I
> looked at a couple upstream, you could profitably put many dozens of
> these tiny libraries into a single .dsc and .deb.
As a regular reader of debian-devel, I must say I am frustrated by this
discussion being raised yet another time. We must have had similar
threads, with *the same* arguments, 5 or 6 times in the last year. This
has been discussed to exaustion, and there is no consensus.
Unfortunately if we want to have useful (FSVO useful) stuff that is
written in Javascript/Node.js in the Debian archive, following what we
all accepted as the DFSG and the Debian standards of quality, we will
have to live with it.
I won't repeat any of the arguments that were already provided several
times, because I am tired. If I, who do very little, or none, of the
actual work necessary, am tired, I imagine how the people actually doing
the work feel. I am grateful that there is people willing to put this
work in, so let's please let them do it without rehashing the same
arguments over and over and over every few months.
signature.asc
Description: PGP signature
Bug#842940: ITP: tendermint-go-merkle -- Merkle-ized data structures with proofs
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tendermint-go-merkle Version : 0.0~git20160312.0.05042c6-1 Upstream Author : Tendermint * URL : https://github.com/tendermint/go-merkle * License : Apache-2.0 Programming Lang: Go Description : Merkle-ized data structures with proofs This package provides two types of merkle trees: * IAVL+ Tree: A snapshottable (immutable) AVL+ tree for persistent data * A simple merkle tree for static dataIAVL+ tree; the purpose of this data structure is to provide persistent storage for key-value pairs (say to store account balances) such that a deterministic merkle root hash can be computed. The tree is balanced using a variant of the AVL algortihm so that all operations are O(log(n)). . This package provides a library used by Tendermint Core. . Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine, written in any programming language, and replicates it on many machines.
Bug#842936: ITP: casacore-data-observatories -- Table of radio observatory coordinates for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-observatories Version : 1.0 * URL : https://github.com/casacore/observatory-table * License : Public domain Description : Table of radio observatory coordinates for casacore This package contains a table with radio observatories and their coordinates for the use with casacore. The data is initially taken from Wikipedia, but will be incrementally replaced with verified coordinates. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-igrf.git Best regards Ole
Bug#842935: ITP: casacore-data-tai-utc -- Difference table between TAI and UTC for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-tai-utc * License : BSD-2-Clause Description : Difference table between TAI and UTC for casacore This native package contains the leap second difference between TAI and UTC, created from /usr/share/zoneinfo/leap-seconds.list. The data are in a format specific to casacore. The table is kept in sync with the tzdata package. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-tai-utc.git Best regards Ole
Bug#842934: ITP: casacore-data-predict -- Earth orientation parameter prediction tables for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-predict * URL : http://maia.usno.navy.mil/ * License : Public domain Description : Earth orientation parameter prediction tables for casacore The IERS Prediction tables provide predictions for the time-varying orientation of the terrestrial reference frame within the quasi-inertial celestial reference frame for casacore. The package will contain the `IERSpredict` and `IERSpredict2000` tables for casacore. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-predict.git Best regards Ole
Bug#842933: ITP: casacore-data-eop -- Earth Orientation Parameters database for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-eop * URL : https://hpiers.obspm.fr/iers/eop/eopc04/ * License : Public domain Description : Earth Orientation Parameters database for casacore The Earth Orientation Parameters (EOP) describe the irregularities of the Earth rotation with respect to a non-rotating reference frame. The package will contain the `IERSeop97` and `IERSeop2000` tables for casacore. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-eop.git Best regards Ole
Bug#842932: ITP: itamae -- Simple and lightweight configuration management tool inspired by Chef.
Package: wnpp Severity: wishlist Owner: Scott Leggett Package name: itamae Version : 1.9.9 Upstream Author : Ryota Arai URL : https://github.com/itamae-kitchen/itamae License : MIT Programming Lang: Ruby Description : Simple and lightweight configuration management tool inspired by Chef. Itamae provides a simple way to handle configuration management. It doesn't use an agent, and runs over ssh. The concept is: * Chef-like DSL (but not compatible with Chef) * Simpler and lighter weight than Chef * Only recipes * Idempotent
Bug#842931: ITP: casacore-data-jplde -- Jet Propulsion Laboratory Development Ephemeris for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-jplde * URL : ftp://ssd.jpl.nasa.gov/pub/eph/planets/ascii/ * License : Public domain Description : Jet Propulsion Laboratory Development Ephemeris for casacore The name Jet Propulsion Laboratory Development Ephemeris are a series of models of the Solar System produced at the Jet Propulsion Laboratory in Pasadena, California, primarily for purposes of spacecraft navigation and astronomy. The package will include the `DE200` and `DE405` tables for casacore. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-jplde.git Best regards Ole
Bug#842930: ITP: ruby-schash -- Ruby hash validator
Package: wnpp Severity: wishlist Owner: Scott Leggett Package name: ruby-schash Version : 0.1.2 Upstream Author : Ryota Arai URL : https://github.com/ryotarai/schash License : MIT Programming Lang: Ruby Description : Ruby hash validator. Validate a Ruby hash using a simple schema langauge. I intend to package this as part of pkg-ruby-extras. This package is a dependency of Itamae, which I also intend to package.
Bug#842925: ITP: casacore-data-igrf -- International Geomagnetic Reference Field data for casacore
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-CC: debian-devel@lists.debian.org, debian-as...@lists.debian.org * Package name: casacore-data-igrf Version : 10 or 12 * URL : http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html * License : Public domain Description : International Geomagnetic Reference Field data for casacore This package contains the coefficients for the standard mathematical description of the Earth's main magnetic field that is used widely in studies of the Earth's deep interior, its crust and its ionosphere and magnetosphere. The package is a part of the effort taken by Benda Xu and me within the Debian Astro team to split up the original "casacore-data" package (RFP #761146) by data source into smaller packages which can be maintained independently. The package will be maintained on our git repository under https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data-igrf.git Best regards Ole
Re: Lots and lots of tiny node.js packages
Russ Allbery writes: ... >> The web ecosystem is still changing rapidly, with WebAssembly coming >> soon, so probably things are going to look very different for the >> Debian buster development cycle. > > Indeed. > > I do think the Node community takes this too far, with way too many > micropackages that should just be part of the standard library. But, > well, it works for them, and it's not a totally unreasonable way to handle > things. I think Debian should find ways to stay flexible and adjust and > incorporate those sorts of philosophies about the reusable unit of > code. As an interested observer, this flood of packages certainly is a bit surprising (although it is very nice to see the underlying problem of missing build tools being addressed). However, having seen the case of node-os-homedir, it strikes me that there is one very good reason to package things individually. It focuses our disdain where it is deserved. If this were in a combined package, and if the broken code was only spotted after passing NEW, then it would be much more effort to eject it. It would almost certainly be argued, as you'll see here: https://github.com/sindresorhus/os-homedir/issues/4 that the code should never be reached in the real world, so nothing to worry about. That however glosses over the fact that we have downstreams doing many bizarre things, and that someone might manage to reach the hopeless code, and thus suffer foreseeable bugs. As it is, we can just say "no thanks" to that specific package, with the result that the packages that depend upon os-homedir get patched to use something newer (if they're to be packaged), to the benefit of the whole node.js community. On the other hand, I suspect that a lot of this code is really not fit to be packaged yet ... or at least not for stable. Take a look at: https://github.com/sindresorhus/repeating/blob/master/index.js This a trivial bit of code, which will make those of us not in the node.js community boggle, but let's forget about that for a moment. Let's say that it had been packaged in May this year, at version 2.0.1 and that would make it's way into Stretch, and thus be preserved in aspic until the end of the LTS support. In June, version 3.0.0 was released, which reverses the order of the two parameters. I presume that much of the software that uses that function will rapidly switch to the new ordering, and would have thus found our 2.0.1 package worse than useless. This is not really criticism of the 'repeating' library itself, but just an instance where a slight change of timing seems likely to have resulted in poor outcomes, if we let this sort of software into stable. That said, the decision to swap the parameters is apparently justified by the fact that 99% of the usage of this function is to repeat an empty string: https://github.com/sindresorhus/repeating/issues/6 which makes me realise that I really have no clue whatsoever what they think they are doing in the land of node.js 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: Lots and lots of tiny node.js packages
On 2016-11-02.07:41, Andrew M.A. Cater wrote: > On Wed, Nov 02, 2016 at 12:04:27AM +0100, Marco d'Itri wrote: > > On Nov 01, Ian Jackson wrote: > > > > > Can you explain why you don't aggregate these into bigger packages, > > > for use in Debian ? > > Because the node.js ecosystem is toxic and broken in encouraging > > relasing software which embeds very specific versions of lots of tiny > > libraries, and because Debian is ideologically against duplicating code > > in different packages and build systems downloading code ad built time. > > > > -- > > ciao, > > Marco > > I have to agree with Marco on this from a position of being a watcher on > the side rather than an active developer of much from Ruby on Rails / NPM > (and, earlier, helping to support users of the Maven build ecosystem). > > NPM and Node is probably the worst offender - but there's a huge tendency > to create "magic environments" which pull in random bits of code to build > your software. Most Node bits are tiny - occasionally they'll break ABI / > versioning and everything else. This isn't the idea of a stable Debian > package. > > Ruby on Rails is also pretty much the same - Maven was and is the same, with > the added complication of difficulty of knowing what you get in millions and > millions of parts when the build system hides dependencies and is automagic. Actually, node is in a league of its own in this regard: http://www.modulecounts.com/ -- Regards, Scott. signature.asc Description: Digital signature
Bug#842921: ITP: libextutils-hascompiler-perl -- check for the presence of a compiler
Package: wnpp Severity: wishlist Owner: Nuno Carvalho * Package name: libextutils-hascompiler-perl Version : 0.016 Upstream Author : Leon Timmermans * URL : https://github.com/Leont/extutils-hascompiler * License : Artistic or GPL-1+ Programming Lang: Perl Description : check for the presence of a compiler This module tries to check if the current system is capable of compiling, linking and loading an XS module.
Re: OpenSSL 1.1.0
On Tue, Nov 1, 2016, at 23:49, Kurt Roeckx wrote: > All the filed bugs already contain a link to the porting guide. Is this https://wiki.openssl.org/index.php/1.1_API_Changes a migration guide? This is a very *poor* migration guide and sentences like "In other words, look at the 1.1 code and add the missing functions into your source. " are not very helpful to a person who is just a maintainer and not a full upstream developer who worked with OpenSSL before. My experience with porting is not as happy as your initial email might be as the upstream packages usually want to keep 1.0.0 compatibility together with 1.1.0 compatibility and it's a hell lot of work. Perhaps I am the unlucky one that doesn't fall into "most packages", but from what I've seen so far I am not happy that this happened so deep into release cycle. 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
Bug#842916: ITP: node-snapdragon -- Fast, pluggable and easy-to-use parser-renderer factory
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-snapdragon Version : 0.8.1 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/snapdragon * License : Expat Programming Lang: JavaScript Description : Fast, pluggable and easy-to-use parser-renderer factory.
Re: OpenSSL 1.1.0
Kurt Roeckx wrote: Hi, > There might also be packages for which the changes are more > involved and that can't be fixed in time for the release. If you > want to stay with OpenSSL 1.0.2 you need to change your Build-Depends > from libssl-dev to libssl1.0-dev. Almost expected, this fails where another build-dep pulls in libssl-dev, i.e. adjusting build-dep for src:asterisk output-version: 1.2 native-architecture: amd64 report: - package: sbuild-build-depends-asterisk-dummy version: 0.invalid.0 architecture: amd64 status: broken reasons: - conflict: pkg1: package: libssl1.0-dev version: 1.0.2j-3 architecture: amd64 unsat-conflict: libssl-dev:amd64 pkg2: package: libssl-dev version: 1.1.0b-2 architecture: amd64 depchain1: - depchain: - package: sbuild-build-depends-asterisk-dummy version: 0.invalid.0 architecture: amd64 depends: libssl1.0-dev:amd64 depchain2: - depchain: - package: sbuild-build-depends-asterisk-dummy version: 0.invalid.0 architecture: amd64 depends: libc-client2007e-dev:amd64 - package: libc-client2007e-dev version: 8:2007f~dfsg-4+b1 architecture: amd64 depends: libssl-dev:amd64 Incidentally libc-client2007e-dev has an open FTBFS RC bug against OpenSSL 1.1.0, but a patch is there. So I cannot really ask them to downgrade to libssl1.0-dev as well. Bernhard
Bug#842913: ITP: node-regex-cache -- Memorize the results of a call to the RegExp constructor
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-regex-cache Version : 0.4.3 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/regex-cache * License : Expat Programming Lang: JavaScript Description : Memorize the results of a call to the RegExp constructor, avoiding repetitious runtime compilation of the same string and options, resulting in suprising performance improvements.
Bug#842907: ITP: node-redent -- Strip redundant indentation and indent the string
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-redent Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/redent#readme * License : Expat Programming Lang: JavaScript Description : Strip redundant indentation and indent the string
Re: Bug#842839: ITP: golang-github-golang-leveldb -- The LevelDB key-value database in the Go programming language.
Dear Martin, >> This package is a Go version of the LevelDB lightweight key-value database. >> It is provided as a dependency of stenographer >> (https://github.com/google/stenographer). > > According to the webpage, this package is unfinished and experimental. Yes, now that I take a closer look I also noticed #799472 [1] and the history of the problem [2]. I didn't experience this issue, but it looks like it's a blocker for getting this into Debian. > You are probably better off using https://github.com/syndtr/goleveldb, > which is already packaged. True. Unfortunately github.com/syndtr/goleveldb does not seem to be API compatible with github.com/golang/leveldb, so someone would need to adapt stenographer to work with the different LevelDB engine. I'll bring it up with upstream. I think I will close this for now and follow up on stenographer's ITP [3] once there is progress. Thanks for your input. Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799472 [2] https://github.com/golang/leveldb/issues/25 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795101
Re: Multi-Arch: allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear David, Le 02/11/2016 à 01:05, David Kalnischkies a écrit : > I would add: > > * Check if gyoto-bin really needs to be M-A:allowed. Name, > Description and the list of filenames included in the package > suggest to me that the package can and should be M-A:foreign – or > in other words: Why is it allowed? Up to now, this is purely theoretical as no package outside of src:gyoto depends or build-depends on gyoto-bin. However, I am considering splitting some of the plug-ins into separate source packages, so I have some interest in doing it right. Some background: Gyoto is a framework for doing some type of scientific numerical computations (general relativistic ray-tracing, to be precise). The package is split as follows: - - gyoto: metapackage that depends on the rest; - - gyoto-dbg: the debugging symbols package that we'll drop at some point; - - libgyoto5: the main C++ library plus standard plug-ins, M-A: same; libgyoto5 Recommends gyoto-bin as it needs it for MPI computations (see below); - - libgyoto5-dev: obvious, M-A: same; - - yorick-gyoto, python-gyoto, python3-gyoto: interpreted interfaces for three interpreters. The Python flavours also include Gyoto plug-ins (for using Python from Gyoto). M-A: allowed on the premise that the interpreters are "allowed" themselves, and you can use the interface in an arch-independant manner; - - gyoto-bin contains two binaries: gyoto: command line tool to render XML sceneries into FITS images. If you build-depend on it just to do some ray-tracing with the standard plug-ins, then it really is foreign (to machine precision, the result does not depend on the architecture). If you build-depend on it to test a plug-in, then you need to be running the same architecture as the one of the plug-in. In general, you will need the same arch for all your plug-ins as for the interface. So M-A: foreign looks wrong to me, it is either "no" or "allowed". gyoto-mpi-worker.: This binary is spawned by MPI for parallel computations (possibly running on another computer), independent of whether the parallel computation is started from the gyoto command-line tool above or from on of the interpreted interfaces. There, I actually don't know whether the spawned processes need to be of the same architecture as the spawning process. When running on distinct hosts, I think not, but this case is orthogonal to the Multi-Arch issue. So I am not sure whether "foreign" would work either. > Rule of thumb: Don't make any package M-A:allowed as long as you > haven't got a bugreport telling you it would be nice from some > cross-folks (be it grader, builder, bootstrapper, …). Reason is > that M-A:same/foreign is instantly useable/ful, but M-A:allowed is > useless if nothing ends up depending on it with :any. "foreign" looks wrong to me in this case, we need to be able to build and test plug-ins. On the other hand, my understanding was that "allowed" was "mostly M-A:no unless otherwise specified", so surely it does not hurt? Kind regards and thanks for your explanations. Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYGa+lAAoJEJOUU0jg3ChA/YEP/2LYwjIAxnZWkj/d1Ga552lO gvuGoYMpR5jeE24QaZKWuleVfP2K7/hazL2FKPoO0JR5KVxgDKT8SeocsH3kVbBl U9uPLbuZzkifHMHw9PTNL7EL2OMKKzJAus3pVOTPS+q5pMJ6u73YbIumBQW3xWiE 5uro3puR3fKeroQ+FS8eKY/P+El8avNhGvn6qbAT/+IG+4CgFka2TD9u7VOGHlsQ RYY3IwBFWYal4C87gDbJMMc0bF1TxWqKVDYorTl9ls+1Pcbm5O9J/N1prezuL7uj /IBzz8+cgH0BZhhk6uIEmiyLINLNLIWbwc1/ZxEbZa7gwcWA0HIuDsbaSiV3Va7K 7iUipNQlncGQLqB5R0gTKalwM+/XXLGDMaO4nG1iqVNZVUBGvlmsNmDsTNukyKmR 3AaoIVrgj/dEGVRXQjxH0sEgbrDzM8SDpZDvnWI73cp/Yb5AaazLQnyScs9PCT2y RAM67BnzZ23ysOyQ9AAjz+l7qn18ETmxOQ0zS78BqJKmDZZvD2Anlz7vZydosL2Y mX58rW0xQtYUXytlsLXvseNsEpEPuHgO+gr0cPtYKPoIcIdeV5w9eBYhvvTkJVUW LJ8FXwVtbcfHIcQl7/lj2mSAkHg5kt+QIPVbBUFTQBEl967XYnYxcxISvZJJA4sp eUMahgF0PKHVYcTU4PHY =h5Ja -END PGP SIGNATURE-
Bug#842904: ITP: node-read-pkg-up -- Read the closest package.json file
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-read-pkg-up Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/read-pkg-up#readme * License : Expat Programming Lang: JavaScript Description : Read the closest package.json file
Re: Lots and lots of tiny node.js packages
On Wed, Nov 02, 2016 at 12:04:27AM +0100, Marco d'Itri wrote: > On Nov 01, Ian Jackson wrote: > > > Can you explain why you don't aggregate these into bigger packages, > > for use in Debian ? > Because the node.js ecosystem is toxic and broken in encouraging > relasing software which embeds very specific versions of lots of tiny > libraries, and because Debian is ideologically against duplicating code > in different packages and build systems downloading code ad built time. > > -- > ciao, > Marco I have to agree with Marco on this from a position of being a watcher on the side rather than an active developer of much from Ruby on Rails / NPM (and, earlier, helping to support users of the Maven build ecosystem). NPM and Node is probably the worst offender - but there's a huge tendency to create "magic environments" which pull in random bits of code to build your software. Most Node bits are tiny - occasionally they'll break ABI / versioning and everything else. This isn't the idea of a stable Debian package. Ruby on Rails is also pretty much the same - Maven was and is the same, with the added complication of difficulty of knowing what you get in millions and millions of parts when the build system hides dependencies and is automagic. Not everyone is well disciplined: most Linux distributions seem to have given up in disgust so we have parallel ecosystems which don't trust or understand the other - but you need a Linux distribution to be able to run it. Meh All the best Andy C.
