I wrote:
> you like, checksums) of files more easily. If there were a standard
> file registration scheme for files which were in the .deb's filesystem
> archive, [...]
I meant "weren't"
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@list
sean finney writes ("Re: Atlas proposal [and 1 more messages]"):
> as an admin i'd be very annoyed by that behavior, because there's no way
> for me to know what package the file came from then, or whether it was my
> own accidental actions that led to it (i
On Wed, Aug 25, 2010 at 06:46:18PM +0100, Ian Jackson wrote:
> Goswin von Brederlow writes ("Re: Atlas proposal [and 1 more messages]"):
> > Just dumping the compiled files into /usr/lib/ I find quite unacceptable
> > too.
>
> No, it is absolutely fine and it is wh
Goswin von Brederlow writes ("Re: Atlas proposal [and 1 more messages]"):
> Just dumping the compiled files into /usr/lib/ I find quite unacceptable
> too.
No, it is absolutely fine and it is what atlas-auto should do. It is
a simple matter for its postinst and postrm to deal
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Atlas proposal"):
>> I also have a package "local-archive" that depends on reprepro,
>> generates a local signing key on first install, adds that to the apt-get
>> keyring and adds a file:/// url
On Wed, Aug 25, 2010 at 11:37:44 (CEST), Goswin von Brederlow wrote:
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
This sounds interesting
Goswin von Brederlow writes ("Re: Atlas proposal"):
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
I think t
Le mercredi 25 août 2010 à 11:37 +0200, Goswin von Brederlow a écrit :
> To support building atlas on one system and installing it on many you
> may want to use Depends: libatlas3gf-base | libatlas3gf-auto |
> libatlas3gf-remote, libatlas3gf-base | libatlas3gf-custom.
>
> The -base is the prebuild
Sylvestre Ledru writes:
> For now, the solution I imagine is:
> * build the package libatlas3gf-base just like it is now
> * the libatlas3gf-auto package contains the upstream tarball + the
> content of the debian/ directory
> * libatlas3gf-auto has dependencies on the build dependencies
> * when
Josselin Mouette writes ("Re: Atlas proposal"):
> Le jeudi 19 août 2010 à 22:53 +0200, Sylvestre Ledru a écrit :
> > * it will start the build (fakeroot debian/rules custom)
> > * at the end, it installs the .deb packages and removes the
> > libatlas3gf-auto
>
&g
Le vendredi 20 août 2010 à 12:49 +0100, Ian Jackson a écrit :
> Yes. Although you should probably do the removal in the prerm.
> (General rule: undo in the prerm what you do in the postinst.)
And leave all reverse dependencies broken during the upgrade?
I don’t think you really want that. Just h
Le jeudi 19 août 2010 à 22:53 +0200, Sylvestre Ledru a écrit :
> * it will start the build (fakeroot debian/rules custom)
> * at the end, it installs the .deb packages and removes the
> libatlas3gf-auto
I think it’s a bit too much to ask from dpkg to be able to do that. And
think of upgrades!
The
Julien Cristau writes:
> On Thu, Aug 19, 2010 at 22:53:35 +0200, Sylvestre Ledru wrote:
>> How does it sound ? Is it possible ?
> Running dpkg --install from your maintainer scripts is probably not the
> best plan ever.
Normally packages that do this ship a script in /usr/sbin that does the
act
On Thu, Aug 19, 2010 at 22:53:35 +0200, Sylvestre Ledru wrote:
> How does it sound ? Is it possible ?
>
Running dpkg --install from your maintainer scripts is probably not the
best plan ever.
Cheers,
Julien
signature.asc
Description: Digital signature
and present the existing work so that our
> users have access to, and their pick of, the best trade-offs currently
> available. So:
>
> Josselin Mouette writes ("Re: Atlas proposal"):
> > Just ship two packages: libatlas3gf-base and libatlas3gf-auto, with
> &g
Russ Allbery writes ("Re: Atlas proposal"):
> I recommend instead doing the same thing that all the out-of-tree kernel
> modules that build with module-assistant do: ship the source as a .tar.bz2
> file, unpack it during the build, and then make clean after a successful
> bu
On Wed, Aug 18, 2010 at 01:59:59PM +0200, Sylvestre Ledru wrote:
> I am more concern about advanced users of scientific computing software
> (Scilab, R, Octave...) which are familiar with such tools but not
> familiar enough with the internals.
> They just see these software as a whole and would n
Ian Jackson writes:
> * Source code distributed in the .deb as
> /usr/src/autobuild/libatlas3gf-auto/*
> * README.DO-NOT-EDIT file in the above directory, and all the
> .deb-installed files are mode 600, to try to avoid the user
> editing the source.
I recommend instead doing
f, the best trade-offs currently
> available. So:
>
> Josselin Mouette writes ("Re: Atlas proposal"):
> > Just ship two packages: libatlas3gf-base and libatlas3gf-auto, with
> > appropriate Conflicts/Provides just as we have now. And have
> > libatlas3gf-auto de
Sylvestre Ledru writes:
> Le mercredi 18 août 2010 à 13:22 +0200, Goswin von Brederlow a écrit :
>> Ben Hutchings writes:
>>
>> > 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 :
>> > [...]
>> I think some midd
h are better in all of performance, portability,
convenience, and impact on other users of the system.
Our job is to package up and present the existing work so that our
users have access to, and their pick of, the best trade-offs currently
available. So:
Josselin Mouette writes ("Re: Atla
Le mercredi 18 août 2010 à 12:13 +0100, Simon McVittie a écrit :
> On Tue, 17 Aug 2010 at 23:09:08 +0200, Sylvestre Ledru wrote:
> > 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 spreadsh
Le mardi 17 août 2010 à 22:19 -0400, Christian PERRIER a écrit :
> 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 debcon
Le mercredi 18 août 2010 à 13:22 +0200, Goswin von Brederlow a écrit :
> Ben Hutchings writes:
>
> > 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 :
> > [...]
> I think some middle ground would be good, which I think is
Ben Hutchings writes:
> 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 b
On Tue, 17 Aug 2010 at 23:09:08 +0200, Sylvestre Ledru wrote:
> 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 optimisatio
> 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
>
How does atlas cope
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.
was about to suggest this, this is the only fea
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
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 par
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 requ
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, et
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 a
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
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
> > > selectin
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 aut
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 thre
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
> > capab
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-b
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
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 th
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 op
42 matches
Mail list logo
