Hi Samuel,
> There is currently some momentum to make espeak-ng able to use mbrola
> voices. I am thus uploading them to Debian. Here is the list of ITPs:
[snip 30 ITPs]
First, thanks for packaging this :)
Secondly, am sorry for not seeing this until these hit NEW. For 100%
clarity, I've put t
Hello,
Chris Lamb, le sam. 21 avril 2018 09:02:44 +0100, a ecrit:
> Anyway, did you consider using dpkg's support for multiple source
> tarballs?
Yes. The thing is: I don't expect many updates (if any) of the
existing packages: since they basically ship a couple of files in
well-established plac
Package: wnpp
Severity: normal
Hi,
I'm looking for co-maintainers for the swi-prolog package, which is a
Prolog interpreter, written in C (core) and Prolog itself (most of its
libraries). SWI-Prolog is still under active development, especially
compared to other Prolog implementations (most of wh
clone 886968 -1
retitle -1 debhelper: Make -V the default for dh_makeshlibs
severity -1 wishlist
tags -1 patch
thanks
Emilio Pozuelo Monfort:
> [...]
>
> It's not in policy (but I don't think it has to be), but following the
> conversation on #-ftp yesterday I opened:
>
> #895949 lintian: warn a
Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni
* Package name: dune
Version : 1.0~beta20
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/ocaml/dune
* License : Apache-2.0
Programming Lang: OCaml
Description : composabl
Package: wnpp
Severity: wishlist
Owner: Manas kashyap
X-Debbugs-CC: debian-devel@lists.debian.org, debian-r...@lists.debian.org
* Package name : ruby-goldiloader
Version : 2.1.0
Upstream Author : Joel Turkel.
* URL : https://github.com/salsify/goldiloader
* License
On Sat, Apr 21, 2018 at 4:02 AM, Chris Lamb wrote:
> Secondly, am sorry for not seeing this until these hit NEW. For 100%
> clarity, I've put them "on hold" there for the time being.
Chris, are you aware that there are already about 45 mbrola voices
packages in Debian, even before these new ITPs?
Hi Helmut,
You've filled a large number of bugs against some of the packages I
maintain. Thanks for this effort.
However, I haven't seen a message from you sent to debian-devel. Did I
miss it, or were you unaware that this is mandatory before such mass
filling?
Also, some of the bugs are questio
On Sat, Apr 21, 2018 at 11:05 AM, Thomas Goirand wrote:
> However, I haven't seen a message from you sent to debian-devel. Did I
> miss it, or were you unaware that this is mandatory before such mass
> filling?
Yes, it looks like you missed the message:
https://lists.debian.org/debian-devel/2018/
Hi Jeremy et al.,
> It might be a bit late to try to change the source packaging for
> all of that.
Oh, I don't know it's ever to late to improve something :)
Let me play devil's advocate for a second… Whilst I would agree
that uploading a package containing all the existing ones for an
additio
On April 21, 2018 3:05:54 PM UTC, Thomas Goirand wrote:
>Hi Helmut,
...
>Also, some of the bugs are questionable at least. While yes, the python
>modules can't be imported, it doesn't seem it's been done in the
>context
>of actually using the Python module. For example, importing a sphinx
>plugi
On Sat, Apr 21, 2018 at 04:28:49PM +0100, Chris Lamb wrote:
> Let me play devil's advocate for a second… Whilst I would agree
> that uploading a package containing all the existing ones for an
> addition might potentially be wasteful of mirror bandwidth, rsync &
> friends would surely be clever en
Hi,
first two facts:
1. Upstream EOL for Python 2 is 2020
2. Debian will fully (security) support Python 2 in buster
until the EOL of buster (ETA: mid-2022)
Python 2 is obsolete, no doubt about that.
But in many cases a Linux distribution is just a platform for running
own applications, an
Adrian Bunk wrote:
> The tip of the iceberg are some recent cases where Python 2 modules
> were dropped that still had reverse dependencies in unstable
I suspect developers may be reading too much into Lintian output,
reading them as "Please remove your Python 2.x module".
The motivating behind
Le sam. 21 avr. 2018 20:04, Chris Lamb a écrit :
> Adrian Bunk wrote:
>
> > The tip of the iceberg are some recent cases where Python 2 modules
> > were dropped that still had reverse dependencies in unstable
>
> I suspect developers may be reading too much into Lintian output,
> reading them as
On 2018-04-21 20:57:55 +0300 (+0300), Adrian Bunk wrote:
[...]
> There are of course cases (e.g. OpenStack) where providing Python 2
> modules in buster is not possible with reasonable effort.
Consider me mildly curious as to why that is. The OpenStack
community rigorously tests all its current pr
On Thu, Apr 05, 2018 at 10:43:04AM +0200, Philipp Kern wrote:
> So what would be needed to make at least a simple export of the data
> happen? I think the requirements I'd have are these:
that's a good question! :)
maybe we can sit together with some ftp-team and reproducible builds
folks in Hamb
On 04/21/2018 05:14 PM, Jeremy Bicha wrote:
> On Sat, Apr 21, 2018 at 11:05 AM, Thomas Goirand wrote:
>> However, I haven't seen a message from you sent to debian-devel. Did I
>> miss it, or were you unaware that this is mandatory before such mass
>> filling?
>
> Yes, it looks like you missed the
On 04/21/2018 05:36 PM, Scott Kitterman wrote:
>
>
> On April 21, 2018 3:05:54 PM UTC, Thomas Goirand wrote:
>> Hi Helmut,
> ...
>> Also, some of the bugs are questionable at least. While yes, the python
>> modules can't be imported, it doesn't seem it's been done in the
>> context
>> of actuall
On Sat, Apr 21, 2018 at 1:57 PM, Adrian Bunk wrote:
> The tip of the iceberg are some recent cases where Python 2 modules
> were dropped that still had reverse dependencies in unstable, but
> also for those without there will in many cases be users who will
> still need these modules in buster.
O
On April 21, 2018 9:05:27 PM UTC, Jeremy Bicha wrote:
>On Sat, Apr 21, 2018 at 1:57 PM, Adrian Bunk wrote:
>> The tip of the iceberg are some recent cases where Python 2 modules
>> were dropped that still had reverse dependencies in unstable, but
>> also for those without there will in many cas
Chris Lamb, le sam. 21 avril 2018 16:28:49 +0100, a ecrit:
> Let me play devil's advocate for a second… Whilst I would agree
> that uploading a package containing all the existing ones for an
> addition might potentially be wasteful of mirror bandwidth, rsync &
> friends would surely be clever eno
On Saturday, April 21, 2018 4:05:27 PM CDT Jeremy Bicha wrote:
> But I think if we had that philosophy, we
> wouldn't ever remove anything until identified security concerns force
> it out.
I don't see anything wrong with that philosophy.
Assuming someone is willing to maintain a package and it i
Hi,
On 21-04-18 23:51, Samuel Thibault wrote:
> Well, that becomes a question of taste. We do need separate binary
> packages anyway, I don't see how using separate source packages makes it
> uglier.
Being one that uploads voices as well, I agree with Samuel on this. Note
though (and I started a
24 matches
Mail list logo
