Bug#701527: ITP: yi -- Haskell-Scriptable Editor

2013-02-24 Thread Masayuki Hatta
Package: wnpp
Severity: wishlist
Owner: Masayuki Hatta 

* Package name: yi
  Version : 0.6.6.0
  Upstream Author : Yi development team 
* URL : http://hackage.haskell.org/package/yi
* License : GPL
  Programming Lang: Haskell
  Description : Haskell-Scriptable Editor

Yi is a text editor written in Haskell and extensible in Haskell.  The goal 
of the Yi project is to provide a flexible, powerful, and correct editor 
for haskell hacking.


-- 
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/20130224080515.9394.78051.report...@xanadu.mhatta.org



Re: WebRTC has landed

2013-02-24 Thread Daniel Pocock
On 24/02/13 01:01, Timo Juhani Lindfors wrote:
> Daniel Pocock  writes:
>> - WebSockets carries the SIP signaling (e.g. to register the user
>> location, find the person you want to call).  WebSockets works through
>> HTTP proxies
> 
> http://en.wikipedia.org/wiki/WebRTC does not mention SIP at all. I
> assume SIP is just one way to use webrtc but it does not need to be
> used?

That is correct - SIP leverages a huge existing infrastructure of
softphones and desk phones and even mobile VoIP (like
http://www.lumicall.org)

In theory, WebRTC is JavaScript running in two web browsers.  As long as
the JavaScript code can learn the IP address of the peer, it can make a
call. So it could display it's own IP address on the web page, the users
could exchange IP addresses over SMS, then enter the IP remote addresses
in a form field, and that would be enough for the browsers to make a call.

>> and make your devices talk to each other without any relay.  If one
>> person is in an obscure location, the TURN server will act as a relay
> 
> Aha, it seems the resiprocate-turn-server package is new in
> wheezy. Default configuration seems to listen on tcp port 3478. I guess
> port 443 should be used to maximize the probability that proxies will
> let websocket access it?

It could be configured that way, and if you had a very clever ICE client
implementation that knows how to use the HTTP CONNECT method, it would
work very widely indeed.


-- 
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/5129d0d5.7030...@pocock.com.au



Bug#701568: ITP: r-cran-memoise -- Memoise functions

2013-02-24 Thread Ivo Maintz
Package: wnpp
Severity: wishlist
Owner: Ivo Maintz 

* Package name: r-cran-memoise
  Version : 0.1
  Upstream Author : Hadley Wickham 
* URL : http://cran.r-project.org/web/packages/memoise/
* License : MIT
  Programming Lang: R
  Description : Memoise functions
 Cache the results of a function so that when you call it again with the same
 arguments it returns the pre-computed value.


-- 
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/20130224153017.1052.27073.report...@orm.biologie.hu-berlin.de



Bug#701571: ITP: aragorn -- detect tRNA genes in nucleotide sequences

2013-02-24 Thread Sascha Steinbiss
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: aragorn
  Version : 1.2.36
  Upstream Author : Dean Laslett , Bjorn Canback 
 
* URL : http://mbio-serv2.mbioekol.lu.se/ARAGORN/ 
* License : GPL
  Programming Lang: C
  Description : detect tRNA genes in nucleotide sequences

Transfer RNAs (tRNAs) are are small RNA molecules used as a linker between
nucleic acids and amino acids during protein synthesis. ARAGORN detects 
and annotates tRNA and tmRNA genes in (longer) nucleotide sequences like 
published genome sequences. Aragorn employs heuristic algorithms to predict 
tRNA secondary structure, based on homology with recognized tRNA consensus 
sequences and ability to form a base-paired cloverleaf.
The tmRNA detection algorithm is an development of the earlier published 
BRUCE algorithm.


-- 
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/20130224155433.11030.93602.reportbug@siyah



Bug#701574: ITP: libcrypt-random-tesha2-perl -- module for generating random numbers using timer/schedule entropy

2013-02-24 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcrypt-random-tesha2-perl
  Version : 0.01+dfsg
  Upstream Author : Dana A Jacobsen 
* URL : https://metacpan.org/release/Crypt-Random-TESHA2/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for generating random numbers using timer/schedule 
entropy

Crypt::Random::TESHA2 generates random numbers using entropy gathered from
timer / scheduler jitter, aka userspace voodoo entropy.

This can be used to generate non-pseudorandom data to seed a PRNG (e.g.
srand/rand, Math::Random::MT, etc.) or CSPRNG (e.g. AES-CTR or
Math::Random::ISAAC). You may use it directly or as part of a random source
module that first checks for O/S randomness sources.

Only Perl CORE modules are used, making this very portable. However, systems
must have a high resolution timer and support usleep from Time::HiRes.


-- 
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/20130224165049.ga15...@jadzia.comodo.priv.at



Bug#701575: ITP: libcrypt-random-seed-perl -- module providing strong randomness for seeding

2013-02-24 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcrypt-random-seed-perl
  Version : 0.3
  Upstream Author : Dana A Jacobsen 
* URL : https://metacpan.org/release/Crypt-Random-Seed/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module providing strong randomness for seeding

Crypt::Random::Seed provides a simple mechanism to get strong randomness. The
main purpose of this module is to provide a simple way to generate a seed for
a PRNG such as Math::Random::ISAAC, for use in cryptographic key generation,
or as the seed for an upstream module such as Bytes::Random::Secure. Flags
for requiring non-blocking sources are allowed, as well as a very simple
method for plugging in a source.


-- 
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/20130224170354.ga11...@jadzia.comodo.priv.at



Bug#701576: ITP: libbytes-random-secure-perl -- Perl extension to generate cryptographically-secure random bytes

2013-02-24 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libbytes-random-secure-perl
  Version : 0.25
  Upstream Author : David Oswald 
* URL : https://metacpan.org/release/Bytes-Random-Secure/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension to generate cryptographically-secure random 
bytes

Bytes::Random::Secure provides two interfaces for obtaining crypt-quality
random bytes. The simple interface is built around plain functions. For
greater control over the Random Number Generator's seeding, there is an
Object Oriented interface that provides much more flexibility.

The "functions" interface provides five functions that can be used any time
you need a string (or MIME Base64 representation, or hex-digits
representation, or Quoted Printable representation) of a specific number of
random bytes. There are equivalent methods available via the OO interface.

Bytes::Random::Secure can be a drop-in replacement for Bytes::Random, with
the primary enhancement of using a much higher quality random number
generator to create the random data. The random_bytes function emulates the
user interface of Bytes::Random's function by the same name. But with
Bytes::Random::Secure the random number generator comes from
Math::Random::ISAAC, and is suitable for cryptographic purposes. The harder
problem to solve is how to seed the generator. This module uses
Crypt::Random::Seed to generate the initial seeds for Math::Random::ISAAC.


-- 
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/20130224172012.ga19...@jadzia.comodo.priv.at



Re: Linux Future

2013-02-24 Thread Toni Mueller

Hi,

On Wed, Jan 23, 2013 at 05:12:59AM +0600, Andrey Rahmatullin wrote:
> On Tue, Jan 22, 2013 at 12:06:16PM +0100, Pau Garcia i Quiles wrote:
> > This blogpost is months old but it makes some interesting reflections:
> > http://www.pappp.net/?p=969
> https://plus.google.com/u/0/115547683951727699051/posts/74r518xVUNH

LOL!

Actually, I find this reply to the PAPPP post largely invalid because LP
does not address the fact that these pipes and sockets are no longer the
official interface for random third-party tools to talk to, but only
used as internal communication mechanisms, using likely ever-changing
and much less than standard D-Bus documented protocols.

Talking to those sockets/pipes is much akin programming with
"Undocumented Windows" in your hand, then get the blame if something
breaks because you didn't use the one officially blessed API. IOW, it's
inherently unreliable, and a doomed approach.

Oh, and I think it *does* matter whether something is Unix or not. There
are even bodies to evolve the Unix spec, if needs be (arguably yes in
some areas, but not in all). If you don't agree, consider the viability
of ReactOS, which is (afaik) free software, too, or the way the
traditional Unices evolved.


Kind regards,
--Toni++


-- 
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/20130224180059.ga5...@spruce.wiehl.oeko.net



Bug#701585: general: Can't select other languages

2013-02-24 Thread Carlos Manso
Package: general
Severity: important
Tags: l10n

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Trying to select another language of format in gnome-setting
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
Select another format of the English language (Ireland in this case).


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20130224192355.9891.55412.reportbug@k54c



Re: NDEBUG when building packages?

2013-02-24 Thread Daniel Pocock
On 23/02/13 17:41, Hendrik Sattler wrote:
> Am Samstag, 23. Februar 2013, 16:39:22 schrieb Lisandro Damián Nicanor Pérez 
> Meyer:
>> On Sat 23 Feb 2013 12:33:58 Lisandro Damián Nicanor Pérez Meyer escribió:
>>> On Sat 23 Feb 2013 12:18:30 Lisandro Damián Nicanor Pérez Meyer escribió:
 On Sat 23 Feb 2013 07:09:39 Vincent Cheng escribió:
 [snip]

> We should also suggest that packages use
> -DCMAKE_BUILD_TYPE=RelWithDebInfo instead (-g -O2). In fact, I think
> that this would be a sensible default for packages using debhelper's
> cmake integration. Sounds like another wishlist bug for debhelper...

 IIRC, the cmake integration already does that. Not checked though.
>>>
>>> It doesn't. Will ask Modestas to see if there is a reaosn for it.
>>
>> Pino pointed me out that RelWithDebInfo is CMake's default. So if
>> CMakeLists.txt doesn't override it, it's there.
> 
> That's news for everyone using CMake. A simple CMake test shows:
> [100%] Building C object CMakeFiles/test.dir/test.c.o
> /usr/bin/gcc-o CMakeFiles/test.dir/test.c.o   -c /home/hendrik/tmp/cmake 
> test/test.c
> 
> So RelWithDebInfo is _NOT_ the default setting. The default setting on Linux 
> is
> an empty CMAKE_BUILD_TYPE variable.
> However, combined with automatically evaluated CPPFLAGS/CFLAGS/CXXFLAGS/...,
> the result may be the same.
> 
> Also testing in Lintian for the -DCMAKE_BUILD_TYPE=RELEASE is plain wrong, as
> it may be configured using other -D settings. Not using -DNDEBUG for CFLAGS is
> new to me, though.
> 

To put it in context, reSIProcate <= 1.7 offered these different
compilation styles:

  --with-compile-type="..."
What compile profile will you use? (Now "debug")
Valid values are: [debug, nodebug, opt, gopt, prof, small]

Choosing one of (nodebug, opt, ...) would automatically add NDEBUG to
CPPFLAGS, so people using all those previous versions in production
never got hit by an assert().

As of v1.8.0, there is autotools configure, and that doesn't mess with
NDEBUG unless you explicitly add it to CPPFLAGS.  When I implemented
this, I made a very lightweight configure.ac, I didn't try to replicate
all of the legacy behavior of the earlier build script.  So people are
starting to experience some assert()s that they never noticed before.

In the end, upstream is able to diagnose and fix them - but it provides
a useful case study.  There are more than a few autotools based packages
that do explicitly set NDEBUG from within configure or Makefile, it
might be interesting to rebuild the whole archive with some kind of cpp
wrapper that detects such flags that lintian might have missed - are
there any other useful things we could test with such an exercise?

> ===
> DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> DEB_HOST_MULTIARCH  ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> 
> CFLAGS = 
> ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
> CFLAGS_RELEASE = -O0 -g -DNDEBUG $(CFLAGS)
> CFLAGS_DEBUG   = -O0 -g $(CFLAGS)
> else
> CFLAGS_RELEASE = -O2 -g -DNDEBUG $(CFLAGS)
> CFLAGS_DEBUG   = -O2 -g $(CFLAGS)
> endif
> 
> BUILD_TYPE = Release
> ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
> BUILD_TYPE = Debug
> endif
> 
> BUILD_FLAGS = -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \
>   -DCMAKE_C_FLAGS_RELEASE="$(CFLAGS_RELEASE)" 
> -DCMAKE_C_FLAGS_DEBUG="$(CFLAGS_DEBUG)" \
>   -DCMAKE_SKIP_RPATH=ON
> 
> ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
> BUILD_FLAGS += -DCMAKE_SYSTEM_NAME=$(shell dpkg-architecture 
> -qDEB_BUILD_ARCH_OS) \
>-DCMAKE_SYSTEM_PROCESSOR=$(shell dpkg-architecture 
> -qDEB_BUILD_ARCH_CPU) \
>-DCMAKE_C_COMPILER=$(DEB_BUILD_GNU_TYPE)-gcc
> endif
> 
> BUILD_FLAGS += -DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH)
> ===
> 
> HS
> 
> 


-- 
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/512a6cd3.8030...@pocock.com.au



Re: NDEBUG when building packages?

2013-02-24 Thread Florian Weimer
* Ian Jackson:

> Mathieu Malaterre writes ("Re: NDEBUG when building packages?"):
>> On Tue, Feb 19, 2013 at 5:30 PM, Ian Jackson
>>  wrote:
>> > Daniel Pocock writes ("NDEBUG when building packages?"):
>> >> I notice some upstreams hack NDEBUG into their Makefile, while others
>> >> leave it at the discretion of the user
>> >>
>> >> Is there any distribution policy for this?  Should I be adding something
>> >> into debian/rules to set -DNDEBUG when I prepare a package for release?
>> >
>> > -DNDEBUG is (normally) EBW.
>> 
>> http://en.wikipedia.org/wiki/EBW ?
>
> Evil, Bad and Wrong.

So it's not "everbody wins"?  Oh.

> Certainly -DNDEBUG should never be used unless upstream explicitly say
> that it's intended to be supported, and usually not even then.

I've seen some cases where -DNDEBUG pampers over crashers due to
invalid asserts.  On the other hand, there is a lot of code out there
which performs actions with side effects inside the assert.

Not overriding upstream's default is probably a good idea, but as was
pointed out, this is a bit murky with CMake projects.


-- 
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/871uc5qu6k@mid.deneb.enyo.de



Bug#701585: marked as done (general: Can't select other languages)

2013-02-24 Thread Debian Bug Tracking System
Your message dated Sun, 24 Feb 2013 22:26:27 +0100
with message-id 

and subject line Re: Bug#701585: general: Can't select other languages
has caused the Debian Bug report #701585,
regarding general: Can't select other languages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
701585: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701585
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important
Tags: l10n

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Trying to select another language of format in gnome-setting
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
Select another format of the English language (Ireland in this case).


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hello Carlos,
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***

Debian-Devel is no user support channel for Debian.

Please discuss your questions over the user support channels:
http://www.debian.org/support
http://www.debian.org/MailingLists/

Btw. "dpkg-reconfigure locales" might help, and look for the
localization packages and tasks via APT/aptititude.

Regards
Markus
-- 
Markus Frosch
mar...@lazyfrosch.de
http://www.lazyfrosch.de--- End Message ---