Re: running CUDA cards

[Lennart Sorensen]

On Tue, May 31, 2011 at 07:15:03PM +0200, Francesco Pietra wrote:
> Unlike CPU machines, where the computational software is "stable",
> with CUDA support the situation is highly experimental, changes
> rapidly and has requirements of recent OS support. New versions of
> NAMD every few weeks and even night builds. One of the goals is to
> have even energies computed by GPU. That to say that I would have no
> objection to install wheezy unless it is too much an adventure. It
> might well be that a new version of NAMD comes soon with requirements
> of libraries not available in squeeze. Finally, NAMD would be the only
> application installed on this dedicated machine so that if dramatic
> problems occur, there will be little to reinstall. I imagine that
> amd64 RAID1 support will be at least as good as with lenny. In this
> case, perhaps, hardware RAID1 would be better but it is too expensive.
> 
> I plan to change from lenny to squeeze with the CPU workstation.
> Quantum mechanics unlike classical mechanics has no CUDA support yet
> (except with very expensive proprietary software, if it works at all).

Well most of the time testing is quite usable, so wheezy is not a
bad option.  It would give you much newer nvidia drivers and cuda
stuff easily.

RAID1 and such will work exactly the same in all the versions.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110531175016.gg21...@caffeine.csclub.uwaterloo.ca

Re: running CUDA cards

[Francesco Pietra]

On Tue, May 31, 2011 at 5:56 PM, Lennart Sorensen
 wrote:
> On Tue, May 31, 2011 at 05:20:35PM +0200, Francesco Pietra wrote:
>> I have just set up a gaming machine with
>>
>> Gigabyte GA 890FXUD5
>> AMD Phenom II 10775T
>> 2 x GTX470 GPU cards
>> 4 x 4GB RAM
>> 2 x 1 Tb HD for RAID1
>>
>> and need to install amd64 to run molecular dynamics using (free for
>> non-commercial use) NAMD software (released binary below or
>> compilation from source). All that is experimental, with little
>> experience and I have no experience whatsoever with CUDA cards. My
>> question is about the version of amd6a to be best used (lenny or
>> squeeze) and what should be added to the typical server installation
>> according to the requirements:
>
> Lenny will stop having support soon, so absolutely go with squeeze.
> The nvidia-glx package in squeeze supports the GTX470 card.  Lenny does
> not.  So install squeeze.
>
> To install the driver, add 'contrib non-free' to your lines in
> /etc/apt/sources.list then do:
>
> apt-get update
> apt-get install nvidia-kernel-dkms
> apt-get install nvidia-glx nvidia-glx-dev libcuda1-dev libcuda1
>
>> (1) NVIDIA Linux driver version 195.17 or newer (released Linux
>> binaries are built with CUDA 2.3, but can be built with newer versions
>> as well).
>
> squeeze has 195.36.31 so that should work.
>
>> (2) libcudart.so.2 included with the binary (the one copied from the
>> version of CUDA it was built with) must be in a directory in your
>> LD_LIBRARY_PATH before any other libcudart.so libraries. For example:
>>
>>   setenv LD_LIBRARY_PATH ".:$LD_LIBRARY_PATH"
>>   (or LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH"; export LD_LIBRARY_PATH)
>>   ./namd2 +idlepoll 
>>   ./charmrun ++local +p4 ./namd2 +idlepoll 
>
> The libcuda1 package should probably take care of the library I think,
> but maybe not.

Unlike CPU machines, where the computational software is "stable",
with CUDA support the situation is highly experimental, changes
rapidly and has requirements of recent OS support. New versions of
NAMD every few weeks and even night builds. One of the goals is to
have even energies computed by GPU. That to say that I would have no
objection to install wheezy unless it is too much an adventure. It
might well be that a new version of NAMD comes soon with requirements
of libraries not available in squeeze. Finally, NAMD would be the only
application installed on this dedicated machine so that if dramatic
problems occur, there will be little to reinstall. I imagine that
amd64 RAID1 support will be at least as good as with lenny. In this
case, perhaps, hardware RAID1 would be better but it is too expensive.

I plan to change from lenny to squeeze with the CPU workstation.
Quantum mechanics unlike classical mechanics has no CUDA support yet
(except with very expensive proprietary software, if it works at all).

Thanks a lot

francesco pietra




>
> wheezy has a lot more cuda packages available, and much newer drivers too,
> but is of course testing, not stable.


>
>> THE FOLLOWING CAN BE SKIPPED, unless one is specifically interested in
>> the matter: The +idlepoll in the command line is needed to poll the
>> GPU for results rather than sleeping while idle, i.e. NAMD does not
>> use any non-specified GPU card. Each namd2 process can use only one
>> GPU. Therefore you will need to run at least one process for each GPU
>> you want to use. Multiple processes can share a single GPU, usually
>> with an increase in performance. NAMD will automatically distribute
>> processes equally among the GPUs on a node. Specific GPU device IDs
>> can be requested via the +devices argument on the namd2 command line,
>> for example:
>>   ./charmrun ++local +p4 ./namd2 +idlepoll +devices 0,2 
>
> --
> Len Sorensen
>


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinqK3ZtYBWCxSkWL=3hnfe27ce...@mail.gmail.com

Re: running CUDA cards

[Lennart Sorensen]

On Tue, May 31, 2011 at 05:20:35PM +0200, Francesco Pietra wrote:
> I have just set up a gaming machine with
> 
> Gigabyte GA 890FXUD5
> AMD Phenom II 10775T
> 2 x GTX470 GPU cards
> 4 x 4GB RAM
> 2 x 1 Tb HD for RAID1
> 
> and need to install amd64 to run molecular dynamics using (free for
> non-commercial use) NAMD software (released binary below or
> compilation from source). All that is experimental, with little
> experience and I have no experience whatsoever with CUDA cards. My
> question is about the version of amd6a to be best used (lenny or
> squeeze) and what should be added to the typical server installation
> according to the requirements:

Lenny will stop having support soon, so absolutely go with squeeze.
The nvidia-glx package in squeeze supports the GTX470 card.  Lenny does
not.  So install squeeze.

To install the driver, add 'contrib non-free' to your lines in
/etc/apt/sources.list then do:

apt-get update
apt-get install nvidia-kernel-dkms
apt-get install nvidia-glx nvidia-glx-dev libcuda1-dev libcuda1

> (1) NVIDIA Linux driver version 195.17 or newer (released Linux
> binaries are built with CUDA 2.3, but can be built with newer versions
> as well).

squeeze has 195.36.31 so that should work.

> (2) libcudart.so.2 included with the binary (the one copied from the
> version of CUDA it was built with) must be in a directory in your
> LD_LIBRARY_PATH before any other libcudart.so libraries. For example:
> 
>   setenv LD_LIBRARY_PATH ".:$LD_LIBRARY_PATH"
>   (or LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH"; export LD_LIBRARY_PATH)
>   ./namd2 +idlepoll 
>   ./charmrun ++local +p4 ./namd2 +idlepoll 

The libcuda1 package should probably take care of the library I think,
but maybe not.

wheezy has a lot more cuda packages available, and much newer drivers too,
but is of course testing, not stable.

> THE FOLLOWING CAN BE SKIPPED, unless one is specifically interested in
> the matter: The +idlepoll in the command line is needed to poll the
> GPU for results rather than sleeping while idle, i.e. NAMD does not
> use any non-specified GPU card. Each namd2 process can use only one
> GPU. Therefore you will need to run at least one process for each GPU
> you want to use. Multiple processes can share a single GPU, usually
> with an increase in performance. NAMD will automatically distribute
> processes equally among the GPUs on a node. Specific GPU device IDs
> can be requested via the +devices argument on the namd2 command line,
> for example:
>   ./charmrun ++local +p4 ./namd2 +idlepoll +devices 0,2 

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110531155619.ge21...@caffeine.csclub.uwaterloo.ca

Re: Which 64bit debian version for Intel(R) Core Quad Processor Q8300?

[Basile Starynkevitch]

On Sun, 29 May 2011 12:43:36 +0200
Goswin von Brederlow  wrote:

> > The only reservation I'd have about that is if you're going to be using 
> > huge programs written in Scheme.  That's pointer-heavy, and will use 
> > about twoce as much RAM to accomplish the same thing in 64-bit more as 
> > 32-bit mode.  Unless you have more than about 6gig of RAM, whereupon 
> > 64-bit is a win again.

Are you really sure of that 2x increase when going from 32bits to
64bits in RAM usage? My feeling (and old experiment with Ocaml code, or
with the GCC compiler itself - which mostly do symbolic processing,
like every compiler) is that the memory footprint indeed increased, but
more with a 1.5x factor than a 2x factor. Assuming C code, sizeof(int)
is still 4 bytes on both 32 and 64 bits x86, but sizeof(long) and sizeof
(void*) goes from 4 to 8 bytes

And going to 64bits system might sometimes be a win, at least in speed,
because the AMD64 instruction set has 16 registers (but x86 in 32 bits
= ia-32 has only 8). This avoid lots of registers spill to memory. I
believe the usual win in speed is about 5-15% (for the same program
operating on the same input files, when going from 32 bits to 64 bits).

And if you have more than 3Gb of RAM (which is quite common today),
going to a 64 bits system may enable you to process more data, because
you can have a single big process which consumes nearly all your RAM
(if you have 6Gb RAM, you cannot have a 5Gb process in 32 bits, but you
can have it in 64 bits).

So I still suggest installing a 64 bits Debian distribution if you have
a 64 bits x86-64 (or AMD64) processor with at least 4Gb RAM.

BTW, some non free programs (e.g. Adobe flashplayer) may be available
only in 32 bits.

And a 64 bits distribution can run 32 bits programs (you'll need to
install some specific packages to enable that).

Regards
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110529170722.912afb28.bas...@starynkevitch.net

Re: Which 64bit debian version for Intel(R) Core Quad Processor Q8300?

[Goswin von Brederlow]

Hendrik Boom  writes:

> On Fri, May 27, 2011 at 11:39:50PM +0200, Gilles Sadowski wrote:
>> Hi.
>> 
>> > Currently i am running windows 7 64 bit on a machine with Intel®
>> > Core™2 Quad Processor Q8300
>> > (http://ark.intel.com/Product.aspx?id=39107). i would like to install
>> > debian. Is the amd64 bit version ok for this processor [...]
>> 
>> Yes.
>
> The only reservation I'd have about that is if you're going to be using 
> huge programs written in Scheme.  That's pointer-heavy, and will use 
> about twoce as much RAM to accomplish the same thing in 64-bit more as 
> 32-bit mode.  Unless you have more than about 6gig of RAM, whereupon 
> 64-bit is a win again.
>
> But most users don't do that.

Multiarch will fix that because then you just install a 32bit scheme.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipstbxd3.fsf_-_@frosties.localnet

Re: Which 64bit debian version for Intel(R) Core™2 Quad Processor Q8300?

[Hendrik Boom]

On Fri, May 27, 2011 at 11:39:50PM +0200, Gilles Sadowski wrote:
> Hi.
> 
> > Currently i am running windows 7 64 bit on a machine with Intel®
> > Core™2 Quad Processor Q8300
> > (http://ark.intel.com/Product.aspx?id=39107). i would like to install
> > debian. Is the amd64 bit version ok for this processor [...]
> 
> Yes.

The only reservation I'd have about that is if you're going to be using 
huge programs written in Scheme.  That's pointer-heavy, and will use 
about twoce as much RAM to accomplish the same thing in 64-bit more as 
32-bit mode.  Unless you have more than about 6gig of RAM, whereupon 
64-bit is a win again.

But most users don't do that.

-- hendrik
k


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110527225312.gc30...@topoi.pooq.com

Re: Which 64bit debian version for Intel(R) Core™2 Quad Processor Q8300?

[Mentus Sarovar]

Thanks
mentus

On Fri, May 27, 2011 at 11:39 PM, Gilles Sadowski
 wrote:
> Hi.
>
>> Currently i am running windows 7 64 bit on a machine with Intel®
>> Core™2 Quad Processor Q8300
>> (http://ark.intel.com/Product.aspx?id=39107). i would like to install
>> debian. Is the amd64 bit version ok for this processor [...]
>
> Yes.
>
>
> Best regards,
> Gilles
>
>
> --
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/20110527213949.gu10...@dusk.harfang.homelinux.org
>
>


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTikFR4y=r5at2jkcqizunq7jhsu...@mail.gmail.com

Re: Which 64bit debian version for Intel(R) Core™2 Quad Processor Q8300?

[Gilles Sadowski]

Hi.

> Currently i am running windows 7 64 bit on a machine with Intel®
> Core™2 Quad Processor Q8300
> (http://ark.intel.com/Product.aspx?id=39107). i would like to install
> debian. Is the amd64 bit version ok for this processor [...]

Yes.


Best regards,
Gilles


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110527213949.gu10...@dusk.harfang.homelinux.org

Re: debian testing: iceweasel issues

[dagecko]

Thanks for the reply and help.

> 
> Try /var/log/dpkg.log

Only initramfs-tools and libtorque where updated yesterday.
Last time there was an update about dependency for iceweasel was
on may 21, for xulrunner. However I did not encountered the
bug until yesterday evening...

> First, Try with a fresh profile (iceweasel -ProfileManager) and see
> if
> the problem exists. If so, it probably is a bug, if not, it may be an
> extension or theme causing you trouble.

Nothing happend with the new profile (the problem remained).

I tried to move the profile (~/.mozilla/firefox/profiles.ini) to another
name, then the problems disappeared.
Then I checked bugs about iceweasel, and I noticed that other people had
the same issue, which should be corrected in the next update of
iceweasel.

> 
> 
> -- 
> Paul Saunders


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/773697334.3675591306322426132.javamail.r...@zimbra20-e3.priv.proxad.net

Re: debian testing: iceweasel issues

[Darac Marjal]

On Wed, May 25, 2011 at 11:17:03AM +0200, dage...@free.fr wrote:
> 
> Hi,
> 
> after updates from yesterday morning (2 files - sorry don't really 
> remember which ones it was - so if someone could tell me how to
> check I'd be please to look and try to remember), iceweasel has
> big issues:

Try /var/log/dpkg.log

> 
> first, the navigation bar does not work anymore: if I select a web
> site on the navigation bar list, nothing happens. If I fill the
> adress and press Enter key or click on the arrow to load the page,
> nothing happens too. The only way for me to manage is to use a
> search engine (fortunately the home icon works) and use the results
> to navigate.
> 
> Second, all passwords are lost and iceweasel does not want to save
> passwords again (the password list is empty and remains empty).
> 
> If you think it's a bug in debian, may I add this bug ?

First, Try with a fresh profile (iceweasel -ProfileManager) and see if
the problem exists. If so, it probably is a bug, if not, it may be an
extension or theme causing you trouble.


-- 
Paul Saunders


signature.asc
Description: Digital signature

Re: ATI proprietary drivers installation issue on debian testing

[A J Stiles]

On Saturday 21 May 2011, dage...@free.fr wrote:
> Hi,
>
> I updated my debian stable into testing... My bad, since I have
> an ATI graphics card...
> I now can't install their drivers, even if I fall-back with the
> previous driver version and/or previous kernel-version (stable).

This sort of problem is going to persist until enough people write to their 
elected representatives and demand the outlawing of proprietary drivers.

Companies should be obliged to release enough information to enable anybody to  
(employ a competent programmer if necessary to help them)  make proper use of 
products they have purchased, or forbidden to sell products without the 
necessary information.  Which is not a corporate secret, but an integral part 
of the instructions for use of the product.

As long as they are allowed to get away with not releasing this information, 
there is also a serious risk that consumers could be being ripped off without 
knowing about it.

-- 
AJS
delta echo bravo six four at earthshod dot co dot uk


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105231014.15038.de...@earthshod.co.uk

Re: ATI proprietary drivers installation issue on debian testing

[dagecko]

> I suspect that if the BKL is not enabled now, it is not likely to be
> enabled in the future.  The BKL is something that pretty much
> everyone
> would like to go away.  In fact, while I see a configuration option
> for
> 2.6.38, 2.6.39 seems to have no such option, so I will assume that
> nothing is using it still and that it has been removed altogether
> from
> Linux.

OK. Thanks. I understand. What I don't understand is why some developers
don't try to get information on what they are developing with (ie ATI
with linux kernel) since, all of a sudden, latest ATI drivers use that
thing "everyone would like to go away".

> That's the problem with proprietary drivers.  When they break, nobody
> else can fix them.

Exactly. I think then that ATI will change its driver code for the
next releases if they still want to be supported 'proprietary' on linux.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/666973923.2826021306139799472.javamail.r...@zimbra20-e3.priv.proxad.net

Re: ATI proprietary drivers installation issue on debian testing

[brian m. carlson]

On Sun, May 22, 2011 at 11:29:34AM +0200, dage...@free.fr wrote:
> Anyway, my question remains the same. Could we expect future kernel
> releases to enable big lock ?

I suspect that if the BKL is not enabled now, it is not likely to be
enabled in the future.  The BKL is something that pretty much everyone
would like to go away.  In fact, while I see a configuration option for
2.6.38, 2.6.39 seems to have no such option, so I will assume that
nothing is using it still and that it has been removed altogether from
Linux.

> I work in graphics industry, so I often need up-to-date drivers to
> make tests and so on. So it would be nice for me that I could install
> drivers as soon as they are made available on IP manufacturers.

That's the problem with proprietary drivers.  When they break, nobody
else can fix them.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: ATI proprietary drivers installation issue on debian testing

[dagecko]

 
> I am using fglrx 11-4-2 from the Debian repositories without any real
> problems. Sometimes the repainting of the screens is a bit choppy,
> especially during drag and drop or moving, or a window is not
> correctly
> repainted while dragging it over the (dual monitor) desktop.

Hi. Indeed, the ATI proprietary drivers providen by Debian work well.
However this is not the case with the 11-5 drivers (latest) available
on ATI website. And it's not possible to install older drivers too.

Only drivers providen by Debian work. I haven't tested this before
sending the mail because last times I tried to do so (months ago),
I couldn't get to make them work (I had errors when compiling the
module).

Anyway, my question remains the same. Could we expect future kernel
releases to enable big lock ?
I work in graphics industry, so I often need up-to-date drivers to
make tests and so on. So it would be nice for me that I could install
drivers as soon as they are made available on IP manufacturers.

> 
> 
> -- 
> Groeten,
> 
> Joost Kraaijeveld
> Askesis B.V.
> Molukkenstraat 14
> 6524NB Nijmegen
> tel: 024-3888063 / 06-51855277
> fax: 024-3608416
> web: www.askesis.nl


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/793225283.2576731306056574089.javamail.r...@zimbra20-e3.priv.proxad.net

Re: ATI proprietary drivers installation issue on debian testing

[Joost Kraaijeveld]

On Sat, 2011-05-21 at 19:12 +0200, dage...@free.fr wrote:
> Hi,
> 
> I updated my debian stable into testing... My bad, since I have
> an ATI graphics card...
> I now can't install their drivers, even if I fall-back with the
> previous driver version and/or previous kernel-version (stable).
> 
> Anyway. Here is the purpose of this mail. It seems newer ATI
> proprietary drivers expect Big Kernel Lock to be activated in the
> kernel, which is not the case.
> 
> Ati installation log will be given below.
> 
> My question is, how far could I expect Big Kernel Lock to be
> providen in future updates of the kernels ?
> 
> For now, I think I'll do the old-job, recompiling the kernel,
> since I can't find a solution (and don't want to go back to
> debian stable)...

I am using fglrx 11-4-2 from the Debian repositories without any real
problems. Sometimes the repainting of the screens is a bit choppy,
especially during drag and drop or moving, or a window is not correctly
repainted while dragging it over the (dual monitor) desktop.


-- 
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl


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

Re: firmware-realtek (0.29) can't work at amd64

[spp mg]

2011/5/17 Camaleón 
>
> On Mon, 16 May 2011 14:39:47 +0800, spp mg wrote:
>
> > 2011/5/9 Camaleón 
> >
> >> On Mon, 09 May 2011 15:05:12 +0800, spp mg wrote:
> >>
> >> > I have rtl8191su wireless chip,and os is debian amd64 testing.
> >> >
> >> > I can compile source from RealTek in kernel 2.6.26,but the newer
> >> > can't. So I try to use apt install the firmware-realtek (0.29).(I
> >> > believe rtl8192 and rtl8191 use same source.),but it can't work too.
> >> >
> >> > And I try to use the i386 system( kernel 2.6.38, installed
> >> > firmware-realtek (0.29)),it work perfect!
> >> >
> >> > How to solve this problem? thanks a lot .
> >>
> >> I'm not sure if you have already tried with any of the mentioned in
> >> this wiki page:
> >>
> >> http://wiki.debian.org/rtl819x
> >>
> >> It seems the driver has been available since kernel 2.6.32-10 so it
> >> should also be present for 2.6.38-x and upwards :-?
>
> > sorry,I am too late to reply.
>
> (no problem, but don't make use of html formatted messages and better yet
> if you reply at bottom or inline and don't cross-post ;-))

Ok, like this?
>
> > Because I have not the RTL chip at hand.I can't try now.
> >
> > I try to describe detail.
> > I use wicd (RTL8191SU and amd64) connect wireless network.
> >
> > wicd scan function is ok, but when I connect net,it will connect a long
> > time,and display "password error".But I'm sure password is right.(The
> > config can use in kernel 2.6.26.)
>
> Make wicd to be more verbose if possible, there must be an option in the
> program settings you can toggle on.

Oh,I used "wicd-curses".I will try to use "wicd-cli" or find logs.

>
> > On the i386,I just use apt install firmware-realtek (0.29).
>
> And it works fine? Then it can be a bug within the amd64 port package.
>
Yes,it's works fine.
When I go back hometown (less then 1 month), I will use live cd of
i386 and amd64 to test again. Because I just use other computer to
test i386.

If it's bug,how to report?

>  --
> > Other information :
> > When RTL chip work ,r8712u will load. I read the Wheezy section (from
> > the debian wiki page). I just don't do that :
> > cp rtl8192u_linux_2.6.0006.1031.2008/firmware/RTL8192U/*
> > /usr/local/lib/firmware/RTL8192U
> >
> > (And my chip is not 8192.)
>
> Your chipset (rtl8191su) should be supported by "r8712u" driver, or at
> least that's what it says the wiki page.
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.05.16.17.44...@gmail.com
>


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikfr2rtkaxacdqskevpy-ui-eh...@mail.gmail.com

Re: Fwd: workstation for CUDA

[Lennart Sorensen]

On Mon, May 16, 2011 at 07:17:46AM +0200, Francesco Pietra wrote:
> I also forgot a most important aspect of CUDA in the choice of the
> mainboard. Currently, the GPUs carry out only a part - albeit major -
> of the task (non bonded forces), while bonded forces and PME
> long-range forces are left to the CPUs. In practice, a CPU to GPU 2:1
> ratio is still needed. The situation is not likely to change rapidly
> due to enormous task of parallelizing with the myriad of loci on GPUs.
> Perhaps, developers are waiting until GPU-CPU integrated boards are
> available.

GTX 570 cards can be found in single slot versions, which helps a lot
for what you want.  A number of motherboards with 4 PCIe x16 slots can
be found as well.  If ou want a 2:1 ratio of cpu to gpu, then probably
a dual 6 core xeon or even dual 4 core would be good.  A single 8 or 12
core opteron might also be possible to get if anyone makes a board with
four slots for video cards.

EVGA has a board called the SR-2 which takes dual xeon (up to 6 core
each), and has 7 PCIe x16 slots for video cards and such.  Putting four
single slot GTX 570s in that should not be a problem.  It can take at
least 24GB of ram.  There are a few others like it around.

You would need a serious power supply for 4 video cards of course,
but that isn't a big deal.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110516164345.gh21...@caffeine.csclub.uwaterloo.ca

Re: firmware-realtek (0.29) can't work at amd64

[spp mg]

sorry,I am too late to reply.
Because I have not the RTL chip at hand.I can't try now.

I try to describe detail.
I use wicd (RTL8191SU and amd64) connect wireless network.

wicd scan function is ok, but when I connect net,it will connect a long
time,and display "password error".But I'm sure password is right.(The config
can use in kernel 2.6.26.)

On the i386,I just use apt install firmware-realtek (0.29).
--
Other information :
When RTL chip work ,r8712u will load.
I read the Wheezy section (from the debian wiki page).
I just don't do that :
cp rtl8192u_linux_2.6.0006.1031.2008/firmware/RTL8192U/*
/usr/local/lib/firmware/RTL8192U

(And my chip is not 8192.)



2011/5/9 Camaleón 

> On Mon, 09 May 2011 15:05:12 +0800, spp mg wrote:
>
> > I have rtl8191su wireless chip,and os is debian amd64 testing.
> >
> > I can compile source from RealTek in kernel 2.6.26,but the newer can't.
> > So I try to use apt install the firmware-realtek (0.29).(I believe
> > rtl8192 and rtl8191 use same source.),but it can't work too.
> >
> > And I try to use the i386 system( kernel 2.6.38, installed
> > firmware-realtek (0.29)),it work perfect!
> >
> > How to solve this problem? thanks a lot .
>
> I'm not sure if you have already tried with any of the mentioned in this
> wiki page:
>
> http://wiki.debian.org/rtl819x
>
> It seems the driver has been available since kernel 2.6.32-10 so it
> should also be present for 2.6.38-x and upwards :-?
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.05.09.15.23...@gmail.com
>
>

Re: libcholmod

[Robert Isaac]

On Thu, May 5, 2011 at 4:00 PM, brian m. carlson
 wrote:
>
> My comment about multiarch was an extension of the previous paragraph.
> If those extra development files (such as headers) end up in both
> library packages, they may cause a file conflict.
>

I'm still not seeing it.  The headers should be the same between
architectures, unless there are differing versions between the
architectures, like say libc 2.8 in lib32 and libc 2.14 in lib64.

Even that bit of insanity could be solved by placing headers in
renamed directories, which every build system worth using can work
with.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktincp6f9mc-pgutx8dndfg4xqxk...@mail.gmail.com

Re: libcholmod

[dagecko]

> So what happens if you have multiple library versions under Linux From
> 
> Scratch, then?  I'm genuinely curious.
> 
> I still think separate -dev packages make compiling from source
> unnecessarily 
> complicated, and benefit only a minority who already have a clue how
> to deal 
> with the problems that would be caused by including -dev files in the
> main 
> packages.  Even an APT option to always install -dev files would be an
> 
> improvement  (especially if it was on by default for n00b installs).
> 

My interest was not to create a polemic.

I was just wondering if there could have some easy ways to deal with
some packages which names are hidden in other packages, by using some
abstract packages or so. This will definately help in finding package
names. This kind of technique could also be used to name packages 
differently, so that a single package could have several names (and
so that users from other distributions could find more easily the
package they are looking for, since package names could be quite
different from a distro to another one).

Maybe should I post this request to another debian list ?

Thanks.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2102531523.253841304705732828.javamail.r...@zimbra20-e3.priv.proxad.net

Re: libcholmod

[A J Stiles]

On Thursday 05 May 2011, brian m. carlson wrote:
> On Thu, May 05, 2011 at 02:18:33PM -0400, Robert Isaac wrote:
> > > It will also affect multiarch, where those two versions of a library
> > > package may be for separate architectures.
> >
> > You'll have to explain how a library in lib32 could possibly conflict
> > with a library in lib64 as long as ld is doing its job correctly.
>
> My comment about multiarch was an extension of the previous paragraph.
> If those extra development files (such as headers) end up in both
> library packages, they may cause a file conflict.

So what happens if you have multiple library versions under Linux From 
Scratch, then?  I'm genuinely curious.

I still think separate -dev packages make compiling from source unnecessarily 
complicated, and benefit only a minority who already have a clue how to deal 
with the problems that would be caused by including -dev files in the main 
packages.  Even an APT option to always install -dev files would be an 
improvement  (especially if it was on by default for n00b installs).


-- 
AJS
delta echo bravo six four at earthshod dot co dot uk


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105060858.15139.de...@earthshod.co.uk

Re: libcholmod

[brian m. carlson]

On Thu, May 05, 2011 at 02:18:33PM -0400, Robert Isaac wrote:
> > It will also affect multiarch, where those two versions of a library
> > package may be for separate architectures.
> >
> 
> You'll have to explain how a library in lib32 could possibly conflict
> with a library in lib64 as long as ld is doing its job correctly.

My comment about multiarch was an extension of the previous paragraph.
If those extra development files (such as headers) end up in both
library packages, they may cause a file conflict.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: libcholmod

[Robert Isaac]

> It will also affect multiarch, where those two versions of a library
> package may be for separate architectures.
>

You'll have to explain how a library in lib32 could possibly conflict
with a library in lib64 as long as ld is doing its job correctly.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktincy8+oe+j8bijgewkenw43vsc...@mail.gmail.com

Re: libcholmod

[brian m. carlson]

On Tue, May 03, 2011 at 04:12:13PM +0100, A J Stiles wrote:
> Or even better, just put the "-dev" files in the main library package
> already.
> 
> The time when separate -dev packages were a good idea has been and
> gone a long while since; nowadays, they are doing more harm than good.

Putting development files in the main library package will cause file
conflicts when trying to install two different versions of a library.
Berkeley DB is a good example of why this won't work.  cURL is another
(due to the differing crypto libraries).  I'm sure you can come up with
more.

It will also affect multiarch, where those two versions of a library
package may be for separate architectures.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: when i install perl, apt remove my linux-image

[johnw.m...@gmail.com]

Ok, thank you.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


Niko Tyni  說：

On Wed, May 04, 2011 at 09:42:44AM +0800, johnw wrote: > hi, when i use apt-get 
dist-upgrade to upgrade perl/perl-base/perl-modules, > apt say need to remove 
linux-image. > is it perl/apt bug(s) ? Yes, about 400 packages and all the 
packages depending on those are currently uninstallable in unstable before they 
get rebuilt for perl 5.12. This effort is ongoing, see 
http://bugs.debian.org/619117 . Just wait a few days until it's cleared up. -- 
Niko Tyni nt...@debian.org 

Re: libcholmod

[Lennart Sorensen]

On Tue, May 03, 2011 at 04:12:13PM +0100, A J Stiles wrote:
> Or even better, just put the "-dev" files in the main library package already.
> 
> The time when separate -dev packages were a good idea has been and gone a 
> long 
> while since; nowadays, they are doing more harm than good.

Those of us making embedded devices would very much like to disagree.

Also having the ability to install multiple versions of a library, but
only one set of development headers has been a great feature in Debian
for many years.  So again, bad idea.

The -dev packages are not about saving disk space at all.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110503151927.gc21...@caffeine.csclub.uwaterloo.ca

Re: libcholmod

[A J Stiles]

On Tuesday 03 May 2011, dage...@free.fr wrote:
> Thanks, that's it.
>
> How about creating a virtual package to help find the devel library ?

Or even better, just put the "-dev" files in the main library package already.

The time when separate -dev packages were a good idea has been and gone a long 
while since; nowadays, they are doing more harm than good.

-- 
AJS
delta echo bravo six four at earthshod dot co dot uk


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105031612.13853.de...@earthshod.co.uk

Re: libcholmod

[dagecko]

Thanks, that's it.

How about creating a virtual package to help find the devel library ?

- "cb"  a écrit :

> dage...@free.fr wrote:
> > Hi,
> > 
> > I had to install libcholmod for an INRIA program.
> > However, the distribution doesn't provide any devel part of the
> library.
> > 
> 
> Hi,
> 
> As far as I understand, libcholmod is part of the suitesparse
> package.
> While the libraries were splitted in different packages, there seems
> to
> be only one developer package for all suitesparse libraries, which is
> called libsuitesparse-dev.
> 
> Kind regards
> Clemens
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/4dc0116f.1090...@clemens-bergmann.de


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/996028643.2000441304434828731.javamail.r...@zimbra20-e3.priv.proxad.net

Re: libcholmod

[cb]

dage...@free.fr wrote:
> Hi,
> 
> I had to install libcholmod for an INRIA program.
> However, the distribution doesn't provide any devel part of the library.
> 

Hi,

As far as I understand, libcholmod is part of the suitesparse package.
While the libraries were splitted in different packages, there seems to
be only one developer package for all suitesparse libraries, which is
called libsuitesparse-dev.

Kind regards
Clemens


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc0116f.1090...@clemens-bergmann.de

Re: GCC-4.5 as the default for (at least some) architectures

[Matthias Klose]

On 04/26/2011 09:28 PM, Kurt Roeckx wrote:

On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:

On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:

I'll make GCC 4.6 the
default after the release of GCC 4.5.3, expected later this week, at
least on amd64, armel, i386 and powerpc.


If you do the switch, please also add mips and mipsel, that would avoid
you to have to complain in two weeks that these architectures have not
yet been switched.


Is there a reason not to switch the remaining (release) arches
(ia64, kfreebsd-*, sparc, s390)?  Maybe hurd-i386 too?


I don't know, and I will not invest time to check. If you did check, and if you 
are confident to fix issues on these architectures, then please tell here.


At least for other ports this seems to be possible (s390: Bastian Blank, 
kfreebsd-*: Aurelian, Petr).



I assume you want to release with at least 4.6 on all arches as
the default, so I see no point in waiting with switching if
there are no known issues.


I will not work on toolchain issues specific to these architectures for the 
wheezy release, so if nobody steps forward, then at least I will not change the 
default for these architectures.


  Matthias


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db73b0c.4000...@debian.org

Re: GCC-4.5 as the default for (at least some) architectures

[Samuel Thibault]

Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit :
> Is there a reason not to switch the remaining (release) arches
> (ia64, kfreebsd-*, sparc, s390)?  Maybe hurd-i386 too?

There's no real reason to defer hurd-i386, as it's basically like i386,
and the key packages (glibc/hurd/gnumach) already use a fixed version
and can be handled independently.

Samuel


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110426204147.gs4...@const.famille.thibault.fr

Re: GCC-4.5 as the default for (at least some) architectures

[Kurt Roeckx]

On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:
> On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
> > I'll make GCC 4.6 the
> > default after the release of GCC 4.5.3, expected later this week, at
> > least on amd64, armel, i386 and powerpc.
> 
> If you do the switch, please also add mips and mipsel, that would avoid
> you to have to complain in two weeks that these architectures have not
> yet been switched.

Is there a reason not to switch the remaining (release) arches
(ia64, kfreebsd-*, sparc, s390)?  Maybe hurd-i386 too?

I assume you want to release with at least 4.6 on all arches as
the default, so I see no point in waiting with switching if
there are no known issues.


Kurt


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be

Re: GCC-4.5 as the default for (at least some) architectures

[Thorsten Glaser]

Matthias Klose dixit:

> At this point, pretty well after the GCC 4.6.0 release, I would like to avoid
> switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce
> maintenance efforts on the debian-gcc side, even before the multiarch changes

Porters side, too. I’m okay with keeping gcc-4.4 for a while (kernel?)
and switching to gcc-4.6 directly for m68k. I know I’ll probably have
to invest some work into the latter, but considering the kernel problem
is almost solved, chances are good. (I do want to bring out a new base
emulator image first, though, but then…)

bye,
//mirabilos
-- 
13:47⎜ if i were omnipotent, i would divide by zero
all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org

Re: GCC-4.5 as the default for (at least some) architectures

[Aurelien Jarno]

On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
> On 04/17/2011 09:33 PM, Adam D. Barratt wrote:
> >On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:
> >>I'll make gcc-4.5 the default for (at least some) architectures within the 
> >>next
> >>two weeks before more transitions start.  GCC-4.5 is already used as the 
> >>default
> >>compiler for almost any other distribution, so there shouldn't be many 
> >>surprises
> >>on at least the common architectures.  About 50% of the build failures 
> >>exposed
> >>by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
> >>(although optimized for a different processor) and powerpc (some object 
> >>files
> >>linked into shared libs had to be built as pic).
> >
> >It looks like kfreebsd-* also made the switch and there's been a request
> >to switch for mips and mipsel.
> >
> >Looking through the bug list for src:gcc-4.5, none of the open issues
> >seem to be specific to the remaining release architectures which haven't
> >switched yet - i.e. ia64, s390 and sparc.  Are you aware of any issues
> >which would preclude switching the default on those architectures?  Has
> >there been any discussion with the port maintainers regarding switching?
> 
> At this point, pretty well after the GCC 4.6.0 release, I would like
> to avoid switching more architectures to 4.5, but rather get rid of
> GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even
> before the multiarch changes go into unstable. I'll make GCC 4.6 the
> default after the release of GCC 4.5.3, expected later this week, at
> least on amd64, armel, i386 and powerpc.  GCC 4.6 apparently will be

If you do the switch, please also add mips and mipsel, that would avoid
you to have to complain in two weeks that these architectures have not
yet been switched.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110426185104.gb29...@hall.aurel32.net

Re: GCC-4.5 as the default for (at least some) architectures

[Mathieu Malaterre]

On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis
 wrote:
> On 26 April 2011 18:03, Matthias Klose  wrote:
>> I'll make GCC 4.6 the default after the release of
>> GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
>> powerpc.
>
> Could you include armhf in the list as well?

I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package:

https://buildd.debian.org/status/package.php?p=vxl

but since there is no log I cannot confirm this is the same ICE as on i386/armel

thanks,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com

Re: GCC-4.5 as the default for (at least some) architectures

[Matthias Klose]

On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote:

On 26 April 2011 18:03, Matthias Klose  wrote:

I'll make GCC 4.6 the default after the release of
GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
powerpc.


Could you include armhf in the list as well?


yes, forgot about that.  with GCC 4.6, armhf is built again from the 4.6 fsf 
branch, and lets us drop the GCC 4.5 Linaro variant.


  Matthias


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db6eb11.2080...@debian.org

Re: GCC-4.5 as the default for (at least some) architectures

[Konstantinos Margaritis]

On 26 April 2011 18:03, Matthias Klose  wrote:
> I'll make GCC 4.6 the default after the release of
> GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
> powerpc.

Could you include armhf in the list as well?

Thanks

Konstantinos


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTimddKkTaiy1fyka6zMOj0o1YzBS=a...@mail.gmail.com

Re: GCC-4.5 as the default for (at least some) architectures

[Matthias Klose]

On 04/17/2011 09:33 PM, Adam D. Barratt wrote:

On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:

I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start.  GCC-4.5 is already used as the default
compiler for almost any other distribution, so there shouldn't be many surprises
on at least the common architectures.  About 50% of the build failures exposed
by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
(although optimized for a different processor) and powerpc (some object files
linked into shared libs had to be built as pic).


It looks like kfreebsd-* also made the switch and there's been a request
to switch for mips and mipsel.

Looking through the bug list for src:gcc-4.5, none of the open issues
seem to be specific to the remaining release architectures which haven't
switched yet - i.e. ia64, s390 and sparc.  Are you aware of any issues
which would preclude switching the default on those architectures?  Has
there been any discussion with the port maintainers regarding switching?


At this point, pretty well after the GCC 4.6.0 release, I would like to avoid 
switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce 
maintenance efforts on the debian-gcc side, even before the multiarch changes go 
into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, 
expected later this week, at least on amd64, armel, i386 and powerpc.  GCC 4.6 
apparently will be used for the next Fedora and OpenSuse releases, and a test 
rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable 
C++ build failures).  A test rebuild of the unstable archive is still 
outstanding, but these build failures will have to be fixed anyway.   From my 
point of view it's important to expose GCC 4.6 early in the release cycle to fix 
issues like #617628 (which are issues in the packages itself) now.


With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, 
which is not easily detachable from the GCC version change. However this change 
only affects GNUstep, which can be dealt with NMU's, or migration to a new 
GNUstep version.


It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D 
maintainers are already working on GCC 4.6 support.


  Matthias


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db6dea5.5010...@debian.org

Re: no kernel driver for sound card

[Seb]

On Tue, 19 Apr 2011 07:51:06 +1000,
Dean Hamstead  wrote:

> my snd-virtuoso stopped loading at boot recently.  i have concluded
> its something in userspace, as booting to older were-working kernels
> doesnt work either.

I had a hunch that upgrading to the 2.6.38 kernel broke this, so was
going to try downgrading the kernel, but sounds as if that won't help.


> i manually load snd-virtuoso the relogin to X and everything is
> fine. gnome doesnt seem to handle soundcards being added mid session,
> perhaps kde is the same?

Yep, this is exactly what I have to do in KDE as well, now that no ALSA
modules get loaded at boot time with 2.6.38 and this hardware.

Thanks,

-- 
Seb


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y636idrh@kolob.sebmags.homelinux.org

Re: Put order on your sound modules on debian

[Thierry Chatelet]

?


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104191505.15366.tchate...@free.fr

Re: no kernel driver for sound card

[Graham Cobb]

On Monday 18 April 2011 21:37:25 Seb wrote:
> On Mon, 18 Apr 2011 11:20:52 -0500,
> 
> Seb  wrote:
> > Fellow AMD64ers, It has been a couple of months since I've lost sound
> > in my Toshiba Satellite laptop, with Debian unstable on it.  Following
> 
> > some investigation with lspci:
> [...]
> 
> On top of all that, /proc/asound simply simply doesn't exist.  However,
> loading what I think is the appropriate module ('modprobe
> snd-hda-intel), does create it and at least ALSA gets up and running.
> But this breaks something with PulseAudio since I only get a greyed out
> Dummy Output and an internal audio device in the list given in KDE sound
> settings, instead of the usual list of devices.  Some posts point to a
> problem with udev, but no solution...

I had some problem with sound when I first moved to Wheezy.  The problem seemed 
to be that the driver was trying to use the sound port on my graphic card, or 
something.  Once thing which seemed to help was to add the following line in 
/etc/modprobe.d/alsa-base.conf:

options snd-hda-intel probe_mask=1

You can also use other values of probe_mask to cause the driver to try specific 
cards (Google for information).

Your symptoms do not seem the same as mine, however, so this may not be at all 
relevant!

Graham


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104182330.28666.g+deb...@cobb.uk.net

Re: no kernel driver for sound card

[Dean Hamstead]

my snd-virtuoso stopped loading at  boot recently.

i have concluded its something in userspace, as booting to older were-working 
kernels doesnt work either.

i manually load snd-virtuoso the relogin to X and everything is fine. gnome 
doesnt seem to handle soundcards being added mid session, perhaps kde is the 
same?

dean



On 19/04/2011, at 6:37 AM, Seb  wrote:

> On Mon, 18 Apr 2011 11:20:52 -0500,
> Seb  wrote:
> 
>> Fellow AMD64ers, It has been a couple of months since I've lost sound
>> in my Toshiba Satellite laptop, with Debian unstable on it.  Following
>> some investigation with lspci:
> 
> [...]
> 
> On top of all that, /proc/asound simply simply doesn't exist.  However,
> loading what I think is the appropriate module ('modprobe
> snd-hda-intel), does create it and at least ALSA gets up and running.
> But this breaks something with PulseAudio since I only get a greyed out
> Dummy Output and an internal audio device in the list given in KDE sound
> settings, instead of the usual list of devices.  Some posts point to a
> problem with udev, but no solution...
> 
> -- 
> Seb
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/87mxjnjny2@kolob.sebmags.homelinux.org
> 


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/d9e4f30c-e2d7-4d04-bdb1-94945cdb5...@fragfest.com.au

Re: no kernel driver for sound card

[Seb]

On Mon, 18 Apr 2011 11:20:52 -0500,
Seb  wrote:

> Fellow AMD64ers, It has been a couple of months since I've lost sound
> in my Toshiba Satellite laptop, with Debian unstable on it.  Following
> some investigation with lspci:

[...]

On top of all that, /proc/asound simply simply doesn't exist.  However,
loading what I think is the appropriate module ('modprobe
snd-hda-intel), does create it and at least ALSA gets up and running.
But this breaks something with PulseAudio since I only get a greyed out
Dummy Output and an internal audio device in the list given in KDE sound
settings, instead of the usual list of devices.  Some posts point to a
problem with udev, but no solution...

-- 
Seb


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxjnjny2@kolob.sebmags.homelinux.org

Re: GCC-4.5 as the default for (at least some) architectures

[Adam D. Barratt]

On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:
> I'll make gcc-4.5 the default for (at least some) architectures within the 
> next
> two weeks before more transitions start.  GCC-4.5 is already used as the 
> default
> compiler for almost any other distribution, so there shouldn't be many 
> surprises
> on at least the common architectures.  About 50% of the build failures exposed
> by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
> (although optimized for a different processor) and powerpc (some object files
> linked into shared libs had to be built as pic).

It looks like kfreebsd-* also made the switch and there's been a request
to switch for mips and mipsel.

Looking through the bug list for src:gcc-4.5, none of the open issues
seem to be specific to the remaining release architectures which haven't
switched yet - i.e. ia64, s390 and sparc.  Are you aware of any issues
which would preclude switching the default on those architectures?  Has
there been any discussion with the port maintainers regarding switching?

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1303068791.3489.499.ca...@hathi.jungle.funky-badger.org

Re: updating question...

[Hendrik Boom]

On Thu, Apr 14, 2011 at 03:35:10PM +0100, Darac Marjal wrote:
> 
> It sounds to me like your locate package has been upgraded to mlocate.
> As per the package status of mlocate, mlocate differs from plain locate
> in that when you run "locate foo" you only see files to which you have
> access. Also instead of re-reading the whole filesystem, timestamps are
> taken into account and only changed files are recorded in the database.
> As a result updatedb is, as you have found, a lot faster.

Interesting.  I wonder how it manages to find the changed files without 
reading the entire directory tree?  It shouldn't have to read the files 
themselves in any case, should it?

-- hendrik


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110414210404.gb12...@topoi.pooq.com

Re: updating question...

[Whit Hansell]

Darac,
Thanks so much for the reply.  If I put the question in the wrong 
forum/list, I apologize but while  my knowledge of LInux is not 
specifically noob, it is not such that I would be able to recognize 
whether a situation was related to debian-amd64, or to wheezy/testing.  
But thanks again for the reply and I appreciate it a lot.  Helps w. my 
understanding of things.


Regards,
Whit

On 04/14/2011 10:35 AM, Darac Marjal wrote:

On Thu, Apr 14, 2011 at 08:51:34AM -0400, Whit Hansell wrote:
   

Guys,
Using Wheezy, debian.

In the past I have always done my updates w.

#aptitude update
#aptitude safe-upgrade
#aptitude autoclean
#updatedb

Everything is working just fine and no problem except the updatedb
command.  I know it used to actually update the file database and
sometimes it actually took some time to do it.  And sometimes when I
would install a file from outside aptitude I would have to run
updatedb to get the system to recognize it.  Now when I run updatedb
it seem like it is doing nothing.  It takes no time at all yet so
far am having no recognition problems.  Am just wondering if I'm
actually doing anything by trying to run it.  E.g is it actually
updating?
 

A couple of caveats:
  1) This isn't strictly amd64 related.
  2) updatedb isn't actually related to the package database, but
  maintains a list of all files on your system.

It sounds to me like your locate package has been upgraded to mlocate.
As per the package status of mlocate, mlocate differs from plain locate
in that when you run "locate foo" you only see files to which you have
access. Also instead of re-reading the whole filesystem, timestamps are
taken into account and only changed files are recorded in the database.
As a result updatedb is, as you have found, a lot faster.

For the record, there's no real need to call "updatedb" after an update
as there should be a cron job that does that for you. However, there's
also no harm in it and I can see a reason for doing so.

   



--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4da71ef8.7010...@comcast.net

Re: updating question...

[Darac Marjal]

On Thu, Apr 14, 2011 at 08:51:34AM -0400, Whit Hansell wrote:
> Guys,
> Using Wheezy, debian.
> 
> In the past I have always done my updates w.
> 
> #aptitude update
> #aptitude safe-upgrade
> #aptitude autoclean
> #updatedb
> 
> Everything is working just fine and no problem except the updatedb
> command.  I know it used to actually update the file database and
> sometimes it actually took some time to do it.  And sometimes when I
> would install a file from outside aptitude I would have to run
> updatedb to get the system to recognize it.  Now when I run updatedb
> it seem like it is doing nothing.  It takes no time at all yet so
> far am having no recognition problems.  Am just wondering if I'm
> actually doing anything by trying to run it.  E.g is it actually
> updating?

A couple of caveats:
 1) This isn't strictly amd64 related.
 2) updatedb isn't actually related to the package database, but
 maintains a list of all files on your system.

It sounds to me like your locate package has been upgraded to mlocate.
As per the package status of mlocate, mlocate differs from plain locate
in that when you run "locate foo" you only see files to which you have
access. Also instead of re-reading the whole filesystem, timestamps are
taken into account and only changed files are recorded in the database.
As a result updatedb is, as you have found, a lot faster.

For the record, there's no real need to call "updatedb" after an update
as there should be a cron job that does that for you. However, there's
also no harm in it and I can see a reason for doing so.

-- 
Darac


signature.asc
Description: Digital signature

Re: udev problem Was: kernel modules not loading at boot after upgrade

[Ernesto Domato]

On Fri, Apr 8, 2011 at 16:27, Ernesto Domato  wrote:
> Ok. I downgrade the "udev" package (and "libudev0" dependency) from
> 167-1 to 166-1 and it solved the problem so I guess my behavior could
> come from it.
>
> Looking at the logs it says, when I upgraded to 167-1, "converting old
> udev database" so maybe the problem is on the database conversion.
>

Well, I found the answers here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621036

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620995

Thanks.
Ernesto


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTi=mqu=7yhnixfx0t_ndr_fuoxg...@mail.gmail.com

Re: Unmounting (during shutdown) then mounting (during bootup) USB-attached external hard drive fails fsck

[Jack Warkentin]

Hi everyone

The problem appears to have been a race condition between udev and fsck. 
I clued in to this possibility when I was about to issue the

fsck.ext3 -v -y -b 32768 /dev/sdb6
command of my original posting. Before I could issue this, there was a 
console message from udev saying that sdb was now available.


So, I checked in /etc/fstab and discovered that the last column, the one 
which specifies the order in which fsck is to be run on various devices, 
specified 2 for /dev/sdb6, the same as for all of the partitions on 
/dev/sda. When I changed that 2 to a 3, the problem went away.


Regards

Jack

Jack Warkentin wrote:

Hi

I have a USB-attached external hard drive with an ext3 partition that
was working very successfully for 18 months with a Pentium-4 3.0 GH
processor. That motherboard failed and last November I bought an AMD64
motherboard as a replacement. Now, frequently, but not 100% of the time,
after I have shutdown the system and then rebooted, that partition fails
the bootup fsck and I am put into single user mode. The error message
indicates that fsck can't find the superblock and suggests running fsck
manually specifying an alternate superblock. When I then issue the command

fsck.ext3 -v -y -b 32768 /dev/sdb6

a bunch of errors are found (and fixed) during the last pass. After
exiting single user mode the system boots successfully and sdb6
functions normally.

Are there any suggestions for preventing these occurrences? I can
provide as much detail about the system as necessary, just let me know
what is required. Unfortunately, the console display during the relevant
part of the bootup is not captured in any of the log files. Is there any
method of capturing these?

Any help would be appreciated.

Jack


--
Jack Warkentin, phone 902-404-0457, email jw...@eastlink.ca
39 Inverness Avenue, Halifax, Nova Scotia, Canada, B3P 1X6


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d9f88e1.8010...@eastlink.ca

Re: Evolution problem - SQUEEZE/WHEEZY

[Alasdair Campbell]

On Wed, 2011-04-06 at 12:16 +0200, Jean-Paul Pozzi wrote: 
> Hello 
> 
> Is your user the same with the same ID ?
> 
> Regards
> 
> 
I guess so, because my I have a separate partition for HOME.
This is mounted on /home in both versions.

Alasdair 
> 
> - Mail d'origine -
> De: Alasdair Campbell 
> À: debian-amd64@lists.debian.org
> Envoyé: Wed, 06 Apr 2011 02:18:09 +0200 (CEST)
> Objet: Evolution problem - SQUEEZE/WHEEZY
> I have recently installed WHEEZY to a separate partion on one of my
> hard drives. My HOME folder is on another partition and is mounted
> on /home in /etc/fstab in both WHEEZY and SQUEEZE.
> Now here is the funny thing - I cannot see any of my evolution vfolders
> when logged into SQUEEZE, all _new_ messages appear in "Inbox" and all
> messages that appeared in my vfolders are not shown.
> When I reboot into WHEEZY all my vfolders appear, and all my messages
> appear _except_ the _new_ messages that are shown in SQUEEZE.
> I am at a complete loss as to why this can be happening. All other files
> in my /home/USER directory behave exactly the same (notably .bashrc) 
> Can anyone help? I am at my wit's end.
> -- 
> Kind regards,
> Alasdair

-- 
Kind regards,

Alasdair



-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1302094084.2365.0.ca...@fellatrix.home

Re: Evolution problem - SQUEEZE/WHEEZY

[Lennart Sorensen]

On Wed, Apr 06, 2011 at 01:18:09AM +0100, Alasdair Campbell wrote:
> I have recently installed  WHEEZY to a separate partion on one of my
> hard drives. My HOME folder is on another partition and is mounted
> on /home in /etc/fstab in both WHEEZY and SQUEEZE.
> 
> Now here is the funny thing - I cannot see any of my evolution vfolders
> when logged into SQUEEZE, all _new_ messages appear in "Inbox" and all
> messages that appeared in my vfolders are not shown.
> 
> When I reboot into WHEEZY all my vfolders appear, and all my messages
> appear _except_ the _new_ messages that are shown in SQUEEZE.
> 
> I am at a complete loss as to why this can be happening. All other files
> in my /home/USER directory behave exactly the same (notably .bashrc) 
> 
> Can anyone help? I am at my wit's end.

When you used the version in wheezy it probably converted the format
of the config files in $HOME to a new format, and the old version can't
read them anymore.

That's always a hazard of sharing a home between different systems.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110405235233.ge...@caffeine.csclub.uwaterloo.ca

RE: Wine with X-trap

[Adrian cosmos]

Thanks i already posted there also, lets hope they can fix this.

> Date: Thu, 31 Mar 2011 15:34:17 +
> From: sand...@crustytoothpaste.net
> To: debian-amd64@lists.debian.org
> Subject: Re: Wine with X-trap
> 
> On Thu, Mar 31, 2011 at 12:29:08AM -0300, Adrian cosmos wrote:
> > 
> > Hello i wish to colaborate with this suggestion for the next Debian
> > distribution.This is what happen to many users that want to play
> > masive rpg games online like WoW, Jade Dynasty, Prison Tale and a lot
> > more. This kind of games has an anti-cheater program like X-trap that
> > can not run under wine or any other program, there is no way to run
> > this under linux. This is one of the reason for a lot of user must
> > intall windows sadly.Imagine this, im playing 2 of this games that
> > represent a community of like 2000 or 3000 people, so imagine that
> > between friends and family and that expand to the others games.
> > Becouse are like more of 20 of this kind of games with a very big
> > community and each day are more bigger becouse they realize new
> > versions of this games, so it gives like 60.000 people that can use
> > linux.This is not a tinny thing, this is important, there is a lot of
> > people that want to use linux  but they cant cos of this.Im sure you
> > can solve this. Thanks in advance.
> 
> You'll probably be interested in the upstream Wine bug 11344:
> <http://bugs.winehq.org/show_bug.cgi?id=11344>.  Debian is unlikely to
> be able to fix this on its own, so you should probably talk to the Wine
> Project about this.  If a fix is made, I'm certain that it will be
> included in Debian if possible.
> 
> Also, please wrap your lines and break your text into paragraphs so that
> it's easier to read what you're saying (and therefore easier for people
> to reply).
> 
> -- 
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
  

Re: Wine with X-trap

[brian m. carlson]

On Thu, Mar 31, 2011 at 12:29:08AM -0300, Adrian cosmos wrote:
> 
> Hello i wish to colaborate with this suggestion for the next Debian
> distribution.This is what happen to many users that want to play
> masive rpg games online like WoW, Jade Dynasty, Prison Tale and a lot
> more. This kind of games has an anti-cheater program like X-trap that
> can not run under wine or any other program, there is no way to run
> this under linux. This is one of the reason for a lot of user must
> intall windows sadly.Imagine this, im playing 2 of this games that
> represent a community of like 2000 or 3000 people, so imagine that
> between friends and family and that expand to the others games.
> Becouse are like more of 20 of this kind of games with a very big
> community and each day are more bigger becouse they realize new
> versions of this games, so it gives like 60.000 people that can use
> linux.This is not a tinny thing, this is important, there is a lot of
> people that want to use linux  but they cant cos of this.Im sure you
> can solve this. Thanks in advance.  

You'll probably be interested in the upstream Wine bug 11344:
.  Debian is unlikely to
be able to fix this on its own, so you should probably talk to the Wine
Project about this.  If a fix is made, I'm certain that it will be
included in Debian if possible.

Also, please wrap your lines and break your text into paragraphs so that
it's easier to read what you're saying (and therefore easier for people
to reply).

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

RE: Wine with X-trap

[Adrian cosmos]

This can sound of many ways, the fact is that there is no way to run this kind 
of games under linux till now.There is a lot of people that no have other 
choice that install windows ( i wish to use Debian)and believe me they dont 
have nothing to do with windows, just like other programs in the world theymake 
it for windows and they are not going to change that. So if we dont care about 
things like this nobodywill do this, and we can win a lot of users if this kind 
of programs can run under linux, remember that is aMMORPG, means MASIVE 
Multiplayer that also means a lot of users.We are talking about thousands of 
players. Thanks for your time.

> From: de...@earthshod.co.uk
> To: debian-amd64@lists.debian.org
> Subject: Re: Wine with X-trap
> Date: Thu, 31 Mar 2011 08:59:16 +0100
> 
> On Thursday 31 Mar 2011, Adrian cosmos wrote:
> > This is what happen to many users that want to play masive rpg
> > games online like WoW, Jade Dynasty, Prison Tale and a lot more. This kind
> > of games has an anti-cheater program like X-trap that can not run under
> > wine or any other program, there is no way to run this under linux.
> 
> This sounds rather like illegal, anti-competitive behaviour to me; since in 
> effect, they are artificially forcing you to use one particular supplier's 
> product  (Microsoft Windows)  over another  (WINE on any compatible OS; the 
> published Source Code of WINE describes the API fully).
> 
> Your MEP might well be interested to know about this, if you can explain it 
> in 
> a way that makes sense to non-computer-literate people.
> 
> -- 
> AJS
> delta echo bravo six four at earthshod dot co dot uk
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/201103310859.16600.de...@earthshod.co.uk
> 
  

Re: Wine with X-trap

[A J Stiles]

On Thursday 31 Mar 2011, Adrian cosmos wrote:
> This is what happen to many users that want to play masive rpg
> games online like WoW, Jade Dynasty, Prison Tale and a lot more. This kind
> of games has an anti-cheater program like X-trap that can not run under
> wine or any other program, there is no way to run this under linux.

This sounds rather like illegal, anti-competitive behaviour to me; since in 
effect, they are artificially forcing you to use one particular supplier's 
product  (Microsoft Windows)  over another  (WINE on any compatible OS; the 
published Source Code of WINE describes the API fully).

Your MEP might well be interested to know about this, if you can explain it in 
a way that makes sense to non-computer-literate people.

-- 
AJS
delta echo bravo six four at earthshod dot co dot uk


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103310859.16600.de...@earthshod.co.uk

Re: chroot to 32bit

[Michael]

It turned out it was an old IDE drive and i had to open the case anyway to get 
access to the last remaining IDE channel (for a DVD drive) and thus i decided 
it was easier to just plug off some of the more difficult hardware, and boot 
that external drive directly.
I'm glad i had a 32bit downward compatible mainboard !

However, i think the question is still interesting and i'm always more happy if 
i don't even have to open the case. I hate dust.
So anyone feel free to enlighten me.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110328014809.34bc6...@mirrors.kernel.org

Re: 32 or 64 bits for the end user.

[Hendrik Boom]

On Sat, Mar 26, 2011 at 03:46:02AM -0400, Robert Isaac wrote:
> > That doesn't seem relevant to whether 32 or 64bit works with flash.
> > That's just a problem with the flash plugin in general.
> 
> Not really, Debian's security support for flash is often lacking.
> If users are lucky there will be a backport available, if not
> then they are on their own.
> 
> > Same package and version exists in stable.
> 
> Will that be the case in 6 months time?  Of course not.

No, of course not.  But that's a general problem with Linux, not a specific 
to 64-bit.  I think we're all looking forward to the gradual demise of Flash in 
favour of something that's actually a standard.  Or at least to something where 
the client implementations keep up with the servers.  Because that's one of the 
problems with Flash -- that people with servers unnecessarily rush to update to 
the latest version, leaving the Linux clients in the dist.

-- hendrik
k


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326141046.ga21...@topoi.pooq.com

Re: 32 or 64 bits for the end user.

[Robert Isaac]

> That doesn't seem relevant to whether 32 or 64bit works with flash.
> That's just a problem with the flash plugin in general.

Not really, Debian's security support for flash is often lacking.
If users are lucky there will be a backport available, if not
then they are on their own.

> Same package and version exists in stable.

Will that be the case in 6 months time?  Of course not.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=n89upq0orcwdjcd7oukhgl_nh8_coltvbp...@mail.gmail.com

Re: 32 or 64 bits for the end user.

[Lennart Sorensen]

On Thu, Mar 24, 2011 at 03:48:26PM -0400, Robert Isaac wrote:
> For Stable?  Historically it's never updated so as to _not_ be vulnerable
> when Adobe screws up.  Do you really want to put someone's spouse through
> the forced death march that is Sid just for a secure flash plugin?
> 
> That may be grounds for divorce in some countries.

That doesn't seem relevant to whether 32 or 64bit works with flash.
That's just a problem with the flash plugin in general.

Same package and version exists in stable.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110324202323.gu...@caffeine.csclub.uwaterloo.ca

Re: 32 or 64 bits for the end user.

[Robert Isaac]

On Tue, Mar 22, 2011 at 5:16 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Tue, Mar 22, 2011 at 05:10:52PM -0400, Robert Isaac wrote:
> > The current stable flash plugin is 32-bit only which leaves you using
> either
> > nsplugin-wrapper or a 32-bit browser.
> >
> > There is a 64-bit beta that was released last year that works fine but no
> > one will package it for the usual reasons.
>
> What is wrong with http://packages.debian.org/sid/flashplugin-nonfree ?
> Works for me (as well as flash ever works that is).
>

For Stable?  Historically it's never updated so as to _not_ be vulnerable
when Adobe screws up.  Do you really want to put someone's spouse through
the forced death march that is Sid just for a secure flash plugin?

That may be grounds for divorce in some countries.

Re: 32 or 64 bits for the end user.

[Whit Hansell]

Hendrik,
Don't worry about it.  Been using amd64 for a few years and had really 
no problems user wise.  I did install ia32 libs in addition to the 
normal 64 bit libs and it has caused no probs.  Had used Lenny for a few 
years, then the new version came out, Squeeze and since back when I had 
been using 32 bit, before  I moved to 64 because of a mtbd change, I had 
been with testing all the time w. no real problems, I went this time, 
jumped squeeze and am using wheezy 64 bit.  And am having no real user  
problems except as everyone has mentioned, linux does have some 
difficulty getting the most current video codecs and drivers.  Hey, I 
was on Veoh the other day and they want you to download an .exe file, M$ 
only I guess.  Oh well.  Yes there are some videos I can't see but for 
most things a normal user would use it's fine.  HTH's


Cheers,
Whit

On 03/22/2011 02:14 PM, Hendrik Boom wrote:

On Tue, Mar 22, 2011 at 10:03:04AM +1100, Sam Varghese wrote:
   

On Mon, Mar 21, 2011 at 04:55:34PM -0600 Jaime Ochoa Malagón said:
 

On Mon, Mar 21, 2011 at 9:35 AM, Hendrik Boomwrote:

   

Yet again the 32 vs 64 bit question.

I have Debian systems at home running 32 bits, and my server has been
running happily in 64-bit mode fopr years.  Now I get to install debian
for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:

Are there still significant end-user problems for 64-bit Debian?  The
machine has nvidia graphics on the motherboard (I believe).  My user is
likely to want to use flash, which has always been a problem in Linux,
but ... Is it still even more of a problem in 64-bit mode?

Any other likely end-user problems?
 


I think you could use it for an end user...

Really few problems right now just try...
   

(text reformatted to bring reply below)

I have been using the 64-bit port since March 2006. Flash was not
available at the time. I must point out that I am a user who enjoys the
benefits that Debian brings and am thus prepared to put up with a few
cons.

Flash stopped being a problem at least two years ago - I could be wrong
there, it may be even longer than that. I have no reason to regret my
choice of using the 64-bit port. And, I may add, I am a non-technical user.
 

Thanks.  I'm a technical user myself, so it's essential I get advice
from a non-technical user before I subject my wife to it.

-- hendrik.


   



--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8a1182.6060...@comcast.net

Re: 32 or 64 bits for the end user.

[plandr...@gmail.com]

64 bit is stable for ages.I use it exclusively and I have no real problems with 
it.

If you have 3+ gb ram, go for it.



Sent from my HTC

- Reply message -
From: "Hendrik Boom" 
Date: Tue, Mar 22, 2011 20:14
Subject: 32 or 64 bits for the end user.
To: 

On Tue, Mar 22, 2011 at 10:03:04AM +1100, Sam Varghese wrote:
> On Mon, Mar 21, 2011 at 04:55:34PM -0600 Jaime Ochoa Malagón said:
> > On Mon, Mar 21, 2011 at 9:35 AM, Hendrik Boom wrote:
> > 
> > > Yet again the 32 vs 64 bit question.
> > >
> > > I have Debian systems at home running 32 bits, and my server has been
> > > running happily in 64-bit mode fopr years.  Now I get to install debian
> > > for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:
> > >
> > > Are there still significant end-user problems for 64-bit Debian?  The
> > > machine has nvidia graphics on the motherboard (I believe).  My user is
> > > likely to want to use flash, which has always been a problem in Linux,
> > > but ... Is it still even more of a problem in 64-bit mode?
> > >
> > > Any other likely end-user problems?
> >
> >
> > I think you could use it for an end user...
> >
> > Really few problems right now just try...
> 
> (text reformatted to bring reply below)
> 
> I have been using the 64-bit port since March 2006. Flash was not
> available at the time. I must point out that I am a user who enjoys the
> benefits that Debian brings and am thus prepared to put up with a few
> cons.
> 
> Flash stopped being a problem at least two years ago - I could be wrong
> there, it may be even longer than that. I have no reason to regret my
> choice of using the 64-bit port. And, I may add, I am a non-technical user.

Thanks.  I'm a technical user myself, so it's essential I get advice 
from a non-technical user before I subject my wife to it.

-- hendrik.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110322181450.ga13...@topoi.pooq.com

Re: 32 or 64 bits for the end user.

[Lennart Sorensen]

On Tue, Mar 22, 2011 at 05:10:52PM -0400, Robert Isaac wrote:
> The current stable flash plugin is 32-bit only which leaves you using either
> nsplugin-wrapper or a 32-bit browser.
> 
> There is a 64-bit beta that was released last year that works fine but no
> one will package it for the usual reasons.

What is wrong with http://packages.debian.org/sid/flashplugin-nonfree ?
Works for me (as well as flash ever works that is).

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110322211632.gs...@caffeine.csclub.uwaterloo.ca

Re: 32 or 64 bits for the end user.

[brian m. carlson]

On Tue, Mar 22, 2011 at 05:10:52PM -0400, Robert Isaac wrote:
> The current stable flash plugin is 32-bit only which leaves you using either
> nsplugin-wrapper or a 32-bit browser.
> 
> There is a 64-bit beta that was released last year that works fine but no
> one will package it for the usual reasons.

The current flashplugin-nonfree package uses the 64-bit plugin, not the
32-bit one with nspluginwrapper.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: 32 or 64 bits for the end user.

[Robert Isaac]

On Tue, Mar 22, 2011 at 2:14 PM, Hendrik Boom wrote:
>
> Flash stopped being a problem at least two years ago - I could be wrong
> there, it may be even longer than that. I have no reason to regret my
> choice of using the 64-bit port. And, I may add, I am a non-technical
user.

Thanks.  I'm a technical user myself, so it's essential I get advice
> from a non-technical user before I subject my wife to it.
>

The current stable flash plugin is 32-bit only which leaves you using either
nsplugin-wrapper or a 32-bit browser.

There is a 64-bit beta that was released last year that works fine but no
one will package it for the usual reasons.

Re: 32 or 64 bits for the end user.

[Hendrik Boom]

On Tue, Mar 22, 2011 at 10:03:04AM +1100, Sam Varghese wrote:
> On Mon, Mar 21, 2011 at 04:55:34PM -0600 Jaime Ochoa Malagón said:
> > On Mon, Mar 21, 2011 at 9:35 AM, Hendrik Boom wrote:
> > 
> > > Yet again the 32 vs 64 bit question.
> > >
> > > I have Debian systems at home running 32 bits, and my server has been
> > > running happily in 64-bit mode fopr years.  Now I get to install debian
> > > for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:
> > >
> > > Are there still significant end-user problems for 64-bit Debian?  The
> > > machine has nvidia graphics on the motherboard (I believe).  My user is
> > > likely to want to use flash, which has always been a problem in Linux,
> > > but ... Is it still even more of a problem in 64-bit mode?
> > >
> > > Any other likely end-user problems?
> >
> >
> > I think you could use it for an end user...
> >
> > Really few problems right now just try...
> 
> (text reformatted to bring reply below)
> 
> I have been using the 64-bit port since March 2006. Flash was not
> available at the time. I must point out that I am a user who enjoys the
> benefits that Debian brings and am thus prepared to put up with a few
> cons.
> 
> Flash stopped being a problem at least two years ago - I could be wrong
> there, it may be even longer than that. I have no reason to regret my
> choice of using the 64-bit port. And, I may add, I am a non-technical user.

Thanks.  I'm a technical user myself, so it's essential I get advice 
from a non-technical user before I subject my wife to it.

-- hendrik.


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110322181450.ga13...@topoi.pooq.com

Re: 32 or 64 bits for the end user.

[Chris Ahlstrom]

I've been using nothing but 64-bit Debian for the last few years.
I love it.  Server, workstation.

 brian m. carlson 23:12 Mon 21 Mar  


On Mon, Mar 21, 2011 at 03:35:46PM +, Hendrik Boom wrote:

Are there still significant end-user problems for 64-bit Debian?  The
machine has nvidia graphics on the motherboard (I believe).  My user is
likely to want to use flash, which has always been a problem in Linux,
but ... Is it still even more of a problem in 64-bit mode?


I can't speak to the nVidia graphics, since I bought Intel on this
motherboard (and two months later, AMD bought ATI and started releasing
specs), but 64-bit Flash works very well here.  I've used Iceweasel and
now use Chromium, and they both seem to work fine.

I haven't encountered any other problems on amd64/sid.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187




--
Since this database is not used for profit, and since entire works are not
published, it falls under fair use, as we understand it.  However, if any
half-assed idiot decides to make a profit off of this, they will need to
double check it all...
-- Notes included with the default fortunes database


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110322101137.ga16...@mlsrock.launchmodem.com

Re: 32 or 64 bits for the end user.

[brian m. carlson]

On Mon, Mar 21, 2011 at 03:35:46PM +, Hendrik Boom wrote:
> Are there still significant end-user problems for 64-bit Debian?  The 
> machine has nvidia graphics on the motherboard (I believe).  My user is 
> likely to want to use flash, which has always been a problem in Linux, 
> but ... Is it still even more of a problem in 64-bit mode?

I can't speak to the nVidia graphics, since I bought Intel on this
motherboard (and two months later, AMD bought ATI and started releasing
specs), but 64-bit Flash works very well here.  I've used Iceweasel and
now use Chromium, and they both seem to work fine.

I haven't encountered any other problems on amd64/sid.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: 32 or 64 bits for the end user.

[Sam Varghese]

On Mon, Mar 21, 2011 at 04:55:34PM -0600 Jaime Ochoa Malagón said:
> On Mon, Mar 21, 2011 at 9:35 AM, Hendrik Boom wrote:
> 
> > Yet again the 32 vs 64 bit question.
> >
> > I have Debian systems at home running 32 bits, and my server has been
> > running happily in 64-bit mode fopr years.  Now I get to install debian
> > for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:
> >
> > Are there still significant end-user problems for 64-bit Debian?  The
> > machine has nvidia graphics on the motherboard (I believe).  My user is
> > likely to want to use flash, which has always been a problem in Linux,
> > but ... Is it still even more of a problem in 64-bit mode?
> >
> > Any other likely end-user problems?
>
>
> I think you could use it for an end user...
>
> Really few problems right now just try...

(text reformatted to bring reply below)

I have been using the 64-bit port since March 2006. Flash was not
available at the time. I must point out that I am a user who enjoys the
benefits that Debian brings and am thus prepared to put up with a few
cons.

Flash stopped being a problem at least two years ago - I could be wrong
there, it may be even longer than that. I have no reason to regret my
choice of using the 64-bit port. And, I may add, I am a non-technical user.

Sam
-- 
(Sam Varghese)
http://www.gnubies.com
The chief virtue that language can have is clearness, and nothing detracts from
it so much as the use of unfamiliar words.
My PGP key: http://www.gnubies.com/encryption/sign.txt


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321230304.GA4397@imap://www.gnubies.com

Re: 32 or 64 bits for the end user.

[Jaime Ochoa Malagón]

I think you could use it for an end user...

Really few problems right now just try...

On Mon, Mar 21, 2011 at 9:35 AM, Hendrik Boom wrote:

> Yet again the 32 vs 64 bit question.
>
> I have Debian systems at home running 32 bits, and my server has been
> running happily in 64-bit mode fopr years.  Now I get to install debian
> for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:
>
> Are there still significant end-user problems for 64-bit Debian?  The
> machine has nvidia graphics on the motherboard (I believe).  My user is
> likely to want to use flash, which has always been a problem in Linux,
> but ... Is it still even more of a problem in 64-bit mode?
>
> Any other likely end-user problems?
>
> -- hendrik
>
>
> --
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/im7r8i$tvd$1...@dough.gmane.org
>
>


-- 
Perhaps the depth of love can be calibrated by the number of different
selves that are actively involved in a given relationship.
Carl Sagan (Contact)

Absolute certainty is a privilege of uneducated minds-and fanatics. It is,
for scientific folk, an unattainable ideal.
Cassius J. Keyser

Eres un barco en el mar de emociones donde la mente y el corazón son el
timón y el motor de tu vida; la muerte es tu destino, el amor tu capitán y
deseo con toda el alma que tu viaje sea emocionante, lleno de aventuras y
que dure muchos años.

   Montaño

Jaime Ochoa Malagón
Arquitecto de Soluciones
Cel: +52 (55) 1021 0774

Re: 32 or 64 bits for the end user.

[Ron Johnson]

On 03/21/2011 11:31 AM, Hendrik Boom wrote:

On Mon, Mar 21, 2011 at 10:53:00AM -0500, Ron Johnson wrote:


Been using 64-bit Sid for about 2 years.

64-bit Iceweasel 3.5.17 (in Sid) works great with Flash 10.2r152, but
v4.0 (b12 thru rc2 from Experimental, confirmed w/ Mozilla FF) has some
"inconsistencies" with Flash.  The 32 bit IW and FF 4.0 beta and rc
versions have no such problems.

Of course, they happen to be on (some) sites that I want to use...

So, when I reinstall Sid in the next few days (boot device is old and
spitting out SMART errors), I'm going to install 32-bits.  Once
stabilized with the nvidia drivers, I'll probably try a 64 bit kernel to
get a larger memory space for my processes (and to be cool).


Thanks.  This seems to be just the kind of intormation I need.  The
system will be running stable, or testing,


Then you probably won't have these problems.


   so the question becomes: will
these iceweasel vs flash problems impede iceweasel's transition to
testing.  My guess is that maybe it won't.

But it looks like 32-bit for normal use is my way to go; sticking 64-bit
as a dual-boot might help test when it's really ready.



Honestly, for my wife/kids' PC, I installed Ubuntu 10.04LTS with a 
few PPAs.  This way, they get stable libraries but keep current with 
important user apps like FF, vlc, etc.


Since I prefer booting into the CLI and use startx, I stick w/ Sid.


Is multiarch on the hirizon yet?



The Far Horizon... :(

--
I prefer banana-flavored energy bars made from tofu.


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d8783e8.4020...@cox.net

Re: 32 or 64 bits for the end user.

[Hendrik Boom]

On Mon, Mar 21, 2011 at 10:53:00AM -0500, Ron Johnson wrote:
>
> Been using 64-bit Sid for about 2 years.
>
> 64-bit Iceweasel 3.5.17 (in Sid) works great with Flash 10.2r152, but 
> v4.0 (b12 thru rc2 from Experimental, confirmed w/ Mozilla FF) has some 
> "inconsistencies" with Flash.  The 32 bit IW and FF 4.0 beta and rc 
> versions have no such problems.
>
> Of course, they happen to be on (some) sites that I want to use...
>
> So, when I reinstall Sid in the next few days (boot device is old and 
> spitting out SMART errors), I'm going to install 32-bits.  Once  
> stabilized with the nvidia drivers, I'll probably try a 64 bit kernel to 
> get a larger memory space for my processes (and to be cool).

Thanks.  This seems to be just the kind of intormation I need.  The 
system will be running stable, or testing, so the question becomes: will 
these iceweasel vs flash problems impede iceweasel's transition to 
testing.  My guess is that maybe it won't.

But it looks like 32-bit for normal use is my way to go; sticking 64-bit 
as a dual-boot might help test when it's really ready.

Is multiarch on the hirizon yet?

-- hendrik


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110321163144.ga24...@topoi.pooq.com

Re: 32 or 64 bits for the end user.

[Ron Johnson]

On 03/21/2011 10:35 AM, Hendrik Boom wrote:

Yet again the 32 vs 64 bit question.

I have Debian systems at home running 32 bits, and my server has been
running happily in 64-bit mode fopr years.  Now I get to install debian
for an end-user on another AMD-64 machine.  64-bit mode is tempting, but:

Are there still significant end-user problems for 64-bit Debian?  The
machine has nvidia graphics on the motherboard (I believe).  My user is
likely to want to use flash, which has always been a problem in Linux,
but ... Is it still even more of a problem in 64-bit mode?

Any other likely end-user problems?



Been using 64-bit Sid for about 2 years.

64-bit Iceweasel 3.5.17 (in Sid) works great with Flash 10.2r152, 
but v4.0 (b12 thru rc2 from Experimental, confirmed w/ Mozilla FF) 
has some "inconsistencies" with Flash.  The 32 bit IW and FF 4.0 
beta and rc versions have no such problems.


Of course, they happen to be on (some) sites that I want to use...

So, when I reinstall Sid in the next few days (boot device is old 
and spitting out SMART errors), I'm going to install 32-bits.  Once 
stabilized with the nvidia drivers, I'll probably try a 64 bit 
kernel to get a larger memory space for my processes (and to be cool).


https://bugzilla.mozilla.org/show_bug.cgi?id=638029
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616061
http://bugs.adobe.com/jira/browse/FP-6302

--
I prefer banana-flavored energy bars made from tofu.


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d87745c.9040...@cox.net

Re: touchscreen issue

[Hendrik Boom]

On Sat, 05 Feb 2011 14:37:02 +0100, dagecko wrote:

> Hello,
> 
> I don't really know where to ask for it. So I start on this list.
> 
> The touchpad of my laptop works well, but I can't make the "click on the
> touchpad works", meaning I must use the touchpad buttons to click,
> double-click and so on.
> If I select a file with the touchpad for example, and then tap on it
> with my finger, (or double tap), the file doesn't open. Hope I was clear
> in my explanation.

I had the same problem on m EEPC netbook -- only I never thought it might 
be software.  When the machine was new, it worked fine.  But gradually I 
had to tap it harder, until at some point tapping it for a mouse click 
didn't work at all.

-- hendrik



-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/im7rth$tvd$2...@dough.gmane.org

Re: upgrade from x86 to amd64

[Christopher Browne]

What seems apparent and what is can vary considerably.

One might imagine it a keen idea to have tooling to upgrade filesystems
in-place from ext3 to XFS or BTRFS, but in practice, it's completely
impractical, and the better idea is to copy files from one to the other,
whether via cp, cpio, or tar being minor variations of preference.

I would be enormously more confident in the ability of Debian to cope with a
fresh install than in some in-place update.

There's a useful analogy that I'd be loathe to predict the usefulness or
recoverability of an interrupted conversion.  True both for filesystem and
distribution.

If power fails 2/3 through the process, do you:
1. Hope to roll back?
2.  Hope to roll  forward?
3.  Kiss the whole system goodbye?

And if the answer is 3, the *real* solution is to have a backup that means
that "install fresh and copy over your favorite data" was always feasible
and the safest solution.

On 2011-03-11 2:51 AM, "Morty Abzug"  wrote:

On Mon, Mar 07, 2011 at 04:34:16PM +, brian m. carlson wrote:

> This isn't automatic, but it wa...
What I'm looking for are recommendations on how to automate the x86 to
x64 upgrade.  Sounds like you have some ideas.  Can you share?  :)

Several people sent email saying that the best thing to do is to
upgrade manually.  Thing is, I really do want to automate this.  It
feels like automation should be possible.  I'm willing to try to
figure this out for myself and/or pay someone to figure it out for me.


- Morty


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "uns...
Archive: http://lists.debian.org/20110311072952.GF4142@red-sonja

Re: upgrade from x86 to amd64

[Goswin von Brederlow]

Morty  writes:

> What would it take to automate an upgrade of Debian x86 to amd64?
>
> I know there is no currently-supported way to do this.  What would it
> take to make one?
>
> Advantages: shops with a mix of x86 and amd64 systems can have one
> master x86 build image that can be automatically upgraded to amd64 as
> needed.  Shops with existing x86 systems that want to upgrade to amd64
> hardware can copy the existing install to new hardware, upgrade
> in-place, and be done with it.  Shops with hardware at remote sites
> can upgrade in-place.
>
> Thanks!
>
> - Morty

There is a script out there that hacks an update together. Google a bit.
But if you can wait then multiarch should simplify this greatly.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vczfhqmf.fsf@frosties.localnet

Re: upgrade from x86 to amd64

[Ron Johnson]

On 03/07/2011 03:25 AM, Morty wrote:

What would it take to automate an upgrade of Debian x86 to amd64?

I know there is no currently-supported way to do this.  What would it
take to make one?

Advantages: shops with a mix of x86 and amd64 systems can have one
master x86 build image that can be automatically upgraded to amd64 as
needed.  Shops with existing x86 systems that want to upgrade to amd64
hardware can copy the existing install to new hardware, upgrade
in-place, and be done with it.  Shops with hardware at remote sites
can upgrade in-place.



KISS and keep your boxes where they are.  For any i386 box that 
really needs 64 bits, you can install a 64 bit *kernel* and some 64 
bit libraries.


--
I prefer banana-flavored energy bars made from tofu.


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d79fdf3.2040...@cox.net

Re: upgrade from x86 to amd64

[Morty Abzug]

On Mon, Mar 07, 2011 at 04:34:16PM +, brian m. carlson wrote:

> This isn't automatic, but it was a lot easier than it might otherwise
> have been.  It is, however, trivially automatable.  Multiarch might make
> it even easier, I don't know.

What I'm looking for are recommendations on how to automate the x86 to
x64 upgrade.  Sounds like you have some ideas.  Can you share?  :)

Several people sent email saying that the best thing to do is to
upgrade manually.  Thing is, I really do want to automate this.  It
feels like automation should be possible.  I'm willing to try to
figure this out for myself and/or pay someone to figure it out for me.

- Morty


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110311072952.GF4142@red-sonja

Re: upgrade from x86 to amd64

[brian m. carlson]

On Mon, Mar 07, 2011 at 04:25:01AM -0500, Morty wrote:
> Advantages: shops with a mix of x86 and amd64 systems can have one
> master x86 build image that can be automatically upgraded to amd64 as
> needed.  Shops with existing x86 systems that want to upgrade to amd64
> hardware can copy the existing install to new hardware, upgrade
> in-place, and be done with it.  Shops with hardware at remote sites
> can upgrade in-place.

What I've done in one case is use LVM.  I had several logical volumes,
including ones for /, /home, /usr, /var, and /tmp.  When I upgraded the
hardware underlying the machine, I created separate logical volumes
called root64, usr64, and var64.  I installed the 64-bit system using
those logical volumes, copied over /etc from the old root to root64, and
rebooted.

This isn't automatic, but it was a lot easier than it might otherwise
have been.  It is, however, trivially automatable.  Multiarch might make
it even easier, I don't know.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: upgrade from x86 to amd64

[Dean Hamstead]

Your best bet is to capture the pertinent files in /etc and /home from
32bit

of course, any databases etc. should also be preserved and log files
stored if they need to be held for legal reasons etc.

then copy them in to their new homes in a fresh 64bit install

ive moved my ~dean around from linux-i386 to linux-ppc to linux-x86_64

obviously anything binary doesnt work but its pretty much always 'just
worked'



Dean

On 3/7/2011, "Morty"  wrote:

>What would it take to automate an upgrade of Debian x86 to amd64?
>
>I know there is no currently-supported way to do this.  What would it
>take to make one?
>
>Advantages: shops with a mix of x86 and amd64 systems can have one
>master x86 build image that can be automatically upgraded to amd64 as
>needed.  Shops with existing x86 systems that want to upgrade to amd64
>hardware can copy the existing install to new hardware, upgrade
>in-place, and be done with it.  Shops with hardware at remote sites
>can upgrade in-place.
>
>Thanks!
>
>- Morty
>
>
>--
>To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>Archive: http://lists.debian.org/20110307092501.GN6076@red-sonja
>


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/xsqokycg.1299490276.490.djz...@bong.com.au

Re: low vision

[Ross Cameron]

Thankyou for spamming us.

Any concern we might have had for you're plight has now been blighted from
the earth.




"Opportunity is most often missed by people because it is dressed in
overalls and looks like work."
Thomas Alva Edison
Inventor of 1093 patents, including:
The light bulb, phonogram and motion pictures.



On Sat, Mar 5, 2011 at 9:20 PM, Harold Blethen wrote:

>
>
>
>
>
>
> Hello,
>
>
>
> I have macular degeneration and am legally blind.  The challenges of the
> Visually Impaired is hard enough to cope with, but high prices of any
> products or aid make one problem even more overwhelming.We have
> published a web-site opening an internet store
> http://www.lindavevision.com.
>
>
>
> Please take a look at our web-site http://www. lindavevision.com we have
> not re-invented the wheel, but have shopped around to present affordable
> reading products and aids to help the visually impaired.  These products
> and combination reading devices have helped many to read again.  Should it
> be a financial burden for some of your patients to afford our products, we
> work with town’s local service clubs to help with the purchase.
>
>
>
> Our goal is to promote the spirit of hope to the individual and assist
> until breakthrough cures comes along.  Take a look at us, hopefully
> together we can help the visually impaired, passing along our information
> will let you patients become aware that helpful products are available.
> Thank you.
>
>
>
> Best regards,
>
>
>
>
>
> Harold Blethen
>
> lindavevision
>
>
>
>
>

Re: GCC-4.5 as the default for (at least some) architectures

[John David Anglin]

> On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose  wrote:
> > I'll make gcc-4.5 the default for (at least some) architectures within th=
> e next
> > two weeks before more transitions start. =A0GCC-4.5 is already used as th=
> e default
> > compiler for almost any other distribution, so there shouldn't be many su=
> rprises
> > on at least the common architectures. =A0About 50% of the build failures =
> exposed
> > by GCC-4.5 are fixed [1]. =A0I didn't see issues on amd64 and i386, armel
> > (although optimized for a different processor) and powerpc (some object f=
> iles
> > linked into shared libs had to be built as pic).
> >
> > As the maintainer file for the ports in GCC is a bit outdated, I'd like t=
> o ask
> > which architectures should do the switch together with the four architect=
> ures
> > mentioned above, and which not, and which ones should be better delayed, =
> or dropped.
> 
> Dave,
> 
> What's your opinion on switching to GCC 4.5 for HPPA?

Do it!  I have built glibc with it and all my recent kernel have
been with 4.5.  I'm not aware of any new issues with 4.5 and a number
of things are fixed.

For kernel builds, the following patch must be included:

2010-12-18  John David Anglin  

PR target/46915
* config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead
of next_real_insn.  Search forward checking for both ASM_INPUT and
ASM_OPERANDS asms until exit condition is found.
(branch_needs_nop_p): Likewise.
(use_skip_p): New function.
(output_cbranch): Use use_skip_p.
(output_bb, output_bvb): Likewise.

There are some other bug fixes in 4.6 that might need back porting.

We also need this binutils change:

2011-02-18  John David Anglin  

PR ld/12376
emulparams/hppalinux.sh (DATA_ADDR): Define.
(SHLIB_DATA_ADDR): Likewise.

This should eliminate cache issues arising from non equivalent aliasing.

Hopefully, the above will help resolve some of the build and kernel issues
that blocked squeeze.  I personally don't know what the critical blockers
were.  If they involve GCC or binutils, I'm willing to take a look.  I'm
sure a number of things have been magically fixed by updates to the
middle-end.  The biggest issue is the callee copies args on HPPA and
this differs from most other targets.

Regards,
Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110307013751.74c8c5...@hiauly1.hia.nrc.ca

Re: GCC-4.5 as the default for (at least some) architectures

[Sythos]

On Wed, 02 Mar 2011 02:34:01 +0100
Matthias Klose  wrote:

> I'll make gcc-4.5 the default for (at least some) architectures
> within the next two weeks before more transitions start.  GCC-4.5 is
> already used as the default compiler for almost any other
> distribution, so there shouldn't be many surprises on at least the
> common architectures.  About 50% of the build failures exposed by
> GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
> (although optimized for a different processor) and powerpc (some
> object files linked into shared libs had to be built as pic).

GCC4.5 still segfault when i try to compile, all previous version work
fine (without any kind of warning), maybe my GCC4.5 isn't the right one
(4.5.2-4), but i'm not so sure can be deployed as "default" (compiling
on i386)


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110307015837.a9d87800.syt...@sythos.net

Re: GCC-4.5 as the default for (at least some) architectures

[Carlos O'Donell]

On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose  wrote:
> I'll make gcc-4.5 the default for (at least some) architectures within the 
> next
> two weeks before more transitions start.  GCC-4.5 is already used as the 
> default
> compiler for almost any other distribution, so there shouldn't be many 
> surprises
> on at least the common architectures.  About 50% of the build failures exposed
> by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
> (although optimized for a different processor) and powerpc (some object files
> linked into shared libs had to be built as pic).
>
> As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask
> which architectures should do the switch together with the four architectures
> mentioned above, and which not, and which ones should be better delayed, or 
> dropped.

Dave,

What's your opinion on switching to GCC 4.5 for HPPA?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinznkgbhpaqc7hd6peyppr8da+1iponh1im6...@mail.gmail.com

RE: low vision

[Kevin Hogan]

Crap – thanks!

 


Kevin Hogan 
Tech Support Group, Inc. 
kho...@tech-support-group.com 
Voice (561) 289-0936
Fax (866) 230-7969

From: Harold Blethen [mailto:har...@lindavevision.com] 
Sent: Saturday, March 05, 2011 2:20 PM
To: debian-ports
Subject: low vision

 

 

 

 

Hello, 

 

I have macular degeneration and am legally blind.  The challenges of the 
Visually Impaired is hard enough to cope with, but high prices of any products 
or aid make one problem even more overwhelming.We have published a web-site 
opening an internet store http://www.lindavevision.com 
<http://www.lindavevision.com/> .

 

Please take a look at our web-site http://www. lindavevision.com 
<http://www.%20lindavevision.com/>  we have not re-invented the wheel, but have 
shopped around to present affordable reading products and aids to help the 
visually impaired.  These products and combination reading devices have helped 
many to read again.  Should it be a financial burden for some of your patients 
to afford our products, we work with town’s local service clubs to help with 
the purchase.

 

Our goal is to promote the spirit of hope to the individual and assist until 
breakthrough cures comes along.  Take a look at us, hopefully together we can 
help the visually impaired, passing along our information will let you patients 
become aware that helpful products are available. Thank you.

 

Best regards,

 

 

Harold Blethen

lindavevision

 

 

Re: GCC-4.5 as the default for (at least some) architectures

[Matthias Klose]

On 02.03.2011 17:54, Martin Guy wrote:
> On 2 March 2011 02:34, Matthias Klose  wrote:
>>   armel (although optimized for a different processor)
> 
> Hi
>   For which processor (/architecture) is it optimized, and do you mean
> optimized-for, or only-runs-on?
> I ask in case this would mean dumping all the armv4t systems that are
> using Debian armel.

I didn't propose changing the minimum required processor for armel.  I said that
4.5 looks ok, although I can only say that for another processor default 
(armv7-a).

  Matthias


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6e787c.9090...@debian.org

Re: GCC-4.5 as the default for (at least some) architectures

[Martin Guy]

On 2 March 2011 02:34, Matthias Klose  wrote:
>  armel (although optimized for a different processor)

Hi
  For which processor (/architecture) is it optimized, and do you mean
optimized-for, or only-runs-on?
I ask in case this would mean dumping all the armv4t systems that are
using Debian armel.

   M


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktiktn0zoa_hzgciwhkzbup7_ji6pbeji+p4c7...@mail.gmail.com

Re: GCC-4.5 as the default for (at least some) architectures

[Matthias Klose]

On 02.03.2011 07:36, Konstantinos Margaritis wrote:
> On 2 March 2011 03:34, Matthias Klose  wrote:
> 
>> I'll make gcc-4.5 the default for (at least some) architectures within the
>> next
>> two weeks before more transitions start.  GCC-4.5 is already used as the
>> default
>> compiler for almost any other distribution, so there shouldn't be many
>> surprises
>> on at least the common architectures.  About 50% of the build failures
>> exposed
>> by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
>> (although optimized for a different processor) and powerpc (some object
>> files
>> linked into shared libs had to be built as pic).
>>
>> As the maintainer file for the ports in GCC is a bit outdated, I'd like to
>> ask
>> which architectures should do the switch together with the four
>> architectures
>> mentioned above, and which not, and which ones should be better delayed, or
>> dropped.
>>
> Could you add armhf to the list?

keeping armhf to build from the linaro branch?

  Matthias


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6e5293.8060...@debian.org

Re: GCC-4.5 as the default for (at least some) architectures

[Konstantinos Margaritis]

On 2 March 2011 03:34, Matthias Klose  wrote:

> I'll make gcc-4.5 the default for (at least some) architectures within the
> next
> two weeks before more transitions start.  GCC-4.5 is already used as the
> default
> compiler for almost any other distribution, so there shouldn't be many
> surprises
> on at least the common architectures.  About 50% of the build failures
> exposed
> by GCC-4.5 are fixed [1].  I didn't see issues on amd64 and i386, armel
> (although optimized for a different processor) and powerpc (some object
> files
> linked into shared libs had to be built as pic).
>
> As the maintainer file for the ports in GCC is a bit outdated, I'd like to
> ask
> which architectures should do the switch together with the four
> architectures
> mentioned above, and which not, and which ones should be better delayed, or
> dropped.
>
> Could you add armhf to the list?

Konstantinos

Re: Et vous, faites-vous parler de vous ?

[Serge BILLECARD]

Bonjour,

 

Je cherche à faire une campagne d’envoi d’e-mail pour le compte de ma
société prestataire de services avec une cible effectif et geographique.

 

Seriez-vous une ste disposant d’une base de données fiable ?

 

Pouvez-vous me communiquer vos coordonnées site internet, voir me
recontacter.

 

Cordialement

 

Serge BILLECARD

LE STORY

 

03 81 57 61 35

Re: touchscreen issue

[dagecko]

Thanks all for the replies. If I submitted here for a bug, this was
because tools for KDE or gnome didn't make the "tap" tool to work.

And since now xorg.conf doesn't come by default with xorg, I didn't
thought about it. Thanks ael for pointed it, it did the job !

Sorry for the disturb :)

- "ael"  a écrit :

> On Sat, Feb 05, 2011 at 02:37:02PM +0100, dage...@free.fr wrote:
> > 
> > Hello,
> > 
> > I don't really know where to ask for it. So I start on this list.
> > 
> > The touchpad of my laptop works well, but I can't make the
> > "click on the touchpad works", meaning I must use the touchpad
> buttons
> > to click, double-click and so on.
> 
> I think that you just need to include the appropriate InputClass
> section
> in your /etc/X11/xorg.conf.
> 
> For example. on my netbook I have:
> 
> Section "InputClass"
> 
> Identifier  "SynPS/2 Synaptics TouchPad"
> 
> Option  "LeftEdge"  "1700"
> Option  "RightEdge" "5700"
> Option  "TopEdge"   "1700"
> Option  "BottomEdge""5100"
> Option  "FingerLow" "25"
> Option  "FingerHigh""30"
> Option  "MaxTapTime""180"
> Option  "MaxTapMove""220"
> Option  "VertScrollDelta"   "100"
> Option  "MinSpeed"  "0.09"
> Option  "MaxSpeed"  "0.6"
> Option  "HorizEdgeScroll"   "true"
> Option  "TapButton1""1"
> Option  "SHMConfig" "true"
> EndSection
> 
> Obviously these parameters may not be suitable for your touchpad, so
> you will probably need to modify the entries. lshal should show you
> the right Identifier string for your system. 
> 
> This is probably better (more fundamental) than using any
> xfce/gname/kde
> tools that may or may not exist. Also likely to be more flexible.
> 
> This is not amd64 specific: rather an xorg question. I don't know a
> good
> way to support the touchpad properly on standard (non-X) terminals:
> gpm
> seems only to do treat the pad like a mouse.
> 
> ael
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20110205163229.GB14722@conquest2.conquest


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/571806205.3717811296929163844.javamail.r...@zimbra20-e3.priv.proxad.net

Re: touchscreen issue

[ael]

On Sat, Feb 05, 2011 at 02:37:02PM +0100, dage...@free.fr wrote:
> 
> Hello,
> 
> I don't really know where to ask for it. So I start on this list.
> 
> The touchpad of my laptop works well, but I can't make the
> "click on the touchpad works", meaning I must use the touchpad buttons
> to click, double-click and so on.

I think that you just need to include the appropriate InputClass section
in your /etc/X11/xorg.conf.

For example. on my netbook I have:

Section "InputClass"

Identifier  "SynPS/2 Synaptics TouchPad"

Option  "LeftEdge"  "1700"
Option  "RightEdge" "5700"
Option  "TopEdge"   "1700"
Option  "BottomEdge""5100"
Option  "FingerLow" "25"
Option  "FingerHigh""30"
Option  "MaxTapTime""180"
Option  "MaxTapMove""220"
Option  "VertScrollDelta"   "100"
Option  "MinSpeed"  "0.09"
Option  "MaxSpeed"  "0.6"
Option  "HorizEdgeScroll"   "true"
Option  "TapButton1""1"
Option  "SHMConfig" "true"
EndSection

Obviously these parameters may not be suitable for your touchpad, so
you will probably need to modify the entries. lshal should show you
the right Identifier string for your system. 

This is probably better (more fundamental) than using any xfce/gname/kde
tools that may or may not exist. Also likely to be more flexible.

This is not amd64 specific: rather an xorg question. I don't know a good
way to support the touchpad properly on standard (non-X) terminals: gpm
seems only to do treat the pad like a mouse.

ael


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110205163229.GB14722@conquest2.conquest

Re: touchscreen issue

[brian m. carlson]

On Sat, Feb 05, 2011 at 04:04:36PM +0100, Thierry Chatelet wrote:
> On Saturday 05 February 2011 14:37:02 dage...@free.fr wrote:
[configuring touchpad to click on tap]
> 
> You can set it from either gnome or kde desktop. For kde you need kde-config-
> touchpad, for gnome, no idea.

gpointing-device-settings may be helpful for GNOME.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: touchscreen issue

[Thierry Chatelet]

On Saturday 05 February 2011 14:37:02 dage...@free.fr wrote:
> Hello,
> 
> I don't really know where to ask for it. So I start on this list.
> 
> The touchpad of my laptop works well, but I can't make the
> "click on the touchpad works", meaning I must use the touchpad buttons
> to click, double-click and so on.
> If I select a file with the touchpad for example, and then tap on it
> with my finger, (or double tap), the file doesn't open.
> Hope I was clear in my explanation.
> 
> I use up-to-date Debian Squeeze amd 64 with packard bell easynote
>  LJ61 laptop.
> The touchpad is a synaptic. I tried to configure it with different
> tools but without success at all.
> For information this worked well on Debian ix86 version.
> 
> If you think this bug belongs to another list (ie Xorg list), please
> let me know.
> 
> Regards

You can set it from either gnome or kde desktop. For kde you need kde-config-
touchpad, for gnome, no idea.
Thierry


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201102051604.36705.tchate...@free.fr

Re: workstation for CUDA

[Lennart Sorensen]

On Mon, Jan 24, 2011 at 09:51:08PM +0100, Francesco Pietra wrote:
> I am planning to build a work station with FOUR PCI express Fermi GTX
> 470 boards for CUDA, to run on amd64 stable. Four GTX 470 is the only
> fixed hardware (Fermi Tesla has no advantage when single precision
> suffices as in my case for molecular dynamics; this implies that the
> intended software runs on GTX 470, like on Tesla). Thus, the culprit
> is the clock, not the RAM size. However, no overclock, as the
> computations may last weeks.
> 
>  I am asking advice about the mainboard and CPUs (overwriting
> intended). Also, if equipped with ECC RAM, it could also serve for
> double precision using the CPUs only.
> 
> What about:
> 
> Supermicro 4021 GA-62R+F (with power supply 1400W)

Max two video cards in that.  That's all it has space for.  I don't see
anything from supermicro that could run four GTX 470 cards.  I think
one system could run three, most only two.

> Two Amd Opteron Six Core 2427
> 
> Actually the Supermicro cage+power_source drains a lot of money (at
> least when imported to Europe) and I would prefer separate
> cage+main-board+power-source (provided they fit together; three years
> ago I assembled a Supermicro four-socket board starting from an old
> Chinese cage; it required a full week engineering the cage, which was
> for a smaller board)

Well if you just want it to work and fit well, you probably want to
stick with premade rack mount boxes.  I read an article a few days ago by
someone that was very happy with a supermicro box with tesla cards in it.

http://www.theregister.co.uk/2011/01/21/supermicro_server_render_farm/

One the the main advantages seems to be an excellent power supply.
Given how hard it can be to find quality power supplies, that's a pretty
big deal.  Rack mount does always drive up cost quite a bit though.

Now if you are not going rackmount, which given you mention workstation,
then things can be a lot more flexible and cheaper.

Something like an Asus P6T7 WS board should be able to run four GTX470
cards with a xeon 34xx or similar CPU with ECC memory.  Since the 470s
are dual slot cars, you need a board with four PCIe x16 slots spaced apart
to do it.  You also need a case with at least eight slot openings to fit
four dual slot cards, such as the Silverstone TJ11 for example (it has
ten openings for slots).

It would need something like a Corsair HX1000 or Turbo-Cool 1000 or 1200
to handle four video cards like that along with the system itself.
Certainly has to be a quality large power supply given each 470 takes
200W or so as far as I can tell.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110124225859.gd...@caffeine.csclub.uwaterloo.ca

Re: autodock packages

[Hendrik Boom]

On Wed, Jan 19, 2011 at 09:45:14PM +, brian m. carlson wrote:
> 
> > I (vaguely) know the reasons for all that, being intrinsic to the
> > rules of Debian. However, it remains that such deb compilations are a
> > waste of time from both the side of the maintainers and the users. I
> > hope a day will come when a general arrangement will be found to save
> > time from both sides.
> 
> If you think the package should not be included in a stable release,
> feel free to contact the package maintainer.  The volatile archive may
> be a more appropriate place for this.  It's really up to the maintainers
> whether they want to maintain it in volatile vs. stable.

Or maybe it belongs in backports?

-- hendrik


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110120013246.gb8...@topoi.pooq.com

Re: autodock packages

[brian m. carlson]

On Wed, Jan 19, 2011 at 09:55:49PM +0100, Francesco Pietra wrote:
> The suite autodock (docking small molecules onto a macromolecule) is a
> GNU fast evolving code. In Debian testing we find in fact the latest
> version 4.3. In Debian stable the autodock version is at 4.0, which is
> no more in use, drastically obsolete.

Why do you consider it obsolete?  Is the old version no longer
functional?  Does it use an outdated file format?  Does it output broken
results?  Does it have a security bug?

If the only reason it's "obsolete" is because there is a newer version
with more features, then you're probably not going to find a lot of
support for adding new versions to stable.

>  What that means? That one tries with binary offered by autodock. It
> may well not run, and in fact it does not on my
> amd6a/dualopteron-based machine.

The upstream binaries are for i386 and ia64.  Neither one of those is
amd64, although it's possible that the i386 binary may run with
ia32-libs installed.

> I (vaguely) know the reasons for all that, being intrinsic to the
> rules of Debian. However, it remains that such deb compilations are a
> waste of time from both the side of the maintainers and the users. I
> hope a day will come when a general arrangement will be found to save
> time from both sides.

If you think the package should not be included in a stable release,
feel free to contact the package maintainer.  The volatile archive may
be a more appropriate place for this.  It's really up to the maintainers
whether they want to maintain it in volatile vs. stable.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: debian system can't boot on "hp 385 g7" server

[Fabricio Cannini]

Em Quarta-feira 19 Janeiro 2011, às 13:13:21, kechen zhang escreveu:
> hello my friend,
>  i'm sorry to bother you,but i need your help ,and i don't know who
> can help me ...
>  Our company have bought 3 servers ,  " hp 385 g7 " , but there's
>  something wrong  after  i have installed   the debian lenny509,  when i
> reboot the box, the system stop at "booting the kernel " ,and uring the
> installing of finding the network, i met the problem "miss the file
> bnx2-09-4.0.5.fw ",then i can't drive the network card，i skipped,i think
> that don't matter,what's you opinion?
> all the servers meet the same problem,i guess that may related with the
> CPU (AMD Opteron 6136), if not ,could you tell me what's the problem or
> something could help me .
> i have called   HP support ,but they said they haven't tried to
> install  Debian on this server.
> and could you tell me why can't debian install on some kinds of
> servers. thank you for your help .
> 
> Marshall Zhang

Hi!

Does the servers have a Broadcom NetXtreme II ethernet card?
If yes, do you have the 'firmware-bnx2' packaged installed?

I did install lenny in a dell that have this card, but it didn't cause the 
boot process to freeze.


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101191516.20767.fcann...@gmail.com

Re: debian system can't boot on "hp 385 g7" server

[Daniel Urbancik, Jr]

hi... Have you upgraded all firmware via RILO? Try to downoad all
newest firmware for linux, for raid controller, nw stuff, etc, uptade
it via RILO and then reboot. What raid controller are you using? Just
on mobo or some addon? d.

On 1/19/11, kechen zhang  wrote:
> hello my friend,
>  i'm sorry to bother you,but i need your help ,and i don't know who
> can help me ...
>  Our company have bought 3 servers ,  " hp 385 g7 " , but there's
>  something wrong  after  i have installed   the debian lenny509,  when i
> reboot the box, the system stop at "booting the kernel " ,and uring the
> installing of finding the network, i met the problem "miss the file
> bnx2-09-4.0.5.fw ",then i can't drive the network card，i skipped,i think
> that don't matter,what's you opinion?
> all the servers meet the same problem,i guess that may related with the
> CPU (AMD Opteron 6136), if not ,could you tell me what's the problem or
> something could help me .
> i have called   HP support ,but they said they haven't tried to
> install  Debian on this server.
> and could you tell me why can't debian install on some kinds of servers.
>thank you for your help .
>
> Marshall Zhang
>


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimu05tc+jzcxvzi-ypqjic1e4uthcwwpqnv_...@mail.gmail.com

Re: help getting grub to see Windows 7 on second drive

[Lennart Sorensen]

On Fri, Dec 10, 2010 at 04:45:00PM +, A J Stiles wrote:
> Sort of makes you wonder why the EU haven't already made it a legal 
> requirement for hardware manufacturers to supply driver Source Code, if they 
> want to sell their products in any European country.  How much otherwise 
> perfectly serviceable kit do you think is ending up in landfill for want of 
> drivers?

Linksys WMP54G cards have no drivers for Windows 7, even though ralink
(make of the chip in v4 and v4.1 cards) has windows 7 drivers available
(which can even be installed if you force them and do work).  Does linksys
care?  Nope, not one bit.  ATI has a long history of not supporting
hardware with drivers if it is more than 2 or 3 years old.  For that
matter the FireGL V3350 cards which are still for sale have no support
under linux from ATI anymore.  What's with that?  OK the drivers were
buggy shit when they did support it, but still better than not supported
at all.

Of course linux users have no problem using the cards at all.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101210185526.gs12...@caffeine.csclub.uwaterloo.ca