On 4/8/20 10:44 PM, Peter Silva wrote:
> doesn´t this whole discussion just mean that k8 should just not be in
> Debian?
IMO no. It means that if we have enough packaging resources (which
probably we don't, I can't tell), then we may just as well ignore an
upstream who's basically saying we should
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: onedal
* URL : https://github.com/oneapi-src/oneDAL
* License : Apache-2
Programming Lang: C++, SYCL
Description : oneAPI Data Analytics Library (oneDAL)
This is possibly previously known as intel DAA
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: onemkl
* URL : https://github.com/oneapi-src/oneMKL
* License : Apache-2
Programming Lang: C++, OpenCL (maybe SYCL)
Description : oneAPI Math Kernel Library (oneMKL) Interfaces
It looks like intel is
On Mi, 08 apr 20, 16:44:22, Peter Silva wrote:
> doesn´t this whole discussion just mean that k8 should just not be in
> Debian?
>
> It should be a third party package, perhaps with a third party repo, and
> just not be in Debian at all.
> If any means of packaging for a Debian release results in
On 3/25/20 11:45 PM, Marc Haber wrote:
On Tue, 24 Mar 2020 20:37:16 +, Jeremy Stanley
wrote:
If this represents the actual state of building Kubernetes, it's
unclear to me why Debian would package it at all. I don't see the
value to users in consuming Kubernetes from a Debian package if t
On 2020-04-08 22:36:17 +0200 (+0200), Thomas Goirand wrote:
[...]
> Also, the docker world is not the only one to be this way. It used to be
> like this in OpenStack too. In the OpenStack world, they haven't changed
> the way they release (ie: every 6 months), but the user survey has shown
> that a
On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote:
I don't agree with this *at all*. It is not in the interest of our users
to be forced to update the software they use for their infrastructure
every few months.
Isn't that the user's decision, when they decided to adopt a tool that
doesn´t this whole discussion just mean that k8 should just not be in
Debian?
It should be a third party package, perhaps with a third party repo, and
just not be in Debian at all.
If any means of packaging for a Debian release results in a package that is
essentially unsupported by upstream... wh
On 4/8/20 6:14 PM, Marc Haber wrote:
> On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote:
>> On 2020-04-05 21:15 +0200, Marc Haber wrote:
>>> having an obsolete version of the software distributed
>>> with/through Debian is (rightfully) seen a liabilty by some upstreams,
>>> not as an asset.
>>
>> I
On Mon, 23 Mar 2020 08:49:44 +0100, Enrico Zini
wrote:
>On Mon, Mar 23, 2020 at 08:10:18AM +0100, Marc Haber wrote:
>> While we're at thiss, what is the tracker.d.o authenticating against?
>> Since Firefox has removed the point-and-drool interface to client
>> certificates, one needs to manually m
On Sun, 5 Apr 2020 23:16:51 +0100, Wookey wrote:
>On 2020-04-05 21:15 +0200, Marc Haber wrote:
>> having an obsolete version of the software distributed
>> with/through Debian is (rightfully) seen a liabilty by some upstreams,
>> not as an asset.
>
>I think a more interesting/important question is
This is an issue with the checking system, not a bug in your package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955268
Le 08/04/2020 à 08:54, Mechtilde Stehmann a écrit :
> Hello,
>
> for most of my packages I get the following message at
> tracker.debian.org (e.g. for tbsync)
>
>
> uscan had problems while searching for a new upstream version:
>
> In watchfile debian/watch, reading webpage
> https://github.c
On 4/8/20 8:54 AM, Mechtilde Stehmann wrote:
> How can I solve it?
Run uscan on your own system to check for new upstream releases.
This is a known issue due to the high number of packages that are
checked by the QA servers, see: #955268.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4A
14 matches
Mail list logo
