Bug#908659: ITP: poliastro -- Astrodynamics and Orbital Mechanics computations

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org

* Package name : poliastro
  Version  : 0.10.0
  Upstream Author  : Juan Luis Cano Rodríguez
* URL  : http://docs.poliastro.space
* License  : MIT
  Programming lang : Python
  Upstream git : https://github.com/poliastro/poliastro
  Pypi URL : https://pypi.python.org/pypi/poliastro
  Description  : Astrodynamics and Orbital Mechanics computations

poliastro is an open source pure Python package dedicated to problems
arising in Astrodynamics and Orbital Mechanics, such as orbit
propagation, solution of the Lambert's problem, conversion between
position and velocity vectors and classical orbital elements and orbit
plotting, focusing on interplanetary applications

This is an Astropy affiliated package.

The Debian package will be maintained by the Debian Astro team. A git
repository will be created at

https://salsa.debian.org/debian-astro-team/poliastro

Best regards

Ole

Bug#908661: ITP: hipspy -- A Python astronomy package for Hierarchical Progressive Surveys

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org

* Package name : hipspy
  Version  : 0.2
  Upstream Author  : Christoph Deil and Thomas Boch
* URL  : https://hips.readthedocs.io
* License  : BSD 3-Clause
  Programming lang : Python
  Upstream git : https://github.com/hipspy/hips (4 stars)
  Pypi URL : https://pypi.python.org/pypi/hips
  Description  : Python package for Hierarchical Progressive Surveys

HiPS (Hierarchical Progressive Surveys) is a way to store large
astronomical survey sky image and catalog datasets on servers (such as
HiPS at CDS), that allows clients to efficiently fetch only the image
tiles or catalog parts for a given region of the sky they are interested
in. Similar to Google maps, but for astronomy (see the HiPS paper).

This is a Python package to fetch and draw HiPS data.

This is an Astropy affiliated package.

The Debian package will be maintained by the Debian Astro team. A git
repository will be created at

https://salsa.debian.org/debian-astro-team/hipspy

Best regards

Ole

Bug#908665: ITP: dtfabric -- Tooling for data type and structure management

[林上智]

Package: wnpp
Severity: wishlist
Owner: SZ Lin (林上智) 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: dtfabric
  Version : 20180808
  Upstream Author : Joachim Metz 
* URL : https://github.com/libyal/dtfabric
* License : Apache-2.0
  Programming Lang: Python
  Description:  Tooling for data type and structure management

 Data types fabric (dtFabric) is a proof-of-concept YAML-based
 definition language to specify format and data types.
 .
 Support data types
 .
 - Storage data types, such as integers, characters, structures
 - Semantic data types, such as constants, enumerations
 - Layout data types, such as format, vectors, trees
 .
 dtfabric is under Apache-2.0 license
--

SZ Lin (林上智) , http://people.debian.org/~szlin

Debian Developer

4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Stuart Prescott]

Jonathan Dowland wrote:

> Yes. Is "environment-modules" well-known these days? I'm surprised not
> to see it mentioned more often.

Indeed, environment-modules and direnv and excellent tools for this sort of 
game.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

Hi,


After now having seen many arguments (this thread became longer than
anticipated) for both changing the policy and for keeping it the way it is, I
am now quite convinced that the policy should be the way it is!

> > stupid idea:
> > 
> > do these scripts (and other consumers of the netgen binaries) actually
> > use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"?
> > 
> > if the latter, you might just put the unchanged names into something
> > like /usr/share/netgen/bin/ and tell users to add to that to their PATH
> > when running their scripts.
> > that provides a simple compat layer for out-of-distro scripts.
> > rdeps in Debian should be patched to use debianized script-names.

For netgen-lvs, I will just put the binary using the upstream name in
  /usr/lib/netgen-lvs/bin
There will be a symlink in /usr/bin/netgen-lvs pointing to
/usr/lib/netgen-lvs/bin/netgen


Actually just putting a note in README.Debian saying something like this...

  If you would like to use netgen-lvs with the upstream name "netgen",
  set the PATH environment variable to  PATH=/usr/lib/netgen-lvs/bin:$PATH

  To permanently enable the upstream binary name "netgen" for a user, you can
  for example add the following to the shell startup source file (~/.bashrc,
  ~/.zshrc ..):

export PATH=/usr/lib/netgen-lvs/bin:$PATH

  ...


should solve the problem.

This way, we do not globally mess up the namespace for the system. It will
only apply for specific users (root is not affected if not explicitly touched,
and hence not system scripts).

It makes it easy to see exceptions (echo $PATH), and we do not have to waste
time making "ugly" compatibility packages.

At the same time, the user will be encouraged to use the Debian name for the
executable if possible.


I guess the "long description" for the package can also refer to README.Debian
for how to handle the "issue", to make the user aware of it even before
installing it.


This may even be good enough for more complicated cases such as nodejs (was)?

Thanks IOhannes for the suggestion..


Best regards,
Ruben

Pre- and post- Buster plans for Julia language related packaging

[Mo Zhou]

Hello folks,

I think I should talk about the pre- and post- Buster plan for Debian's
Julia related packages publically rather than inside the three-person Julia
team, because neither me nor Graham is heavy Julia user. Peter is too busy.
Any suggestion and feedback will help us make Julia related packages better
for our users.

Pre-Buster
--

[Confirmed] Testing Migration and Build Failures

  The most important work for Julia team before the Buster release is to
  fix build failures and bugs of julia itself. I don't expect Julia team
  to finish any more work before the Buster release.

  Dependencies and the vim plugin are in good shape[1].

[Not Sure] Really Supported Architectures

  Julia's supported architectures are less and less since 0.3.2 to 1.0.0 
   - The mips64el package has been waiting for removal.
   - Upstream lacks aarch64 (aka arm64) maintainer[2]
  Currently we only enabled upstream tests for amd64 and i386.

  I suggest we keep amd64, i386, arm64, armhf, ppc64el for Buster.
  But should we still keep an architecture if Julia compiles but fails
  too many tests on it? IMHO such buggy resulting binary package is not
  different from junk.

  @ginggs @peter Thoughts?
  
  For reference, upstream[3] only provides prebuilt binary tarball for
  three architectures: amd64, i686, armhf.

Post-Buster
---

[Not Sure] extra packages such as PackageCompiler.jl and Plots.jl

  Julia has a built-in package manager that pulls extra packages from
  github, conveniently. And I haven't found any extra package that should
  really enter Debian archive. Please tell us if you have found one.

  That means I shall not work on extra julia packages in foreseeable future.
  @ginggs @peter How do you think?


[1] 
https://qa.debian.org/developer.php?email=pkg-julia-devel%40lists.alioth.debian.org
[2] https://github.com/JuliaLang/julia/issues/28783
[3] https://julialang.org/downloads/
[4] https://salsa.debian.org/julia-team/dh-julia

ITP: argparse-manpage

[Timo Aaltonen]

Package: wnpp
Severity: wishlist

Package name: argparse-manpage
Version : 1.1
Upstream Author : Pavel Raiskup 
URL : https://github.com/praiskup/argparse-manpage
License : Apache-2.0
Programming Lang: python
Description : Automatically build a manpage from argparse

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adrian Bunk]

On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
>...
> For example, in the Rust team, we have been discussing about packaging fd (a 
> find alternative developed using rust [1]).
> We are planning to install it in /usr/bin/fd .. but this conflicts with 
> something completely different, fdclone a clone
> of fd, a MS-DOS file browser...
> While this is probably fun, with a declining popcon (104 today), and no 
> upstream release since 2013,

This is fake news.

The latest upstream release was one month ago.

The software is developed and used since 1995.

What will be the development status and usage of the Rust "fd"
in the year 2040?

Or today?
At first sight "find program with different syntax" sounds like some 
package people will want to remove from Debian as obsolete cruft in
a few years.

"bat" from the same author also reminds me of "dog"[1].

> I am not sure it is relevant to reverse the path for a leaf packages like 
> this one.
>...

For git, node and chromium there were real problems since widely used 
programs took names that were previously used by fringe packages.

One guy on GitHub giving his fringe programs names like "bat" or "fd",
the sane solutions are to either rename or not package.

Making it easy for fringe programs to take over already used names
would cause more trouble that it would be worth.

> Cheers,
> Sylvestre
>...

cu
Adrian

[1] https://tracker.debian.org/pkg/dog

-- 

   "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: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Chris Lamb]

Dear Adrian,

> This is fake news.

Please try and avoid casual use of this term on Debian lists.

Whilst I understand your meaning and intentions, the term has now been
so overused and overapplied and has been evacuated of all useful
meaning.

Indeed, its use now appears to only distract & unnecessarily antagonise
readers and should probably be considered an illegal move in civilised
or otherwise productive conversation.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#908703: ITP: r-cran-purrrlyr -- GNU R Tools at the Intersection of 'purrr' and 'dplyr'

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-purrrlyr
  Version : 0.0.3
  Upstream Author : Lionel Henry, Hadley Wickham, RStudio
* URL : https://cran.r-project.org/package=purrrlyr
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R Tools at the Intersection of 'purrr' and 'dplyr'
 This GNU R package provides some functions at the intersection of
 r-cran-dplyr and and r-cran-purrr that formerly lived in the
 package r-cran-purrr.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-purrrlyr
This package is needed to run the autopkgtest of r-cran-snakecase.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adrian Bunk]

On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> Dear Adrian,

Dear Chris,

> > This is fake news.
> 
> Please try and avoid casual use of this term on Debian lists.
> 
> Whilst I understand your meaning and intentions, the term has now been
> so overused and overapplied and has been evacuated of all useful
> meaning.
> 
> Indeed, its use now appears to only distract & unnecessarily antagonise
> readers and should probably be considered an illegal move in civilised
> or otherwise productive conversation.

I thought this would would have been less offensive than the normal
"This is a lie." when a statement is the exact opposite of the
truth (compare [1] with the claim "no upstream release since 2013"), 
but as non-native speaker I accept your explanation that I was wrong
on that.

> Best wishes,

cu
Adrian

[1] ftp://ftp.unixusers.net/src/fdclone/

-- 

   "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: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sylvestre Ledru]

Le 12/09/2018 à 23:31, Adrian Bunk a écrit :
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
>> Dear Adrian,
> Dear Chris,
>
>>> This is fake news.
>> Please try and avoid casual use of this term on Debian lists.
>>
>> Whilst I understand your meaning and intentions, the term has now been
>> so overused and overapplied and has been evacuated of all useful
>> meaning.
>>
>> Indeed, its use now appears to only distract & unnecessarily antagonise
>> readers and should probably be considered an illegal move in civilised
>> or otherwise productive conversation.
> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.
>
It was just a mistake in my side. I was confused by the letters in the
version
and the absence of uploads in 2015, 2016 & 2017.

By the way, thanks Chris!

Sylvestre

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ian Jackson]

Ruben Undheim writes ("Re: New package netgen-lvs with binary /usr/bin/netgen - 
already taken"):
> Actually just putting a note in README.Debian saying something like this...
> 
>   If you would like to use netgen-lvs with the upstream name "netgen",
>   set the PATH environment variable to  PATH=/usr/lib/netgen-lvs/bin:$PATH
> 
>   To permanently enable the upstream binary name "netgen" for a user, you can
>   for example add the following to the shell startup source file (~/.bashrc,
>   ~/.zshrc ..):
> 
> export PATH=/usr/lib/netgen-lvs/bin:$PATH

You might want to consider writing something to discourage this
approach.  It is superficially easy, but it can cause trouble if the
same user later wants the other netgen too.

Ian.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

Adrian Bunk writes ("Re: Updating the policy for conflicting binaries names ? 
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already 
taken]"):
> I thought this would would have been less offensive than the normal
> "This is a lie."

You should never accuse someone of lying unless you are sure that they
know that what they are saying is wrong.

If you can prove that someone is deliberately saying untrue things on
Debian lists, that is abuse which should be reported and stopped.
Report such things to listmaster.

I can see no useful purpose being served by publicly claiming that
some other participant here is lying.

Ian.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Nicholas D Steeves]

On Thu, Sep 13, 2018 at 12:31:40AM +0300, Adrian Bunk wrote:
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> > Dear Adrian,
> 
> Dear Chris,
> 
> > > This is fake news.
> > 
> > Please try and avoid casual use of this term on Debian lists.
> > 
> > Whilst I understand your meaning and intentions, the term has now been
> > so overused and overapplied and has been evacuated of all useful
> > meaning.
> > 
> > Indeed, its use now appears to only distract & unnecessarily antagonise
> > readers and should probably be considered an illegal move in civilised
> > or otherwise productive conversation.
> 
> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.

I agree, no one likes being called a liar, but "This is untrue", "this
is false", and "this is a falsehood" are more neutral than "this is a
lie", because a lie is the product of lying, and lying includes the
intent to deceive and/or mislead.  Better to allow for the possibility
that someone was mistaken or misspoke ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Russ Allbery]

Adrian Bunk  writes:

> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.

"I don't think this is correct" is a less confrontational way of phrasing
this that assumes the other person is writing in good faith and just made
a mistake, as opposed to maliciously attempted to deceive people, which is
what both your original phrasing and "this is a lie" (unintentionally, I
assume) implied.

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adam D. Barratt]

On Wed, 2018-09-12 at 22:34 +0300, Adrian Bunk wrote:
> On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
> > ...
> > For example, in the Rust team, we have been discussing about
> > packaging fd (a find alternative developed using rust [1]).
> > We are planning to install it in /usr/bin/fd .. but this conflicts
> > with something completely different, fdclone a clone
> > of fd, a MS-DOS file browser...
> > While this is probably fun, with a declining popcon (104 today),
> > and no upstream release since 2013,
> 
> This is fake news.
> 
> The latest upstream release was one month ago.

Leaving aside the issues with wording, as I think others have covered
that sufficiently already, Sylvestre's was a relatively simple mistake
to make.

Googling for "fdclone" leads one to https://github.com/knu/FDclone as
the first hit (at least it does for me), which indeed says "Latest
commit 460e591 on 7 Jun 2013".

Regards,

Adam

[Delayed] Summary of the web team BoF at DC18

[Steve McIntyre]

[ Please note the cross-post and Reply-To ]

Hey folks,

As promised, here's a quick summary of what was discussed at the web
team BoF session in Hsinchu. Apologies for the delay in posting...

Thanks to the awesome efforts of our video team, the session is
already online [1]. I've taken a copy of the Gobby notes too,
alongside my small set of slides for the session. [2]

DebConf18 Web team BoF
3th August 2018, Hsinchu, Taiwan

Migration to git


Since the BoF last year, we finally managed to migrate away from CVS
to git. We managed it *just* before alioth went away. There was quite
a lot of work involved:

 * Actual migration of the data and code from CVS to git, very slow
   due to the huge repository we have full of many thousand small
   files

 * Changes to the translation helper and tracking scripts to use git

 * Changes to the wml itself - some of the template pages contain
   quite a lot of embedded perl which needed updating too. Also needed
   updating to use git.

 * Lots of work needed to make the new git-related code work with
   acceptable performance. Builds a cache of git revisions to allow
   for version comparisons that we used to do by directly comparing
   CVS versions. In the end, website rebuilds are now much faster than
   we were using CVS. \o/ Still not fast enough, but we have a very
   large site...

 * The workflow afterwards is *almost* the same, but had to change how
   smart_change.pl works due to the way git works

 * On the translation dashboards, we've had to drop the direct diff
   links that we used to have. Instead we now have cut and paste
   command lines for git diff commands. Needed as otherwise this
   causes too much load on salsa and it times out on the links often.

Main point to take away: the migration has happened! It should now
allow us to work on more intrusive changes to our website that would
never have been feasible before. Hopefully it might now also encourage
more people to contribute, who were put off previously.

We already have merge requests coming in via salsa to make small
improvements to the website, which is a good sign! We can now be more
agile / more daring with rapid website changes.

Design work
---

There was already another session earlier during DebConf, run by
Thomas Lange [3], focussing on the www.d.o front page and top-level
pages. We could do with making these easier for *new* people to use,
to find out more about Debian and how to get involved. Most DDs rarely
use these pages, so we have a lot of content that is not actually
useful for any audience. We should improve this. See

  https://informatik.uni-koeln.de/public/lange/debian-homepage/

as an example look from Thomas.

Steve's own pet project here is a clean new "download" page group to
replace the huge, scattered set of conflicting, out of date pages we
have now.

What else should we do with design? A new look?

Content
---

We have too much content on the website. Good content is great, but
very old stuff that hasn't been updated in a decade and is now
clearly out of date is really not helpful. Really old information for
users about how to use Debian isn't valuable, and is more likely to
put people off or maybe even be dangerous.

With too much content, it's also likely to put people off when they
want to change things. Which pages need changing? Which ones are users
actually finding? It's difficult to know, and demotivating.

Should we maybe split the website into multiple repos? We spoke about
this last year...

Suggested workflow for layout / page look changes:

  * Go and work on a branch and make the changes
  * Send a MR, and post screenshots alongside to show what the new
pages look like

That way, people can see what's proposed. Merging changes are easy,
even if we need to tweak translations afterwards.

We now (again!) have https://www-staging.debian.org/ available, thanks
to work from pabs. Maybe we could use that to compare before=and-after
changes.

Other points


 * Build using GitLab CI?  (this looks quite difficult! proposals welcome :-))
 * More discussion with Thomas about changes to the front page
   + Why Debian? - add some simple points
   + Too much information in sentences - just remove lots of that, and
 switch to links to further pages for more info
   + Remove the security updates links - just link to the security
 tracker once, or a top-level /security/ page? The level of detail
 on the front page right now is both too detailed and not detailed
 enough, depending on POV
   + Remove the duplicated sets of links, in particular the blocks at
 the top of the front page.
   + The "News" section is not great, just lists our stable and
 oldstable updates. Is that really News? What about DebConf? Talks
 by prominent DDs? Links to other people talking about Debian?
   + Make things more visual and welcoming
 * Remove duplication - far too much of our information is found in
   multiple p