Happy birthday!

[surma]

Hey,
I just wanted to wish you happy birthday. :)
I've been using
debian since 1996, I started
to code then and debian was the best
platform
to write C language.
Anyway, happy birthday!
-Surma

Happy birthday!

[Eric KOM]

Hello!
Happy birthday at Debian Project!
I've been using Debian since 2002.
It was not easy to obtain the CD, even download the ISO.
I really enjoyed  the way this OS was developed.
At this time, It was not easy to use Linux in my country (Cameroon).
Debian is very fun, easier and the more complete OS in the world!
Happy birthday!

-- 
Yours truly,
Eric KOM
110 LAWN STREET ROSETTENVILLE
2190
JOHANNESBURG
SOUTH AFRICA

Phone: +27 (0) 788 791 334
Fax: +27 (0) 865 563 009
E-mail: eric...@namekom.co.za
Websites: www.erickom.co.za | www.namekom.co.za/erickom |  www.namekom.co.za


-- 
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/b379dfc6ebe2778901ea0b64af53aef1.squir...@panel.netheberge.com

Re: libexplain: need access to debian alpha machine

[Bastien ROUCARIES]

On Tue, Aug 17, 2010 at 5:46 AM, Paul Wise  wrote:
> On Mon, Aug 16, 2010 at 6:05 PM, Peter Miller  
> wrote:
>
>> I'm trying to get my libexplain project [1] to build on Debian alpha.
>> I don't actually have access to an alpha machine, so my feedback loop is
>> via the Debian build farm [2]... one fix per release.
>>
>> This isn't completely satisfactory.  Can anyone suggest a dev machine I
>> can ssh to, and do the edit-build-test loop more efficiently?
>
> There is one alpha porterbox available:
>
> http://db.debian.org/machines.cgi?host=albeniz
>
> It is listed as public rather than developer only so as a non-DD you
> would probably be able to get access. Please contact the Debian
> sysadmins about it.

BTW for new debian port could we ask to have a qemu port functionnal ?
HPPA and alpha are not emulated and it is a real pain to debug this
kind of stuff, particularly if you are often offline like me.

Bastien


--
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/aanlkti=m9ag01c5eyb_zga4+eyr81boxsq1o1e2wi...@mail.gmail.com

Bug#593330: ITP: rapid-spring -- content download tool for spring RTS

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 


* Package name: rapid-spring
  Version : 0.3.2
  Upstream Author : Tobi Vollebregt 
* URL : http://pypi.python.org/pypi/rapid-spring/
* License : GPLv2+
  Programming Lang: Python
  Description : content download tool for spring RTS

Rapid-spring is a set of tools (command line and GUI) to download game contents
(maps, mods, …) for the spring rts engine. Rapid manages the artifacts in a
repository in the user's home directory.

The commandline tool is mostly meant for power users as simply installing a
package can also be done the GUI way. The GUI currently only allows installing
single packages.

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Bug#593333: ITP: python-bitarray -- module for efficient handling of boolean arrays

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 


* Package name: python-bitarray
  Version : 0.3.5
  Upstream Author : Ilan Schnell 
* URL : http://pypi.python.org/pypi/bitarray/
* License : Python Software Foundation License
  Programming Lang: Python, C
  Description : module for efficient boolean array handling

This module provides an object type which efficiently represents an array of
booleans. Bitarrays are sequence types and behave very much like usual lists.
Eight bits are represented by one byte in contiguous block of memory. The user
can select between two representations; little-endian and big-endian.

Most of the functionality is implemented in C. Methods for accessing the
machine representation are provided. This can be useful when bit level access
to binary files is required, such as portable bitmap image files (.pbm). Also,
when dealing with compressed data which uses variable bit length encoding, you
may find this module useful.


I intend to package this module because it is needed as dependency for
rapid-spring (ITP: #593330).

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Bug#593339: RFP: freeorion -- FreeOrion is a free, open source, turn-based space empire and galactic conquest computer game

[Roman V. Nikolaev]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: freeorion
Version: 0.3.15
Upstream Author: FreeOrion Team
URL: http://www.freeorion.org
URL: http://sourceforge.net/projects/freeorion/files/FreeOrion/
License: GPL 2
Description: FreeOrion is a free, open source, turn-based space
empire and galactic conquest computer game
FreeOrion is a free, open source, turn-based space empire and galactic
conquest (4X) computer game being designed and built by the FreeOrion
project. FreeOrion is inspired by the tradition of the Master of Orion
games, but is not a clone or remake of that series or any other game.

SVN:
svn co http://freeorion.svn.sourceforge.net/svnroot/freeorion/trunk
freeorion
Comments:
http://www.freeorion.org/forum/viewtopic.php?f=9&t=1792
License:
http://www.freeorion.org/index.php/FreeOrionWiki:Copyrights
(Code - GPL2, Art - CC)

-- 

 Roman V. Nikolaev

mail:rsha...@rambler.ru
icq: 198-364-657
jabber:  rsha...@jabber.org
site:http://www.rshadow.ru



signature.asc
Description: OpenPGP digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Ian Jackson]

Russ Allbery writes ("Re: Non-recompilable binaries in source and binary 
packages (Adobe Flash strikes again)"):
>Ian Jackson  writes:
>>Well, some maintainers have been rebuilding source packages to remove
>>things like RFCs and non-free-GFDL documentation.  Perhaps not
>>everyone has.
> 
> RFCs are definitely non-free because they're unmodifiable.  They can't
> even be in contrib.  [...]

My point stands: it is a waste of everyone's time to repackage
upstream source to remove insufficiently free stuff.

This applies whether the item is non-modifiable, or non-rebuildable,
or whatever.  Obviously it has to be redistributable or we're not
_allowed_ to distribute it, but removing incidental non-free stuff
from source packages is a collossal waste of effort.

Doing so does not advance freedom, because practically no-one is going
to rely more on these files due to us not removing them from our
tarballs, and no upstreams are going to be persuaded to remove them
because of our zealous stance.

It just uses up time which we could spend doing something useful.

Ian.


-- 
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/19562.27602.910912.514...@chiark.greenend.org.uk

Bug#593341: ITP: twittering-mode -- a Twitter client for Emacs

[Takaya Yamashita]

Package: wnpp
Owner: Takaya Yamashita 
Severity: wishlist

* Package name: twittering-mode
  Version : 1.0.0
  Upstream Author : Yuto Hayamizu
* URL or Web page : http://twmode.sf.net/
* License : GPL2
  Description : A Twitter client for Emacs

---
Best Regards,

Takaya Yamashita
yamash...@takaya.biz
tak...@debian.or.jp



-- 
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/20100817.201758.298819466.tak...@debian.or.jp

Re: libexplain: need access to debian alpha machine

[Didier 'OdyX' Raboud]

Bastien ROUCARIES wrote:

> On Tue, Aug 17, 2010 at 5:46 AM, Paul Wise  wrote:
>> On Mon, Aug 16, 2010 at 6:05 PM, Peter Miller 
>> wrote:
>>
>>> I'm trying to get my libexplain project [1] to build on Debian alpha.
>>> I don't actually have access to an alpha machine, so my feedback loop is
>>> via the Debian build farm [2]... one fix per release.
>>>
>>> This isn't completely satisfactory.  Can anyone suggest a dev machine I
>>> can ssh to, and do the edit-build-test loop more efficiently?
>>
>> There is one alpha porterbox available:
>>
>> http://db.debian.org/machines.cgi?host=albeniz
>>
>> It is listed as public rather than developer only so as a non-DD you
>> would probably be able to get access. Please contact the Debian
>> sysadmins about it.
> 
> BTW for new debian port could we ask to have a qemu port functionnal ?
> HPPA and alpha are not emulated and it is a real pain to debug this
> kind of stuff, particularly if you are often offline like me.
> 
> Bastien

That would IMHO be a rather hard requirement for small benefit, as (that's 
one reason, there are others) qemu can hide issues: e.g. I had an armel 
segfault during a build that was not reproducible in a qemu instance, only 
on a real machine.

Having qemu support can be very useful, but it's far from being the holy 
grail for porting to exotic architectures. IMHO…

OdyX


-- 
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/i4dsr8$jr...@dough.gmane.org

Re: libexplain: need access to debian alpha machine

[Asheesh Laroia]

On Tue, 17 Aug 2010, Paul Wise wrote:


On Mon, Aug 16, 2010 at 6:05 PM, Peter Miller  wrote:


I'm trying to get my libexplain project [1] to build on Debian alpha.
I don't actually have access to an alpha machine, so my feedback loop is
via the Debian build farm [2]... one fix per release.

This isn't completely satisfactory.  Can anyone suggest a dev machine I
can ssh to, and do the edit-build-test loop more efficiently?


There is one alpha porterbox available:

http://db.debian.org/machines.cgi?host=albeniz

It is listed as public rather than developer only so as a non-DD you
would probably be able to get access. Please contact the Debian
sysadmins about it.


One more thing you could try: Around this time last release, I found the 
#gentoo-alpha community quite helpful (on irc.freenode.net).


-- Asheesh.

--
Tomorrow, this will be part of the unchangeable past but fortunately,
it can still be changed today.

Re: libcairo2 in squeeze & subpixel rendering

[Stanislav Maslovski]

On Mon, Aug 16, 2010 at 12:06:48PM +0200, Josselin Mouette wrote:
> Le lundi 09 août 2010 à 23:40 +0400, Stanislav Maslovski a écrit :
> > Thus I repeat: the subpixel rendering of fonts in current squeeze is
> > suboptimal, because instead of providing flexibility and full control
> > it virtually limits the choice of fonts by roughly two families, one
> > of which is non-free.
> 
> And the other one being the default.
> 
> I’ll let you come back with accurate figures of the number of users who
> change the default fonts.

Well, many users of non-latin alphabets do. I do not have an accurate
figure, however. Anyone interested should speak up (there was a
discussion of this in debian-russian, for example). Actually, whatever
figure it could be, my point you quoted above remains valid.

I'm currently travelling; I will be back home next week, then I will
look into porting the patch.

-- 
Stanislav


-- 
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/20100817134107.ga4...@kaiba.homelan

Re: Is Ryan Niebur MIA?

[Xavier Oswald]

On 08:13 Tue 17 Aug , Yves-Alexis Perez wrote:
> Hey,
> 
> did anybody have news from Ryan recently? Some time ago we discussed
> midori new upstream release (debian has 0.2.4, 0.2.7 just came out), but
> I heard no news since few months. I pinged him on irc, by mail and on
> the BTS, but nothing. Seems the last activity was like a month ago, and
> I don't know about a [VAC].
> 
> Do we know if he's ok?
> 
> On a side note, I'd very much like to update midori, but doing a NMU for
> a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
> really prefer he we had news and if he's coming back soon :)

Hi,

Some times ago I sponsored him uploads of midori. I told him that Im interested
in helping maintaining midori and he said that he is active and will take care
of it if I well remember. Im sad to hear this.

What do you suggest ?

Greetings,
-- 
Xavier Oswald 
GNU/Linux Debian Developer - http://www.debian.org/
GPG key IDs: 0x88BBB51E, 0x464B8DE3


signature.asc
Description: Digital signature

Re: Is Ryan Niebur MIA?

[Yves-Alexis Perez]

On 17/08/2010 15:51, Xavier Oswald wrote:
> Some times ago I sponsored him uploads of midori. I told him that Im 
> interested
> in helping maintaining midori and he said that he is active and will take care
> of it if I well remember. Im sad to hear this.

I asked him multiple time if he needed help, but apparently he didn't.
The 0.2.4 upload has needed some pings, but in the end it was
successful. For 0.2.5+, not so much (Ryan had concerns about some bugs
preventing him to upload, but there wasn't any recent news on the
subject on the BTS)
> 
> What do you suggest ?

If we don't manage to get some news from Ryan, I'm not sure. Midori
upstream is (kind of) part of Xfce project, so it could be maintained
there, but Ryan already uses git (pkg-xfce is on svn), and to be honest
I'm not that sure I'm quite prepared to add another waf-based project.

But yes, in the end, moving the project to collab maint and adding some
uploaders might be a sensible thing to do.

Cheers,
-- 
Yves-Alexis


-- 
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/4c6a97ea.8000...@debian.org

Re: Is Ryan Niebur MIA?

[Ryan Niebur]

On Tue, Aug 17, 2010 at 08:13:54AM +0200, Yves-Alexis Perez wrote:
> 
> On a side note, I'd very much like to update midori, but doing a NMU for
> a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
> really prefer he we had news and if he's coming back soon :)
> 

Alright, Please do go ahead with an NMU. Thanks in advance!

Cheers,
Ryan

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Is Ryan Niebur MIA?

[Yves-Alexis Perez]

On mar., 2010-08-17 at 11:46 -0700, Ryan Niebur wrote:
> On Tue, Aug 17, 2010 at 08:13:54AM +0200, Yves-Alexis Perez wrote:
> > 
> > On a side note, I'd very much like to update midori, but doing a NMU for
> > a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
> > really prefer he we had news and if he's coming back soon :)
> > 
> 
> Alright, Please do go ahead with an NMU. Thanks in advance! 

Ok, will do. Glad to see you're still around. Any idea about what's next
(are you back and will you have time to take care, or should we proceed
with some other plan?)

Cheers,
-- 
Yves-Alexis


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

Re: why are there /bin and /usr/bin...

[Sven Mueller]

Am 10.08.2010 17:54, schrieb Russ Allbery:
> Simon McVittie  writes:
> 
>> It might be worth having a Lintian check for the situation you describe,
>> since missing libraries will generally prevent the executable from
>> starting up at all, whereas missing bits of /usr/share or /var might not
>> be so important.
> 
> Unfortunately, there isn't any way to check this in Lintian since Lintian
> has no idea whether a given library will be found in /lib or in /usr/lib.
> It's one of those things that needs to be done in a cross-archive check
> that has access to data about multiple packages at once.

I might be wrong here, but if lintian finds the library a package
depends on installed on the system where lintian is run, it could at
least catch some of these errors. Alternatively, if apt-file is
installed, or a Contents. is available, it could use the
information from there.
Still, this would require implementation by someone knowing lintian
well. Also, I admit that a cross-archive check would be more efficient.

regards,
Sven


-- 
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/4c6ada42.50...@incase.de

Re: why are there /bin and /usr/bin...

[Russ Allbery]

Sven Mueller  writes:
> Am 10.08.2010 17:54, schrieb Russ Allbery:

>> Unfortunately, there isn't any way to check this in Lintian since
>> Lintian has no idea whether a given library will be found in /lib or in
>> /usr/lib.  It's one of those things that needs to be done in a
>> cross-archive check that has access to data about multiple packages at
>> once.

> I might be wrong here, but if lintian finds the library a package
> depends on installed on the system where lintian is run, it could at
> least catch some of these errors. Alternatively, if apt-file is
> installed, or a Contents. is available, it could use the
> information from there.

> Still, this would require implementation by someone knowing lintian
> well. Also, I admit that a cross-archive check would be more efficient.

We also intentionally don't do things in Lintian that vary by what
packages you have installed, since one of the goals of Lintian is
reproducible tags, and we're worried about the frustration and confusion
that could happen if different people running the same version of Lintian
on the same package get different results.

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

Re: Is Ryan Niebur MIA?

[Xavier Oswald]

On 11:46 Tue 17 Aug , Ryan Niebur wrote:
> On Tue, Aug 17, 2010 at 08:13:54AM +0200, Yves-Alexis Perez wrote:
> > 
> > On a side note, I'd very much like to update midori, but doing a NMU for
> > a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
> > really prefer he we had news and if he's coming back soon :)
> > 
> 
> Alright, Please do go ahead with an NMU. Thanks in advance!

Will you time to take care of it in the future? Maybe we could maintain it
together, you, Corsac, and me. Feel free to tell us your plan.

Greetings,
-- 
Xavier Oswald 
GNU/Linux Debian Developer - http://www.debian.org/
GPG key IDs: 0x88BBB51E, 0x464B8DE3


signature.asc
Description: Digital signature

Atlas proposal

[Sylvestre Ledru]

Hello,

As I presented during the DebConf 10, I would like to change the way we
are packaging Atlas.

Quick remember, Atlas is a linear algebra library implementing the BLAS
API/ABI. It is widely used in the scientific computing world but also by
some spreadsheets (openoffice).
This is an highly optimized library. The optimisation is done at build
time against the hardware it is building on.
The current package provides an easy way to build locally the optimized
packages.

In unstable, the following already optimized packages are:
libatlas3gf-base, libatlas3gf-core2sse3, libatlas3gf-sse2,
libatlas3gf-sse3, libatlas3gf-sse

However, due to the nature of the optimization system (at build time),
the causes three major issues:
* all packages in the archive are optimized for the machine it has built
one
* Atlas could have much better performances on the device it builds on.
* Since the number of threads is statically launchable is computed at
build time, some algorithms on a single core machine could have dramatic
degradations if packages have been generated on a multicore machine.

After some discussions at the DebConf, here is a proposal on what should
be done:
* drop all optimized packages from the archive
* only provide libatlas3gf-base & libatlas-base-dev without any
extension and limited to one thread.
* Update the description of the package with these information.
* During the installation of the package, through debconf, inform the
user that the current package is under optimized and better performances
would be achieved by recompiling locally the package (which takes time
anyway)
* Through the DebConf process, propose to the user to build and install
the optimized package

My main questions are:
* does it sound reasonable ? 
* is it possible to use debconf this way ?

My target is still Squeeze. The current Atlas packages in testing are
not good enough.
I will try to implement my proposal this week. 

Sylvestre



-- 
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/1282079348.13818.3228.ca...@zlarin

Re: Atlas proposal

[Roger Leigh]

On Tue, Aug 17, 2010 at 11:09:08PM +0200, Sylvestre Ledru wrote:
> After some discussions at the DebConf, here is a proposal on what should
> be done:
> * drop all optimized packages from the archive
> * only provide libatlas3gf-base & libatlas-base-dev without any
> extension and limited to one thread.
> * Update the description of the package with these information.
> * During the installation of the package, through debconf, inform the
> user that the current package is under optimized and better performances
> would be achieved by recompiling locally the package (which takes time
> anyway)
> * Through the DebConf process, propose to the user to build and install
> the optimized package
> 
> My main questions are:
> * does it sound reasonable ? 

No.  Requiring the user to hand-build an optimised version for their
system is unacceptable.  Why can't this be fixed the correct way:
by building all optimised variants for a given architecture and
selecting the appropriate variant at runtime based upon the system's
capabilities e.g. from CPUID on i386/amd64?  I'm sure I saw this
question asked at least once on -release, and I don't recall seeing
it being addressed.

This is done by many other packages, from the kernel to video players
and games so is technically feasible.  It means a single version will
run on all systems and make use of each system to the best of its
capabilities.

Disabling threading is also suspect: how can the optimal number of
threads possibly be determined at build time?  This should also be
configurable or at least auto-detectable at runtime.

In short, Atlas' approach to optimisation by detecting everything at
build time is wrong.  Rather than working around this limitation by
totally crippling the library to work on a least-common-denominator
system by removing all optimisations and threading, it should be
actually fixed, probably best if done in collaboration with upstream.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Atlas proposal

[Samuel Thibault]

Roger Leigh, le Tue 17 Aug 2010 22:45:50 +0100, a écrit :
> Why can't this be fixed the correct way:
> by building all optimised variants for a given architecture and
> selecting the appropriate variant at runtime based upon the system's
> capabilities e.g. from CPUID on i386/amd64?

Because atlas doesn't optimise only for the instruction set, but also
the number of available cores, the size of the caches, etc. etc.  Ask
anybody who has done serious benchmarks with atlas, he will tell you
that providing an "optimized" binary is hopeless.

> Disabling threading is also suspect: how can the optimal number of
> threads possibly be determined at build time?

Because it changes how Atlas will statically schedule the computation
kernels.

> In short, Atlas' approach to optimisation by detecting everything at
> build time is wrong.

It's not "wrong", it's HPC.  And HPC people will happily rebuild the
package to get an optimized version.

> it should be actually fixed, probably best if done in collaboration
> with upstream.

Upstream will not go the dynamic way.

Samuel


-- 
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/20100817215538.gc4...@const.famille.thibault.fr

Re: Atlas proposal

[Sylvestre Ledru]

Le mardi 17 août 2010 à 22:45 +0100, Roger Leigh a écrit :
> On Tue, Aug 17, 2010 at 11:09:08PM +0200, Sylvestre Ledru wrote:
> > After some discussions at the DebConf, here is a proposal on what should
> > be done:
> > * drop all optimized packages from the archive
> > * only provide libatlas3gf-base & libatlas-base-dev without any
> > extension and limited to one thread.
> > * Update the description of the package with these information.
> > * During the installation of the package, through debconf, inform the
> > user that the current package is under optimized and better performances
> > would be achieved by recompiling locally the package (which takes time
> > anyway)
> > * Through the DebConf process, propose to the user to build and install
> > the optimized package
> > 
> > My main questions are:
> > * does it sound reasonable ? 
[...]

> 
> Disabling threading is also suspect: how can the optimal number of
> threads possibly be determined at build time?  This should also be
> configurable or at least auto-detectable at runtime.
C/C from the FAQ:
http://math-atlas.sourceforge.net/faq.html#tnum
"Can I vary the number of threads ATLAS uses dynamically?
No. The maximum number of threads to use is determined at compile time.
ATLAS will never use more than this, but may use less if the problem
sizes are too small to get speedup from the additional parallelism."

> In short, Atlas' approach to optimisation by detecting everything at
> build time is wrong.  Rather than working around this limitation by
> totally crippling the library to work on a least-common-denominator
> system by removing all optimisations and threading, it should be
> actually fixed, probably best if done in collaboration with upstream.
OK, I forgot to add something.

I know upstream is doing it "wrong" from our distro point of view.
However, I am not upstream, I don't plan to patch atlas to manage this
and I don't think upstream is interested in it. It is not the approach
of upstream and I don't think the current build system will allow the
introduction of such features easily.

For example, software like Scilab (under Windows) and Matlab are
shipping pre-optimized packages of Atlas.

Sylvestre



-- 
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/1282082172.13818.3241.ca...@zlarin

Re: Atlas proposal

[Don Armstrong]

On Tue, 17 Aug 2010, Samuel Thibault wrote:
> Roger Leigh, le Tue 17 Aug 2010 22:45:50 +0100, a écrit :
> > Why can't this be fixed the correct way:
> > by building all optimised variants for a given architecture and
> > selecting the appropriate variant at runtime based upon the system's
> > capabilities e.g. from CPUID on i386/amd64?
> 
> Because atlas doesn't optimise only for the instruction set, but
> also the number of available cores, the size of the caches, etc.
> etc.

All of these are things that can be detected at run time and
appropriate libraries dlopened or codepaths diverged, etc. Whether
upstream can be convinced of the wisdom of this doesn't change that
this is the right design from a distribution perspective, and I
submit, for an upstream perspective as well.

> > Disabling threading is also suspect: how can the optimal number of
> > threads possibly be determined at build time?
> 
> Because it changes how Atlas will statically schedule the
> computation kernels.

This answers the wrong half of the question; there's no way to know at
build time what precisely the machine is going to be doing. It's
possible that you'll have 8 different processes running atlas, and so
atlas shouldn't be using as many threads as if you were only running 1
atlas process.
 
> It's not "wrong", it's HPC. And HPC people will happily rebuild the
> package to get an optimized version.

It's wrong even in HPC unless you tweak the settings of atlas
compilation for your particular problem set as well as your hardware
and software architecture.

But all of that is fine; we can't possibly hope to optimize to get the
last iota of performance out of a system. We should attempt to provide
a reasonable set of optimized binaries (whether that means one or ten
is up to the package maintainer), and then provide an easy method to
build packages which can seemlessly be installed and used in a Debian
system.

This doesn't mean using debconf. After all, anyone who is actually
doing HPC is going to build the packages on one machine, upload them
to their local Debian mirror, and deploy them across their cluster.


Don Armstrong

-- 
Where I sleep at night, is this important compared to what I read
during the day? What do you think defines me? Where I slept or what I
did all day?
 -- Thomas Van Orden of Van Orden v. Perry

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100817221315.gd22...@rzlab.ucr.edu

Re: Atlas proposal

[Josselin Mouette]

Le mardi 17 août 2010 à 23:09 +0200, Sylvestre Ledru a écrit :
> After some discussions at the DebConf, here is a proposal on what should
> be done:
> * drop all optimized packages from the archive
> * only provide libatlas3gf-base & libatlas-base-dev without any
> extension and limited to one thread.
> * Update the description of the package with these information.
> * During the installation of the package, through debconf, inform the
> user that the current package is under optimized and better performances
> would be achieved by recompiling locally the package (which takes time
> anyway)
> * Through the DebConf process, propose to the user to build and install
> the optimized package

This sounds like debconf abuse.

Just ship two packages: libatlas3gf-base and libatlas3gf-auto, with
appropriate Conflicts/Provides just as we have now. And have
libatlas3gf-auto depend on all build-dependencies, ship the source, and
build itself in its postinst. Gentoo-style.

In libatlas3gf-auto you could use debconf for overriding things like the
number of threads or some optimizations, but I wouldn’t use debconf for
selecting the implementation.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


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

Bug#593411: ITP: pd-wiimote -- A puredata external for accessing the wiimote controller

[Roman Haefeli]

Package: wnpp
Severity: wishlist
Owner: Roman Haefeli 


* Package name: pd-wiimote
  Version : 0.3.1
  Upstream Author : Iohannes M. Zmoelnig
* URL : http://puredata.info/community/projects/software/wiimote/
* License : GPLv2
  Programming Lang: C
  Description : A puredata external for accessing the wiimote controller

Adds access to the sensor data from Nintendo's wiimote controller. Also
it provides an interface to control the controller's actuators such as
LED 1-4 and the rumble vibrator. Furthermore, it supports some of the extensions
of the wiimote, such as Nunchuk, Motion Plus, Classic Control.
.
Check the help-patch for more usage information.

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



-- 
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/20100817222638.12078.80200.report...@netpd.org

Re: Atlas proposal

[Ben Hutchings]

On Tue, 2010-08-17 at 23:56 +0200, Sylvestre Ledru wrote:
> Le mardi 17 août 2010 à 22:45 +0100, Roger Leigh a écrit :
[...]
> > Disabling threading is also suspect: how can the optimal number of
> > threads possibly be determined at build time?  This should also be
> > configurable or at least auto-detectable at runtime.
> C/C from the FAQ:
> http://math-atlas.sourceforge.net/faq.html#tnum
> "Can I vary the number of threads ATLAS uses dynamically?
> No. The maximum number of threads to use is determined at compile time.
> ATLAS will never use more than this, but may use less if the problem
> sizes are too small to get speedup from the additional parallelism."

Can we set a large maximum at build time and then reduce it at run-time
based on the number of hardware threads found at run-time?  Or does it
do that already?  Given the phrase 'may use less', it is clear that the
code does support varying the number of threads used at run-time.

> > In short, Atlas' approach to optimisation by detecting everything at
> > build time is wrong.  Rather than working around this limitation by
> > totally crippling the library to work on a least-common-denominator
> > system by removing all optimisations and threading, it should be
> > actually fixed, probably best if done in collaboration with upstream.
> OK, I forgot to add something.
> 
> I know upstream is doing it "wrong" from our distro point of view.
> However, I am not upstream, I don't plan to patch atlas to manage this
> and I don't think upstream is interested in it. It is not the approach
> of upstream and I don't think the current build system will allow the
> introduction of such features easily.
[...]

The dynamic linker does the run-time selection for you.  All you need to
do is to install the optimised libraries in subdirectories that specify
the hardware they require.  Currently the following platform and
capability flag names are recognised for i386:

"i386", "i486", "i586", "i686",
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
"cx8", "apic", "10", "sep", "mtrr", "pge", "mca", "cmov",
"pat", "pse36", "pn", "clflush", "20", "dts", "acpi", "mmx",
"fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe"

Use nested subdirectories to specify multiple flags.  The library in the
most specific directory (i.e. the one which selects the most flags, all
satisfied by the current hardware) will be used.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Atlas proposal

[Samuel Thibault]

Don Armstrong, le Tue 17 Aug 2010 15:13:15 -0700, a écrit :
> On Tue, 17 Aug 2010, Samuel Thibault wrote:
> > Roger Leigh, le Tue 17 Aug 2010 22:45:50 +0100, a écrit :
> > > Why can't this be fixed the correct way:
> > > by building all optimised variants for a given architecture and
> > > selecting the appropriate variant at runtime based upon the system's
> > > capabilities e.g. from CPUID on i386/amd64?
> > 
> > Because atlas doesn't optimise only for the instruction set, but
> > also the number of available cores, the size of the caches, etc.
> > etc.
> 
> All of these are things that can be detected at run time and
> appropriate libraries dlopened or codepaths diverged, etc.

Errr, then you'll need a myriad of libraries/codepaths for all the
combinations of L1/L2/L3 cache sizes, number of processors, speed, etc.
etc.

> > > Disabling threading is also suspect: how can the optimal number of
> > > threads possibly be determined at build time?
> > 
> > Because it changes how Atlas will statically schedule the
> > computation kernels.
> 
> This answers the wrong half of the question; there's no way to know at
> build time what precisely the machine is going to be doing.

In HPC, yes: the machine will just be running atlas.

> > It's not "wrong", it's HPC. And HPC people will happily rebuild the
> > package to get an optimized version.
> 
> It's wrong even in HPC unless you tweak the settings of atlas
> compilation for your particular problem set as well as your hardware
> and software architecture.

Err, what example of tuning?
The hardware architecture is known: the atlas build system is running on
it.

> But all of that is fine; we can't possibly hope to optimize to get the
> last iota of performance out of a system. We should attempt to provide
> a reasonable set of optimized binaries (whether that means one or ten
> is up to the package maintainer),

The problem is that currently the Atlas build system doesn't have any
way to do generic optimization, and not agressive L1/L2/L3 cache size
-related optimizations which will actually make performance quite worse
whenever running on a machine with a smaller L2 for instance.

Samuel


-- 
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/20100817235023.go4...@const.famille.thibault.fr

Re: Atlas proposal

[Samuel Thibault]

Ben Hutchings, le Wed 18 Aug 2010 00:07:58 +0100, a écrit :
> The dynamic linker does the run-time selection for you.  All you need to
> do is to install the optimised libraries in subdirectories that specify
> the hardware they require.  Currently the following platform and
> capability flag names are recognised for i386:

Again, it's not only a matter of processor capability, but also the
precise combination of cache size, etc.

Samuel


-- 
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/20100817235220.gp4...@const.famille.thibault.fr

Re: Atlas proposal

[Don Armstrong]

On Wed, 18 Aug 2010, Samuel Thibault wrote:
> Don Armstrong, le Tue 17 Aug 2010 15:13:15 -0700, a écrit :
> > All of these are things that can be detected at run time and
> > appropriate libraries dlopened or codepaths diverged, etc.
> 
> Errr, then you'll need a myriad of libraries/codepaths for all the
> combinations of L1/L2/L3 cache sizes, number of processors, speed,
> etc. etc.

You've got them already; you either select them during build-time, or
you select them during run-time.
 
> > This answers the wrong half of the question; there's no way to
> > know at build time what precisely the machine is going to be
> > doing.
> 
> In HPC, yes: the machine will just be running atlas.

Unless it's a particularly boring problem, there will be a set of
processes which are using atlas; it's a library, after all, and there
are myraids of different problems which use it to varying degrees.

For example, if I'm using atlas from R, I may be using an R process
for each core using RMPI, each of which is running atlas for only part
of the calculation, so it probably should be using only one core. Or,
I may only be running one R process, and atlas should be using all of
the available cores instead.

> > It's wrong even in HPC unless you tweak the settings of atlas
> > compilation for your particular problem set as well as your
> > hardware and software architecture.
> 
> Err, what example of tuning? The hardware architecture is known: the
> atlas build system is running on it.

Sure, but atlas can't know at build time what the state of the machine
will be when it's running. Optimization isn't just about using all of
the hardware available on a machine maximally by one subset of the
problem; it's about maximizing the throughput of a particular problem,
which may mean that atlas shouldn't use all of the cache, or shouldn't
use as many cores as exist on a particular machine, etc.
 
> > But all of that is fine; we can't possibly hope to optimize to get the
> > last iota of performance out of a system. We should attempt to provide
> > a reasonable set of optimized binaries (whether that means one or ten
> > is up to the package maintainer),
> 
> The problem is that currently the Atlas build system doesn't have
> any way to do generic optimization, and not agressive L1/L2/L3 cache
> size -related optimizations which will actually make performance
> quite worse whenever running on a machine with a smaller L2 for
> instance.

Oh, I've no doubt that there are serious design issues that need to be
addressed by Atlas upstream, and that we may have to live with a
suboptimal solution. We just should make sure that the packages that
we distribute work as well as we can, and provide good documentation
(or an -auto package?) so that people who need/want an optimized build
can make one.


Don Armstrong

-- 
Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100818002405.gp17...@teltox.donarmstrong.com

Re: Atlas proposal

[Samuel Thibault]

Don Armstrong, le Tue 17 Aug 2010 17:24:05 -0700, a écrit :
> On Wed, 18 Aug 2010, Samuel Thibault wrote:
> > Don Armstrong, le Tue 17 Aug 2010 15:13:15 -0700, a écrit :
> > > All of these are things that can be detected at run time and
> > > appropriate libraries dlopened or codepaths diverged, etc.
> > 
> > Errr, then you'll need a myriad of libraries/codepaths for all the
> > combinations of L1/L2/L3 cache sizes, number of processors, speed,
> > etc. etc.
> 
> You've got them already;

Yes. Each machine builds its own combination.

> you either select them during build-time, or
> you select them during run-time.

But to select them during run-time, you need to build and upload _all_
combinations, which as I said is a myriad when you see the parameters
that Atlas takes into account.

> Optimization isn't just about using all of
> the hardware available on a machine maximally by one subset of the
> problem;

Well, talk with upstream, because it's what they consider.

> it's about maximizing the throughput of a particular problem,
> which may mean that atlas shouldn't use all of the cache, or shouldn't
> use as many cores as exist on a particular machine, etc.

That's way harder to do in an optimized way, and that's probably why
Atlas doesn't do it.

> > > But all of that is fine; we can't possibly hope to optimize to get the
> > > last iota of performance out of a system. We should attempt to provide
> > > a reasonable set of optimized binaries (whether that means one or ten
> > > is up to the package maintainer),
> > 
> > The problem is that currently the Atlas build system doesn't have
> > any way to do generic optimization, and not agressive L1/L2/L3 cache
> > size -related optimizations which will actually make performance
> > quite worse whenever running on a machine with a smaller L2 for
> > instance.
> 
> Oh, I've no doubt that there are serious design issues that need to be
> addressed by Atlas upstream, and that we may have to live with a
> suboptimal solution. We just should make sure that the packages that
> we distribute work as well as we can, and provide good documentation
> (or an -auto package?) so that people who need/want an optimized build
> can make one.

I agree on this.  What we still don't agree on is whether you can build
an optimized package at all, since Atlas will optimize it for the
machine where it got built, and the optimizations it does will
potentially make performance worse on another machine...

Samuel


-- 
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/20100818003526.gw4...@const.famille.thibault.fr

Re: Atlas proposal

[Ben Hutchings]

On Wed, 2010-08-18 at 01:52 +0200, Samuel Thibault wrote:
> Ben Hutchings, le Wed 18 Aug 2010 00:07:58 +0100, a écrit :
> > The dynamic linker does the run-time selection for you.  All you need to
> > do is to install the optimised libraries in subdirectories that specify
> > the hardware they require.  Currently the following platform and
> > capability flag names are recognised for i386:
> 
> Again, it's not only a matter of processor capability, but also the
> precise combination of cache size, etc.

So make a reasonable guess at the minimum expected cache sizes, so that
most people running e.g. OOCalc, who will never build a custom package,
still get good performance.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Atlas proposal

[Don Armstrong]

On Wed, 18 Aug 2010, Samuel Thibault wrote:
> Don Armstrong, le Tue 17 Aug 2010 17:24:05 -0700, a écrit :
> > [Optimization is] about maximizing the throughput of a particular
> > problem, which may mean that atlas shouldn't use all of the cache,
> > or shouldn't use as many cores as exist on a particular machine,
> > etc.
> 
> That's way harder to do in an optimized way, and that's probably why
> Atlas doesn't do it.

It's probably close to impossible at build time; you'd certainly be
able to come closer if you optimized on the fly. But this is a very
difficult problem, and atlas may have already hit on the right
combination of automated build optimization vs. automated on-the-fly
optimization vs. expert knowledge optimization.

> I agree on this. What we still don't agree on is whether you can
> build an optimized package at all, since Atlas will optimize it for
> the machine where it got built, and the optimizations it does will
> potentially make performance worse on another machine...

You should be able to select a set of optimizations that Atlas will
apply which are relatively conservative and work across a reasonable
swath of machines, even if this means that you haven't gotten every
last iota out of some of the hardware. Where the balance is between
the number of packages, the number of machines with a particular
hardware architecture, etc. is something that the maintainer can
decide. I think that most people who are doing HPC are going to be
running relatively new hardware, with relatively high-end CPUs, so
erring towards that end is probably reasonable.

In any event, if this means one package plus documentation on how to
build more or an auto package which helps with building, that's fine
by me. So long as we're not doing debconf prompting by default.


Don Armstrong

-- 
"There's no problem so large it can't be solved by killing the user
off, deleting their files, closing their account and reporting their
REAL earnings to the IRS."
 -- The B.O.F.H..

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100818012352.ge22...@rzlab.ucr.edu

Re: Atlas proposal

[Christian PERRIER]

Quoting Sylvestre Ledru (sylves...@debian.org):

> * is it possible to use debconf this way ?


If you end up doing so, I'd insist strongly for a review to happen on
debian-l10n-english. I suspect that the text of debconf templates
might be tricky to write




signature.asc
Description: Digital signature