Bug#850405: ITP: node-imurmurhash -- An incremental implementation of MurmurHash3

[Roshan]

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

* Package name: node-imurmurhash
  Version : 0.1.4
  Upstream Author : Jens Taylor  (
https://github.com/homebrewing)
* URL : https://github.com/jensyt/imurmurhash-js
* License : Expat
  Programming Lang: JavaScript
  Description : An incremental implementation of MurmurHash3

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Adam Borowski]

On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote:
> On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote:
> > Neither systemd-shim nor consolekit are solutions that are viable in
> > the long term, the sooner we get rid of both, the better.  I don't
> > know what's a good alternative, though.  Loginkit is
> > vapourware.  Elogind maybe?
> 
> With elogind do you mean https://github.com/wingo/elogind?  That
> project doesn't look very active.
> 
> Is there any active project trying to reimplement the logind API? 

Consolekit2 for example; it suffers from being a fork of consolekit codebase
though.

I haven't done the research, my current solution works for me so far (even
if I know it's not going to last).

> Including access to devices (which X wants these days)?

That's just for ancient graphics cards (ie, with no KMS/DRM support) without
xserver-xorg-legacy, right?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#850401: ITP: node-json-schema -- JSON Schema validation and specifications

[Amarpreet Singh Arora]

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

* Package name: node-json-schema
  Version : 0.2.3
  Upstream Author : Kris Zyp
* URL : https://github.com/kriszyp/json-schema#readme
* License : AFLv2.1
  Programming Lang: JavaScript
  Description : JSON Schema validation and specifications

Bug#850399: ITP: node-cli-boxes -- Boxes for use in the terminal

[Pradnya Hulle]

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

* Package name: node-cli-boxes
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/cli-boxes
* License : Expat
  Programming Lang: JavaScript

Bug#850398: ITP: node-sumchecker -- Checksum validator

[nikhil gawande]

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

* Package name: node-sumchecker
  Version : 1.3.0
  Upstream Author : Mark Lee
* URL : https://github.com/malept/sumchecker#readme
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Checksum validator

Bug#850397: ITP: node-arrify -- Convert a value to an array

[Ravishankar Purne]

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

* Package name: node-arrify
  Version : 2.0.1
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/arrify#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Convert a value to an array

Re: Converting to dgit

[Scott Kitterman]

On Friday, January 06, 2017 12:29:54 AM IOhannes m zmölnig wrote:
> On 01/04/2017 05:42 AM, Colin Watson wrote:
> > git-dpm does too, and I agree it's nice.
> 
> here's an opposite data point:
> 
> being forced to use git-dpm by the python-modules-team policy - i
> haven't had a single joyful experience with git-dpm.
> so far, every import of a new upstream release turned into a nightmare
> with an extra working clone of the repository, and skimming through the
> same man- and webpages full of outdated documentation even though i'm
> pretty sure that the required information was there the last time i looked.
> 
> git-dpm might be useful if you use it daily.
> as it stands, i'm a very happy gbp user (without fancy addons) for
> almost all of my packages, and the few python modules i maintain don't
> do releases that often (which explains why i don't get a routine for
> doing new upstream imports with git-dpm).

I don't use it often enough to remember all the details either.  I don't 
recall the last time I had to do more than copy/paste a command from the man 
page (OK, git-dpm tag I can remember).

Scott K

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

Re: Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

[Nicholas D Steeves]

On Fri, Jan 06, 2017 at 10:01:38AM +0800, Paul Wise wrote:
> On Thu, Jan 5, 2017 at 9:32 PM, Christian Seiler wrote:
>
> > Could we maybe hide library packages from apt searches by default?
>
> This is going to have unintended consequences; for example, if we base
> it on Debian Section fields, library source packages that build a
> binary package containing tools, that are (incorrectly) put into the
> libs section, will not be found by users.

If ever something like this does go through, would it be possible to
limit it to UIDs != 0?  Eg: Hiding lib packages would be limited to
'apt-cache search' called as a non-root user without using sudo.

> > I think most users don't care about libraries in any language (be it
> > Perl, C, JS, Python, ...), but only care about software they
> > use directly. And developers that do care about libraries could pass
> > a flag to APT to say "yeah, please show me all packages that match
> > this". And maybe even indicated how many library packages were not
> > shown in the default search results?
>
> How would you propose to implement that? apt currently doesn't have
> enough metadata about packages to say if they are end-user tools or
> not, and it depends on the user which tools are acceptable. For
> example; some folks can deal with the command-line but the majority of
> humanity cannot, some folks dislike particular GUI toolkits, etc.

Isn't this something the "GNOME Software" application addresses?
Additionally, thought I'm at least two years out of date with
packagekit news/status/frustrations, I wonder if it already has one
half of a distro-agnostic method to implement this...

Cheers,
Nicholas

Bug#850395: ITP: tpm-quote-tools -- programs that provide support for TPM based attestation using the TPM quote operation

[Andrew Pollock]

Package: wnpp
Severity: wishlist
Owner: Andrew Pollock 

* Package name: tpm-quote-tools
  Version : 1.0.2
  Upstream Author : John D. Ramsdell 
* URL : https://sourceforge.net/projects/tpmquotetools
* License : BSD
  Programming Lang: C
  Description : collection of programs that provide support for TPM based 
attestation using the TPM quote operation

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Paul Wise]

On Fri, Jan 6, 2017 at 3:27 AM, Sean Whitton wrote:

> Could you explain "lower bus factor" a bit more, please?

Don already explained this for the BTS, but in general, many if not
most of the services Debian provides are maintained by 0.5 person (one
busy person who already has lots of other responsibilities) or 1
person teams.

If you or others have time to spare, please consider regularly
spending time on some of the services Debian provides or becoming
co-maintainer of one of them:

https://wiki.debian.org/Services

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

[Paul Wise]

On Thu, Jan 5, 2017 at 9:32 PM, Christian Seiler wrote:

> Could we maybe hide library packages from apt searches by default?

This is going to have unintended consequences; for example, if we base
it on Debian Section fields, library source packages that build a
binary package containing tools, that are (incorrectly) put into the
libs section, will not be found by users.

> I think most users don't care about libraries in any language (be it
> Perl, C, JS, Python, ...), but only care about software they
> use directly. And developers that do care about libraries could pass
> a flag to APT to say "yeah, please show me all packages that match
> this". And maybe even indicated how many library packages were not
> shown in the default search results?

How would you propose to implement that? apt currently doesn't have
enough metadata about packages to say if they are end-user tools or
not, and it depends on the user which tools are acceptable. For
example; some folks can deal with the command-line but the majority of
humanity cannot, some folks dislike particular GUI toolkits, etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Work-needing packages report for Jan 6, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1041 (new: 4)
Total number of packages offered up for adoption: 149 (new: 0)
Total number of packages requested help for: 47 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cyclades-serial-client (#849719), orphaned 6 days ago
 Description: Network Serial port client software for Cyclades
   terminal servers
 Installations reported by Popcon: 8
 Bug Report URL: http://bugs.debian.org/849719

   ivykis (#849917), orphaned 3 days ago
 Description: Asynchronous I/O readiness notification library
 Reverse Depends: libivykis-dev libivykis0-dbg syslog-ng-core
   syslog-ng-dev syslog-ng-mod-basicfuncs-plus syslog-ng-mod-date
   syslog-ng-mod-grok syslog-ng-mod-kafka syslog-ng-mod-lua
   syslog-ng-mod-perl (5 more omitted)
 Installations reported by Popcon: 1525
 Bug Report URL: http://bugs.debian.org/849917

   libnss-extrausers (#849773), orphaned 6 days ago
 Description: nss module to have an additional passwd, shadow and
   group file
 Installations reported by Popcon: 40
 Bug Report URL: http://bugs.debian.org/849773

   seahorse-nautilus (#849727), orphaned 6 days ago
 Description: Nautilus extension for Seahorse integration
 Installations reported by Popcon: 612
 Bug Report URL: http://bugs.debian.org/849727

1037 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 149 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4454 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 25
 Bug Report URL: http://bugs.debian.org/278442

   autopkgtest (#846328), requested 36 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 589
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 1929 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 686
 Bug Report URL: http://bugs.debian.org/642906

   cardstories (#624100), requested 2082 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7
 Bug Report URL: http://bugs.debian.org/624100

   cups (#532097), requested 2770 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (65 more omitted)
 Installations reported by Popcon: 170123
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 470 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (128 more omitted)
 Installations reported by Popcon: 188713
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 174 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 61230
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 859 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 18964
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 464 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (25 more
   omitted)
 Installations reported by Popcon: 12802
 Bug Report URL: http://bugs.debian.org/800413

   ejabberd (#767874), requested 794 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd

Re: Feedback on 3.0 source format problems

[Matthieu Caneill]

Hi Sean,

On Thu, Jan 05, 2017 at 01:05:54PM -0700, Sean Whitton wrote:
> On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote:
> > https://sources.debian.net/patches/ goes in that direction. AFAIK it
> > might not be complete and TTBOMK it hasn't been announced widely but
> > it exists and (I think) works for "3.0 (quilt)" packages.
> > 
> > For an example of a package using git-debcherry cf.
> > https://sources.debian.net/patches/libmodule-build-perl/0.422000-1/
> 
> Just to confirm, are you saying that sources.debian.net/patches would
> execute git-debcherry on a 3.0 (quilt) package using
> single-debian-patch, presumably by cloning Vcs-Git?  Does this have to
> be explicitly requested for that package?

No, sources.debian.net/patches is not aware of any VCS. It parses on
the fly the series and the patches of a package (and only for
3.0 (quilt) presently). Still, this allows having URLs to point
upstream to, for released packages.

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Re: Converting to dgit

[Debian/GNU]

On 01/04/2017 05:42 AM, Colin Watson wrote:
> git-dpm does too, and I agree it's nice.

here's an opposite data point:

being forced to use git-dpm by the python-modules-team policy - i
haven't had a single joyful experience with git-dpm.
so far, every import of a new upstream release turned into a nightmare
with an extra working clone of the repository, and skimming through the
same man- and webpages full of outdated documentation even though i'm
pretty sure that the required information was there the last time i looked.

git-dpm might be useful if you use it daily.
as it stands, i'm a very happy gbp user (without fancy addons) for
almost all of my packages, and the few python modules i maintain don't
do releases that often (which explains why i don't get a routine for
doing new upstream imports with git-dpm).


gfmrds
IOhannes



signature.asc
Description: OpenPGP digital signature

Re: Converting to dgit

[Nikolaus Rath]

On Jan 05 2017, Sean Whitton  wrote:
> On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote:
>> But, as far as I can tell, doing this work up-front is much easier:
>
> Yes, but you have to do it every single time you make changes that you
> want to be able to push (i.e. more than once per upload).

What do you mean with "it"? You don't have to resolve any conflicts
unless you update to a new upstream that conflicts with your patches, or
unless you change a patch in such a way that it conflicts with a
different patch.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Converting to dgit

[Sean Whitton]

On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote:
> But, as far as I can tell, doing this work up-front is much easier:

Yes, but you have to do it every single time you make changes that you
want to be able to push (i.e. more than once per upload).  For a lot of
packages I maintain, this isn't worth it.  I appreciate that this may
not apply to other kinds of package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Converting to dgit

[Nikolaus Rath]

On Jan 05 2017, Sean Whitton  wrote:
> Dear Nikolaus,
>
> On Wed, Jan 04, 2017 at 09:44:14AM -0800, Nikolaus Rath wrote:
>> No, that's a misunderstanding.
>> 
>> "The information I need" is the Debian-specific modifications to the
>> current upstream source, separated into logically independent patches.
>> 
>> Having separate patches in debian/patches gives me this information very
>> quickly.
>> 
>> Having to run git log, and then to manually merge the the commits gives
>> me the same information, but it is not "very quickly".
>> 
>> 
>> This is the drawback of the single-debian-patch approach. The fact that
>> the patches are available in individual Git commits no longer helps
>> after a few merges.
>
> Thanks for your reply.  I see what you mean.
>
> The difference between our approachs seems to be whether we do the
> semantic work up front, when making an upload, or later, when extracting
> information by means of `git log` and `git diff`.

But, as far as I can tell, doing this work up-front is much easier:

When using git-dpm or gbp-pq, the tool will present you with the
conflicts separately for each Debian-modification that is being
rebased. Resolving the conflicts is the only work you have to do.

If you do the work later, then you start with a bunch of commits, any of
which potentially contains parts of multiple Debian modifications. It is
not clear how me how you would go about untangling them in a systematic
way.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


signature.asc
Description: PGP signature

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Don Armstrong]

On Thu, 05 Jan 2017, Sean Whitton wrote:
> Right, but I'd like to hear a bit more from Paul about this is
> relevant for the spam issue.

Currently only Blars and myself are doing anything with the spam in the
BTS. [And I have very limited time which I'm spending primarily on BTS
development and keeping my packages in some semblance of shape.]

-- 
Don Armstrong  https://www.donarmstrong.com

He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello Ian,

On Wed, Jan 04, 2017 at 12:08:57PM +, Ian Jackson wrote:
> git-dpm sort of does this.  I have been experimenting with and
> blundering towards another approach, which is closer to raw git.
> 
> Something like this:
> 
>--/--A-/---B3---/--> interchange view
> ///
>//3
>   ///
>  222
> ///
>111
>   ///
> ---p-p--Ap---B---> `packaging-only' branch
>   / / /
>--#-#---#-> upstream

Could you explain in general terms the difference between the
interchange and packaging-only branches?  Does the packaging-only branch
contain debian/ alone?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello,

On Tue, Jan 03, 2017 at 06:48:10PM -0800, Nikolaus Rath wrote:
> I'd think that anything that's relevant for upstream development is
> forwarded to upstream by the maintainer in whatever format upstream
> prefers. This requires extra time, but I would be surprised to hear if
> there are maintainers that have sufficient time to create patches that
> are suitable for upstream, but don't have the little extra time to send
> them upstream.

On Wed, Jan 04, 2017 at 02:47:36PM +1000, Russell Stuart wrote:
> This is not a novel requirement.  Most projects I've worked with insist
> you rebase your patches.  This is not new.  Before git they insisted
> your patches applied cleanly - which amounts to the same thing. 
> Breaking up large patches into a series of smaller independent patches
> each with a simple and documented purpose isn't an unusual requirement
> either.

Indeed.  When forwarding a patch upstream, you'll need to ensure it
applies cleanly.  The easiest way is to start a new branch based on the
current upstream HEAD, and cherry-pick your commit onto it.  git
minimises the amount of manual resolution required.

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote:
> I can't think of an example where having a patch history somewhere else
> than within the patch itself is useful. My thinking is probably limited
> by my workflow :) Would you have an example where and how this could be
> usefull?

In most cases, when you merge a new upstream release, git transparently
handles dropping and refreshing patches, which saves a lot of time.  For
example, after forwarding a patch upstream as I just described, merging
a new upstream release will not usually result in any conflicts, even if
the cherry-pick required manual resolution.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Feedback on 3.0 source format problems

[Sean Whitton]

Hello gregor,

On Wed, Jan 04, 2017 at 03:10:16AM +0100, gregor herrmann wrote:
> On Tue, 03 Jan 2017 20:15:10 +, Sean Whitton wrote:
> 
> > On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote:
> > > Well, if we had one more thing: a patches.debian.org service that would
> > > show the git-debcherry-extracted patches against upstream.  I really like
> > > being able to just point upstream at all the patches relevant to them that
> > > Debian has applied.
> > That would be great.  Then the git-debcherry series would be available
> > for those that want it, without requiring package maintainers to do any
> > curation at all.
> 
> https://sources.debian.net/patches/ goes in that direction. AFAIK it
> might not be complete and TTBOMK it hasn't been announced widely but
> it exists and (I think) works for "3.0 (quilt)" packages.
> 
> For an example of a package using git-debcherry cf.
> https://sources.debian.net/patches/libmodule-build-perl/0.422000-1/

Just to confirm, are you saying that sources.debian.net/patches would
execute git-debcherry on a 3.0 (quilt) package using
single-debian-patch, presumably by cloning Vcs-Git?  Does this have to
be explicitly requested for that package?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Sean Whitton]

Hello Christian,

On Thu, Jan 05, 2017 at 08:51:01PM +0100, Christian Seiler wrote:
> On 01/05/2017 08:27 PM, Sean Whitton wrote:
> > On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
> >> The solution is simply a lower bus factor in all Debian services,
> >> including the BTS [...]
> > 
> > Could you explain "lower bus factor" a bit more, please?
> 
> https://en.wikipedia.org/wiki/Bus_factor

Right, but I'd like to hear a bit more from Paul about this is relevant
for the spam issue.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Christian Seiler]

On 01/05/2017 08:27 PM, Sean Whitton wrote:
> On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
>> The solution is simply a lower bus factor in all Debian services,
>> including the BTS [...]
> 
> Could you explain "lower bus factor" a bit more, please?

https://en.wikipedia.org/wiki/Bus_factor

Regards,
Christian

Re: Converting to dgit

[Sean Whitton]

Dear Nikolaus,

On Wed, Jan 04, 2017 at 09:44:14AM -0800, Nikolaus Rath wrote:
> No, that's a misunderstanding.
> 
> "The information I need" is the Debian-specific modifications to the
> current upstream source, separated into logically independent patches.
> 
> Having separate patches in debian/patches gives me this information very
> quickly.
> 
> Having to run git log, and then to manually merge the the commits gives
> me the same information, but it is not "very quickly".
> 
> 
> This is the drawback of the single-debian-patch approach. The fact that
> the patches are available in individual Git commits no longer helps
> after a few merges.

Thanks for your reply.  I see what you mean.

The difference between our approachs seems to be whether we do the
semantic work up front, when making an upload, or later, when extracting
information by means of `git log` and `git diff`.

Based on this discussion we've been having, it seems that each of these
approaches would be advantageous for different packages, depending on
the number of patches that aren't likely to be merged upstream, and the
likelihood that someone will need a tidied patch queue of changes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Sean Whitton]

Hello Paul,

On Wed, Jan 04, 2017 at 09:24:32AM +0800, Paul Wise wrote:
> The solution is simply a lower bus factor in all Debian services,
> including the BTS [...]

Could you explain "lower bus factor" a bit more, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850297: ITP: ldap-csvexport -- easily and quickly export LDAP entries into CSV format

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ldap-csvexport
  Version : 1.9
  Upstream Author : Benedikt Hallinger 
* URL : http://ldap-csvexport.sourceforge.net/
* License : GPL
  Programming Lang: Perl
  Description : easily and quickly export LDAP entries into CSV format

ldap-csvexport is a tool that lets the user easily and quickly export
LDAP entries into arbitrary CSV format files.

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlhunMQxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8paTfg/9Gb8TX3Aq4PUYkaXG/v/V41S8Gsgj
tf8X71sW/apvF6ie3eJuxidxUsBOl1CrxHLXCe/ZzexxGQZOKmlN0CuwV+iSxujY
dpzcB0AlwKkQQcBYVDGS3H7EonPRiQ0mqzlweeVbC7g98FJPOjLkQ0Uc6HpUGS65
TEay5c09c1som12BKkM+sz1+ocUngS6jOhxBM0gT6iqUq3EqvTIZZv33GxOCP9FL
8ACn0jZ4DIH6li/APsNWujGfzcW96Rfa7wdY8JlYQMtrMh6zu78OiBZ+HT54HkHR
JFe4ByRYgq1z4GCjpifVql3XuXg1P98aLgihzqD2ozzAxxZffRjN2sAsP/0C4wuM
dgzUHEpi7YUJCrNAhpuki1JA30E7twQZy6HupKlDVEqph4PAww3MnrRAFZAX6OYN
ls2hNKBoouLfOgY8p8yGnYZaXXd8J0Hlvp4BB4UeItqH+Icdd0PDN9GSCl8eCNh+
IPAYxkhTAtkcFm3jYsl2N/gnhutL7INZNISDd2HzIggJ3gy5hwrqak/GtrJtcE5I
hod828sbANgkZizCFggbgr0E7/olkqsun97PWWn9BbLpbeUgljDkKra9ODYnxyZK
fWoMGkgRGoOKbnnJ/qlSXnbZnLnK42oZqB9CI/LdssieFJFnF80OA0YsdwbtnYi9
Tyo3ycrX8VtgEdI=
=meyu
-END PGP SIGNATURE-

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 05.01.2017 um 19:56 schrieb Michael Biebl:
> Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
> and make it executable.

Obviously, the wrapper script should start systemd-shim.orig.

Fixed one attached.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#!/bin/sh

# We rely on cgmanager to setup /sys/fs/cgroup
if ! mountpoint -q /sys/fs/cgroup; then
echo "cgmanager has not setup /sys/fs/cgroup or is not running, exiting"
exit 1
fi

# Mount legacy cgroup controller at /sys/fs/cgroup/systemd
if ! mountpoint -q /sys/fs/cgroup/systemd; then
mkdir -p /sys/fs/cgroup/systemd
mount -t cgroup -o nosuid,noexec,nodev,none,name=systemd systemd 
/sys/fs/cgroup/systemd
fi

mkdir -p /run/systemd

exec /usr/lib/x86_64-linux-gnu/systemd-shim.orig


signature.asc
Description: OpenPGP digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 04.01.2017 um 20:12 schrieb Ian Jackson:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things 
> [and 1 more messages]"):
>> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
>>> I think #844785 needs a fix though. 
>>
>> Agreed. Does anyone who uses sysvinit want to look into this?
> 
> Um, me ?  Well, I don't particularly want to but I intend to.
> Help from all quarters gratefully accepted.

Assuming you use amd64 (adjust the paths if necessary for i386):
# mv /usr/lib/x86_64-linux-gnu/systemd-shim 
/usr/lib/x86_64-linux-gnu/systemd-shim.orig

Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
and make it executable.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#!/bin/sh

# We rely on cgmanager to setup /sys/fs/cgroup
if ! mountpoint -q /sys/fs/cgroup; then
echo "cgmanager has not setup /sys/fs/cgroup not running, exiting"
exit 1
fi

# Mount legacy cgroup controller at /sys/fs/cgroup/systemd
if ! mountpoint -q /sys/fs/cgroup/systemd; then
mkdir -p /sys/fs/cgroup/systemd
mount -t cgroup -o nosuid,noexec,nodev,none,name=systemd systemd 
/sys/fs/cgroup/systemd
fi

mkdir -p /run/systemd

exec /usr/lib/x86_64-linux-gnu/systemd-shim


signature.asc
Description: OpenPGP digital signature

Bug#850290: ITP: node-xdg-basedir -- Get XDG Base Directory paths

[Vinay Desai]

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

* Package name: node-xdg-basedir
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/xdg-basedir
* License : Expat
  Programming Lang: JavaScript
  Description : Get XDG Base Directory paths

Re: Worthless descriptions for almost all of the recent node-* ITPs (was: Re: Worthless node-* package descriptions in ITPs)

[Philip Hands]

Christian Seiler  writes:

> On 01/05/2017 02:06 PM, Jonas Smedegaard wrote:
>> Quoting Riku Voipio (2017-01-05 12:53:16)
>>> Vast majority of users would only install this via dependencies. It's 
>>> hardly a node-specific problem that debian package searches output 
>>> large amount of packages that are not useful unless you happen to be a 
>>> programmer.
>> 
>> ...and I agree that the issue is not specific to node-* packages, but I 
>> find it is quite common there.  Quite likely due to recent inclusion of 
>> lots of packages, prepared semi-automated - as Philip pointed out very 
>> well.
>
> Could we maybe hide library packages from apt searches by default?

I think you are perhaps misinterpreting my original subject line as
saying that the node packages themselves are somehow not of interest.

Sorry for not making that clearer in the original subject, perhaps the
new one is better?

I was only referring to the quality of the descriptions -- I don't know
enough about node.js to comment on the merit of the packages themselves,
nor their likelihood of being of interest to people.

The example I picked out was laughably useless, but most of them are
packed with field-specific jargon in the short description, and lack a
long description.

We (as a group) appear to be learning to treat "node-*" as a flag
indicating that one does not need to pay attention.  That would seem to
be the reason that these ITPs mostly go without comment, and thus the
package gets uploaded with the same flaws.

I encourage people to take a closer look, and to comment on what they
find -- I've only scratched the surface, and have had a pretty good
hit-rate finding things (in addition to the missing descriptions) that
are worth commenting on.

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: Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

[Jonas Smedegaard]

Quoting Christian Seiler (2017-01-05 14:32:45)
> On 01/05/2017 02:06 PM, Jonas Smedegaard wrote:
>> Quoting Riku Voipio (2017-01-05 12:53:16)
>>> Vast majority of users would only install this via dependencies. 
>>> It's hardly a node-specific problem that debian package searches 
>>> output large amount of packages that are not useful unless you 
>>> happen to be a programmer.
>> 
>> ...and I agree that the issue is not specific to node-* packages, but 
>> I find it is quite common there.  Quite likely due to recent 
>> inclusion of lots of packages, prepared semi-automated - as Philip 
>> pointed out very well.
>
> Could we maybe hide library packages from apt searches by default? I 
> think most users don't care about libraries in any language (be it 
> Perl, C, JS, Python, ...), but only care about software they use 
> directly. And developers that do care about libraries could pass a 
> flag to APT to say "yeah, please show me all packages that match 
> this". And maybe even indicated how many library packages were not 
> shown in the default search results?

Sounds like a nice UI improvement if package managers could 
(optionally!) skip package sections considered less relevant.

In my opinion that does not, however, change the need for package 
descriptions to be generally understandable, no matter the package 
section.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Hiding library packages from apt searches by default?

[Ole Streicher]

Christian Seiler  writes:
> Could we maybe hide library packages from apt searches by default? I
> think most users don't care about libraries in any language (be it
> Perl, C, JS, Python, ...), but only care about software they
> use directly.

Please don't we (astronomers) use Python packages as end-users via
jupyter notebooks, and it would be desatrous if f.e. python3-astropy
would disappear from the list.

Best regards

Ole

Re: Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2017-01-05 14:41, Stéphane Blondon wrote:
> 
> I think it would be nice to send a pull-request to fix it
> upstream.

I did.

https://github.com/floatdrop/is-retry-allowed/pull/1

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlhuXMkACgkQOIRDexPY
/4viaBAAkIoIbpWKvRBudhsvIAMxs8rsRr9G/EmtZnshevkaTews2toSmlREHlU0
g4f/BnIkJXotzcG4sQKid0RxctvSZ8gLwglArruVjWPGmxPCqXRX0HKs8rqleL4r
tj5gPy8pH3UosdOTq2X870WIBKewgOAktRewRjW9xYTHRhXt0Uj83vNq2BdQvwbG
8ygJzbU+w5anFBTdQFYIgInR2zM9u97chcx3rpP0EbIS/DqPLrpfOR5BSejURTbW
3j0OIVGY9hjocK8208xZQz1BohccUZ2aMCAy2NaS2zrDZ3CFvFQRh0WyKY123yTC
oox462CJ3KHvKa1tAiKh0WxBQ9r7Hs+S6PtHOS41SO54G/Yiif1xLgyOtlvqH1pI
0zUlPE0WExvenWunTZQOf9ThpOqPmdeOAekBbEVf8tHQgUJFYY6WgyumUbiMN868
fDQ76hgptdbX61ll9yo3mfUQDekMfdw5su5P7+9XsQhw6C/FFKvtSuNJR2HxuIee
2lTAIdlLDspe6GX9oxsPP0uhqY5XAVt0Wj/Kw76qLtmpqXGmccqYFTAz0Y2xXs8U
zVKuY7zZIIRZS23qil8PUZ5vuXXvANGB01VUQCWGA3my4kjsYXTJK/1NZE9SHF34
AkGQeBFoXPdH4P775d5+T66Zqo5T/NHk12EKh/45SIgJkpkY6M8=
=/N4y
-END PGP SIGNATURE-

Re: Feedback on 3.0 source format problems

[Jonathan Dowland]

On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> > Looked at another way, it is trying to be a version control system,
> > layered on top of the Debian archive.  But it is only about a quarter
> > of a VCS.  There are no formal interfaces to do proper VCS operations.
> > If there is a formal interface, it is quilt(1) (which is itself very
> > poor.  NB that is not quilt's fault: quilt inevitably has a hard job
> > because can't make enough assumptions).
> 
> there quilt push, pop and header which seems enough.

quilt is not a hard dependency of dpkg-dev, but the abstraction is quite leaky
without it: if you try to build a 3.0 (quilt) package without having quilt,
dpkg-buildpackage will apply the patches fine, but if something breaks and
you have a half-built tree, things are pretty messy and I often rely on rm -rf
.pc and git reset (when I have the advantage of working in a git repository)
to get back to a buildable source.

I'd much prefer if it the state of a build tree after 'dpkg-buildpackage'
could be wound back without relying on external (or non-depended) tools, it
would help me feel that the tool was well rounded and internally consistent.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Bug#850271: ITP: node-capture-stack-trace -- Error.captureStackTrace ponyfill

[Rushi Bhadane]

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

* Package name: node-capture-stack-trace
  Version : 1.0.0
  Upstream Author : Vsevolod Strukchinsky  (
github.com/floatdrop)
* URL : https://github.com/floatdrop/capture-stack-trace
* License : Expat
  Programming Lang: JavaScript
  Description : Error.captureStackTrace ponyfill

Re: Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Stéphane Blondon]

2017-01-05 13:21 GMT+01:00 Christian Seiler :

> On 01/05/2017 01:18 PM, Martin Bagge / brother wrote:
> > "description": "My prime module",
>
> Yikes. My apologies, then at least now I get where that comes
> from.
>
> Still, the description on the github link appears to be the
> one that's preferable to "my prime module". So thanks for
> intending to fix this.
>
>
I think it would be nice to send a pull-request to fix it upstream.


-- 
Stéphane

Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

[Christian Seiler]

On 01/05/2017 02:06 PM, Jonas Smedegaard wrote:
> Quoting Riku Voipio (2017-01-05 12:53:16)
>> Vast majority of users would only install this via dependencies. It's 
>> hardly a node-specific problem that debian package searches output 
>> large amount of packages that are not useful unless you happen to be a 
>> programmer.
> 
> ...and I agree that the issue is not specific to node-* packages, but I 
> find it is quite common there.  Quite likely due to recent inclusion of 
> lots of packages, prepared semi-automated - as Philip pointed out very 
> well.

Could we maybe hide library packages from apt searches by default? I
think most users don't care about libraries in any language (be it
Perl, C, JS, Python, ...), but only care about software they
use directly. And developers that do care about libraries could pass
a flag to APT to say "yeah, please show me all packages that match
this". And maybe even indicated how many library packages were not
shown in the default search results?

Regards,
Christian

PS: I'm throwing this idea in as a general idea, I don't think this
is something for Stretch though, we're far too late in the release
cycle for that.

Re: Worthless node-* package descriptions in ITPs

[Jonas Smedegaard]

Quoting Riku Voipio (2017-01-05 12:53:16)
> On Thu, Jan 05, 2017 at 10:53:36AM +0100, Philip Hands wrote:
>> At present you are forcing that vast majority of our users, that have 
>> no interest in this software, to individually learn that they need to 
>> look out for the node- prefix, and ignore such packages.

Thanks, Philip, for raising this concern.  I agree with it.


> Vast majority of users would only install this via dependencies. It's 
> hardly a node-specific problem that debian package searches output 
> large amount of packages that are not useful unless you happen to be a 
> programmer.

...and I agree that the issue is not specific to node-* packages, but I 
find it is quite common there.  Quite likely due to recent inclusion of 
lots of packages, prepared semi-automated - as Philip pointed out very 
well.


> The only people installing node libs directly would be node 
> developers, for whom matching description with upstream project is 
> valuable. If the description is not useful for developer either ( for 
> example "Itty bitty little widdle twinkie pinkie" ), better propose 
> the upstream project a more concise description, than to carry extra 
> delta in debian.

It seems you argue that package descriptions need not make sense beyond 
the package section they belong to.  I disagree, and it seems Debian 
Policy disagrees too - see § 3.4:

> The description should describe the package (the program) to a user 
> (system administrator) who has never met it before so that they have 
> enough information to decide whether they want to install it.  This 
> description should not just be copied verbatim from the program's 
> documentation.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#850264: ITP: node-unzip-response -- Unzip a HTTP response if needed

[Himanshu Chopra]

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

* Package name: node-unzip-response
  Version : 2.0.1
  Upstream Author : Sindre Sorhus 
* URL : https://github.com/sindresorhus/unzip-response#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Unzip a HTTP response if needed

Bug#850260: ITP: node-ansi-align -- align-text with ANSI support for CLIs

[Yashashree Kolhe]

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

* Package name: node-ansi-align
  Version : 1.1.0
  Upstream Author : nexdrew
* URL : https://github.com/nexdrew/ansi-align#readme
* License : ISC
  Programming Lang: JavaScript
  Description : align-text with ANSI support for CLIs

Bug#850259: ITP: node-single-line-log -- Keep writing to the same line in the terminal. Very useful when you write progress bars, or a status message during longer operations

[Nupur Malpani]

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

* Package name: node-single-line-log
  Version : 1.1.2
  Upstream Author : Tobias Baunbæk 
* URL : https://github.com/freeall/single-line-log#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Keep writing to the same line in the terminal. Very
useful when you write progress bars, or a status message during longer
operations

Re: Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

On 01/05/2017 01:18 PM, Martin Bagge / brother wrote:
> On 2017-01-05 13:04, Christian Seiler wrote:
>> The official package description appears to be:
> 
>> "Is retry allowed for Error?"
> 
>> And while that is still a bit vague, it does at least give an 
>> indication what the module does, while I have no idea what "my
>> prime module" is supposed to mean?
> 
>> I would urge you to use upstream's description when packaging this
>> module.
> 
> Well. They did.
> 
> https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
> #L4
> reads
> 
> "description": "My prime module",

Yikes. My apologies, then at least now I get where that comes
from.

Still, the description on the github link appears to be the
one that's preferable to "my prime module". So thanks for
intending to fix this.

Regards,
Christian

Re: Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2017-01-05 13:04, Christian Seiler wrote:
> The official package description appears to be:
> 
> "Is retry allowed for Error?"
> 
> And while that is still a bit vague, it does at least give an 
> indication what the module does, while I have no idea what "my
> prime module" is supposed to mean?
> 
> I would urge you to use upstream's description when packaging this
> module.

Well. They did.

https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
#L4
reads

"description": "My prime module",

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlhuOZkACgkQOIRDexPY
/4uYvQ/7BiyOh0+4ubzf6VRuoUnQjhMX9NlnhjuTTGmS4BnYK6rKALuZ5FXtEmnd
Ht6Hh7a3FQh6c9G7a4PvEyJBdnJdPlc/2vk7szYKJC73ke+O1JFAsXBomF1IUeC9
LEcWV8oLYFcLO30qGfSfI08TsTx8yzlaG7gr9/5QV5jDTzDyNV7FEN1JZtrmvDS7
etLipBLxxoNFEyBlar8xO/fq+qzhrTWnlJ/YWilpLOZI9t/vsBxHGOicRwHuNbM9
6NCbMzIPrTE/rRus1GhjUGuPAgCYblV/BwXAqCxuBd4lesUsPQMB2+tQK0fJ6P2g
5Rk2HxN+FtUaWZD9G3g577cYkl1KDYZ0RJW4sSMX6A2zoWYWV2Ne6q/VH1/M/Qju
qD4yfdI4wfhg/Q87MZZtghZJNNfqHoC71BLjBP5uD/oduHsOclewyTu8er0oXp1k
odwKSuYUCnpPplNiUcjtZaNnrto8vor8Em3BOovEA8Cl4WGWjkv7Wg5iPsYa7uoB
NZYSSON6GGjVwIh6NmDE78urBfpHX5gg8aWKyPVYOJKofpCb6a1t6xomsv0h9Y/m
EkGN+labdO8tF+efa0Wh6WcgL7ZP8ITiHuUeQ4z6gdWy+qLFqoRBz8LsCxG+OtoP
E3BkxPfbIyYN+hjBnsa/PidT8vbc+oTQcSTluTEkBshyr2Mvh6Y=
=V2QQ
-END PGP SIGNATURE-

Re: Worthless node-* package descriptions in ITPs

[Riku Voipio]

On Thu, Jan 05, 2017 at 10:53:36AM +0100, Philip Hands wrote:
> At present you are forcing that vast majority of our users, that have no
> interest in this software, to individually learn that they need to look
> out for the node- prefix, and ignore such packages.

Vast majority of users would only install this via dependencies. It's hardly
a node-specific problem that debian package searches output large amount of
packages that are not useful unless you happen to be a programmer.

The only people installing node libs directly would be node developers,
for whom matching description with upstream project is valuable. If the
description is not useful for developer either ( for example 
"Itty bitty little widdle twinkie pinkie" ), better propose the upstream
project a more concise description, than to carry extra delta in debian.

Riku 

Re: Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

Hi there,

Let me nitpick a bit: ;-)

On 01/05/2017 12:52 PM, saurabhagra...@disroot.org wrote:
> * URL : https://github.com/floatdrop/is-retry-allowed#readme
>   Description : My prime module

The official package description appears to be:

"Is retry allowed for Error?"

And while that is still a bit vague, it does at least give an
indication what the module does, while I have no idea what
"my prime module" is supposed to mean?

I would urge you to use upstream's description when packaging
this module.

Regards,
Christian

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[saurabhagrawal]

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

* Package name: node-is-retry-allowed
  Version : 1.1.0
  Upstream Author : Vsevolod Strukchinsky  
(github.com/floatdrop)
* URL : https://github.com/floatdrop/is-retry-allowed#readme
* License : Expat
  Programming Lang: JavaScript
  Description : My prime module

Bug#850256: ITP: node-pkg-conf -- Get namespaced config from the closest package.json

[akshay kemekar]

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

* Package name: node-pkg-conf
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/pkg-conf#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get namespaced config from the closest package.json

Bug#850254: ITP: node-extract-zip -- unzip a zip file into a directory using 100% pure gluten-free organic javascript

[Sumedh Pendurkar]

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

* Package name: node-extract-zip
  Version : 1.6.0
  Upstream Author : max ogden
* URL : https://github.com/maxogden/extract-zip
* License : BSD-2-Clause
  Programming Lang: JavaScript
  Description : unzip a zip file into a directory using 100% pure 
gluten-free organic javascript

Bug#850251: ITP: node-is-npm -- Check if your code is running as an npm script

[Ameya Apte]

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

* Package name: node-is-npm
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (
http://sindresorhus.com)
* URL : https://github.com/sindresorhus/is-npm
* License : Expat
  Programming Lang: JavaScript
  Description : Check if your code is running as an npm script

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote:
> Neither systemd-shim nor consolekit are solutions that are viable in
> the long term, the sooner we get rid of both, the better.  I don't
> know what's a good alternative, though.  Loginkit is
> vapourware.  Elogind maybe?

With elogind do you mean https://github.com/wingo/elogind?  That
project doesn't look very active.

Is there any active project trying to reimplement the logind API? 
Including access to devices (which X wants these days)?

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Adam Borowski writes ("Re: "not authorised" doing various desktoppy things [and 
1 more messages]"):
> In my experience, systemd-shim never worked in the first place, so this is
> no regression.  I see results that Ian observes since the day policykit and
> friends were recompiled against logind rather than consolekit.  It's
> somewhat puzzling that it's reported to have worked for _some_ people in the
> past.

It worked for me earlier in the year.  I don't know what set of
versions that was, but I installed one of the stretch alphas and it
worked until quite recently.  And the submitters of #844785 seem to
see something similar.

> Neither systemd-shim nor consolekit are solutions that are viable in the
> long term, the sooner we get rid of both, the better.  I don't know what's
> a good alternative, though.  Loginkit is vapourware.  Elogind maybe?

Surely this is something to think about for buster.  (Having said
that, I haven't heard of most of these things and I generally don't
have a clue what I'm doing in this area.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850249: ITP: node-speedometer -- simple speed measurement in javascript

[Himanshu Chopra]

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

* Package name: node-speedometer
  Version : 1.0.0
  Upstream Author : Mathias Buus Madsen 
* URL : https://github.com/mafintosh/speedometer
* License : Expat
  Programming Lang: JavaScript
  Description : simple speed measurement in javascript

Re: Bug#850182: Please disable TSX in stretch and backport to jessie

[Emilio Pozuelo Monfort]

On 04/01/17 20:04, Ian Jackson wrote:
> Package: eglibc

eglibc got renamed back to src:glibc a while ago.

Cheers,
Emilio

> 
> Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
>> I've just noticed this RC bug [1] against scilab. [...]
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
>> [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
> ...
>> I don't have access to any box with TSX enabled, and failed to find any
>> porterbox as well. [...]
> 
> amd64 with TSX is for the purposes of pthreads like a new
> architecture: the locking primitives behave differently and expose
> extra bugs.
> 
> These extra bugs will be discovered only by chance (as we see in that
> bug report and in the earlier bugs #843324 and maybe #842796).  As
> more TSX-capable hardware becomes available, we will discover more of
> them, during the life of stretch, when they are hard to fix.
> 
> Also, we don't have the capability to debug them.  I don't think we
> can have a release architecture for stretch that has no porterboxes.
> 
> So please would the libc be changed not to make use of these features
> for stretch.  The downsides will be somewhat lower performance and
> not detecting some preexisting bugs; but the upsides are not shipping
> undetected bugs, and not throwing useful software out of Debian.
> 
> Please would you make a decision quickly.
> 
> Regards,
> Ian.
> 

Bug#850242: ITP: diamond-aligner -- accelerated BLAST compatible local sequence aligner

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: diamond-aligner
  Version : 0.8.31
  Upstream Author : Benjamin Buchfink 
* URL : https://github.com/bbuchfink/diamond
* License : BSD
  Programming Lang: C++
  Description : accelerated BLAST compatible local sequence aligner
 DIAMOND is a sequence aligner for protein and translated DNA searches
 and functions as a drop-in replacement for the NCBI BLAST software
 tools. It is suitable for protein-protein search as well as DNA-protein
 search on short reads and longer sequences including contigs and
 assemblies, providing a speedup of BLAST ranging up to x20,000.


Remark: The original upstream name 'diamond' was changed since
there is a package in Debian with this name.  The package will be
maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/diamond-aligner.git

Re: Bug#850238: ITP: node-hoek -- General purpose node utilities

[Holger Levsen]

On Thu, Jan 05, 2017 at 03:39:31PM +0530, Akash Sarda wrote:
>   Description : General purpose node utilities
> 
>  Utility methods for the hapi ecosystem. This module is not intended to
> solve every problem for everyone, but rather as a central place to store
> hapi-specific methods. If you're looking for a general purpose utility
> module, …

please make the short description match the long one…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Adam Borowski]

On Wed, Jan 04, 2017 at 07:21:42PM +0100, Michael Biebl wrote:
> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> > I think #844785 needs a fix though. 
> 
> Agreed. Does anyone who uses sysvinit want to look into this?

In my experience, systemd-shim never worked in the first place, so this is
no regression.  I see results that Ian observes since the day policykit and
friends were recompiled against logind rather than consolekit.  It's
somewhat puzzling that it's reported to have worked for _some_ people in the
past.

At home, I'm still using my set of rebuilds against consolekit (semi-public
repository: http://angband.pl/debian nosystemd-{jessie,stretch})[1].  That's
not because of any love towards consolekit -- it's a piece of crap that
needs to die -- but because it works for me.

Neither systemd-shim nor consolekit are solutions that are viable in the
long term, the sooner we get rid of both, the better.  I don't know what's
a good alternative, though.  Loginkit is vapourware.  Elogind maybe?



Meow!

[1]. Also built with all references to libsystemd0 eradicated; this is not
because of bloat concerns but because in multiple cases the detection is
done at compile time rather than runtime, thus purging libsystemd0 is a
cheap way to ensure it's not needed.
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#850240: ITP: node-slash -- Convert Windows backslash paths to slash paths

[Vivek Bhave]

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

* Package name: node-slash
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(http://sindresorhus.com)
* URL : https://github.com/sindresorhus/slash
* License : Expat
  Programming Lang: JavaScript
  Description : Convert Windows backslash paths to slash paths

Bug#850238: ITP: node-hoek -- General purpose node utilities

[Akash Sarda]

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

* Package name: node-hoek
  Version : 4.1.0
  Upstream Author : FIX_ME upstream author
* URL : https://github.com/hapijs/hoek#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : General purpose node utilities

 Utility methods for the hapi ecosystem. This module is not intended to
solve every problem for everyone, but rather as a central place to store
hapi-specific methods. If you're looking for a general purpose utility
module, check out lodash  or underscore
.

Bug#850239: ITP: node-lodash -- Lodash modular utilities.

[Sumedh Pendurkar]

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

* Package name: node-lodash
  Version : 4.17.4
  Upstream Author : John-David Dalton  
(http://allyoucanleet.com/)

* URL : https://lodash.com/
* License : Expat
  Programming Lang: JavaScript
  Description : Lodash modular utilities.

Bug#850237: ITP: node-private -- Utility for associating truly private state with any JavaScript object

[Ameya Apte]

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

* Package name: node-private
  Version : 0.1.6
  Upstream Author : Ben Newman 
* URL : http://github.com/benjamn/private
* License : Expat
  Programming Lang: JavaScript
  Description : Utility for associating truly private state with any
JavaScript object

Worthless node-* package descriptions in ITPs

[Philip Hands]

Hi Roshan,

Please don't take this personally, you just happen to be the one
touching the most recent remarkably meaninglessly described ITP for a
node-* package -- I could easily have picked on one of the many other
examples.

I've Bcc:ed the bug to ensure that replies about this stay on -devel.

Roshan  writes:

...
> * Package name: node-pinkie
...
> * URL : https://github.com/floatdrop/pinkie
...
>   Description : Itty bitty little widdle twinkie pinkie ES2015 Promise 
> implementation

Can we stop the worthless descriptions in node-* ITPs please?

What meaning is contained in the descriptions, is generally
JavaScript/Node specific jargon that is pretty much meaningless to
anyone else.  This is because it is being lifted directly from the git
repository description, where it is reasonable for the upstream to
expect people to already know something about node, so that's the
audience that is being addressed.  That is not a reasonable assumption
when applied to Debian users in general.

To All Node.js packagers:

  Please proof-read and correct the short descriptions before filing
  ITPs.

  Also please fix the script that is generating these ITPs to add a long
  description that at the very least mentions that this is something to
  do with node.js, and what that means (such that people that are not
  interested in node.js can quickly determine that fact and move on).

At present you are forcing that vast majority of our users, that have no
interest in this software, to individually learn that they need to look
out for the node- prefix, and ignore such packages.

You are also giving the impression that all these packages are sloppily
packaged, which makes one wonder if they are going to have any ongoing
maintenance effort available for them (since it seems that too little
effort was devoted to the initial packaging), which in turn makes one
concerned about whether they are going to be fit for a stable release.

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