Bug#895509: ITP: r-cran-dorng -- GNU R generic reproducible parallel backend for 'foreach' loops

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-dorng
  Version : 1.6.6
  Upstream Author : Renaud Gaujoux 
* URL : https://cran.r-project.org/package=doRNG
* License : GPL
  Programming Lang: GNU R
  Description : GNU R generic reproducible parallel backend for 'foreach' 
loops
 This GNU R package provides functions to perform
 reproducible parallel foreach loops, using independent
 random streams as generated by L'Ecuyer's combined
 multiple-recursive generator [L'Ecuyer (1999), ].
 It enables to easily convert standard %dopar% loops into
 fully reproducible loops, independently of the number
 of workers, the task scheduling strategy, or the chosen
 parallel environment and associated foreach backend.


Remark: This package is needed to upgrade r-cran-blockmodeling to its latest
upstream version.  It will be maintained by the R-pkg team at
https://salsa.debian.org/r-pkg-team/r-cran-dorng

Bug#895510: ITP: python-raccoon -- Python DataFrame with fast insert and appends

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: python-raccoon
  Version : 2.1.5
  Upstream Author : Ryan Sheftel
* URL : https://github.com/rsheftel/raccoon
* License : MIT
  Programming Lang: Python
  Description : Python DataFrame with fast insert and appends

 Lightweight DataFrame and Series implementation inspired by the
 phenomenal Pandas package for the one use case where Pandas is known to
 be sub-optimal: DataFrames that grow in size by rows frequently in the
 code. Additionally Raccoon DataFrames can be parametrized to be sorted
 so that additions to the DataFrame keep the index in sorted order to
 speed inserts and retrievals.

This will be a dependency for recent mlbstreamer releases.

Bug#895514: ITP: ccextractor -- fast closed captions extractor

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 

* Package name: ccextractor
  Version : 0.86
  Upstream Author : Carlos Fernandez
* URL : https://github.com/CCExtractor/ccextractor/
* License : GPL-2
  Programming Lang: C
  Description : fast closed captions extractor

This tools analyzes video files and produces independent subtitle files
from the closed captions data. It supports DVD, HDTV transport streams,
Replay TV.

Bug#895523: ITP: r-cran-magic -- GNU R create and investigate magic squares

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-magic
  Version : 1.5-8-1
  Upstream Author : Robin K. S. Hankin
* URL : https://cran.r-project.org/package=magic
* License : GPL
  Programming Lang: GNU R
  Description : GNU R create and investigate magic squares
 A collection of efficient, vectorized algorithms for the
 creation and investigation of magic squares and hypercubes, including
 a variety of functions for the manipulation and analysis of
 arbitrarily dimensioned arrays.  The package includes methods for
 creating normal magic squares of any order greater than 2.  The
 ultimate intention is for the package to be a computerized embodiment
 all magic square knowledge, including direct numerical verification
 of properties of magic squares (such as recent results on the
 determinant of odd-ordered semimagic squares).  Some antimagic
 functionality is included.  The package also
 serves as a rebuttal to the often-heard comment "I thought R
 was just for statistics".


Remark: This package is needed as a dependency for r-cran-geometry which
in turn is a new dependency to upgrade r-cran-ddalpha to its latest
upstream version.  It is maintained by the R-pkg team at
   https://salsa.debian.org/r-pkg-team/r-cran-magic

Bug#895529: ITP: r-cran-geometry -- GNU R mesh generation and surface tesselation

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-geometry
  Version : 0.3-6-1
  Upstream Author : David C. Sterratt 
* URL : https://cran.r-project.org/package=geometry
* License : GPL
  Programming Lang: GNU R
  Description : GNU R mesh generation and surface tesselation
 This GNU R package makes the qhull library (www.qhull.org)
 available in R, in a similar manner as in Octave and MATLAB. Qhull
 computes convex hulls, Delaunay triangulations, halfspace
 intersections about a point, Voronoi diagrams, furthest-site
 Delaunay triangulations, and furthest-site Voronoi diagrams. It
 runs in 2-d, 3-d, 4-d, and higher dimensions. It implements the
 Quickhull algorithm for computing the convex hull. Qhull does not
 support constrained Delaunay triangulations, or mesh generation of
 non-convex objects, but the package does include some R functions
 that allow for this. Currently the package only gives access to
 Delaunay triangulation and convex hull computation.


Remark: This package is needed to upgrade r-cran-ddalpha to its latest
upstream version.  It is maintained by the R-pkg team at
   https://salsa.debian.org/r-pkg-team/r-cran-geometry

Bug#895542: ITP: jsoneditor.js -- A web-based tool to view, edit, format, and validate JSON

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: jsoneditor.js
  Version : 5.14.1
  Upstream Author : Jos de Jong 
* URL : https://github.com/josdejong/jsoneditor
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : A web-based tool to view, edit, format, and validate JSON

 JSON Editor is a web-based tool to view, edit, format, and validate JSON. It
has various modes such as a tree editor, a code editor, and a plain text
editor. The editor can be used as a component in your own web application.
 .
 Supported browsers: Chrome, Firefox, Safari, Opera, Internet Explorer 9+.

This package is a dependency of swagger-ui (see #895422), which I am also
ITPing.

Re: Debian Policy 4.1.4.0 released

[Ian Jackson]

Paul Wise writes ("Re: Debian Policy 4.1.4.0 released"):
> uscan is used in situations where one does not want arbitrary code
> >from source packages automatically run by uscan. As long as `uscan
> --safe` ignores that fallback, that should be fine I guess though.

I think safety should be the default, so I have filed
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895546

Thanks,
Ian.

Bug#895559: ITP: json-editor.js -- JSON Schema based editor

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: json-editor.js
  Version : 0.7.28
  Upstream Author : Jeremy Dorn  (http://jeremydorn.com)
* URL : https://github.com/json-editor/json-editor#readme
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Schema based editor

 JSON Editor takes a JSON Schema and uses it to generate an HTML form.
 It has full support for JSON Schema version 3 and 4 and can integrate with
several popular CSS frameworks (bootstrap, foundation, and jQueryUI).

This package is a dependency of swagger-ui (see #895422), which I am also
ITPing.

Re: Bug#515856: Debian Policy 4.1.4.0 released

[Russ Allbery]

Andreas Tille  writes:

> I think additional information in README.source is a very helpful thing
> to have.  However, my *personal* policy for sponsoring a package is that
> I will not sponsor a package that comes without a method that enables me
> automatically to reproduce the upstream source tarball.  Some vague
> advise in README.source like "download from xyz, check file abc, remove
> def, create a tarball with name mno_ver" is IMHO not acceptable.  The
> fact that the get-orig-source was mentioned in policy enabled to give
> some pointer to a documented way to provide this code.

> After the removal I will surely stick to my personal policy but for an
> explanation who to implement it in a somehow standardized way I need do
> add extra information now.

You would already have to add some extra information since the Policy text
was ambiguous.  Different people interpreted it differently; for instance,
whether it downloaded the *current* orig.tar.gz file or the one for the
next upstream release.

> As I said before I'm fine with the removal from debian/rules but we
> should somehow settle with some default recommendation that avoids that
> every developer invents its own way to obtain the upstream source (if
> uscan does not work and I'm talking only about this case).

I don't think agree that this is something Debian *needs*, and I
personally don't really agree with your sponsorship rule and wouldn't
apply that rule myself.  (You're of course free to apply any restrictions
you want to what packages you're willing to sponsor.)  I can see how it's
very *useful* to automate a common operation like updating to a new
version of upstream, but I wouldn't make it a requirement, and I also
don't think this fairly unusual edge case requires standardization.

That said, I think guidance for good practices for edge cases is always
useful if someone wants to write it up, and the Developer's Reference
seems like a good place to accumulate such things.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#515856: Debian Policy 4.1.4.0 released

[Andreas Tille]

On Thu, Apr 12, 2018 at 09:39:39AM -0700, Russ Allbery wrote:
> > After the removal I will surely stick to my personal policy but for an
> > explanation who to implement it in a somehow standardized way I need do
> > add extra information now.
> 
> You would already have to add some extra information since the Policy text
> was ambiguous.

I agree that this needs fixing.

> Different people interpreted it differently; for instance,
> whether it downloaded the *current* orig.tar.gz file or the one for the
> next upstream release.

This was in fact open for interpretation.

> > As I said before I'm fine with the removal from debian/rules but we
> > should somehow settle with some default recommendation that avoids that
> > every developer invents its own way to obtain the upstream source (if
> > uscan does not work and I'm talking only about this case).
> 
> I don't think agree that this is something Debian *needs*, and I
> personally don't really agree with your sponsorship rule and wouldn't
> apply that rule myself.  (You're of course free to apply any restrictions
> you want to what packages you're willing to sponsor.)  I can see how it's
> very *useful* to automate a common operation like updating to a new
> version of upstream, but I wouldn't make it a requirement, and I also
> don't think this fairly unusual edge case requires standardization.

I do not subscribe the edge case argument.  In the dir where I have
nearly all Git repositories of Debian Med team I have

$ find . -name debian -type d | grep -v \.git | wc -l
858
$ find . -name get-orig-source -type f | wc -l
119

I have not checked every single of these and with my recent knowledge
about obtaining the source from Git repositories via uscan some of these
might be droped.  But its roughly 10 percent of the packages (not only
released packages but also not yet finished preparations admittedly and
may be the percentage of get-orig-source scripts is higher there).
 
> That said, I think guidance for good practices for edge cases is always
> useful if someone wants to write it up, and the Developer's Reference
> seems like a good place to accumulate such things.

I'm not really happy with the "downgrade from policy to Developer's
Reference".  I would have loved if some more precise wording would
have been found for policy but as long as we can settle with some
clarified wording that's OK for me.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Updated proposal for improving the FTP NEW process

[Adrian Bunk]

On Wed, Apr 11, 2018 at 02:05:03PM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > Imagine tomorrow a random person from the internet noone has ever heard
> > of uploads a package dgit 5.0 to mentors.d.n.
> 
> > It is clear that this would not be sponsored.
> 
> > "detected by tooling" would mean that this would result in dak
> > autorejecting any future uploads of a dgit package version 5.0 to
> > Debian.
> 
> This sounds like a feature?  I think that would be exactly the right
> outcome.  It avoids any possibility of confusion with this rogue 5.0
> version, if it should turn up somewhere else.

Debian version numbers are usually not globally unique.

The binary packages of dgit 4.3 in Debian and Ubuntu are different 
builds from the same sources, and for binary-any packages such
different builds usually have different contents.[1]

And more common is actually the reverse problem of someone publishing
a different 5.0 after a 5.0 is already in our archive (usually by
making modifications without changing the version number).

> Version numbers are composed of integers.  Getting another integer is
> free, and there is not a limited supply.  We won't run out, and missing
> sequence numbers cause no problems in the world.

Giving every person on the internet the power to steal version numbers
for random packages would be dangerous.

There's implicit meaining behind version numbers, like debhelper 12
being the first version where compat 12 will be stable.

Apart from obvious (scripted) DoS for taking all reasonable numbers for 
a package, it would also e.g. encourage derivates to steal Debian 
version numbers instead of using a proper namespace.[2]

Versions of packages that are accepted into our archive must be unique, 
but random people from the internet should not have the power to 
restrict what a maintainer can do in Debian.

cu
Adrian

[1] e.g. different Debian revisions of gcc usually generate slightly
different code
[2] e.g. using 1.0-2 instead of 1.0-1devuan, resulting in an
improved dak autorejecting a maintainer upload of 1.0-2

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#895246: gconf: Intent to Adopt

[Adrian Bunk]

On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> (I don't speak for the GNOME team, or for Josselin, who is officially
> this package's maintainer; please don't assume I do.)
> 
> On Sun, 08 Apr 2018 at 22:19:43 +0300, Adrian Bunk wrote:
> > I hereby declare my intent to adopt gconf.
> 
> Thank you for offering to take over this package. Do you also intend
> to adopt these related packages?
> 
> - src:gconf-editor (which depends on gconf and is useless without it;
>   currently maintained by the GNOME team)

Makes sense.

> - src:orbit2 (orphaned library needed by gconf)
> - src:libidl (orphaned library needed by orbit2)

Where does gconf depend on these?

> - various language bindings for gconf

Good point, I haven't yet looked at these.

>...
> Do you use software that relies on gconf yourself/are you able to test it?

Yes.

>...
> For contributors: every time a package that hasn't had upstream
> development for a few years fails to build during a transition, or
> needs fixes for a new architecture, or has RC bugs that someone looks
> at during a BSP, it takes a little bit more of several contributors'
> time and attention

There have been 2 port bringups already this year so far (ia64, riscv64),
and a bigger amount of contributors' time and attention is actually 
wasted for these in cases like #876592 or #887868 where the maintainer
didn't apply a simple FTBFS fix for months.

> (even if the only attention it gets is to look at the
> package, realise it hasn't changed significantly in a decade, and decide
> to prioritize something different). Software that depends on gconf isn't
> *directly* an indication of something terribly bad, but it's reasonably
> well correlated with the dependent software also being unmaintained or
> undermaintained upstream. Each individual package blocking a transition,
> and each individual RC bug, doesn't necessarily take much time and
> attention, but it adds up over time, and I'm concerned that the long
> tail of GNOME-2-based packages might be collectively and cumulatively
> taking more time and attention than it deserves.
>...

The worst-possible outcome is when you force reverse dependencies to 
bundle copies of the libraries, like glademm in aeskulap.

>...
> If we had bikesheds, PPAs or an equivalent of Ubuntu universe, I'd
> suggest moving unmaintained/undermaintained packages to one of those
> to indicate that users shouldn't have the same quality expectations,
> but we don't currently have that facility.

I will begin to take your suggestion seriously after you have managed
to enforce that for ITPs - whatever quality expectations we have should
be enforced there already, usually software does not suddenly become
low-quality after it was shipped in half a dozen Debian releases.

> If, bearing all that in mind, you still think Debian is better with
> gconf than without it, then I'm not going to try to prevent you from
> maintaining it. (Again, I don't speak for the GNOME team.)

Thanks.

> smcv
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#895246: gconf: Intent to Adopt

[Simon McVittie]

On Thu, 12 Apr 2018 at 23:12:44 +0300, Adrian Bunk wrote:
> On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> > - src:orbit2 (orphaned library needed by gconf)
> > - src:libidl (orphaned library needed by orbit2)
> 
> Where does gconf depend on these?

I thought it did, but that was incorrect. The protocol it uses behind the
scenes was switched from CORBA to D-Bus before upstream maintenance ended.

If someone (you or otherwise) wants to keep libgnome, libgnomeui or
libbonobo* alive, *that* is the dependency tree that would require
orbit2 and libidl (the "Network Object Model" part of the original
expansion of the GNOME acronym).

smcv

Work-needing packages report for Apr 13, 2018

[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: 1278 (new: 3)
Total number of packages offered up for adoption: 158 (new: 2)
Total number of packages requested help for: 53 (new: 1)

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



The following packages have been orphaned:

   convmv (#895272), orphaned 3 days ago
 Description: filename encoding conversion tool
 Installations reported by Popcon: 2308
 Bug Report URL: http://bugs.debian.org/895272

   raphael (#895407), orphaned yesterday
 Description: JavaScript library to work with vector graphics
 Reverse Depends: dnsviz libjs-elycharts libjs-graphael nzbget
   ocsinventory-reports redmine ruby-raphael-rails
 Installations reported by Popcon: 318
 Bug Report URL: http://bugs.debian.org/895407

   scsitools (#895273), orphaned 3 days ago
 Description: Collection of tools for SCSI hardware management
 Installations reported by Popcon: 787
 Bug Report URL: http://bugs.debian.org/895273

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



The following packages have been given up for adoption:

   ocsinventory-agent (#895426), offered yesterday
 Description: Hardware and software inventory tool (client)
 Installations reported by Popcon: 3110
 Bug Report URL: http://bugs.debian.org/895426

   ocsinventory-server (#895424), offered yesterday
 Description: Hardware and software inventory tool (Communication
   Server)
 Installations reported by Popcon: 247
 Bug Report URL: http://bugs.debian.org/895424

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



For the following packages help is requested:

[NEW] ltsp (#895057), requested 6 days ago
 Description: network booted thin and fat clients
 Reverse Depends: education-ltsp-server education-thin-client
   ltsp-client ltsp-server-standalone
 Installations reported by Popcon: 338
 Bug Report URL: http://bugs.debian.org/895057

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

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

   broadcom-sta (#886599), requested 94 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1993
 Bug Report URL: http://bugs.debian.org/886599

   cargo (#860116), requested 366 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 603
 Bug Report URL: http://bugs.debian.org/860116

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

   cyrus-sasl2 (#799864), requested 932 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 (122 more omitted)
 Installations reported by Popcon: 197201
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 636 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: 64246
 Bug Report URL: http://bugs.debian.org/831388

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

   devscripts (#800413), requested 926 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian bzr-builddeb customdeb debci debian-builder debmake (28
   more omitted)
 Inst

Re: Fw:Re: Urging for solution to the slow NEW queue process

[Lumin]

Hi Andreas,

> The fact that the NEW queue is continuely growing is a sign that DDs are
> continuosely motivated to fill it up. ;-)  As Mattia said in his
> response patience is a feature you learn as DD and it is not a bad
> feature.

Thank you and Mattia for pointing that out.

And it would be better if the ftp-master site provide graphs indicating
"how much packages are processed". With these graphs one are
less likely to misinterpret the situation of the NEW queue.

> I have not seen any applause in this thread for your offer to help.  I
> hereby do this and thank you explicitly.  I have learned that e-mails to
> ftp-master work way worse than IRC via #debian-ftp.  May be you repeat
> your offer there.
>
> I personally admit that getting no response to e-mails is more draining
> on the patience than waiting for getting a package acceptet.  Thus
> knowing this alternative channel helped me a lot.

Sounds like a good way looking for help when next time I encountered
a problem alike. I just prefer email because conversations are archived,
while those in IRC are not.

-- 
Best,

Re: Urging for solution to the slow NEW queue process

[Lumin]

Hi Holger,

> you didnt mention which package of yours is stuck in NEW, could you
> please elaborate? Else this seems like a rant out of the blue, without
> much checking of facts, like Phil (Hands) thankfully provided.

I was just afraid that things getting wrong seeing a large median number
of time for a package to wait, without knowing the problem of node
ecosystem since I don't write code in language whose name starts with "J".

> I also share wookey's observation that NEW is being processed more
> quickly than ever currently (and actually since quite some time now.
> Which reminds me of the situation that some people *still* think Debian
> releases are unpredictable and infreqently while in reality for the last
> 14 years we've released every 22 months or so, with a variation of 2
> months.)

I'm glad to know nothing goes wrong except for the node upstream.
Thank you everyone for letting me know the actual situation of NEW queue
:-)

-- 
Best,

Bug#895584: ITP: ell -- Embedded Linux library

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: ell
  Version : 0.4
  Upstream Author : Intel Corporation
* URL : https://01.org/ell
* License : LGPL-2.1
  Programming Lang: C
  Description : Embedded Linux library

The Embedded Linux* Library (ELL) provides core, low-level
functionality for system daemons. It typically has no dependencies
other than the Linux kernel, C standard library, and libdl
(for dynamic linking). While ELL is designed to be efficient and
compact enough for use on embedded Linux platforms, it is not
limited to resource-constrained systems.