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: 1395 (new: 3)
Total number of packages offered up for adoption: 156 (new: 0)
Total number of packages reques
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-pylibsrtp
Version : 0.6.1
Upstream Author : Jeremy Lainé
URL : https://pypi.org/project/pylibsrtp/
License : BSD-3
Programming Lang: Python
Description : Python wrapper around lib
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-aioice
Version : 0.6.14
Upstream Author : Jeremy Lainé
URL : https://pypi.org/project/aioice/
License : BSD-3
Programming Lang: Python
Description : library for Interactive Connec
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-av
Version : 6.1.2
Upstream Author : Mike Boers
URL : https://pypi.org/project/av/
License : BSD-3
Programming Lang: Python
Description : Pythonic binding for the FFmpeg libraries
On 2019-02-07 21:20:07 +0100 (+0100), Ondřej Surý wrote:
> en_DK.UTF-8 is a good default locale?
[...]
I'm a proponent of en_DK.UTF-8 in general, particularly as it gets
you ISO 8601 date and time when set for LC_TIME. I have trouble with
its inversion (relative to my cultural background) of "," a
On Thu, Feb 07, 2019 at 10:21:49PM +0100, Ansgar wrote:
(And you get 24-hour time, but very strange Endian in C.UTF-8:
WEEKDAY MMM DD HH:MM:SS TZ
while en_US.UTF-8 has at least DD MMM ... Having
-MM-DD HH:MM:SS[+]
instead would be much nicer if we were to create an arbitrary s
Michael Stone writes:
> On Thu, Feb 07, 2019 at 09:20:07PM +0100, Ondřej Surý wrote:
>>en_DK.UTF-8 is a good default locale?
>
> I think the suggestion of just "en" made the most sense--specify the
> language and an arbitrary set of rules that aren't tied to a specific
> country.
C.UTF-8 has the d
On Thu, Feb 07, 2019 at 09:20:07PM +0100, Ondřej Surý wrote:
en_DK.UTF-8 is a good default locale?
I think the suggestion of just "en" made the most sense--specify the
language and an arbitrary set of rules that aren't tied to a specific
country.
en_DK.UTF-8 is a good default locale?
On Thu, 7 Feb 2019 at 14:05, Adam Borowski wrote:
> On Thu, Feb 07, 2019 at 02:55:33PM +0500, Roman Mamedov wrote:
> > So for those of us (the entire world), who have been relying on this
> behavior:
> >
> > > * en_US (.UTF-8) is used as the default English
]] Simon McVittie
> I think this is exactly the "international/culture-neutral English"
> locale that you're looking for.
I wish we'd get away from this; nothing is ever culture-neutral, and «C»
does not give you any guarantees about what language (if any!) the
output is in.
If people want Engl
> "Alex" == Alex Bennée writes:
Alex> Hi,
Alex> The following bug has come up and we would like some input
Alex> from the multiarch and cross developers on how best to handle
Alex> this case.
Alex> In an ideal world all cross compilers would be available on
Alex> all
Hi,
The following bug has come up and we would like some input from the
multiarch and cross developers on how best to handle this case.
In an ideal world all cross compilers would be available on all release
architectures but I think it will be a while before we get there. My own
efforts to get
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anywa
(Apologies if you receive this message twice; I dropped a ball juggling
e-mail identities).
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source p
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote:
> On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
> > POSIX specifies the output format for various utilities in the C locale,
> > which defeats my understanding of the purpose of this proposal. So, for
> > example, in ls -l:
>
> I
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> On Thu, 07 Feb 2019 at 14:05:33 +0100, Adam Borowski wrote:
> > a locale for a silly country with weird customs
>
> Please don't take this tone. Insulting people who disagree with you[1]
> is rarely an effective way to persuade them
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote:
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> How would this locale differ from C.UTF-8? Is the only difference
> that C.UTF-8 has strict lexicographical sorting, w
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
> On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> > How would this locale differ from C.UTF-8? Is the only difference
> > that C.UTF-8 has strict lexicographical sorting, whereas "en" would
> > have
> > case-insensitive sorti
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
How would this locale differ from C.UTF-8? Is the only difference
that C.UTF-8 has strict lexicographical sorting, whereas "en" would have
case-insensitive sorting like en_GB.utf8 does? (If that's the only
difference, then perhaps so
On Thu, 07 Feb 2019 at 14:05:33 +0100, Adam Borowski wrote:
> a locale for a silly country with weird customs
Please don't take this tone. Insulting people who disagree with you[1]
is rarely an effective way to persuade them that you're right and
they're wrong.
> • promoting C.UTF-8 in our user i
On Wed, Feb 06, 2019 at 06:32:02PM +0100, Carsten Schoenert wrote:
I know of at least git-buildpackage will do this with the option
'--import-dscs' by importing all available versions from the Debian
archives.
I assume Ian's tool can do something similar.
To be explicit, that's "dgit"
https://
Quoting Adam Borowski :
The en_US.UTF-8 locale has two purposes:
And I always wondered why other locales than en_DK.UTF-8 even exist!
• promoting C.UTF-8 in our user interfaces (allowing to select it in d-i,
making dpkg-reconfigure locales DTRT, making it the d-i default)
-- nice for Unix
Peter Silva writes ("Re: Bug#877900: How to get 24-hour time on en_US.UTF-8
locale now?"):
> iso_en ? That sounds smart...
>
> English for most of the world that aren't necessarily native English speakers?
> https://en.wikipedia.org/wiki/International_English
> Use ISO dates and stuff, and pick
iso_en ? That sounds smart...
English for most of the world that aren't necessarily native English
speakers? https://en.wikipedia.org/wiki/International_English
Use ISO dates and stuff, and pick a random spelling. As a Canadian, I'm
pretty sure about colour, but unclear about whether we should st
On Thu, Feb 07, 2019 at 02:55:33PM +0500, Roman Mamedov wrote:
> So for those of us (the entire world), who have been relying on this behavior:
>
> > * en_US (.UTF-8) is used as the default English locale for all places that
> > don't have a specific variant (and often even then). Generally, te
Package: wnpp
Severity: wishlist
Owner: Peter Pentchev
* Package name: libperl-prereqscanner-notquitelite-perl
Version : 0.9904
Upstream Author : Kenichi Ishigaki
* URL : https://metacpan.org/release/Perl-PrereqScanner-NotQuiteLite
* License : Artistic or GPL-
Package: wnpp
Severity: wishlist
Owner: Peter Pentchev
* Package name: libregexp-trie-perl
Version : 0.02
Upstream Author : Dan Kogai
* URL : https://metacpan.org/release/Regexp-Trie
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : P
On Wed, Feb 06, 2019 at 12:34:22PM -0500, Roberto C. Sánchez wrote:
> On Wed, Feb 06, 2019 at 05:59:40PM +0100, Carsten Leonhardt wrote:
> > Ian Jackson writes:
> >
> > > There are utilities that will download all revisions of a particular
> > > package from snapshot.d.o and make them into a comb
28 matches
Mail list logo
