Bug#909457: ITP: blis -- BLAS-like Library Instantiation Software Framework

[Mo Zhou]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org
Owner: Mo Zhou 

* Package name: blis
  Version : 0.4.1
  Upstream Author : The University of Texas at Austin, HP Enterprise, AMD Inc.
* URL : https://github.com/flame/blis
* License : BSD-3-clause
  Programming Lang: C
  Description : BLAS-like Library Instantiation Software Framework

This is a relatively new BLAS implementation and a new candidate to
libblas.so.3 . However unlike OpenBLAS, BLIS doesn't provide LAPACK API/ABI.

Upstream benchmarks shows a promising and comparative performance compared
to OpenBLAS and MKL, however I'm still not quite sure how fast it is,
objectively. So maybe I'll set the priority to 37, which means for the
libblas.so.3 alternative,

  OpenBLAS > BLIS > Atlas > Netlib > MKL

Moreinfo: https://github.com/flame/blis/issues/254

Bug#909463: ITP: flang -- Fortran compiler using the LLVM toolkit

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: flang
  Version : 7.0
  Upstream Author : Steve Scalpone 
* URL : https://github.com/flang-compiler
* License : BSD
  Programming Lang: C++, Fortran
  Description : Fortran compiler using the LLVM toolkit



Flang is a Fortran compiler targeting LLVM.

Flang is a Fortran language front-end designed for integration with LLVM and 
the LLVM optimizer.

Flang+LLVM is a production-quality Fortran solution designed to be co-installed 
and is fully interoperable with Clang C++.

Flang single-core and OpenMP performance is now on par with GNU Fortran; for 
certain applications up to 40% faster.
Flang has implemented Fortran 2003 and has a near full implementation of OpenMP 
through version 4.5 targeting multicore CPUs.

This will be maintained with the LLVM packaging team.

Re: Bumping epoch and reusing package name "elisa"

[Ian Jackson]

Aurélien COUDERC writes ("Bumping epoch and reusing package name "elisa""):
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the
> package has a lower version than the former Elisa project and they
> proposed bumping the epoch and reusing the name. It seems reasonable
> to me as it leaves us with 2 elisa-less Debian releases.

I think that that would be reasonable.  But:

You should see Michael Biebl's suggestions for alternative approaches.
I think it is fine if you decide to reject them but you should at
least consider them.

In particular see also Sean's response about not reusing the same
(upstream or Debian) version numbers even if you have an epoch.  That
may make Michael's suggestions more attractive.

Ian.

Bug#909483: ITP: node-worker-loader -- worker loader module for webpack

[Pirate Praveen]

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

* Package name: node-worker-loader
  Version : 2.0.0
  Upstream Author : Tobias Koppers @sokra
* URL : https://github.com/webpack-contrib/worker-loader
* License : Expat
  Programming Lang: JavaScript
  Description : worker loader module for webpack
 This loader registers the script as Web Worker.
 .
 Webpack packs CommonJs/AMD modules for the browser.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of gitlab 10.x. Since it is ES6 and needs babel to build from
source, it is not suitable for embedding.



signature.asc
Description: OpenPGP digital signature

Re: Bumping epoch and reusing package name "elisa"

[Jonathan Dowland]

On Mon, Sep 24, 2018 at 12:51:05PM +0100, Ian Jackson wrote:

You should see Michael Biebl's suggestions for alternative approaches.
I think it is fine if you decide to reject them but you should at
least consider them.

In particular see also Sean's response about not reusing the same
(upstream or Debian) version numbers even if you have an epoch.  That
may make Michael's suggestions more attractive.


+1 from me. Epochs are not only painful for maintainers, they are
confusing for users too.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Bumping epoch and reusing package name "elisa"

[Sean Whitton]

Hello,

On Sun 23 Sep 2018 at 11:49PM +0200, Michael Biebl wrote:

> Another idea could be to inform upstream of this situation. Maybe they
> are willing to bump the version number from say 0.2 to 1.2

Aurélien can use his judgement, but I'd advise against this -- it has
the potential to make upstream less happy about their software being
included in Debian.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[W. Martin Borgert]

Quoting Aurélien COUDERC :

I’m working on packaging Elisa, a modern and simple music player based
on the KDE Frameworks stack. [0][1]

I initially named the package elisa, but such a package already  
existed in the

archive in the past.


In a similar case, I just renamed the package. There used to be
dino, an "integrated MIDI piano roll editor and sequencer engine",
and there is dino, a "modern XMPP client". I renamed the latter to
"dino-im" (im = instant messaging). All problems solved.

Maybe elisa-music-player? Then it is clear to everyone, that it is
not a reference to Weizenbaums ELIZA, but maybe to "Für Elise"?

Cheers

Re: Bumping epoch and reusing package name "elisa"

[Michael Biebl]

Am 24.09.18 um 16:24 schrieb Sean Whitton:
> Hello,
> 
> On Sun 23 Sep 2018 at 11:49PM +0200, Michael Biebl wrote:
> 
>> Another idea could be to inform upstream of this situation. Maybe they
>> are willing to bump the version number from say 0.2 to 1.2
> 
> Aurélien can use his judgement, but I'd advise against this -- it has
> the potential to make upstream less happy about their software being
> included in Debian.

I don't understand. Can you elaborate why you think making upstream
aware of this situation will make them unhappy?



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



signature.asc
Description: OpenPGP digital signature

Re: Bumping epoch and reusing package name "elisa"

[Andrey Rahmatullin]

On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote:
> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package has a
> lower version than the former Elisa project and they proposed bumping the 
> epoch
> and reusing the name. 
I don't find this reasonable to be honest.
Unless it has some other reasons than just "lower version".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote:

>> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package
>> has a lower version than the former Elisa project and they proposed
>> bumping the epoch and reusing the name.

> I don't find this reasonable to be honest.
> Unless it has some other reasons than just "lower version".

This causes a ton of headaches for the archive software.  IIRC, I believe
dak is rather unhappy about version numbers going backwards, and of course
apt is going to have no idea what to do for a system that already has the
previous package installed.  Consider also systems like
snapshot.debian.org and what they have to do to deal with this.

It's basically a whole bunch of pain that can be relatively easily avoided
and probably isn't worth chasing in every piece of software.  Version
numbers should be monotonically increasing, and I think it's reasonable
for a lot of software to bake in the assumption that's the case.

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

Re: Bumping epoch and reusing package name "elisa"

[Andrey Rahmatullin]

On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
> This causes a ton of headaches for the archive software.  IIRC, I believe
> dak is rather unhappy about version numbers going backwards
This is unfortunate.

> apt is going to have no idea what to do for a system that already has the
> previous package installed. 
This is not a problem as upgrading to an unrelated software is not
something that we should care about.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Chris Lamb]

Jonathan,

> +1 from me. Epochs are not only painful for maintainers, they are
> confusing for users too.

Completely agree with this.

As an curiosa-like aside, I once deliberately bumped an epoch in order
to be *less* confusing to users.

The somewhat unique background and confluence of events was that
upstream were shipping both 4.x & 5.x versions for some time whilst
the Debian epoch was at 4: for each.

This was resulting in demonstrable and user-evidenced confusion around
versions such as `4:5.0~rc4-3`. Truth be told, I was conflating the
various branches too due to the common suffix (combined with the noise
of the regular Debian suffix). I thus therefore "unnecessarily" bumped
the epoch to 5: for the 5.x series.

I'm not sure I would do this again mind you and I'm loathed to mention
it just in case it sets precedent. (Just don't tell anyone, ok?)


Best wishes,

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

Re: Bumping epoch and reusing package name "elisa"

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:

>> apt is going to have no idea what to do for a system that already has
>> the previous package installed.

> This is not a problem as upgrading to an unrelated software is not
> something that we should care about.

I agree it's probably not going to cause problems in practice in this case
(ironically, it's probably worse for the new software to have a higher
version in terms of unexpected apt behavior), but it's still breaking
apt's version model, and I'm not sure I can think through all the
implications.

Ideally, we would never reuse the name of a binary package for some
unrelated piece of software, although I know that's not realistic in the
real world.

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

Re: Bumping epoch and reusing package name "elisa"

[Holger Levsen]

On Mon, Sep 24, 2018 at 09:24:05PM +0500, Andrey Rahmatullin wrote:
> On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote:
> > This causes a ton of headaches for the archive software.  IIRC, I believe
> > dak is rather unhappy about version numbers going backwards
> This is unfortunate.

and it's a fact.

> > apt is going to have no idea what to do for a system that already has the
> > previous package installed. 
> This is not a problem as upgrading to an unrelated software is not
> something that we should care about.

the problem lies elsewhere, as Russ described. You even acknowledged it
when calling that "unfortunate".


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Andrey Rahmatullin]

On Mon, Sep 24, 2018 at 09:38:24AM -0700, Russ Allbery wrote:
> Ideally, we would never reuse the name of a binary package for some
> unrelated piece of software
Indeed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Christoph Biedl]

Michael Biebl wrote...

> Am 24.09.18 um 16:24 schrieb Sean Whitton:
>
> > Aurélien can use his judgement, but I'd advise against this -- it has
> > the potential to make upstream less happy about their software being
> > included in Debian.
>
> I don't understand. Can you elaborate why you think making upstream
> aware of this situation will make them unhappy?

For me this concern is about asking upstream for a change that is caused
by something more or less Debian-internal - although other distributions
might have that issue as well. So it should rather be handled inside
Debian.

And I subscribe to that position.

Christoph


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Michael Biebl]

Am 24.09.18 um 19:19 schrieb Christoph Biedl:

> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.

So if other distros are potentially affected as well, it follows that
this should be handled in Debian. I can't follow that logic.

Keep in mind, that maybe upstream isn't even aware that there previously
was a software of the same name and that such a name conflict exists.

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



signature.asc
Description: OpenPGP digital signature

Re: Bumping epoch and reusing package name "elisa"

[Jeremy Stanley]

On 2018-09-24 18:07:11 +0200 (+0200), W. Martin Borgert wrote:
> Quoting Aurélien COUDERC :
> > I’m working on packaging Elisa, a modern and simple music player based
> > on the KDE Frameworks stack. [0][1]
> > 
> > I initially named the package elisa, but such a package already existed
> > in the
> > archive in the past.
> 
> In a similar case, I just renamed the package. There used to be
> dino, an "integrated MIDI piano roll editor and sequencer engine",
> and there is dino, a "modern XMPP client". I renamed the latter to
> "dino-im" (im = instant messaging). All problems solved.
[...]

Same here. When I introduced a package of the command-line utility
`weather` (in Etch) I named the source and binary packages
weather-util because there was a non-free game with the package name
"weather" in the archive three Debian releases earlier (removed
after Potato). I could have made the case for it, but packages names
are cheap and reusing a package name (no matter how old) is just a
recipe for headaches.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[Russ Allbery]

Christoph Biedl  writes:

> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.

> And I subscribe to that position.

Upstreams are going to vary a lot here.  For example, I as upstream would
be happy to bump a version number for a similar problem in Red Hat, since
meh, I don't attach a ton of significance to version numbers anyway as
long as they go up and vaguely follow semver.  (The only thing that would
give me pause is going from a 0.x to a 1.x version number, since that
carries some more semantic weight.)  But I could see some people being
irritated by the request.

I think there's no substitute for knowing upstream and having a feel for
how they'd react.

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

Re: Bumping epoch and reusing package name "elisa"

[Holger Levsen]

On Mon, Sep 24, 2018 at 07:19:57PM +0200, Christoph Biedl wrote:
> For me this concern is about asking upstream for a change that is caused
> by something more or less Debian-internal - although other distributions
> might have that issue as well. So it should rather be handled inside
> Debian.

Archlinux has epochs for the same reason and with the same effects as
well. (Except that their packages files carry the epoch in the filename,
which we don't do.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

[W. Martin Borgert]

On 2018-09-24 09:38, Russ Allbery wrote:
> Ideally, we would never reuse the name of a binary package for some
> unrelated piece of software,

Nor source package. Why not "elisa-music-player" or whatever?

Bug#906183: Dependency change and upgrade

[Devarajulu, Mohanasundaram]

Hello All,

One of the dev package, if installed alone, leads to a dangling symlink as the 
package that installs the files is not depended upon (not installed). After 
lots of discussions we found that it is better for the dev package to depend on 
the binary meta package. So the dependencies were changed on the dev package 
and meta package. Now the bug is resolved and the install happens well.
During the upgrade if all the packages are installed then upgrade is going 
through well. If only the dev package with the problem and its dependencies are 
installed, by default apt keeps the packages back as it does not want to 
install the new packages. This is the expected behavior.

The apt-get install "kept-back-package" and apt-get dist-upgrade work fine.  We 
do not foresee backporting these packages to the old releases. We do not see a 
problem in this approach even though it is an inconvenience.  Do you foresee 
any other problem?

Regards
Mohan

possible conflict over the /usr/bin/ia namespace

[Antoine Beaupré]

Hi,

TL;DR: new package from archive.org conflicts with existing `ia`
binary from python-duckduckgo2. Policy §10.1 consensus sought.

I'm in the process of packaging the Internet Archive (archive.org)
Python commandline client and that installs a client that is
conveniently called "ia" in /usr/bin. It's a simple wrapper around a
more elaborate Python library, but it allows a fairly complete set of
operations of the archive like searching, downloading, uploading and
deleting data.

Unfortunately, apt-file (is there a better way?) tells me that
python-duckduckgo2 already claimed that command namespace, along with
the ddg command, naturally.

I tried to figure out what the other package does: there's no
documentation in the Debian package, and neither command supports has
inline help or manpages. From what I can tell, the `ddg` command output
structured data from a DDG (DuckDuckGo.com) search and `ia` command does
a "feel lucky" type of request to output only one answer. This seems to
be somewhat related "Instant Answers" API (hence the `ia` acronym)
as defined here:

https://duckduckgo.com/api

So the situation falls directly under section 10.1 of the Policy:

https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries

> Two different packages must not install programs with different
> functionality but with the same filenames.

The solution proposed by the policy is to rename one or both of the
packages, after a discussion here:

> [...] try to find a consensus about which program will have to be
> renamed. If a consensus cannot be reached, both programs must be
> renamed.

Obviously, DDG has the upper hand right now: it's already passed new and
is in the archive. My "internetarchive" package is only at the ITP stage
(in CC) but it's fairly complete and would be ready for upload. Right
now it Conflicts with the DDG package, but that's not the best solution
- I would need to rename the commandline binary to respect policy, if I
understand it correctly. But before doing that, I want to give the
Internet Archive a chance.

As an argument for the archive, I would say its acronym is more commonly
known and used than DDG's, which I found out for the first time here and
never heard about before. Wikipedia agrees; in this disambiguiation
page, DDG is not listed at the time of writing, while the Archive is:

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

The "snap" package `ia` also points to the archive's software:

https://snapcraft.io/ia

Same for FreeBSD and, as far as I can tell, Arch Linux.

I would therefore propose for the python-duckduckgo2 ia binary to be
renamed to ddg-ia, as its "ia" use is only secondary in the package's
purpose.

The alternative course of action would be to rename the ia binary in the
internetarchive package to "internetarchive" but that's rather long and
unusual: all upstream documentation refers to the `ia` binary and this
could confuse our users needlessly, especially since other platforms
also use the `ia` acronym to refer to the archive as well.

The source of the package is available here:

https://salsa.debian.org/python-team/modules/python-internetarchive

Progress in the packaging can be followed in the CC'd bug report.

With good faith and spirit, sorry for the long email and thanks for any
feedback!

A,

PS: there is, incidentally, also the question of how to name this
(source and binary!) package: python3-internetarchive, internetarchive
and ia would all be interesting names for various reasons. I would
prefer the latter, but it would obviously require the DDG side to rename
first to make any sense. The Debian Python policy on this is, as far as
I know, rather undecided right now, especially for packages like
internetarchive that mix libraries and commandline tools.

-- 
I'm no longer accepting the things I cannot change.
I'm changing the things I cannot accept.
- Angela Davis

Re: Bug#906183: Dependency change and upgrade

[Andrey Rahmatullin]

On Tue, Sep 25, 2018 at 12:36:30AM +, Devarajulu, Mohanasundaram wrote:
> During the upgrade if all the packages are installed then upgrade is
> going through well. If only the dev package with the problem and its
> dependencies are installed, by default apt keeps the packages back as it
> does not want to install the new packages. This is the expected
> behavior.
I don't think it's expected, why?

-- 
WBR, wRAR


signature.asc
Description: PGP signature