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
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 usin
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 lea
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 : Ex
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 o
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 upstr
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
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
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.
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 fi
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
>
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 wa
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 c
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.
a
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
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 m
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
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
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.
Upst
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.
Ar
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?
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
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.
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
24 matches
Mail list logo
