Re: Specifying a C++11 compatible pre-dependency

2013-05-19 Thread Ondřej Surý 
Depend on gcc-4.8 and override CC=cc-4.8 on powerpc in debian/rules.

Ondřej Surý

On 16. 5. 2013, at 5:20, Shachar Shemesh  wrote:

> Hi all,
> 
> I have a package[1] that will not transition to testing due to failed 
> compilation on powerpc. The problem is that the actual package requires a 
> fairly complete C++11 support in order to compile. I have tried to signify 
> this by adding "Build-Depends: gcc (>= 4:4.7)" to the dependencies.
> 
> On PowerPC, despite gcc version 4.7 (and, indeed, 4.8) being available, the 
> "gcc" package is for version 4.6.4. This means that without some platform 
> specific tricks in the package (as I don't have a PowerPC platform, these 
> tricks are hard to know), the package fails dependencies. Even if that were 
> not the case, the package would fail to build, as gcc points to gcc-4.6.4.
> 
> Is there some better way to cause the system to use a C++11 capable compiler?
> 
> Shachar
> 
> P.S.
> I no longer have a PowerPC platform to test with, and qemu-user isn't 
> emulating deep enough for fakeroot-ng to work under (and is extremely buggy 
> for PowerPC emulation anyways). As such, the best I can tell at the moment is 
> that under ppc, when specifying gcc-4.8 compiler, the code compiles.
> 
> 1 - http://packages.qa.debian.org/f/fakeroot-ng.html

Re: jessie release goals

2013-05-19 Thread Jean-Christophe Dubacq 
Le 16/05/2013 08:43, Vincent Lefevre a écrit :
> On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote:
>> No. Your server comes unconfigured, you do configure it while the other
>> is still working, and then you stop the service on the first, finish
>> syncing the mailboxes, switch the MX record, and then you can go to
>> rest.
> 
> This is not possible, as I have only one server (which is sufficient
> for a personal server).
> 
If this is a first configuration, then the mail was not working before
anyway. So you are not losing thousands of emails.

It this is not, then you are already configured, and debconf will not
touch your files.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Bug#708858: Installation: Screen and keyboard freeze (but not mouse) right after login on post-install Debian

2013-05-19 Thread Gobiel 
Package: general
Severity: critical

Dear Maintainer,

I installed Debian on a i5 750 (so no integrated graphics), GTX 590, Intel SSD 
system. The installation runned fine. However, after booting with GRUB in 
"normal mode", the system freezes after log in (or before if I run the mouse 
over the log in boxes, over GNOME classic etc.), i.e. stops doing anything.
While I can still move my mouse's cursor around on the screen without beeing 
able to interact with anything, the keyboard does not do anything. I have USB 
mouse and keyboard, and VGA screen. There is no sound coming out.

Thinking this was a graphical problem, I ran some research on how to install 
nvidia drivers and tried some command lines : it couldn't find the packages, 
neither the "deb" command. When trying to continue looking at Xorg config, the 
directory wasn't found (i.e. can't "cd" in it) though it was displayed with 
"dir" command.
It was really confusing, and my problem still isn't solved. I have tried 
installing Debian with no-inst, live cd, DVD and expert DVD with KDE 
installations, with the same outcome. Ubuntu's live cd does not even load, 
however.
Windows 7 x64 runs fine on the same SSD drive. My system is not overclocked and 
all BIOS settings were brought back to default without effect.

I would have expected Debian to boot right out of the box, as it did in Live 
CD, but well :'(. I am not good at all with Linux distributions as it is my 
first encounter with those, but I allowed myself to put "critical".

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

-- Added by me: (surely hardware related problem ?)
Motherboard: P7P55D
CPU: i5 750 (socket 1156)
SSD: Intel 'something' 180GB
GPU: Gigabyte GTX 590
Sound card: Asus Xonar D2


-- 
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/20130519085700.2978.46054.reportbug@debian

Re: GFDL in main

2013-05-19 Thread Bastien ROUCARIES 
I do am doing an update on this list and fill bug:

This work is based on the new lintian check, then manual checking.

These packages include documentation licensed under GFDL with Invariant
Sections or Cover Texts:

autoconf2.64
binutils
chromium-browser
dico
docbook-defguide
ecl
eclipse-linuxtools

I plan ASAP to update the list from f to z.

Bastien ROUCARIES


-- 
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/CAE2SPAauxojefeb341bk9VCUjNmMhF=XaRRA0QjYRddj33h=m...@mail.gmail.com

Re: GFDL in main

2013-05-19 Thread Neil Williams 
On Sun, 19 May 2013 12:36:33 +0200
Bastien ROUCARIES  wrote:

> These packages include documentation licensed under GFDL with Invariant
> Sections or Cover Texts:
> 
> autoconf2.64
> binutils
> chromium-browser
> dico
> docbook-defguide
> ecl
> eclipse-linuxtools
> 
> I plan ASAP to update the list from f to z.

When you do, please run the list through dd-list and attach the output -
it is much more useful to see that breakdown rather than a plain list of
package names.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpZuLl_l6cmg.pgp
Description: PGP signature

update-rc.d: Removal of start and stop actions

2013-05-19 Thread Roger Leigh 
Hi,

With the release of wheezy, all systems should be using dependency-
based booting.  This makes the provision of static sequence ordering
pointless, but the update-rc.d interface still allows sequence
numbers to be passed for its start, stop and defaults actions.  They
just get ignored when using insserv, but they still need providing
unless you are using defaults with no options (which is recommended).

I'm planning on merging these two patches:
http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=3ed24526866d93e28ae3a501b131d5efe002f11a
http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=48daa9d5c8e28f8669e5b85cd369605c8254232c

These do the following:
- remove all support for non-dependency-based boot; in practice, this
  code hasn't been used for a couple of stable releases, since we always
  used the insserv code.
- remove support for start and stop; the options still exist, but they
  just invoke the "defaults" action.  This was already the case with
  insserv, but it's now explicit.
- the update-rc.d(8) manpage is updated to remove all the legacy
  documentation and examples.  This should make it clear what's
  currently supported, and it greatly simplifies the interface.

None of this should affect anyone since in practice there will be no
noticable difference other than the addition of a warning if the start
or stop actions are used.  I'm just bringing it up in case this will
cause anyone problems--in which case shout now before it's changed!

Following this change, I'd like to have debhelper and lintian warn
if the obsolete options are used, then we can start to migrate the
remaining uses of the old options to just use "defaults" in their
maintainer scripts.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130519154702.ge31...@codelibre.net

Re: Debian development and release: always releasable (essay)

2013-05-19 Thread Ondřej Surý 
On Sun, May 12, 2013 at 1:46 PM, Thomas Goirand  wrote:
> On 05/12/2013 02:03 AM, Antonio Terceiro wrote:
>> You can't assume that just because something works today, it will work
>> forever.
>
> True, though it's been at least 2 release cycle (maybe 3?) that this
> set of packages were maintained quite well. I don't remember
> seeing complains or bad bugs. Do you?

Part of the problem is that some of those important packages don't
have enough manpower.

As an example: There's a RFH bug filled on PHP for a long time, some
people came, but in the end I had to poke Ubuntu PHP maintainer
several times to help me write php5{en,dis}mod, which I could
integrate with PHP. (To see the situation, you can look at ohloh.net:
https://www.ohloh.net/p/pkg-php/contributors/summary)

This (in the end) leads to inevitable situations where I do upload
packages with bugs sometimes, or I just don't have enough time to fix
bugs in time and other (sometimes more virtual than real) team members
are also in slumber.

So apart from the more hands on some packages with high priority, it
would really help me to have some automated tests which would be run
before uploading to testing.

One thing which immediatelly comes to the mind is the install & upgrade test.

1. install every built package
2. try upgrade from stable for every built package
3. try upgrade from testing for every built package
4. try upgrade from unstable for every built package

Optionally:
5. do some testing with all r-deps (treeish?)

I am not sure if we need to do that for all packages in the archive,
but I am writing this from the perspective of maintainer/only active
team member of PHP5 (php5 5.3 -> 5.4 transition), Berkeley DB
(db4.7+db4.8 -> db5.1 transition), Cyrus SASL (cyrus-sasl2), Cyrus
IMAPd (cyrus-imapd-2.2 -> cyrus-imapd-2.4 transition with some crazy
database backends change). And I already have pu for three of four of
them (not very proud of that).

And rails 2.3+3.2, but thanks to Antonio Terceiro (and rest of
pkg-ruby-extra), I don't feel that alone there.

Ondrej
--
Ondřej Surý 


--
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/caljhhg_d5e+2qopnput1hjvq7urjd7zmswlrtnn0cjmln_t...@mail.gmail.com

Re: [Popcon-developers] encrypted popcon submissions

2013-05-19 Thread Peter Palfrader 
On Thu, 16 May 2013, Bill Allombert wrote:

> On Sat, May 11, 2013 at 11:43:25AM +0200, Bill Allombert wrote:
> > > Why do you think this is too much for popov to handle? 
> > 
> > I did some benchmark. Currently popov CPU has about 20% of a real CPU.
> > Currently processing the popcon data takes between 6h30 and 8h30.
> > At this rate decrypting the report would take an additional 7h.
> 
> Sorry my benchmarks were completly wrong. Actually the bottleneck is the speed
> of the filesystem, especially for writing. Unfortunately popcon.debian.org
> has to process a lot of data. The database holds 10.5Gb and it receives about
> 1.4GB of submissions each days.

> Maybe I could try to schedule popcon cron job at a different time.

Our storage at ubc is pretty slow, probably overloaded.  We could
conceivably move the service to bytemark.  The HW is nice and shiny, and
for now not overloaded.

Let us know should that become necessary.

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
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/20130519171718.gf24...@anguilla.noreply.org

Re: GFDL in main

2013-05-19 Thread Russ Allbery 
Bastien ROUCARIES  writes:

> These packages include documentation licensed under GFDL with Invariant
> Sections or Cover Texts:

> autoconf2.64

The documentation has subsequently been relicensed upstream to remove the
invariant sections requirement.  I'm not sure what our stance is on that,
given that the contents of the documentation in this release are
essentially identical to the documentation at the point at which it was
relicensed.

It is, at the least, exceedingly unlikely that anyone would ever enforce
those license terms, given that they've been changed.

On the other hand, it looks like this package exists almost solely for
GCC.  The only package that Build-Depends or Depends on it other than the
GCC package set is kyototycoon.  So the documentation probably isn't
particularly important.  (It would be lovely if GCC would switch to a
current Autoconf so that we could just get rid of this package entirely,
but I suspect that's an upstream problem.)

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87ip2eal6k@windlord.stanford.edu

Re: update-rc.d: Removal of start and stop actions

2013-05-19 Thread Wouter Verhelst 
On 19-05-13 17:47, Roger Leigh wrote:
> Hi,
> 
> With the release of wheezy, all systems should be using dependency-
> based booting.  This makes the provision of static sequence ordering
> pointless, but the update-rc.d interface still allows sequence
> numbers to be passed for its start, stop and defaults actions.  They
> just get ignored when using insserv, but they still need providing
> unless you are using defaults with no options (which is recommended).
> 
> I'm planning on merging these two patches:
> http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=3ed24526866d93e28ae3a501b131d5efe002f11a
> http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=48daa9d5c8e28f8669e5b85cd369605c8254232c
> 
> These do the following:
> - remove all support for non-dependency-based boot; in practice, this
>   code hasn't been used for a couple of stable releases, since we always
>   used the insserv code.
> - remove support for start and stop; the options still exist, but they
>   just invoke the "defaults" action.  This was already the case with
>   insserv, but it's now explicit.
> - the update-rc.d(8) manpage is updated to remove all the legacy
>   documentation and examples.  This should make it clear what's
>   currently supported, and it greatly simplifies the interface.
> 
> None of this should affect anyone since in practice there will be no
> noticable difference other than the addition of a warning if the start
> or stop actions are used.  I'm just bringing it up in case this will
> cause anyone problems--in which case shout now before it's changed!

How does this relate to file-rc?

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51993067.4030...@debian.org

Re: update-rc.d: Removal of start and stop actions

2013-05-19 Thread Roger Leigh 
On Sun, May 19, 2013 at 10:04:55PM +0200, Wouter Verhelst wrote:
> On 19-05-13 17:47, Roger Leigh wrote:
> > Hi,
> > 
> > With the release of wheezy, all systems should be using dependency-
> > based booting.  This makes the provision of static sequence ordering
> > pointless, but the update-rc.d interface still allows sequence
> > numbers to be passed for its start, stop and defaults actions.  They
> > just get ignored when using insserv, but they still need providing
> > unless you are using defaults with no options (which is recommended).
> > 
> > I'm planning on merging these two patches:
> > http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=3ed24526866d93e28ae3a501b131d5efe002f11a
> > http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=48daa9d5c8e28f8669e5b85cd369605c8254232c
> > 
> > These do the following:
> > - remove all support for non-dependency-based boot; in practice, this
> >   code hasn't been used for a couple of stable releases, since we always
> >   used the insserv code.
> > - remove support for start and stop; the options still exist, but they
> >   just invoke the "defaults" action.  This was already the case with
> >   insserv, but it's now explicit.
> > - the update-rc.d(8) manpage is updated to remove all the legacy
> >   documentation and examples.  This should make it clear what's
> >   currently supported, and it greatly simplifies the interface.
> > 
> > None of this should affect anyone since in practice there will be no
> > noticable difference other than the addition of a warning if the start
> > or stop actions are used.  I'm just bringing it up in case this will
> > cause anyone problems--in which case shout now before it's changed!
> 
> How does this relate to file-rc?

file-rc now uses insserv, so it's unaffected.  insserv support was
added to file-rc for wheezy in order that the static ordering stuff
could be removed for jessie.

However, the utility of file-rc in a dependency-boot-enabled world
is questionable.  While the configuration file can be hand edited,
in practice you really want to only use the update-rc.d interface to
so so (since the runlevel sequence ordering is dynamic).  Apart from
that, it works just fine.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130519210508.gg31...@codelibre.net

Re: GFDL in main

2013-05-19 Thread Bastien ROUCARIES 
On Sun, May 19, 2013 at 12:36 PM, Bastien ROUCARIES
 wrote:
> I do am doing an update on this list and fill bug:
>
> This work is based on the new lintian check, then manual checking.
>
> These packages include documentation licensed under GFDL with Invariant
> Sections or Cover Texts:
>
autoconf2.64
binutils
chromium-browser
dico
docbook-defguide
ecl
eclipse-linuxtools
freefoam
gcj-4.8 (patch remove license not sure about this).
gengetopt
gnade
gprbuild
grub
horae
ikarus
imview-doc (borderline)
jwhois
libmatheval
manpages-fr-extra
manpages-ja
mathgl
mh-e
muse-el
# no bug send
ntfsdoc
numdiff
orgmode
polyorb
procps
ruby-gsl
smbc
source-highlight
tla
xemacs21-packages
sisu-markup-samples

Full list:

Alessio Treglia 
   gengetopt

Arthur Loiret 
   autoconf2.64 (U)

Barak A. Pearlmutter 
   ikarus

Carlo Segre 
   horae

Christoph Egger 
   ecl (U)

Colin Watson 
   grub (U)

Craig Small 
   procps

D Haley 
   mathgl (U)

Daigo Moriwaki 
   ruby-gsl

Daniel Jacobowitz 
   binutils (U)

Daniel Leidert (dale) 
   docbook-defguide

David Martínez Moreno 
   ntfsdoc

David Prévot 
   manpages-fr-extra (U)

Debian Chromium Maintainers 
   chromium-browser

Debian Common Lisp Team 
   ecl

Debian GCC Maintainers 
   autoconf2.64
   gcj-4.8

Debian Java Maintainers 
   eclipse-linuxtools

Debian QA Group 
   tla

Debian Ruby Extras Maintainers

   ruby-gsl (U)

Debian Science Maintainers 
   freefoam
   imview-doc
   libmatheval
   mathgl

Deepak Tripathi 
   ruby-gsl (U)

Dimitrios Eftaxiopoulos 
   mathgl (U)

Felix Zielcke 
   grub (U)

Gerber van der Graaf 
   freefoam (U)

Giuseppe Iuculano 
   chromium-browser (U)

GRUB Maintainers 
   grub

Jakub Adam 
   eclipse-linuxtools (U)

James Troup 
   binutils (U)

Julian Taylor 
   libmatheval (U)

Julien Danjou 
   muse-el

Keita Maehara 
   manpages-ja

Ludovic Brenta 
   gprbuild
   polyorb (U)

Matthias Klose 
   autoconf2.64 (U)
   binutils
   gcj-4.8 (U)

Michael Gilbert 
   chromium-browser (U)

Michael Wild 
   freefoam (U)

Nicolas FRANCOIS (Nekral) 
   manpages-fr-extra

Noèl Köthe 
   smbc

OHURA Makoto 
   xemacs21-packages

Paolo Greppi 
   numdiff

Paul Dwerryhouse 
   jwhois

Peter Eisentraut 
   source-highlight

Peter S Galbraith 
   mh-e

Peter Van Eynde 
   ecl (U)

Ralph Amissah 
   sisu-markup-samples (U)

Robert Millan 
   grub (U)

Sebastien Delafond 
   org-mode

Simon Paillard 
   manpages-fr-extra (U)

SiSU Project 
   sisu-markup-samples

Stephen Leake 
   gnade

Teemu Ikonen 
   imview-doc (U)

Xavier Grave 
   polyorb

Yaroslav Halchenko 
   numdiff (U)

أحمد المحمودي (Ahmed El-Mahmoudy) 
   dico






False positive to fix in lintian:
oidentd
png-definitive-guide















> I plan ASAP to update the list from f to z.
>
> Bastien ROUCARIES


--
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/cae2spaavgq2deomjm+umukxtgvdsfevquygokuyu6pumbh6...@mail.gmail.com

Re: GFDL in main

2013-05-19 Thread David Prévot 
Hi,

Le 19/05/2013 17:32, Bastien ROUCARIES a écrit :
> On Sun, May 19, 2013 at 12:36 PM, Bastien ROUCARIES
>  wrote:
>> I do am doing an update on this list and fill bug:

Isn’t the point of mailing to debian-devel to gather more opinion
*before* filling those bugt, or did I miss something obvious?

http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#submit-many-bugs

What is the point of submitting such bug now that Lintian in
experimental is already aware of such issue, and that you are already
working on refining this test?

It’s commonly good practice to (B)CC the actual maintainers too with
such “in advance” notification, but since you already filed the bugs,
well, we can probably sleep on it too.

> manpages-fr-extra
> manpages-ja

Those two are duplicates of

> procps

and the first one was wrongly submitted against another non-related
pacckage, I hope the quality of other bugs already reported is not that low…

Regards

David




signature.asc
Description: OpenPGP digital signature

Re: GFDL in main

2013-05-19 Thread Jakub Wilk 

* David Prévot , 2013-05-19, 18:03:
It’s commonly good practice to (B)CC the actual maintainers too with 
such “in advance” notification,


Indeed. You should get a PGP-signed permission from the maintainers (or 
from tech-ctte) before filing any bug with severity >= minor.


--
Jakub Wilk


--
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/20130519222937.ga9...@jwilk.net

Bug#708977: ITP: node-mysql -- MySQL client implementation for Node.js

2013-05-19 Thread Mike Gabriel 
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-mysql
  Version : 0.9.6
  Upstream Author : Felix Geisendörfer 
* URL : https://github.com/felixge/node-mysql
* License : Expat
  Programming Lang: Javascript
  Description : MySQL client implementation for Node.js

 Implementation of the MySQL protocol for Node.js.
 .
 This MySQL module provides non-blocking I/O with MySQL databases. It is written
 in pure Javascript and there is no dependency on external C libraries such as
 libmysql.


-- 
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/20130519223100.25023.63284.report...@minobo.das-netzwerkteam.de

Bug#708984: ITP: bignumber.js -- Arbitrary-precision decimal and non-decimal arithmetic

2013-05-19 Thread Mike Gabriel 
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: bignumber.js
  Version : 1.0.1
  Upstream Author : Michael Mclaughlin 
* URL : https://github.com/MikeMcl/bignumber.js
* License : Expat
  Programming Lang: Javascript
  Description : Arbitrary-precision decimal and non-decimal arithmetic

 Features:
 .
- Faster, smaller, and perhaps easier to use than Javascript versions of
  Java's BigDecimal
- 5 KB minified and gzipped
- Simple API but full-featured
- Works with numbers with or without fraction digits in bases from 2 to 36
  inclusive
- Replicates the toExponential, toFixed, toPrecision and toString methods of
  Javascript's Number type
- Includes a toFraction and a squareRoot method
- Stores values in an accessible decimal floating point format
- No dependencies
- Comprehensive documentation and test set
 .
 If an even smaller and simpler library is required see big.js. It's half the
 size but only works with decimal numbers and only has half the methods. It
 neither allows NaN or Infinity, or have the configuration options of this
 library.


-- 
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/20130519232939.3209.95157.report...@minobo.das-netzwerkteam.de

Re: Debian development and release: always releasable (essay)

2013-05-19 Thread Paul Wise 
On Mon, May 20, 2013 at 12:39 AM, Ondřej Surý wrote:

> So apart from the more hands on some packages with high priority, it
> would really help me to have some automated tests which would be run
> before uploading to testing.
>
> One thing which immediatelly comes to the mind is the install & upgrade test.
>
> 1. install every built package
> 2. try upgrade from stable for every built package
> 3. try upgrade from testing for every built package
> 4. try upgrade from unstable for every built package

Perhaps you missed the existence of piuparts.d.o?

http://piuparts.debian.org/

Failures of installation in sid are advertised on the PTS, we are
hoping to extend this to the other tests soon (#696094).

> Optionally:
> 5. do some testing with all r-deps (treeish?)

We don't yet have any systems running autopkgtest, but Ubuntu does so
you could look at their instance. In the meantime check out DEP-8:

http://dep.debian.net/deps/dep8/

Other tests may be suitable for the Debian Jenkins instance:

http://jenkins.debian.net/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/caktje6efj0gdcf3uuzai4uquhq6scowfxrbndda9ekmzrsy...@mail.gmail.com

Re: WebID as passwordless authentication for debian web services

2013-05-19 Thread Daniel Kahn Gillmor 
On 05/18/2013 12:08 PM, Olivier Berger wrote:

> We do verify such trust chains every day for db.debian.org AFAIU (and of
> course for uploads)... so provided a GPG public key is in our keyrings,
> it can be used to "certify" a WebID document, by verifying that it has
> been signed by the correct GPG key, right ?
>
> So, if I'm not trying to think too far of potential abuses, in pratical
> terms, my understanding is that we may use WebID + TLS for Debian,
> provided that we only trust FOAF/WebID documents signed with GPG by
> Debian participants which would have been registered in a DB of ours as
> allowing the use of a (remote) WebID, such registration being made with
> the same GPG key's signature (for instance using the mail gateway of
> db.debian.org).
> 
> Then such WebID could be trusted by Debian to provide meta-data about
> the Debian project member, and could be used to authenticate to Debian
> servers in a password-less way, using their associated TLS cert.

You've described several steps of cryptographic check that could be done
here.  At least one of the critical steps seems to rely on OpenPGP data
signatures (as opposed to OpenPGP identity certifications), if i'm
understanding your proposal correctly.  Other steps also rely on OpenPGP
identity certifications (in contrast to OpenPGP data signatures).

It's not clear to me how i might revoke an OpenPGP data signature (i.e.
a signature over a document) or what a data signature with an expiration
date would mean; but OpenPGP expiration and revocation semantics are
well-understood and already implemented when looking at OpenPGP identity
certifications.

If the only thing that the cryptographic signature is used for is the
assertion of identity information coupled with a claim of public key
material, then just using a standard OpenPGP identity certification
seems like the simplest thing -- you already need to be able to rely on
such a claim in the first place for potential signing-capable subkeys
(and their subkey-binding certifications).

I understand how debian's web services might make use of identity
certification this way; I haven't yet heard an explanation for what
advantages debian would get as an organization for any of the
linked-data sort of material, and one isn't springing to mind for me
(though i might just be insufficiently imaginative).  I share the
hesitance that both Russ and Jonas have expressed about encouraging
public participation in the publication of rich social graphs, so i tend
to lean toward the idea of just publishing identity certifications (if
that's all debian needs) and leaving out the other features until it
becomes clear that we have a real use case for them.

--dkg



signature.asc
Description: OpenPGP digital signature

Automated piuparts when entering the archive (Was: Debian development and release: always releasable (essay))

2013-05-19 Thread Ondřej Surý 
On Mon, May 20, 2013 at 3:15 AM, Paul Wise  wrote:
> On Mon, May 20, 2013 at 12:39 AM, Ondřej Surý wrote:
>
>> So apart from the more hands on some packages with high priority, it
>> would really help me to have some automated tests which would be run
>> before uploading to testing.
>>
>> One thing which immediatelly comes to the mind is the install & upgrade test.
>>
>> 1. install every built package
>> 2. try upgrade from stable for every built package
>> 3. try upgrade from testing for every built package
>> 4. try upgrade from unstable for every built package
>
> Perhaps you missed the existence of piuparts.d.o?
>
> http://piuparts.debian.org/
>
> Failures of installation in sid are advertised on the PTS, we are
> hoping to extend this to the other tests soon (#696094).

Nope, I know about piuparts, but:

1. some packages and some transitions are more complicated.  Bundle
db4.7->db5.3 transition with cyrus-imapd-2.2->cyrus-imapd-2.4 and I am
quite sure that "installation in sid" is not enough.

2. I would like to see these tests to be run BEFORE the package enters
the archive, and failures would prevent the package to enter.

>> Optionally:
>> 5. do some testing with all r-deps (treeish?)
>
> We don't yet have any systems running autopkgtest, but Ubuntu does so
> you could look at their instance. In the meantime check out DEP-8:
>
> http://dep.debian.net/deps/dep8/

Thanks, I will check it, but from quick glance the tests must be
written by hand, which combined with my constant lack of time is a
no-go (not complaining, just stating the fact). Anyway it might be a
good material for new volunteers *grin*.

> Other tests may be suitable for the Debian Jenkins instance:
>
> http://jenkins.debian.net/

I am thinking about running instance of Debian Jenkins myself, but
again I would have to even a fully automated
"all-possible-non-conflicting-combinations-of-packages-installation-and-upgrades-from-stable-testing-and-sid"
testing automaton would be a great help to start.

Even finishing this page:
http://wiki.debian.org/piuparts#Howto_setup_a_piuparts_test-instance_for_development
would help

Ondrej
--
Ondřej Surý 


--
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/caljhhg8kndjvfezjd_z2ttcv+6mdioubzwy4c42bgzbmkng...@mail.gmail.com