On 2016, ഡിസംബർ 13 1:48:33 AM IST, Vincent Danjean wrote:
> I suppose these communities (js, nodejs, ...) do not generally have
>test suites for their libraries...
Node packages usually have tests, for most packages we have test suites
packaged already (mocha, tap, chai), but still many test
Le 12/12/2016 à 19:02, Pirate Praveen a écrit :
> Updating a library is a difficult task compared to packaging new
> libraries or applications.
With all the explanations in this thread, its logical. But it the
reverse of what I experimented in nearly all parts of Debian I've
been involved (C/Perl/
❦ 12 décembre 2016 20:51 +0100, Vincent Bernat :
>> Why -unicode, that's obvious. Here's why -256color: thanks to a misdesign,
>> there's no way to detect 256 color support nor the used palette and trying
>> to use it when not supported results in visual breakage.
>
> Isn't that possible with t
❦ 12 décembre 2016 18:42 +0100, Adam Borowski :
> Why -unicode, that's obvious. Here's why -256color: thanks to a misdesign,
> there's no way to detect 256 color support nor the used palette and trying
> to use it when not supported results in visual breakage.
Isn't that possible with terminfo
tl;dr: I'm on board. popcon doesn't cover rclock, transition shouldn't
drop it. Worry about the number of rxvt-ml's out there for non-ascii
compatible encodings.
On Mon, Dec 12, 2016 at 12:42 PM, Adam Borowski wrote:
> I'd like to propose one migration:
> let's replace "rxvt" and "rxvt-unicode
On തിങ്കള് 12 ഡിസംബര് 2016 10:03 വൈകു, Antonio Terceiro wrote:
> On Mon, Dec 12, 2016 at 12:38:47PM +0530, Pirate Praveen wrote:
>> 1. When handling fragile languages (javascript, ruby, go and possibly
>> more),
>
> I think that this view of "fragile languages" is very misleading, and
> perhaps
On തിങ്കള് 12 ഡിസംബര് 2016 08:29 വൈകു, Ian Jackson wrote:
> This is quite a checklist. Frankly, in Paul's position, I probably
> wouldn't have thought of such a list and if I had I would have
> concluded that the problem was too hard, and go and spend my effort
> somewhere else.
>
> What would
On Mon, Dec 12, 2016 at 11:20:33AM +0100, Adrien CLERC wrote:
> Multibyte encodings such as utf8 are not supported
>
> Is that still an issue? I highly doubt that a terminal application that
> doesn't support UTF8 is useful nowadays.
Right. This reminds me of a 2011 debian-devel thread:
Me:
} I
On Mon, Dec 12, 2016 at 05:13:38PM +0100, Christian Seiler wrote:
> It's even funnier: the complaint here is actually fruitless,
> because I have actually helped Sruthi to patch out the usage of
> node-user-home from node-v8flags - it's now in the NEW queue:
> https://ftp-master.debian.org/new/node
On Mon, Dec 12, 2016 at 10:10:57AM -0700, Sean Whitton wrote:
> Hello Josh,
>
> On Sun, Dec 11, 2016 at 09:48:17PM -0800, Josh Triplett wrote:
> > dpkg-shlibdeps automatically generates Depends on library packages
> > corresponding to any libraries pulled in by the linker for the binaries
> > in a
On Mon, Dec 12, 2016 at 10:10:57AM -0700, Sean Whitton wrote:
> > dpkg-shlibdeps automatically generates Depends on library packages
> > corresponding to any libraries pulled in by the linker for the binaries
> > in a package. However, library -dev packages still have to manually
> > specify Depen
Hello Josh,
On Sun, Dec 11, 2016 at 09:48:17PM -0800, Josh Triplett wrote:
> dpkg-shlibdeps automatically generates Depends on library packages
> corresponding to any libraries pulled in by the linker for the binaries
> in a package. However, library -dev packages still have to manually
> specify
> Did you document your attempts so people willing to help have a point
> to start from?
No, and all the blame for that goes to me.
BTW the same holds for all of my other packages, I'm more than willing
to accept help/co-maintainership.
Thanks for the patch.
Michael
--
Michael Meskes
Michael
On Mon, Dec 12, 2016 at 12:38:47PM +0530, Pirate Praveen wrote:
> 1. When handling fragile languages (javascript, ruby, go and possibly
> more),
I think that this view of "fragile languages" is very misleading, and
perhaps a little dangerous. There are no fragile languages, but fragile
projects. Y
Sorry for the long delay to this response; it got pre-empted by
something more urgent, and then I forgot about it.
On Sun, 18 Sep 2016 at 22:19:38 +0900, Osamu Aoki wrote:
> So listing im-config in MBF seems to be FALSE POSITIVE if it is only
> based on this string in the comment.
Yes, looks like
On 12/12/2016 04:22 PM, Holger Levsen wrote:
> On Mon, Dec 12, 2016 at 04:08:15PM +0100, Lars Wirzenius wrote:
>> On Mon, Dec 12, 2016 at 11:56:53AM -0300, Fernando Toledo wrote:
>>> A package to get user home path ?
>>> The world is dying...
>> We've had a number of discussions about nodejs's appr
Package: wnpp
Severity: wishlist
Owner: Sophie Brun
* Package name: lua-sandbox-extensions
Version : 0~git20161128
Upstream Author : Mike Trinkala
* URL : https://github.com/mozilla-services/lua_sandbox_extensions
* License : MPL-2.0
Programming Lang: C, lua
Package: wnpp
Severity: wishlist
Owner: Roger Shimizu
X-Debbugs-Cc: debian-devel@lists.debian.org, rogershim...@gmail.com
* Package name: brother-inkjet-dcpj952n
Version : 3.0.0-2
Upstream Author : Brother. Industries, Ltd.
* URL :
http://support.brother.co.jp/j/b/dow
On Mon, Dec 12, 2016 at 04:08:15PM +0100, Lars Wirzenius wrote:
> On Mon, Dec 12, 2016 at 11:56:53AM -0300, Fernando Toledo wrote:
> > A package to get user home path ?
> > The world is dying...
> We've had a number of discussions about nodejs's approach to what is a
> suitable library/package size
On Mon, Dec 12, 2016 at 11:56:53AM -0300, Fernando Toledo wrote:
> A package to get user home path ?
> The world is dying...
We've had a number of discussions about nodejs's approach to what is a
suitable library/package size. Can we please not have that again?
--
I want to build worthwhile thin
Pirate Praveen writes ("Re: What happened to the idea of using migrations and
coordinated uploads when updating packages that has many reverse
dependencies?"):
> On ചൊവ്വ 06 ഡിസംബര് 2016 01:26 രാവിലെ, Paul Gevers wrote:
> > Sorry, and to prevent further damage, I'll not touch existing JavaScript
El 11/12/16 a las 08:28, Sruthi Chandran escribió:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Sruthi Chandran
>> X-Debbugs-CC: debian-devel@lists.debian.org
>>
>> * Package name: node-user-home
>> Version : 2.0.0
>> Upstream Author : Sindre Sorhus
>> (sindresorhus.com)
>> *
On Mon, Dec 12, 2016 at 11:20:33AM +0100, Adrien CLERC wrote:
> >From the main page:
> Multibyte encodings such as utf8 are not supported, because Python is buggy.
>
> Is that still an issue? I highly doubt that a terminal application that
> doesn't support UTF8 is useful nowadays.
I would agree,
2016-12-09 0:12 GMT+02:00 Christoph Biedl :
> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
> it gives a bad feeling having to trash them some day just because
> there's no support any more.
>
> On the other hand, they face another problem I guess is typical for
> that gene
Hello Josh Triplett,
Manually handling the dependencies of -dev packages often leads to
mistakes. Automating this similar to how you describe has multiple times
surfaced where I'm involved (and I guess also in other places).
Unfortunately noone has volunteered to actually implement it. Thanks for
Package: wnpp
Severity: wishlist
Owner: Paolo Greppi
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-liftoff
Version : 2.3.0
Upstream Author : Tyler Kellen (http://goingslowly.com/)
* URL : https://github.com/js-cli/js-liftoff
* License : Expat
Package: wnpp
Severity: wishlist
Owner: Paolo Greppi
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-fined
Version : 1.0.2
Upstream Author : JS CLI Team (https://github.com/js-cli)
* URL : https://github.com/js-cli/fined#readme
* License : Expa
Le 11/12/2016 à 23:39, Ferenc Wágner a écrit :
> * Package name: tcvt
> Version : git snapshot 82c24e2
> Upstream Author : Helmut Grohne
> * URL : http://subdivi.de/~helmut/tcvt/
>From the main page:
Multibyte encodings such as utf8 are not supported, because Python is
Package: wnpp
Severity: wishlist
Owner: Paolo Greppi
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-parse-filepath
Version : 1.0.1
Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/parse-filep
Package: wnpp
Severity: wishlist
Owner: Paolo Greppi
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-path-root
Version : 0.1.1
Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/path-root
* Lice
On Mon, Dec 12, 2016 at 5:22 AM, Josh Triplett wrote:
> If we can get every package to handle this entirely at runtime, then
> ideally I'd suggest archive metadata downloaded by apt. That would have
> the advantage of automatically handling new sections, including for
> third-party archives. Pac
Package: wnpp
Owner: Christopher Hoskin
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libchi-memoize-perl
Version : 0.07
Upstream Author : Jonathan Swartz
* URL : https://metacpan.org/release/CHI-Memoize
*
On 12/12/2016 12:40 AM, Christian Seiler wrote:
> I've attached a git patch against your current packaging (you can
> use git am to apply it) that does just this. I've tried building
> it in sbuild -d unstable and it works - and the tests pass.
>
> Hope that helps.
Thanks!!! That helped.
signatu
33 matches
Mail list logo
