Bug#893848: ITP: r-cran-pbmcapply -- GNU R tracking the progress of Mc*pply with progress bar

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-pbmcapply
  Version : 1.2.4
  Upstream Author : Kevin Kuang, Francesco Napolitano
* URL : https://cran.r-project.org/package=pbmcapply
* License : MIT
  Programming Lang: GNU R
  Description : GNU R tracking the progress of Mc*pply with progress bar
 This light-weight GNU R package helps you track and visualize the
 progress of parallel version of vectorized R functions (mc*apply).
 Parallelization (mc.core > 1) works only on *nix systems providing
 the fork() functionality.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-pbmcapply

Bug#893850: ITP: r-cran-whatif -- GNU R evaluate counterfactuals

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-whatif
  Version : 1.5-9
  Upstream Author : Christopher Gandrud, Gary King, Ben Sabath, Heather Stoll, 
Langche Zeng
* URL : https://cran.r-project.org/package=WhatIf
* License : GPL
  Programming Lang: GNU R
  Description : GNU R evaluate counterfactuals
 Inferences about counterfactuals are essential for prediction,
 answering what if questions, and estimating causal effects.
 However, when the counterfactuals posed are too far from the data at
 hand, conclusions drawn from well-specified statistical analyses
 become based largely on speculation hidden in convenient modeling
 assumptions that few would be willing to defend. Unfortunately,
 standard statistical approaches assume the veracity of the model
 rather than revealing the degree of model-dependence, which makes this
 problem hard to detect. WhatIf offers easy-to-apply methods to
 evaluate counterfactuals that do not require sensitivity testing over
 specified classes of models. If an analysis fails the tests offered
 here, then we know that substantive inferences will be sensitive to at
 least some modeling choices that are not based on empirical evidence,
 no matter what method of inference one chooses to use. WhatIf
 implements the methods for evaluating counterfactuals discussed in
 Gary King and Langche Zeng, 2006, "The Dangers of Extreme
 Counterfactuals," Political Analysis 14 (2) ;
 and Gary King and Langche Zeng, 2007, "When Can History Be Our Guide? The
 Pitfalls of Counterfactual Inference," International Studies
 Quarterly 51 (March) .



Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-whatif

Bug#893853: ITP: r-cran-zeligchoice -- GNU R zelig choice models

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-zeligchoice
  Version : 0.9-6
  Upstream Author : Christine. Choirat, Christopher Gandrud, James Honaker
* URL : https://cran.r-project.org/package=ZeligChoice
* License : GPL
  Programming Lang: GNU R
  Description : GNU R zelig choice models
 This package provides an add-on for r-cran-zelig. Enables the use of a
 variety of logit and probit regressions.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-zeligchoice

Bug#893854: ITP: r-cran-eipack -- GNU R ecological inference and higher-dimension data management

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-eipack
  Version : 0.1-7
  Upstream Author : Olivia Lau 
* URL : https://cran.r-project.org/package=eiPack
* License : GPL
  Programming Lang: GNU R
  Description : GNU R ecological inference and higher-dimension data 
management
 Provides methods for analyzing RxC ecological contingency
 tables using the extreme case analysis, ecological regression,
 and Multinomial-Dirichlet ecological inference models.  Also
 provides tools for manipulating higher-dimension data objects.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-eipack

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Lars Wirzenius]

On Thu, 2018-03-22 at 15:40 +0100, Guillem Jover wrote:
> I'm not sure now if this also has been said before, but I'm happy to
> repeat it in any case. :) I'd very strongly object to completely moving
> those fields out of the source packages, because it means when you get
> or have a source package lying around then it's missing important
> metadata and it stops being standalone, which would require checking
> somewhere online, and you might first need to infer which distro/repo
> was this coming from. I'll happily take outdated data than no data any
> day, because usually you can use that outdated data to trace your way
> to the current one, not so if it's missing.

I believe I understand your point of view, but I still disagree.


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

Bug#893856: ITP: r-cran-gmm -- GNU R generalized method of moments and generalized empirical likelihood

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-gmm
  Version : 1.6-2
  Upstream Author : Pierre Chausse 
* URL : https://cran.r-project.org/package=gmm
* License : GPL
  Programming Lang: GNU R
  Description : GNU R generalized method of moments and generalized 
empirical likelihood
 This GNU R package is a complete suite to estimate models based on
 moment conditions. It includes the two step Generalized method of
 moments (Hansen 1982; ), the iterated GMM and
 continuous updated estimator (Hansen, Eaton and Yaron 1996;
 ) and several methods that belong to the
 Generalized Empirical Likelihood family of estimators (Smith 1997;
 , Kitamura 1997;
 , Newey and Smith 2004;
 , and Anatolyev 2005
 ).



Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-gmm

Bug#893857: ITP: r-cran-tmvtnorm -- GNU R truncated multivariate normal and student t distribution

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-tmvtnorm
  Version : 1.4-10
  Upstream Author : Stefan Wilhelm 
* URL : https://cran.r-project.org/package=tmvtnorm
* License : GPL
  Programming Lang: GNU R
  Description : GNU R truncated multivariate normal and student t 
distribution
 Random number generation for the truncated multivariate normal and
 Student t distribution. Computes probabilities, quantiles and densities,
 including one-dimensional and bivariate marginal densities. Computes
 first and second moments (i.e. mean and covariance matrix) for the
 double-truncated multinormal case.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-tmvtnorm

Bug#893859: ITP: r-cran-ucminf -- GNU R general-purpose unconstrained non-linear optimization

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-ucminf
  Version : 1.1-4
  Upstream Author : Hans Bruun Nielsen and Stig Bousgaard Mortensen
* URL : https://cran.r-project.org/package=ucminf
* License : GPL
  Programming Lang: GNU R
  Description : GNU R general-purpose unconstrained non-linear optimization
 An algorithm for general-purpose unconstrained non-linear optimization.
 The algorithm is of quasi-Newton type with BFGS updating of the inverse
 Hessian and soft line search with a trust region type monitoring of the
 input to the line search algorithm. The interface of 'ucminf' is
 designed for easy interchange with 'optim'.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-ucminf

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Markus Koschany]

Am 23.03.2018 um 05:27 schrieb Guillem Jover:
> On Thu, 2018-03-22 at 23:23:22 +0100, Markus Koschany wrote:
>> Am 22.03.2018 um 15:40 schrieb Guillem Jover:
>>> On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote:
 On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
[...]
>> You need online access to make use of the above information in any way.
>> If you want to contact the maintainer you need internet access, if you
>> want to visit the upstream homepage you need internet access, etc.
> 
> Not really. For starters, we'd need to have network access to be able
> to run dch or lintian, because they do check whether an upload is
> supposed to be an NMU, team upload, etc. This seems ridiculous.

It is not that difficult to pass dch --team, dch --nmu or gbp dch manually.

If you were involved in team maintenance you would know that the
Uploaders field is often completely outdated. The only way you can see
who maintains a package is by looking at the Git history or upload
history in tracker.debian.org. We had/have contributors who were
mentioned as Uploaders in hundreds of packages and now they only can be
removed by uploading a new package. A web based solution with a database
would solve this problem in seconds. NMU or Team uploads are
interchangeable terms and not very interesting when all you want to know
is: Who did the last upload?


> Some people like to add branch information in the Vcs- fields, this
> would then require to support adding that info before the package
> exists in tha vcs or archive branch (which means less sanity checks)
> or afterwards (which means it's prone to be forgotten).

I don't mind if you have special requirements but I don't see a reason
why this should get in the way of the majority of contributors who can
live with the standards. My point is that the default should be
different. Don't require contributors to maintain information which can
be maintained more efficiently in tracker.debian.org. Prefer convention
over configuration.

> The Section and Priority are overridden by ftp-masters, but the
> maintainer tends to fill it more or less correctly. Without them,
> ftp-masters would need to come up with values from scratch, which
> is more difficult than correcting them if they seem off.

Almost all packages are priority optional. That could simply be the
default. Our essential, required or standard packages change very
rarely. If you have to introduce a new package with a higher priority as
optional it has to go through NEW as every other package. While this
processing takes place we could find a way to ensure that the priority
is correct.

Removing Section and Priority from debian/control would not be an urgent
priority for me because they don't change frequently like
Vcs/homepage/maintainer but if we think outside the box it could be done.

> If one has got to update the data for several of those fields, it can
> currently be done off-line, and then pushed when one's back on-line,
> this is getting back into the centralized development model.

I don't see how this outweighs the benefit of adding and changing
information _once_ when you are back online. Instead of preparing
hundreds of uploads, compiling the packages on our infrastructure and
duplicating the same information on hundreds of mirrors around the world
(which wastes time, energy and disk space) you maintain your _meta
information_ in a web application. Most, especially younger people, are
familiar with this concept and I would expect this would seem more
natural to them and probably even attract more contributors.

That doesn't stop you from doing the real development work offline.
Besides a web based solution like tracker would provide the unique
opportunity to get more people without upload permissions involved.
Imagine a contributor that corrects your outdated homepage entry and
upstream Git repository while you are offline and as soon as you are
back online the only thing you have to do is to approve it.

> These fields/files are generally useful outside Debian, if we stop
> providing them then it's to be expected that tooling might bit-rot.
> While requiring someone with a tiny local archive to install a tracker
> instance seems just onerous.

There is no need for a local tracker instance. An offline feature is not
important as long as you are online once in a while which is to be
expected nowadays. The meta information just moves to a new central
place. Yes, you have to adapt some tools but you gain all the benefits
of a REST API with a unique interface and data in JSON/XML/YAML/HTML
whatever. It will be easier to access for random people and I can
imagine it would simplify the information exchange between different
distributions not just Debian derivatives.

> 
>> These
>> information are distribution-independent because they are either the
>> same like "Homepage" or you could simply look them up if you define a
>> common and central platform like tracker.debian.org as your main hub for
>>

Bug#893871: ITP: r-cran-ei -- GNU R ecological inference

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-ei
  Version : 1.3-3
  Upstream Author : James Honaker 
* URL : https://cran.r-project.org/package=ei
* License : GPL
  Programming Lang: GNU R
  Description : GNU R ecological inference
 This package contains the GNU R software accompanying Gary King's book: A
 Solution to the Ecological Inference Problem. (1997). Princeton University
 Press.  ISBN 978-0691012407.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-ei

Bug#893872: ITP: r-cran-zeligei -- GNU R zelig ecological inference models

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-zeligei
  Version : 0.1-2
  Upstream Author : Christopher Gandrud, James Honaker
* URL : https://cran.r-project.org/package=ZeligEI
* License : GPL
  Programming Lang: GNU R
  Description : GNU R zelig ecological inference models
 This package provides an add-on for r-cran-zelig 5. It enables the use of a
 variety of  ecological inference models.


Remark: This package is part of a pyramid of dependencies to package
 r-cran-zeligverse which is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-zeligei

Bug#893875: ITP: ayatana-indicator-messages -- Ayatana Indicator that collects messages that need a response

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: ayatana-indicator-messages
  Version : 0.6.0
  Upstream Author : Mike Gabriel 
Ted Gould 
* URL : 
https://github.com/AyatanaIndicators/ayatana-indicator-messages
* License : GPL-3
  Programming Lang: C
  Description : Ayatana Indicator that collects messages that need a 
response

 The messages Ayatana Indicator provides a place on the user's desktop
 that collects messages that need a response.
 .
 This menu provides a condensed and collected view of all of those messages
 for quick access, but without making them annoying in times that you want
 to ignore them.

Bug#893877: ITP: r-cran-zeligverse -- GNU R easily install and load stable zelig packages

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-zeligverse
  Version : 0.1.1
  Upstream Author : Christopher Gandrud 
* URL : https://cran.r-project.org/package=zeligverse
* License : GPL
  Programming Lang: GNU R
  Description : GNU R easily install and load stable zelig packages
 This GNU R packacge provides an easy way to load stable Core Zelig and
 ancillary Zelig packages.  It is needed to run the full test suite of
 the package r-cran-zelig.


Remark: This package is needed to run the full test suite of
 r-cran-zelig (see #883002).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-zeligverse

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Simon McVittie]

On Fri, 23 Mar 2018 at 13:56:09 +0100, Markus Koschany wrote:
> If you were involved in team maintenance you would know that the
> Uploaders field is often completely outdated. The only way you can see
> who maintains a package is by looking at the Git history or upload
> history in tracker.debian.org. We had/have contributors who were
> mentioned as Uploaders in hundreds of packages and now they only can be
> removed by uploading a new package.

Or, alternatively, you work around the current d/control arrangement like
the GNOME team does, and auto-generate the Uploaders at upload-time from a
list of team members and the most recent uploaders in the changelog, which
to be honest seems fairly pointless: consumers of this information typically
have access to the changelog and can equally well see who uploaded the
package for themselves.

(I don't recommend going this route: it's fighting against generic
packaging infrastructure assumptions like "d/control is its own source
code".)

> Well, you can adjust Lintian in a way to check the web service for the
> information which was formerly present in debian/control and get all the
> warnings and errors people like

By design, Lintian can't actually do this (it looks at individual
packages in isolation), but a Lintian-like service definitely could
(like the way we now get warnings on tracker.d.o or on UDD about
Multi-arch fields, duplicated data files, failing uscan runs, and similar
external-to-the-package issues that Lintian cannot check).

smcv

Bug#893885: ITP: r-cran-mockr -- mocking in GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-mockr
  Version : 0.1
  Upstream Author : Kirill Müller 
* URL : https://cran.r-project.org/package=mockr
* License : GPL
  Programming Lang: GNU R
  Description : mocking in GNU R
 Provides a means to mock a package function, i.e., temporarily
 substitute it for testing. Designed as a drop-in replacement for
 'testthat::with_mock()', which may break in R 3.4.0 and later.


Remark: This package is needed to run the full test suite of
 r-cran-tibble (see #888417).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-mockr

Bug#893899: ITP: r-cran-libcoin -- GNU R linear test statistics for permutation inference

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-libcoin
  Version : 1.0-1
  Upstream Author : Torsten Hothorn 
* URL : https://cran.r-project.org/package=libcoin
* License : GPL
  Programming Lang: GNU R
  Description : GNU R linear test statistics for permutation inference
 Basic infrastructure for linear test statistics and permutation
 inference in the framework of Strasser and Weber (1999)
 . This package must not be used by end-users.
 CRAN package 'coin' implements all user interfaces and is ready to be
 used by anyone.


Remark: This package is needed to run the full test suite of
 r-cran-coin (see #882865).  It will be maintained by the r-pkg team at
  https://salsa.debian.org/r-pkg-team/r-cran-libcoin

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Joerg Jaspert]

On 14984 March 1977, Jonas Smedegaard wrote:

>> That was announced several times and it will not reside. 
> Why? Lack of volunteers maintaining a redirector, or new service 
> incompatible with indirections, or?

Multiple things, and it ended up a decision we took at the meeting in
Hamburg.

First off we (the salsa admins) would have liked to take over the
hostname. But then we discussed and thought through it. What would it
get us? A host of problems and not much gain actually. It sounds simple
"Hey the host is same, no need to change packages" - but that is not
true. Gitlab is very different in its layout and handling of things than
old alioth.

Before you come "Well, apache redirect map", think of it. We have that
right now already. Actually twice. There is one map on alioth itself,
trying to map old stuff into cgit, and there is the new alioth
redirector mapping migrated stuff to alioth. Now what, that only does a
small subset of requests, http. Not git. (Not ssh). And it needs manual
action for each and every migrated package...

Very much not optimal. And the cgit one, while being there for a long
time, still does not work for all cases, is a mess, declared as
"unmaintainable" by its maintainer.

So redirecting is a bad way, its hard to maintain and only does it for a
subset of the needed pieces. The redirector WILL go away in the not-too
distant future, it is a hacky interims solution.

So, moving the hostname. Could have done that. When? How about

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
anonscm moved over, if you didn't migrate your repos yet, you won't see
them on anonscm anymore"?

Or would

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
in half a year, anonscm moves over, if you migrate your repos before,
you won't see them on anonscm until then"

be better?

And both leave out that part of "And hey, the whole entirely different
to alioth means its a new url, please immediately update your packages
vcs-whatever entries for it", which means an upload anyways..


So that got us to "It would be nice. It does not work usefully. -> It
won't happen". And basically you can expect another hostname change to
happen *AGAIN* in the future, should we switch from gitlab to
whatever-is-good-then, UNLESS that hypothetical thing is about identical
on the whole layout. THEN one can do a "switchover day is X, all repos
and groups and whatnot will be forcefully migrated then, no user action
needed".

-- 
bye, Joerg

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Ole Streicher]

Joerg Jaspert  writes:
> So that got us to "It would be nice. It does not work usefully. -> It
> won't happen". And basically you can expect another hostname change to
> happen *AGAIN* in the future, should we switch from gitlab to
> whatever-is-good-then, UNLESS that hypothetical thing is about identical
> on the whole layout. THEN one can do a "switchover day is X, all repos
> and groups and whatnot will be forcefully migrated then, no user action
> needed".

 which IMO proves that a sophisticated "layout" with namespaces or
subdirs is a bad idea for canonical URLs.

Why can't we have a flat name space with redirection

https://git.debian.org/

(or similar) that just redirects to the proper real location within salsa?
Our source package names are unique, so there should be no conflicts.

That would make the discovery of a certain package *much* easier than
the current structured approach.

Best

Ole

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Daniele Nicolodi]

On 23/03/2018 17:04, Ole Streicher wrote:
> Why can't we have a flat name space with redirection
> 
> https://git.debian.org/
> 
> (or similar) that just redirects to the proper real location within salsa?
> Our source package names are unique, so there should be no conflicts.
> 
> That would make the discovery of a certain package *much* easier than
> the current structured approach.

Isn't this in essence the idea at the base of the Vcs- fields in
debian/control?  Namely providing an universal way to map from packages
to repositories independently of where they are hosted?

Cheers,
Daniele