Bug#719356: ITP: libarchive-any-lite-perl -- simple CPAN package extractor

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libarchive-any-lite-perl
  Version : 0.07
  Upstream Author : Kenichi Ishigaki, 
* URL : http://search.cpan.org/dist/Archive-Any-Lite/
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : simple CPAN package extractor

Archive::Any::Lite is a fork of Archive::Any by Michael Schwern and
Clint Moore. The main difference is that Archive::Any::Lite works
properly even when you fork(), and may require less memory to extract a
tarball. On the other hand, Archive::Any::Lite isn't pluggable (it only
supports file formats used in the CPAN toolchains), and doesn't check
mime types (at least as of this writing).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130811102916.65477.4487.report...@island.zedat.fu-berlin.de

Re: Bug#719323: ITP: jackson-core -- fast and powerful JSON library for Java

[Stephen Nelson]

On 11 Aug 2013 00:32, "Wolodja Wentland"  wrote:
> It is not, but thank you for catching this and reviewing WNPP bugs! :)
>
> libjackson-json-java is version 1.* of the JSON processoe by FasterXML
while I
> plan to package version 2.* which has been split into a number of
packages and
> should be packaged separately. In the light of this I will try to make it
more
> obvious that this is, in fact, Jackson2.
>
> Have a good day!

Thanks for packaging the latest version. I think it would be better to be
consistent on the naming according to the Debian Java standards [1] and
name it something like libjackson2-core-java.

[1] http://www.debian.org/doc/packaging-manuals/java-policy/x114.html

Cheers.

Re: Bug#719323: ITP: jackson-core -- fast and powerful JSON library for Java

[Wolodja Wentland]

On Sun, Aug 11, 2013 at 12:52 +0100, Stephen Nelson wrote:
> On 11 Aug 2013 00:32, "Wolodja Wentland"  wrote:

>> It is not, but thank you for catching this and reviewing WNPP bugs! :)
>> libjackson-json-java is version 1.* of the JSON processoe by FasterXML
>> while I plan to package version 2.* which has been split into a number of
>> packages and should be packaged separately. In the light of this I will try
>> to make it more obvious that this is, in fact, Jackson2.

> Thanks for packaging the latest version. I think it would be better to be
> consistent on the naming according to the Debian Java standards [1] and name 
> it
> something like libjackson2-core-java.

> [1] http://www.debian.org/doc/packaging-manuals/java-policy/x114.html

I am not sure if it makes sense to adapt this naming scheme for source
packages and I would personally very much prefer to use the name used by
upstream. There are also quite a number of packages maintained by pkg-java
that simply use the name used by upstream.

The binary packages will, naturally, follow the naming conventions of pkg-java
and this particular source package builds two binary packages, namely:

* libjackson2-core-java
* libjackson2-core-java-doc

Please let me know if that is in line with your expectations and have a nice
day!
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Bug#719421: ITP: libreturn-multilevel-perl -- Perl module to enable returning from a nested call stack

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libreturn-multilevel-perl
  Version : 0.03
  Upstream Author : Lukas Mai, 
* URL : http://search.cpan.org/dist/Return-MultiLevel/
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : Perl module to enable returning from a nested call stack

Return::MultiLevel provides a way to return immediately from a deeply
nested call stack. This is similar to exceptions, but exceptions don't
stop automatically at a target frame (and they can be caught by
intermediate stack frames). In other words, this is more like
setjmp(3)/longjmp(3) than die.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130811142153.11426.2820.reportbug@thinkpad

Re: unnecessarily tight dependency on R for r-cran-scales

[Andreas Tille]

Hi Faheem,

On Sat, Aug 10, 2013 at 12:24:23PM +0530, Faheem Mitha wrote:
> >One could consider adding systematically the magic tilde to the
> >version numbers passed to ${R:Depends}, but at that point, I think
> >that it is even better to implement a versionned R API number.
> 
> A versioned R API number would be a good idea. Is this supported by
> R? What would be involved in implementing it?

I can not read Charles' mind but as far as I understood he tried to
propose that we are distinguishing via R package versioning between
different R APIs and there is no support from R upstream is needed -
we just need to know when R API has changed to bump the version of
the package.

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130811160533.gf16...@an3as.eu

Bug#719436: ITP: autorevision -- extracts metadata about the current revision from your repository

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 

* Package name: autorevision
  Version : 1.4
  Upstream Author : dak180, Eric S. Raymond
* URL : http://www.catb.org/esr/autorevision/
* License : MIT
  Programming Lang: shell
  Description : extracts metadata about the current revision from your 
repository

I'm packaging this since warzone2100 uses it during the build process.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

UTF-8 in jessie

[Adam Borowski]

On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie.

I would like to propose full UTF-8 support.  I don't mean here full
support for all of Unicode's finer points, merely complete eradication of
mojibake.  That is, ensuring that /m.o/ matches "möo", or that "ä" sorts
as equal to "a""combining ¨" is out of scope of this proposal.

I propose the following sub-goals:

1. all programs should, in their default configuration, accept UTF-8 input
   and pass it through uncorrupted.  Having to manually specify encoding
   is acceptable only in a programmatic interface, GUI/std{in,out,err}/
   command line/plain files should work with nothing but LC_CTYPE.

2. all GUI/curses/etc programs should be able to display UTF-8 output where
   appropriate

3. all file names must be valid UTF-8

4. all text files should be encoded in UTF-8


This proposal doesn't call for eradication of non-UTF8 locales, even though
I think that's long overdue.  Josselin Mouette proposed that in #603914,
and I agree, but that's material for another flamewar.


Let's discuss the above points in depth: 

1. properly passing UTF-8

Text entered by an user should never get mangled.  These days, we can assume
mixed charsets are a thing of the past, thus there's no need of special
handling.  So are, mostly, programs that don't support it -- but due to
historic reasons, some are not configured to do so.  Thus, let's mandate
that no per-program steps are needed.

An example: let's say we have an SQL table foo(a varchar(250)).  Let's run
somesqlclient -e "insert into foo values('$x'); select a from foo"
(-e being whatever stands for "execute this statement").

sqlite3: ok
p[ostgre]sql: ok
mysql: doesn't work!

But... the schema was declared as UTF-8, my locale is en_US.UTF-8, why
doesn't it work?  Turns out mysql requires you to call it with an extra
argument, --default-character-set=utf8.  There's no binary ABI to maintain,
compat with some historic behaviour makes no sense.  I can accept having to
specify the charset in, say, a DBI line, as that's what the API wants, but
on the command line... that's just wrong.  Am I supposed to wrap everything
with iconv, and suffer data loss on the way?  Setting LANG/LC_foo should
be enough.

Another case, perhaps more controversial, is apache.  Just take a look at
how many of Debian random project pages have mangled encodings somewhere. 
By a 0th approximation, well over one third (more for text/plain, such as
logs).  And that's with users whose skills are way above average.
These days, producing text that's not in UTF-8 can take quite a bit of
effort, especially with modern GUI tools which don't even really pay lip
service to supporting ancient charsets anymore.  Thus, if someone serves
some text in such a charset, he takes pains to even edit it.
One argument is that because AddDefaultCharset overrides http-equiv,
such old files would be mangled.  I'd say, as they already take effort
to maintain, let's let them rot in hell, as they are a rare case that
stands in the way of a nearly ubiquitous one working properly.  Such an
admin can always configure his server to use an ancient encoding if he
wishes to do so.
(The other argument, our own files shipped in /doc/, is dead since apache
2.2.22-4, and is a major part of part 4 of this proposal.)


2. GUI/curses display

With gtk, qt, and probably more, the issue is mostly moot.  Other toolkits
might require some work, but typically it's a matter of encoding (part 1 of
this proposal): characters have different horizontal widths so you use
outside functions for functionality like line wrapping already.

Not so much in curses.  Here, you have some characters take two spaces
(CJK), some take zero (zero width spaces), some take zero but must not be
detached from the previous character (combining).  The line wrapping
algorithm is actually quite simple, but needs to be implemented for every
curses program that displays arbitrary strings.  Ouch.

[I got quite some experience fixing curses/etc programs this way, so I
pledge priority help here.  gtk/qt/fooxwidgets, not so much.]


3. all file names must be UTF-8

This is quite straightforward.  They are already uninstallable on
filesystems that operate in characters rather than bytes.  Might be a good
idea to forbid nasty stuff like newlines, tabs, etc too.

I propose to apply this restriction to source packages as well.  If
Contents-* files are to be believed, the only violation is a binary package,
zero source ones, so there'd be no extra work now, and at most a repack
if an upstream regresses.  The benefit is less clear than for binaries,
but it's trivial and would prevent unexpected breakages.


4. all shipped text files in UTF-8

We don't want mojibake in provided documentation, config files, etc.  With
the amount of hackers nearby, even perl/shell/python/etc scripts in
/*/bin.  In short, all text files.

This could be done

Re: UTF-8 in jessie

[Chow Loong Jin]

On Mon, Aug 12, 2013 at 02:51:52AM +0200, Adam Borowski wrote:
> [...]
> 
> On the other hand, detecting text files is hard.  The best tool so far,
> "file", makes so many errors it's useless for this purpose.  One could use
> location: like, declaring stuff in /etc/ and /usr/share/doc/ to be text
> unless proven otherwise, but that's an incomplete hack.  Only hashbangs can
> be considered reliable, but scripts are not where most documentation goes.

Just a note: hashbangs can't really be considered reliable either -- consider
tarball-in-sh/other-script files (waf is a good example). Then there's stuff
like gambas-compiled executables which also ship with valid hashbangs, and
#!/usr/bin/haserl stuff which can contain lua bytecode after the hashbang line.

The only requirement for valid hashbangs, afaict, is that the first two bytes
are #!, and everything up to the \x20 or \n is resolvable to a valid filename.

> [...]


-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: UTF-8 in jessie

[Charles Plessy]

Le Mon, Aug 12, 2013 at 02:51:52AM +0200, Adam Borowski a écrit :
> 
> I would like to propose full UTF-8 support.  I don't mean here full
> support for all of Unicode's finer points, merely complete eradication of
> mojibake.

Hi Adam,

this is a great goal.  Here are two comments.

There is a related issue opened on the Policy (),
where we propose the following:

 - Require UTF-8 for the names of all files and directories installed by binary 
packages.
 - Recommend ASCII when possible.
 - Require ASCII for files in /bin, /sbin, /usr/bin, /usr/sbin and /usr/games.

About display by GUIs, I think that we should have a system to install all the
fonts necessary to display languages that we support at the installation.

Have a nice Debconf !

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130812021825.gc6...@falafel.plessy.net

Bug#719458: ITP: python-contextlib2 -- Backported utilities for context management

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name: python-contextlib2
  Version : 0.4.0
  Upstream Author : Nick Coghlan
* URL : http://contextlib2.readthedocs.org/
* License : PSF License
  Programming Lang: Python
  Description : Backports and enhancements for the contextlib module

contextlib2 is a backport of the standard library's contextlib module to
earlier Python versions.

It also serves as a real world proving ground for possible future
enhancements to the standard library version.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130812034638.3327.8862.report...@lorien.mithrandi.net