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
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 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
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
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
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-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
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
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
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
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,
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)
>> *
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
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
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
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
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
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
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 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
> 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
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
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
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 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 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 തിങ്കള് 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 തിങ്കള് 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
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
❦ 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
❦ 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
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/
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
33 matches
Mail list logo
