Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout
* Package name: golang-github-containerd-typeurl
Version : 0.0~git20170912.f694355-1
Upstream Author : Arnaud Rebillout
* URL : https://github.com/containerd/typeurl
* License : Apache-2.0
Programming L
Em 23-02-2018 01:51, Georg Faerber escreveu:
...at least for me. Could someone forward this to DSA?
Everything just just fine for, is it really on home page?
(I would have contacted them directly via ITC, but currently traveling
without access to IRC.)
Thanks,
Georg
--
Lucas Castro
...at least for me. Could someone forward this to DSA?
(I would have contacted them directly via ITC, but currently traveling
without access to IRC.)
Thanks,
Georg
signature.asc
Description: Digital signature
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1263 (new: 2)
Total number of packages offered up for adoption: 159 (new: 0)
Total number of packages reques
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero
* Package name: ignition-tools
Version : 0.1.0
Upstream Author : Open Robotics
* URL : https://ignitionrobotics.org/libs/tools
* License : Apache2
Programming Lang: ruby
Description : Entry point
Hi Ian,
On Tue, Feb 20, 2018 at 09:23:00PM +, Ian Jackson wrote:
> I would like some test cases for experimenting with various algorithms
I think python-pandas 0.20.3 -> 0.22.0 would qualify as complex test
case.
Hope this helps
Andreas.
--
http://fam-tille.de
]] Daniel Pocock
> Even if DSA didn't grant access to the instance you run now, would it be
> considered easier for you to support extra, identical instances of RT
> rather than supporting Kanboard or alternatives?
That depends on what the alternatives are, but I think that's unlikely.
We'd like
Le jeudi, 22 février 2018, 19.44:06 h CET Roberto C. Sánchez a écrit :
> If we are going to start applying this sort of logic to naming, then
> there are plenty of other places (e.g., where actual vulgarities are
> used in package names, where abreviations and/or acronyms create words
> that are or
On Thu, Feb 22, 2018 at 07:31:23PM +0100, Didier 'OdyX' Raboud wrote:
> Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> > ("super long-term maintenance", SLTS in their jargon)
>
> A small point, but I haven't seen anyone mention it yet: I would not use the
> 'slts' acronym,
Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> ("super long-term maintenance", SLTS in their jargon)
A small point, but I haven't seen anyone mention it yet: I would not use the
'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear
word.
Cheers,
Hi Raphael
On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
> > I would however suggest that it should not be part of the normal mirror
> > area, since:
> Ack on all this. That's why I suggested to keep only the part on
> security.debian.org and drop the part on the main mirror.
T
On Fri, Feb 16, 2018 at 04:11:29PM +0100, Raphael Hertzog wrote:
> Hello everybody,
>
> the fact that I had to request the removal of dolibarr from Debian makes
> me sad (see below for the reasons) and I believe that we should be able
> to do better to provide complex applications to our end users
On Thu, 2018-02-22 at 16:51 +0100, Raphael Hertzog wrote:
> Hi,
>
> On Thu, 22 Feb 2018, Lars Wirzenius wrote:
> > I don't have an opinion on whether this should be done on Debian
> > servers or not, but I have a comment on providing security support for
> > more than a decade. How do you plan to
Hi,
On Thu, 22 Feb 2018, Lars Wirzenius wrote:
> I don't have an opinion on whether this should be done on Debian
> servers or not, but I have a comment on providing security support for
> more than a decade. How do you plan to deal with the kernel?
FTR, I'm not involved in CIP and thus I can't s
On Thu, 2018-02-22 at 16:31 +0200, Lars Wirzenius wrote:
> I don't have an opinion on whether this should be done on Debian
> servers or not, but I have a comment on providing security support for
> more than a decade. How do you plan to deal with the kernel? Do you
> expect to backport security fi
Hello,
On Thu, 22 Feb 2018, Geert Stappers wrote:
> But what is "CIP"?
>
> My websearch did bring up "Clean In Place" and "Christelijk Intromatie
> Platform" ...
It was explained in my first mail.
Civil Infrastructure Platform
https://www.cip-project.org/
Cheers,
--
Raphaël Hertzog ◈ Debian
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
* Package name: golang-github-dcso-fluxline
Version : 0.0~git20180222.25ae683-1
Upstream Author : DCSO GmbH
* URL : https://github.com/DCSO/fluxline
* License : BSD-3-clause
Programming Lang: Go
Descr
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
* Package name: golang-github-safchain-ethtool
Version : 0.0~git20170622.7ff1ba2-1
Upstream Author : Sylvain Afchain
* URL : https://github.com/safchain/ethtool
* License : Apache-2.0
Programming Lang:
On 2018-02-22 at 09:45, Geert Stappers wrote:
> On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
>> On Thu, 22 Feb 2018, Philip Hands wrote:
>>
>>> I'm in favour of making it possible for our users to build
>>> structures that enable longer support periods if that's what they
>>>
On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote:
> Hello,
>
> On Tue, 20 Feb 2018, Moritz Mühlenhoff wrote:
> > LTS has a clearly defined scope, while this is essentially contracting
> > work to extend the life time of some packages for some customers.
> >
> > I don't see a compel
I don't have an opinion on whether this should be done on Debian
servers or not, but I have a comment on providing security support for
more than a decade. How do you plan to deal with the kernel? Do you
expect to backport security fixes to the wheezy kernel, or upgrade the
kernel to newer versions
On Tue, Feb 20, 2018 at 11:48:43PM +0100, Joerg Jaspert wrote:
If this would be "just" extending the current LTS ways for more time,
then it would be OKish to stay on donated, voluntarily managed,
infrastructure. After all it helps all users of wheezy with updates,
nominally over all of wheezy.
Hello,
On Tue, 20 Feb 2018, Moritz Mühlenhoff wrote:
> LTS has a clearly defined scope, while this is essentially contracting
> work to extend the life time of some packages for some customers.
>
> I don't see a compelling reason for it to run on Debian infrastructure.
This was also my first fee
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-phytools
Version : 0.6-44
Upstream Author : Liam J. Revell
* URL : https://cran.r-project.org/package=phytools
* License : GPL
Programming Lang: GNU R
Description : GNU R phyl
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-animation
Version : 2.5
Upstream Author : Yihui Xie
* URL : https://cran.r-project.org/package=animation
* License : GPL
Programming Lang: GNU R
Description : GNU R gallery of
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-clustergeneration
Version : 1.3.4
Upstream Author : Weiliang Qiu
* URL : https://cran.r-project.org/package=clusterGeneration
* License : GPL
Programming Lang: GNU R
Description
On 21/02/18 20:39, Tollef Fog Heen wrote:
> ]] Daniel Pocock
>
>> Another possibility: DSA already run RT and there is a Kanban
>> extension[3] for it.
>
> I doubt we're interested in making the RT setup generally available for
> people to create and sign up for queues and such.
>
> (Speaking
* Philip Hands: " Re: Extended Long Term Support for Wheezy" (Thu, 22 Feb 2018
08:46:16 +0100):
> On Wed, 21 Feb 2018, m...@linux.it (Marco d'Itri) wrote:
> > On Feb 21, Antonio Terceiro wrote:
> >
> [...]
> > Indeed. If the scope of the project is reasonable and clearly defined
> > then
Hi Adam,
On 11 February 2018 at 13:51, Adam D. Barratt wrote:
> The answer was "yes", in fact.
>
> I'm unsure how you've deduced "i386 wasn't a problem" when the above
> clearly shows that the lack of a lua-torch-torch7 package on several
> architectures is a current blocker for the migration.
>
29 matches
Mail list logo
