Re: Compatibility with Dell PowerEdge R250

[Andrew M.A. Cater]

On Fri, Jul 07, 2023 at 09:40:33AM +0300, Hassen Ibrahim wrote:
> Greetings,
> 
> I just purchased a Dell PowerEdge R250 server and was wondering if debian
> 10 is compatible with this server. The server has an Intel Xeon E-2334
> processor, 32GB RAM and 6TB storage. I'll be looking forward to hearing
> from you.
> 
> Best regards
> Hassen Mulugeta

Hi 

That should be fine: is there any reason specifically why you must use 
Debian 10 since this is now beyond end of life and is supported only
by the LTS team (and will be out of support by them within a year)?

It might be better to use Debian 12 (Bookworm)

See also https://wiki.debian.org/DebianReleases#Production_Releases

With every good wish,  as ever,

Andy Cater

Compatibility with Dell PowerEdge R250

[Hassen Ibrahim]

Greetings,

I just purchased a Dell PowerEdge R250 server and was wondering if debian
10 is compatible with this server. The server has an Intel Xeon E-2334
processor, 32GB RAM and 6TB storage. I'll be looking forward to hearing
from you.

Best regards
Hassen Mulugeta

Re: [bullseye] ganglia-monitor-python compatibility

[Dan Ritter]

Bardo Bardo wrote: 
> Hi,
> 
> Ganglia has some useful monitoring plugins such as diskstat, mysql,
> postgresql, elasticsearch, advanced cpu metrics, ... i'm using theses
> metrics for years, but since Debian 11 these modules are no longer
> available,
> Is there any idea why the package Ganglia Python Modules
>  is no longer
> supported on Debian Bullseye ? Is this a kernel incompatibility issue or
> Python related problem ? Is there a workaround solution to use some of
> these monitoring plugins ?


Looking through the mailing list and
https://tracker.debian.org/pkg/ganglia

I suspect that it did not have an active maintainer at the time
that bullseye was being assembled, and it had enough problems
that it did not make it into that release. There is a new
maintainer as of last year, but it doesn't look like much
activity has happened since.

-dsr-

[bullseye] ganglia-monitor-python compatibility

[Bardo Bardo]

Hi,

Ganglia has some useful monitoring plugins such as diskstat, mysql,
postgresql, elasticsearch, advanced cpu metrics, ... i'm using theses
metrics for years, but since Debian 11 these modules are no longer
available,
Is there any idea why the package Ganglia Python Modules
 is no longer
supported on Debian Bullseye ? Is this a kernel incompatibility issue or
Python related problem ? Is there a workaround solution to use some of
these monitoring plugins ?

Thanks and have a nice day :)
--

how to check compatibility of (any party) package file? (and more)

[Patrice Duroux]

Hi,

My purpose is multiple here.

First, I am trying to build a tool[1] to check a given package file (ie a
.deb, whatever its origin) for the compatibility with Debian distribution
versions, including if it may be required to have more sections (contrib,
non-free) or a backports pool.
I am able to extract some field values (package, version, architecture,
depends) and check the compatibility of some of the values with my current
host system (using . deb-dpkg and dpkg).
I am currently stuck to check the depends value.
Is there any facility for this: 1. on my local system (using some
commands)? 2. on all the Debian systems (using rmadison or some ad-hock UDD
queries)?
Check the value as a whole or iterate all its elements, deal with the
version constraint, etc..

Second, would it be useful to maintain a website (database + webui) where
to identify those package files not part of a known (Debian or famous 3rd)
repository.
I am thinking of this for a better / improved deb-get[2] project and a
robot to maintain the database content.

Third, expose the first tool as a webservice where to post a .deb file and
get all the Debian distribution versions it is compatible with? Or maybe
get the corresponding apt source configuration required (ie. the context)
required to be able to install the package?
Is piuparts able to determine or setup an adequate Debian container such to
install a given package?

Thanks,
Patrice

[1] as simple as a shell script if possible
[2] https://github.com/wimpysworld/deb-get

Re: Compatibility of Debian 9 compiled files in Debian 11 version

[David Christensen]

On 2/10/22 09:54, Nagaraju Mulpuri wrote:

Dear Debian Users,
Greetings of the day!
I have been using Debian 9 version for the last 4 years. Recently, my computer 
crashed. I have to install Debian OS again. I am planning to install Debian 11 
version. I have many of my own programs compiled on the Debian 9 version. 
Compiled programs in Debian 9 version will support in Devian 11 version? Or, 
should I go with Debian 9 version?

Thank you very much.
Have a great day!
Best regards,
Raju



Doing both disaster recovery and a (two) major version upgrade 
simultaneously sounds more complex that doing one or the other alone. 
Given the first is required, I would do a fresh install of Debian 9 onto 
a blank SSD and do the disaster recovery.



David

Re: Compatibility of Debian 9 compiled files in Debian 11 version

[Andrew M.A. Cater]

On Thu, Feb 10, 2022 at 05:54:08PM -, Nagaraju Mulpuri wrote:
> Dear Debian Users,
> Greetings of the day!
> I have been using Debian 9 version for the last 4 years. Recently, my 
> computer crashed. I have to install Debian OS again. I am planning to install 
> Debian 11 version. I have many of my own programs compiled on the Debian 9 
> version. Compiled programs in Debian 9 version will support in Devian 11 
> version? Or, should I go with Debian 9 version?
> 
> Thank you very much.
> Have a great day!
> Best regards,
> Raju

Hi Raju

If your programs are your own: what language are they written in - and
did you have them backed up?

I suspect the problem you may have is if they are in older versions of
Python - otherwise, C or C++ should work.

Be aware that some programs may be more memory hungry / larger in Debian 11
but otherwise there shouldn't be a problem.

I would respectfully suggest starting from the unofficial non-free .iso file
to give yourself a head start with any needed firmware.

All the very best, as ever,

Andy Cater

Re: Compatibility of Debian 9 compiled files in Debian 11 version

[Greg Wooledge]

On Thu, Feb 10, 2022 at 05:54:08PM -, Nagaraju Mulpuri wrote:
> I have been using Debian 9 version for the last 4 years. Recently, my 
> computer crashed. I have to install Debian OS again. I am planning to install 
> Debian 11 version. I have many of my own programs compiled on the Debian 9 
> version. Compiled programs in Debian 9 version will support in Devian 11 
> version? Or, should I go with Debian 9 version?

If the shared libraries that they're linked against still exist, they'll
work.  Most likely.

The question is whether those shared libraries will be present on a clean
installation of Debian 11.  We can't guess without knowing more about
your programs.

You can try it and see.  If one of the programs fails to run, try using
ldd on it to see what shared libraries it's missing.  Then, based on
the knowledge you gain this way, you can decide whether it'll be easier
to recompile them on Debian 11, or to launch an archaeological expedition
to try to find the necessary shared libraries.

Re: Compatibility of Debian 9 compiled files in Debian 11 version

[tomas]

On Thu, Feb 10, 2022 at 05:54:08PM -, Nagaraju Mulpuri wrote:
> Dear Debian Users,
> Greetings of the day!
> I have been using Debian 9 version for the last 4 years. Recently, my 
> computer crashed.
> I have to install Debian OS again. I am planning to install Debian 11 
> version. I have
> many of my own programs compiled on the Debian 9 version. Compiled programs 
> in Debian 9
> version will support in Devian 11 version? Or, should I go with Debian 9 
> version?

Most probably not. But you might be lucky, sometimes.

Why not compile them again?

Cheers
-- 
t


signature.asc
Description: PGP signature

Compatibility of Debian 9 compiled files in Debian 11 version

[Nagaraju Mulpuri]

Dear Debian Users,
Greetings of the day!
I have been using Debian 9 version for the last 4 years. Recently, my computer 
crashed. I have to install Debian OS again. I am planning to install Debian 11 
version. I have many of my own programs compiled on the Debian 9 version. 
Compiled programs in Debian 9 version will support in Devian 11 version? Or, 
should I go with Debian 9 version?

Thank you very much.
Have a great day!
Best regards,
Raju

Re: btfs disk compatibility between i386 and amd64

[Andrei POPESCU]

On Vi, 28 ian 22, 17:44:59, Joseph Brenner wrote:
> > Careful, unlink in the *nix world typically means delete (a file), while
> you probably meant unmount / mount.
> 
> Yes, precisely.
> 
> 
> > In general there shouldn't be a problem for newer kernels to read older
> versions of a particular file system[1], but the other way around can be
> a problem.
> 
> That's interesting in itself.  Makes some sense.
> 
> On 1/28/22, Andrei POPESCU  wrote:
> > On Mi, 26 ian 22, 17:33:04, Joseph Brenner wrote:
> >> I was wondering if the on-disk data format for btrfs is
> >> compatible between the i386 and amd64 code bases--
> >> e.g. would you expect to be able to swap data drives
> >> between machines running either?
> >
> > In general yes.
> >
> >> I've got an old i386 installation with /home in it's
> >> own partition, and I'm wondering if I can expect to just
> >> unlink /home and install a new amd64 version, and then link
> >> in the home parition again.

Later I realised my answer doesn't directly address your query regarding 
i386 (32 bits) -> amd64 (64 bits).

In general I would expect a 64 bit kernel (could also be arm64) to be 
able to deal with a file system created by a 32 bit kernel. In case 
there are any limitations they are likely to appear the other way 
around, e.g. a file system created on a 64 bit system *might* have some 
internals that can't be dealt with by a 32 bit kernel. Again, such 
limitations should be thoroughly documented.

In any case, just trying to mount the file system (read-only if you want 
to be extra careful) with an eye on 'dmesg -w' should be enough. If 
there are problems the kernel should simply refuse to mount it.

As with anything dealing with possibly irreplaceable data, you should 
have good backups. Could you recover your data if you format and 
overwrite the partition by mistake?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: btfs disk compatibility between i386 and amd64

[Joseph Brenner]

> Careful, unlink in the *nix world typically means delete (a file), while
you probably meant unmount / mount.

Yes, precisely.


> In general there shouldn't be a problem for newer kernels to read older
versions of a particular file system[1], but the other way around can be
a problem.

That's interesting in itself.  Makes some sense.

Thanks much.



On 1/28/22, Andrei POPESCU  wrote:
> On Mi, 26 ian 22, 17:33:04, Joseph Brenner wrote:
>> I was wondering if the on-disk data format for btrfs is
>> compatible between the i386 and amd64 code bases--
>> e.g. would you expect to be able to swap data drives
>> between machines running either?
>
> In general yes.
>
>> I've got an old i386 installation with /home in it's
>> own partition, and I'm wondering if I can expect to just
>> unlink /home and install a new amd64 version, and then link
>> in the home parition again.
>
> Careful, unlink in the *nix world typically means delete (a file), while
> you probably meant unmount / mount.
>
>
> In general there shouldn't be a problem for newer kernels to read older
> versions of a particular file system[1], but the other way around can be
> a problem.
>
> More than that, as far as I recall some newer kernels would
> automatically enable some new features thus rendering the particular
> file system unreadable for older kernels[2].
>
> In any case, this should be very well documented for every file system,
> so you should check the btrfs documentation for that.
>
>
> [1] In this context I consider the various ext file systems to be
> different file systems, not different versions of the same file system,
> although they do have much more in common between them then with xfs or
> so.
>
> [2] I believe this was with ext4, but it could have been ext3
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscr...@kzsu.stanford.edu.
>

Re: btfs disk compatibility between i386 and amd64

[Andrei POPESCU]

On Mi, 26 ian 22, 17:33:04, Joseph Brenner wrote:
> I was wondering if the on-disk data format for btrfs is
> compatible between the i386 and amd64 code bases--
> e.g. would you expect to be able to swap data drives
> between machines running either?
 
In general yes.

> I've got an old i386 installation with /home in it's
> own partition, and I'm wondering if I can expect to just
> unlink /home and install a new amd64 version, and then link
> in the home parition again.

Careful, unlink in the *nix world typically means delete (a file), while 
you probably meant unmount / mount.


In general there shouldn't be a problem for newer kernels to read older 
versions of a particular file system[1], but the other way around can be 
a problem.

More than that, as far as I recall some newer kernels would 
automatically enable some new features thus rendering the particular 
file system unreadable for older kernels[2].

In any case, this should be very well documented for every file system, 
so you should check the btrfs documentation for that.


[1] In this context I consider the various ext file systems to be 
different file systems, not different versions of the same file system, 
although they do have much more in common between them then with xfs or 
so.

[2] I believe this was with ext4, but it could have been ext3

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

btfs disk compatibility between i386 and amd64

[Joseph Brenner]

I was wondering if the on-disk data format for btrfs is
compatible between the i386 and amd64 code bases--
e.g. would you expect to be able to swap data drives
between machines running either?

I've got an old i386 installation with /home in it's
own partition, and I'm wondering if I can expect to just
unlink /home and install a new amd64 version, and then link
in the home parition again.

Re: processor compatibility

[Georgi Naplatanov]

On 11/13/21 22:39, deutsch_da...@tuta.io wrote:
> Hello! Is the Intel Core i7-9750H processor supported by your operating
> system?
> 

Hi!

The architecture of this processor is AMD64 so it's supported and you
can use this image -

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.1.0+nonfree/amd64/iso-cd/firmware-11.1.0-amd64-netinst.iso

Kind regards
Georgi

Re: processor compatibility

[Andy Smith]

Hello,

On Sat, Nov 13, 2021 at 09:39:16PM +0100, deutsch_da...@tuta.io wrote:
> Hello! Is the Intel Core i7-9750H processor supported by your operating 
> system?

I don't have one but this suggests yes:

https://linux-hardware.org/index.php?id=cpu:intel-6-158-10-core-i7-9750h

That CPU is a couple of years old now so I would not expect it to
have any feature or quirk that makes it difficult to use with Linux,
and the many pages of Linux distributions there that say they work
support that.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

processor compatibility

[deutsch_danya]

Hello! Is the Intel Core i7-9750H processor supported by your operating system?

-- 
.

Re: 64bit ext4 and kernel version compatibility

[R. Ramesh]

On 1/9/20 2:02 AM, Klaus Singvogel wrote:

R. Ramesh wrote:

I want to make sure
that my current kernel version does not have any limitation to support 64bit
ext4.

Please consult the Kernel Wiki regarding Ext4:

https://ext4.wiki.kernel.org/index.php/Main_Page

You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
which was released a quiet long time ago (around 2009). As your
distribution is running 3.13.0-132-generic, the support of ext4 should be
no problem (never tested it to be 100% sure).

Another important information I was missing of: the machine architecture
of your processor; whether you're running a 64bit kernel or 32bit kernel.

"uname -m" will tell you, if you have 64bit, like in "x86_64", or not.

I'm very unsure, if your processor is able to address such files. PAE
extension (32 bit) of Intel architecture supports it, but not sure about
other archs, like Raspberry Pi v1 has.

Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if
this machine connects or is connectable from the internet, due to security
reasons.

Regards,
Klaus.

Klaus,

  Thanks for your help. The last time I tried to upgrade to 16.04, my 
mythtv broke. I am sure I made some mistakes. I will ry once 20.04 is 
released to do a fresh install rather than upgrade from 14.04. That way 
I will manually install mythtv and do a database backup and restore. I 
have been lazy and not doing it right. This time I will be more thorough.


  May be I should delay 64bit conversion until then. Let me see, if I 
can manage delaying it till summer.


Regards
Ramesh

Re: Re: 64bit ext4 and kernel version compatibility

[R. Ramesh]

On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote:
> On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > > Before I get the source and build and update e2fsprogs and then the
> > > file system, I want to make sure that my current kernel version does
> > > not have any limitation to support 64bit ext4.
> > 
> > You kernel should support the feature, as it was introduced back at the

> > version 3.6 of the kernel - [1].
> > 
> > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
> 
> That web page is talking about metadata checksums I can't see anything

> about '64-bit'.

Let me read it for you (note kernel version):

Install Linux 3.6+ and e2fsprogs 1.43-WIP.
modprobe crc32c-intel
mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk


To enable "metadata_csum" in its full glory one needs to enable "64bit"
fs feature:

In a perfect world, one could simply enable metadata checksums ...
Therefore, it is best to start by formatting a fresh
filesystem with 64-bit support enabled ...


>What I'm assuming the OP is interested is 64-bit block numbers because
>they said they want to "convert ext4 fs on this server to 64bit so that
>I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 =
>16TB, so block numbers whould need to be more than 32-bit for bigger
>drives.

Same page says:

Therefore, it is best to start by formatting a fresh filesystem with
64-bit support enabled, since it is not possible to upgrade a 32-bit
filesystem to a 64-bit filesystem.


So if "convert" = "mkfs", then OP is fully set.
But then again, it's nothing that can't be solved by pre-existing
backup.

Reco


Reco,

  Thanks for the details. I do not know why, for a moment I thought 3.6 
> 3.13 (must have been treating version numbers as floating point 
numbers :-)


  No I do not plan to convert/grow in place. I have 2x8tb disks (and 
several other 4TB disks) for making backup. I will back up each md that 
is less than 16TB (separately) and make them 64bit first. After that I 
will grow them as needed.


Regards
Ramesh

Re: 64bit ext4 and kernel version compatibility

[Reco]

On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote:
> On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > > Before I get the source and build and update e2fsprogs and then the
> > > file system, I want to make sure that my current kernel version does
> > > not have any limitation to support 64bit ext4.
> > 
> > You kernel should support the feature, as it was introduced back at the
> > version 3.6 of the kernel - [1].
> > 
> > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
> 
> That web page is talking about metadata checksums I can't see anything
> about '64-bit'.

Let me read it for you (note kernel version):

Install Linux 3.6+ and e2fsprogs 1.43-WIP.
modprobe crc32c-intel
mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk


To enable "metadata_csum" in its full glory one needs to enable "64bit"
fs feature:

In a perfect world, one could simply enable metadata checksums ...
Therefore, it is best to start by formatting a fresh
filesystem with 64-bit support enabled ...


>What I'm assuming the OP is interested is 64-bit block numbers because
>they said they want to "convert ext4 fs on this server to 64bit so that
>I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 =
>16TB, so block numbers whould need to be more than 32-bit for bigger
>drives.

Same page says:

Therefore, it is best to start by formatting a fresh filesystem with
64-bit support enabled, since it is not possible to upgrade a 32-bit
filesystem to a 64-bit filesystem.


So if "convert" = "mkfs", then OP is fully set.
But then again, it's nothing that can't be solved by pre-existing
backup.

Reco

Re: 64bit ext4 and kernel version compatibility

[Tixy]

On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > Before I get the source and build and update e2fsprogs and then the
> > file system, I want to make sure that my current kernel version does
> > not have any limitation to support 64bit ext4.
> 
> You kernel should support the feature, as it was introduced back at the
> version 3.6 of the kernel - [1].
> 
> Reco
> 
> [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

That web page is talking about metadata checksums I can't see anything
about '64-bit'. What I'm assuming the OP is interested is 64-bit block
numbers because they said they want to "convert ext4 fs on this server
to 64bit so that I can grow it past 16TB limit". Note from me, 4kB
sized blocks * 2^32 = 16TB, so block numbers whould need to be more
than 32-bit for bigger drives.

-- 
Tixy

Re: 64bit ext4 and kernel version compatibility

[Reco]

Hi.

On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> Before I get the source and build and update e2fsprogs and then the
> file system, I want to make sure that my current kernel version does
> not have any limitation to support 64bit ext4.

You kernel should support the feature, as it was introduced back at the
version 3.6 of the kernel - [1].

Reco

[1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

Re: 64bit ext4 and kernel version compatibility

[Tixy]

On Thu, 2020-01-09 at 09:02 +0100, Klaus Singvogel wrote:
> R. Ramesh wrote:
> > I want to make sure
> > that my current kernel version does not have any limitation to support 64bit
> > ext4.
> 
> Please consult the Kernel Wiki regarding Ext4:
> 
>   https://ext4.wiki.kernel.org/index.php/Main_Page
> 
> You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
> which was released a quiet long time ago (around 2009). As your
> distribution is running 3.13.0-132-generic, the support of ext4 should be
> no problem (never tested it to be 100% sure).

But features keep getting added to filesystems as time goes by and it's
quite possible that support for 64-bit block numbers wasn't included
from the start. The man page for e2fsprogs says this about the '64bit'
option: "Note that some older kernels and older versions of e2fsprogs
will not support file systems with this ext4 feature enabled"

-- 
Tixy

Re: 64bit ext4 and kernel version compatibility

[Klaus Singvogel]

R. Ramesh wrote:
> I want to make sure
> that my current kernel version does not have any limitation to support 64bit
> ext4.

Please consult the Kernel Wiki regarding Ext4:

https://ext4.wiki.kernel.org/index.php/Main_Page

You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
which was released a quiet long time ago (around 2009). As your
distribution is running 3.13.0-132-generic, the support of ext4 should be
no problem (never tested it to be 100% sure).

Another important information I was missing of: the machine architecture
of your processor; whether you're running a 64bit kernel or 32bit kernel.

"uname -m" will tell you, if you have 64bit, like in "x86_64", or not.

I'm very unsure, if your processor is able to address such files. PAE
extension (32 bit) of Intel architecture supports it, but not sure about
other archs, like Raspberry Pi v1 has.

Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if
this machine connects or is connectable from the internet, due to security
reasons.

Regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

64bit ext4 and kernel version compatibility

[R. Ramesh]

Hi,

  On my DVR, I am running fairly old version of kernel 
(3.13.0-132-generic, mythbuntu 14.04.5 LTS). I want to convert ext4 fs 
on this server to 64bit so that I can grow it past 16TB limit. At that 
time of installation (2014), e2fsprogs did not support 64bit fs.  Now it 
does. Before I get the source and build and update e2fsprogs and then 
the file system, I want to make sure that my current kernel version does 
not have any limitation to support 64bit ext4.   My google searches do 
not mention any kernel limitations. I think this is due to my inability 
to ask the right question to google. Appreciate any help I can get on 
answering my question.


At this time it is difficult for me to upgrade the kernel without 
updating the distribution (and hence mythtv) and that path is beyond me 
at this time due to time constraints.


Ramesh

Re: Compatibility with DELL PowerEdge R440 Server

[Sven Hartge]

Aylwin  wrote:

> I am planning to order 4 units of Dell PowerEdge R440 Servers
>  .

> Can you please advise me if Debian 9 64-bit can be installed without
> any conflicts.

If you plan on using the PERC RAID controller, you will most likely need
to use 4.19 as your kernel.

I can only vouch for Debian 10 working without problems in R440, I have
not tested Debian 9, as I see no benefit from installing the Oldstable
release at this point in time.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Compatibility with DELL PowerEdge R440 Server

[john doe]

On 10/21/2019 3:29 PM, Aylwin wrote:
> Hi,
>
>
>
> I am planning to order 4 units of Dell PowerEdge R440 Servers
>  .
>
>
>
> Can you please advise me if Debian 9 64-bit can be installed without any
> conflicts.
>

Do you realy insist on oldstable (Debian 9 Stretch) or can you cope with
stable (Debian 10 Buster)?

--
John Doe

Compatibility with DELL PowerEdge R440 Server

[Aylwin]

Hi,

 

I am planning to order 4 units of Dell PowerEdge R440 Servers
 .

 

Can you please advise me if Debian 9 64-bit can be installed without any
conflicts.

 

Thanks and looking forward to your reply.

 

Best regards,

Aylwin

Sales & Operations Manager,

South East Asia

 

-

 

RugGear Mobile Pte Ltd

1014 Geylang East Ave 3,

#05-198, Singapore 389729

Tel : +65 6687 4158

HP : +65 9220 1990

 

Email :   ayl...@ruggear.com.sg

Web : www.ruggear.com.sg

 

Re: Old problem for hardware compatibility: Thinkpad Lenovo SL400 Camera

[Miguel A . Díaz D .]

Exactly. Currently I use Debian 9. I have not found a single way to put
work my camera since Debian 7.

El dom., 12 may. 2019 a las 11:48, Cindy Sue Causey (<
butterflyby...@gmail.com>) escribió:

> On 5/12/19, Georgi Naplatanov  wrote:
> > On 5/12/19 2:13 AM, Miguel A. Díaz D. wrote:
> >> Dear Debian team,
> >>
> >> I would like to know if it is possible put to work the camera of an
> >> old Thinkpad Lenovo SL400 laptop. I have seen this issue in old posts
> >> for Ubuntu but a real solution is not reached. There is no way to solve
> >> this? I have read that driver was only available for Microsoft Windows
> >> Vista OS.
> >
> > Did you try this
> >
> > https://ubuntuforums.org.
>
>
> The impression I got from the original post was that the Linux user
> was looking for a *Debian* alternative solution... not being
> redirected back to "ubuntu"... particularly since the request for
> insight was posted here on the... *Debian*-User listserv. :)
>
> Cindy :)
> --
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
>
> * runs with.. a fresh, very Happy USER-FRIENDLY Debian debootstrap *
>
>

Re: Old problem for hardware compatibility: Thinkpad Lenovo SL400 Camera

[Cindy Sue Causey]

On 5/12/19, Georgi Naplatanov  wrote:
> On 5/12/19 2:13 AM, Miguel A. Díaz D. wrote:
>> Dear Debian team,
>>
>> I would like to know if it is possible put to work the camera of an
>> old Thinkpad Lenovo SL400 laptop. I have seen this issue in old posts
>> for Ubuntu but a real solution is not reached. There is no way to solve
>> this? I have read that driver was only available for Microsoft Windows
>> Vista OS.
>
> Did you try this
>
> https://ubuntuforums.org.


The impression I got from the original post was that the Linux user
was looking for a *Debian* alternative solution... not being
redirected back to "ubuntu"... particularly since the request for
insight was posted here on the... *Debian*-User listserv. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with.. a fresh, very Happy USER-FRIENDLY Debian debootstrap *

Re: Old problem for hardware compatibility: Thinkpad Lenovo SL400 Camera

[Georgi Naplatanov]

On 5/12/19 2:13 AM, Miguel A. Díaz D. wrote:
> Dear Debian team,
> 
> I would like to know if it is possible put to work the camera of an
> old Thinkpad Lenovo SL400 laptop. I have seen this issue in old posts
> for Ubuntu but a real solution is not reached. There is no way to solve
> this? I have read that driver was only available for Microsoft Windows
> Vista OS.

Did you try this

https://ubuntuforums.org/showthread.php?t=1056511

Kind regards
Georgi

Old problem for hardware compatibility: Thinkpad Lenovo SL400 Camera

[Miguel A . Díaz D .]

Dear Debian team,

I would like to know if it is possible put to work the camera of an
old Thinkpad Lenovo SL400 laptop. I have seen this issue in old posts for
Ubuntu but a real solution is not reached. There is no way to solve this? I
have read that driver was only available for Microsoft Windows Vista OS.

Thanks in advance for any information you could give.

Sincereley,

Miguel A. Díaz D.

Re: unison compatibility in stretch

[Eric S Fraga]

On Friday, 29 Dec 2017 at 11:27, Tony van der Hoff wrote:

[...]

> Syncthing appears to be an extremely powerful file synchronization tool,

[...]

> I've decided to give up on Syncthing, and revert to Unison, which means
> upgrading my server, but hey, what are holidays for?

Thanks for the update.  Your experience may be what I ran into when I
tried syncthing a long time ago; I cannot remember why I gave up on it
but it may have had to do with a complex network setup at home...

Let's hope that unison doesn't get out of sync (no pun intended) for you
too soon again!

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.5


signature.asc
Description: PGP signature

Re: unison compatibility in stretch

[Tony van der Hoff]

On 13/12/17 17:49, Tony van der Hoff wrote:
> On 13/12/17 17:29, Anders Andersson wrote:
>> On Wed, Dec 13, 2017 at 5:44 PM, Tony van der Hoff  
>> wrote:
>>> On 13/12/17 15:40, Curt wrote:
 Sorry for butting in once again, but you do have unison-all installed,
 the metapackage which allows specifically for the -addversionno "kludge" by
 bringing in versions 2.32 and 2.40 as per the following post curiously
 similar to your case (two machines, one with Debian Jessie and one with
 Debian Stretch)

 https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system

 and then working around the eventual minor version number truncation
 bug, if indeed it still exists, as per my previous cryptic message.

>>>  I'm fed up with trying bodgy work-arounds, which really should not be
>>> required. I have now spent so much time on this issue that I've become
>>> thoroughly disenchanted with Unison (which is great when it works) that
>>> I'm taking my custom elsewhere.
>> Do you have a good alternative? I'm fed up with Unison since a long
>> time, because of such an important tool not handling different
>> versions, and the impracticality of writing it in yet another
>> experimental language requiring its own complete little world to build
>> and run.
>>
> As mentioned upthread, "Syncthing" [https://docs.syncthing.net] seems to
> do much the same as Unison, hopefully more sensibly. I'm going to give
> it a try over the next few days, and I'll report back here.
>
Well, "the next few days" turned out to be a drawn-out frustrating
struggle, with no benefit.

Syncthing appears to be an extremely powerful file synchronization tool,
with an emphasis on security, which in theory would make it an excellent
replacement for unison. However, after many days struggling wit its
configuration through two firewalls and a NAT router, trying to
synchronize 3 systems, with more to add, I've given up. The machines
appear to connect, and some meta-data is transferred, but no data
transfers take place.

I've decided to give up on Syncthing, and revert to Unison, which means
upgrading my server, but hey, what are holidays for?

Cheers, Tony

Re: unison compatibility in stretch

[Tony van der Hoff]

On 13/12/17 17:29, Anders Andersson wrote:
> On Wed, Dec 13, 2017 at 5:44 PM, Tony van der Hoff  
> wrote:
>> On 13/12/17 15:40, Curt wrote:
>>> Sorry for butting in once again, but you do have unison-all installed,
>>> the metapackage which allows specifically for the -addversionno "kludge" by
>>> bringing in versions 2.32 and 2.40 as per the following post curiously
>>> similar to your case (two machines, one with Debian Jessie and one with
>>> Debian Stretch)
>>>
>>> https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system
>>>
>>> and then working around the eventual minor version number truncation
>>> bug, if indeed it still exists, as per my previous cryptic message.
>>>
>>  I'm fed up with trying bodgy work-arounds, which really should not be
>> required. I have now spent so much time on this issue that I've become
>> thoroughly disenchanted with Unison (which is great when it works) that
>> I'm taking my custom elsewhere.
> Do you have a good alternative? I'm fed up with Unison since a long
> time, because of such an important tool not handling different
> versions, and the impracticality of writing it in yet another
> experimental language requiring its own complete little world to build
> and run.
>
As mentioned upthread, "Syncthing" [https://docs.syncthing.net] seems to
do much the same as Unison, hopefully more sensibly. I'm going to give
it a try over the next few days, and I'll report back here.

Re: unison compatibility in stretch

[Anders Andersson]

On Wed, Dec 13, 2017 at 5:44 PM, Tony van der Hoff  wrote:
> On 13/12/17 15:40, Curt wrote:
>> Sorry for butting in once again, but you do have unison-all installed,
>> the metapackage which allows specifically for the -addversionno "kludge" by
>> bringing in versions 2.32 and 2.40 as per the following post curiously
>> similar to your case (two machines, one with Debian Jessie and one with
>> Debian Stretch)
>>
>> https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system
>>
>> and then working around the eventual minor version number truncation
>> bug, if indeed it still exists, as per my previous cryptic message.
>>
>  I'm fed up with trying bodgy work-arounds, which really should not be
> required. I have now spent so much time on this issue that I've become
> thoroughly disenchanted with Unison (which is great when it works) that
> I'm taking my custom elsewhere.

Do you have a good alternative? I'm fed up with Unison since a long
time, because of such an important tool not handling different
versions, and the impracticality of writing it in yet another
experimental language requiring its own complete little world to build
and run.

Re: unison compatibility in stretch

[Tony van der Hoff]

On 13/12/17 15:40, Curt wrote:
> On 2017-12-13, Tony van der Hoff  wrote:
>> It seems the unison developers are a little careless with compatibility
>> issues. This situation has arisen previously, then overcome by unison-all.
>>
>> Thanks for your suggestion of syncthing; I'll give that a go...
> Sorry for butting in once again, but you do have unison-all installed,
> the metapackage which allows specifically for the -addversionno "kludge" by
> bringing in versions 2.32 and 2.40 as per the following post curiously
> similar to your case (two machines, one with Debian Jessie and one with
> Debian Stretch)
>
> https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system
>
> and then working around the eventual minor version number truncation
> bug, if indeed it still exists, as per my previous cryptic message.
>
Yes, thanks Curt. I have unison-all installed, and I've seen that post,
and followed the suggestions, without success. Unison-all is simply a
meta-package, which depennds on all available unison versions. Since
stretch only has 6.40 in its repo, it can only pull that one in.

 I'm fed up with trying bodgy work-arounds, which really should not be
required. I have now spent so much time on this issue that I've become
thoroughly disenchanted with Unison (which is great when it works) that
I'm taking my custom elsewhere.

Re: unison compatibility in stretch

[Curt]

On 2017-12-13, Tony van der Hoff  wrote:
>>
> It seems the unison developers are a little careless with compatibility
> issues. This situation has arisen previously, then overcome by unison-all.
>
> Thanks for your suggestion of syncthing; I'll give that a go...

Sorry for butting in once again, but you do have unison-all installed,
the metapackage which allows specifically for the -addversionno "kludge" by
bringing in versions 2.32 and 2.40 as per the following post curiously
similar to your case (two machines, one with Debian Jessie and one with
Debian Stretch)

https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system

and then working around the eventual minor version number truncation
bug, if indeed it still exists, as per my previous cryptic message.

> Cheers, Tony
>
>


-- 
"The world is full of shipping clerks who have read the Harvard Classics."
— Charles Bukowski

Re: unison compatibility in stretch

[Tony van der Hoff]

On 13/12/17 13:35, Eric S Fraga wrote:
> On Wednesday, 13 Dec 2017 at 12:49, Tony van der Hoff wrote:
>
> [...]
>
> unison is a fantastic tool but these incompatibilities make it
> incredibly frustrating to use every now and again.
>
> You could consider the following options:
>
> 1. build unison yourself on each system from source.
> 2. try other tools such as syncthing.
>
> Hope you get this sorted!
>
It seems the unison developers are a little careless with compatibility
issues. This situation has arisen previously, then overcome by unison-all.

Thanks for your suggestion of syncthing; I'll give that a go...

Cheers, Tony

Re: unison compatibility in stretch

[Eric S Fraga]

On Wednesday, 13 Dec 2017 at 12:49, Tony van der Hoff wrote:

[...]

> The server is running Jessie, the repository does not contain 2.48.
> There appears to be no backport.
> The client is running Stretch. Its repository does not contain anything
> other than 2.48.
>
>>From what I can see froom googling, there is an incompatibility in one
> of the underlying libraries (ocaml?), which prevents Unison 2.48 being
> built for Jessie, or Unison 2.40 being built for Stretch.
>
> There doesn't appear to be an alternative for both jessie and stretch.
> What a mess!

Can you install from testing (buster) on these systems?  I.e. download
the .deb file from the net and install using dpkg directly.  There is
only a dependency on libc6 (>= 2.17); maybe that's satisfied on those
systems?  Maybe not, of course...

The ocaml aspect hit me recently in that unison v2.48.3 and v2.48.4 are
incompatible with each other.  A real mess.  Finally managed to get all
my systems running v2.48.4...

unison is a fantastic tool but these incompatibilities make it
incredibly frustrating to use every now and again.

You could consider the following options:

1. build unison yourself on each system from source.
2. try other tools such as syncthing.

Hope you get this sorted!

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: unison compatibility in stretch

[Tony van der Hoff]

On 12/12/17 11:58, Eric S Fraga wrote:
> On Monday, 11 Dec 2017 at 10:36, Tony van der Hoff wrote:
>
> [...]
>
>> No:
>>
>> tony@tony-lx:~$ unison -addversionno tony
>> Contacting server...
>> bash: unison-2.48: command not found
> But you do need to install the various versions you may to use on the
> server.  Then the client can request to use the version that it has by
> using that option.
>
> So install unison-2.48?
>
The server is running Jessie, the repository does not contain 2.48.
There appears to be no backport.
The client is running Stretch. Its repository does not contain anything
other than 2.48.

>From what I can see froom googling, there is an incompatibility in one
of the underlying libraries (ocaml?), which prevents Unison 2.48 being
built for Jessie, or Unison 2.40 being built for Stretch.

There doesn't appear to be an alternative for both jessie and stretch.
What a mess!

Re: unison compatibility in stretch

[David Margerison]

On 12 December 2017 at 21:16, Tony van der Hoff  wrote:
> On 12/12/17 08:50, Curt wrote:
>>
>> * workaroundable via symlink version number truncation bug
>>
> Thanks for your reply, Curt, but we appear to speak different languages ;)
>
> WVSVNTB?

The mysterious "WVSVNTB" might be a reference to the first line I have
quoted above.

Re: unison compatibility in stretch

[Curt]

On 2017-12-12, Tony van der Hoff  wrote:

>>> tony@tony-lx:~$ unison -addversionno tony
>>> Contacting server...
>>> bash: unison-2.48: command not found
>>> Fatal error: Lost connection with the server
>>>
>>>
>> * workaroundable via symlink version number truncation bug
>>
> Thanks for your reply, Curt, but we appear to speak different languages ;)
>
> WVSVNTB?
>
> could you please reduce the brevity of your solution?
>
> Cheers, Tony
>
>

A reduced brevity version would be to create a symbolic link unison-2.48
pointing to your installed version (unison-2.48.3?) to obviate
the dreaded WVSWVNTB.

 ln -s unison-2.48.3 unison-2.48

-- 
"The world is full of shipping clerks who have read the Harvard Classics."
— Charles Bukowski

Re: unison compatibility in stretch

[Eric S Fraga]

On Monday, 11 Dec 2017 at 10:36, Tony van der Hoff wrote:

[...]

> No:
>
> tony@tony-lx:~$ unison -addversionno tony
> Contacting server...
> bash: unison-2.48: command not found

But you do need to install the various versions you may to use on the
server.  Then the client can request to use the version that it has by
using that option.

So install unison-2.48?

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.3


signature.asc
Description: PGP signature

Re: unison compatibility in stretch

[Tony van der Hoff]

On 12/12/17 08:50, Curt wrote:
> On 2017-12-11, Tony van der Hoff  wrote:
>> On 10/12/17 19:40, Eric S Fraga wrote:
>>> On Sunday, 10 Dec 2017 at 12:25, Tony van der Hoff wrote:
>>>
>>> [...]
>>>
 In the passt, I've always worked round this by installing the lower
 version on my desktop and adjusted the links. This appears no lnger to
 be possible.

 Does anyone know how to get round this? (I've no immediate intention to
 upgrade the server).
>>> There is the -addversionno option which allows use to use different
>>> versions of unison on the server end.  Try this out (without adjusting
>>> any links).
>>>
>> No:
> What, no? Yes (WVSVNTB).
>
>> tony@tony-lx:~$ unison -addversionno tony
>> Contacting server...
>> bash: unison-2.48: command not found
>> Fatal error: Lost connection with the server
>>
>>
> * workaroundable via symlink version number truncation bug
>
Thanks for your reply, Curt, but we appear to speak different languages ;)

WVSVNTB?

could you please reduce the brevity of your solution?

Cheers, Tony

Re: unison compatibility in stretch

[Curt]

On 2017-12-11, Tony van der Hoff  wrote:
> On 10/12/17 19:40, Eric S Fraga wrote:
>> On Sunday, 10 Dec 2017 at 12:25, Tony van der Hoff wrote:
>>
>> [...]
>>
>>> In the passt, I've always worked round this by installing the lower
>>> version on my desktop and adjusted the links. This appears no lnger to
>>> be possible.
>>>
>>> Does anyone know how to get round this? (I've no immediate intention to
>>> upgrade the server).
>> There is the -addversionno option which allows use to use different
>> versions of unison on the server end.  Try this out (without adjusting
>> any links).
>>
> No:

What, no? Yes (WVSVNTB).

> tony@tony-lx:~$ unison -addversionno tony
> Contacting server...
> bash: unison-2.48: command not found
> Fatal error: Lost connection with the server
>
>

* workaroundable via symlink version number truncation bug

-- 
"The world is full of shipping clerks who have read the Harvard Classics."
— Charles Bukowski

Re: unison compatibility in stretch

[Tony van der Hoff]

On 10/12/17 19:40, Eric S Fraga wrote:
> On Sunday, 10 Dec 2017 at 12:25, Tony van der Hoff wrote:
>
> [...]
>
>> In the passt, I've always worked round this by installing the lower
>> version on my desktop and adjusted the links. This appears no lnger to
>> be possible.
>>
>> Does anyone know how to get round this? (I've no immediate intention to
>> upgrade the server).
> There is the -addversionno option which allows use to use different
> versions of unison on the server end.  Try this out (without adjusting
> any links).
>
No:

tony@tony-lx:~$ unison -addversionno tony
Contacting server...
bash: unison-2.48: command not found
Fatal error: Lost connection with the server

Re: unison compatibility in stretch

[Eric S Fraga]

On Sunday, 10 Dec 2017 at 12:25, Tony van der Hoff wrote:

[...]

> In the passt, I've always worked round this by installing the lower
> version on my desktop and adjusted the links. This appears no lnger to
> be possible.
>
> Does anyone know how to get round this? (I've no immediate intention to
> upgrade the server).

There is the -addversionno option which allows use to use different
versions of unison on the server end.  Try this out (without adjusting
any links).

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: unison compatibility in stretch

[Juan R. de Silva]

On Sun, 10 Dec 2017 12:25:42 +, Tony van der Hoff wrote:

> Hi,
> 
> For years I've been using unison to keep common files amongst my various
> systems.
> 
> I now find that stretch provides version 2.48, whereas Jessie provided
> 2.40, and they are not compatible. My server, which still runs Jessie,
> will therefore not accept connections from my desktop box.
> 
> In the passt, I've always worked round this by installing the lower
> version on my desktop and adjusted the links. This appears no lnger to
> be possible.

Why do you say:"It is no longer possible"? I'm currently running Jessie 
on my desktop and Stretch on laptop. I installed on both Unison 2.40 and 
synchronize them without any problem.

Re: unison compatibility in stretch

[Joe]

On Sun, 10 Dec 2017 12:25:42 +
Tony van der Hoff  wrote:

> Hi,
> 
> For years I've been using unison to keep common files amongst my
> various systems.
> 
> I now find that stretch provides version 2.48, whereas Jessie provided
> 2.40, and they are not compatible. My server, which still runs Jessie,
> will therefore not accept connections from my desktop box.
> 
> In the passt, I've always worked round this by installing the lower
> version on my desktop and adjusted the links. This appears no lnger to
> be possible.
> 
> Does anyone know how to get round this? (I've no immediate intention
> to upgrade the server).
> 

a) Do it the hard way with rsync and ssh?

b) Do it the cumbersome way by exporting samba/nfs mounts and running
Unison 'locally'?

I do the latter, as everything I want to synchronise is kept on my
server on samba shares, where it is also accessible from my Windows
laptop with FreeFileSync (yes, I do know there's a Unison for Windows).

-- 
Joe

unison compatibility in stretch

[Tony van der Hoff]

Hi,

For years I've been using unison to keep common files amongst my various
systems.

I now find that stretch provides version 2.48, whereas Jessie provided
2.40, and they are not compatible. My server, which still runs Jessie,
will therefore not accept connections from my desktop box.

In the passt, I've always worked round this by installing the lower
version on my desktop and adjusted the links. This appears no lnger to
be possible.

Does anyone know how to get round this? (I've no immediate intention to
upgrade the server).

Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

[Olaf Meeuwissen]

Hi Alex,

Sorry for the belated follow-up.

Alex ARNAUD writes:

> Le 28/09/2017 à 15:45, Olaf Meeuwissen a écrit:
>> Hi Alex,
>>
>> Based on a quick `git grep -i iris` on the sane-backends source code,
>> the only Irisscan device known to be supported is the "Express 2".  If
>> the "executive 4" has a USB port, could you provide the USB product ID?
>>
>> Connect the device, power it up, run `lsusb` and post the output.
>
> Hi Olaf,
>
> This is what I get when I plug the device and look at dmesg:
>
>> 469.816835] usb 1-6.3: new high-speed USB device number 13 using xhci_hcd
>> [  469.921775] usb 1-6.3: New USB device found, idVendor=0a38, idProduct=0162
>> [  469.921779] usb 1-6.3: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [  469.921782] usb 1-6.3: Product: IRIScanExec4
>> [  469.921784] usb 1-6.3: Manufacturer: IRIS
>> [  469.921787] usb 1-6.3: SerialNumber: A08805056B700953
>
> Best regards.

The only entry we have for idVendor=0a38 has idProduct=0301 and it's in
the list of unsupported devices :-(

 http://sane-project.org/cgi-bin/driver.pl?manu=&model=&bus=any&v=0a38&p=0301

Hope this helps (guess it doesn't),
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Re: Scanner Compatibility question

[Anthony DeRobertis]

On Tue, Oct 24, 2017 at 08:02:28PM +, J.W. Foster wrote:
> I'm wondering if anyone here has used or been able to install a
> scanner model: Canon - 9000F Mark II Flatbed Scanner - 

I personally use said model with a Debian testing box. It works
perfectly, though I've never tried the 4-channel (rgb+infrared) film
scanning.

Re: Scanner Compatibility question

[Brian]

On Tue 24 Oct 2017 at 20:02:28 +, J.W. Foster wrote:

> I'm wondering if anyone here has used or been able to install a
> scanner model: Canon - 9000F Mark II Flatbed Scanner - BlackI am
> currently trying to decide if I can use this scanner with current
> debian stable.  There is not much online to indicate a position either
> way. If that one seems out of the possibility then the other model is
> the  Epson Perfection V600 Photo Scanner .The Canon seems to have a
> decent edge as far as resolution. Also any other recommendations are
> welcome. most important is  the resolution as this is for photographic
> work.Thanks!John

Thomas Amm has directed you to the primary source for SANE-related
things. There is also the Debian wiki, This is very far from your
claim of "not much online". Either source will give you everything
you want.

-- 
Brian.

Re: Scanner Compatibility question

[Thomas Amm]

On Tue, 24 Oct 2017 20:02:28 + (UTC)
"J.W. Foster"  wrote:

> I'm wondering if anyone here has used or been able to install a
> scanner model: Canon - 9000F Mark II Flatbed Scanner - BlackI am
> currently trying to decide if I can use this scanner with current
> debian stable.  There is not much online to indicate a position
> either way. If that one seems out of the possibility then the other
> model is the  Epson Perfection V600 Photo Scanner .The Canon seems to
> have a decent edge as far as resolution. Also any other
> recommendations are welcome. most important is  the resolution as
> this is for photographic work.Thanks!John
> 
> 

According to SANEs scanner compatibility map
(http://www.sane-project.org/sane-mfgs.html) the 9000F Mark II is fully
supported.


-- 
--
Backup not found: (A)bort (R)etry (P)anic

Re: Scanner Compatibility question

[Dan Ritter]

On Tue, Oct 24, 2017 at 08:02:28PM +, J.W. Foster wrote:
> I'm wondering if anyone here has used or been able to install a scanner 
> model: Canon - 9000F Mark II Flatbed Scanner - BlackI am currently trying to 
> decide if I can use this scanner with current debian stable.  There is not 
> much online to indicate a position either way. If that one seems out of the 
> possibility then the other model is the  Epson Perfection V600 Photo Scanner 
> .The Canon seems to have a decent edge as far as resolution. Also any other 
> recommendations are welcome. most important is  the resolution as this is for 
> photographic work.Thanks!John
> 

The Canon appears to use the Canon PIXMA backend driver for
SANE, so I would expect it to work without any problems.

I haven't used this particular model, but scanners in general
have been well supported since Jessie.

-dsr-

Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

[Alex ARNAUD]

Le 28/09/2017 à 15:45, Olaf Meeuwissen a écrit :

Hi Alex,

Based on a quick `git grep -i iris` on the sane-backends source code,
the only Irisscan device known to be supported is the "Express 2".  If
the "executive 4" has a USB port, could you provide the USB product ID?

Connect the device, power it up, run `lsusb` and post the output.


Hi Olaf,

This is what I get when I plug the device and look at dmesg:


469.816835] usb 1-6.3: new high-speed USB device number 13 using xhci_hcd
[  469.921775] usb 1-6.3: New USB device found, idVendor=0a38, idProduct=0162
[  469.921779] usb 1-6.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[  469.921782] usb 1-6.3: Product: IRIScanExec4
[  469.921784] usb 1-6.3: Manufacturer: IRIS
[  469.921787] usb 1-6.3: SerialNumber: A08805056B700953


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

[Brian]

On Thu 28 Sep 2017 at 22:45:10 +0900, Olaf Meeuwissen wrote:

> If you want to use SANE on Debian GNU/Linux, all you really need to do
> is install the sane-utils package.  Next make sure that your users are
> members of the scanner and you should be able to use the `scanimage`
> command-line utility.

A small but important point: a user does not need to be a member
of the scanner group unless he is expected to log in from a remote
location. Permissions on the scanner device on the USB bus are
automatically taken care of by udev.

-- 
Brian.

Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

[Olaf Meeuwissen]

Hi Alex,

Alex ARNAUD writes:

> Dear all,
>
> I install Debian GNU/Linux on computer for visual-impaired users and
> I've a request about the compatibility of a Irisscan executive 4 scanner.
>
> I've sought on the internet without finding any specific data about this
> model.

Based on a quick `git grep -i iris` on the sane-backends source code,
the only Irisscan device known to be supported is the "Express 2".  If
the "executive 4" has a USB port, could you provide the USB product ID?

Connect the device, power it up, run `lsusb` and post the output.

Maybe that will turn up extra information.  I am sceptical about
that though, but see below.

> Do you know if this model is compatible with Sane and if yes where I
> could find a tutorial to install it?

If you want to use SANE on Debian GNU/Linux, all you really need to do
is install the sane-utils package.  Next make sure that your users are
members of the scanner and you should be able to use the `scanimage`
command-line utility.

# That's assuming your scanner is supported, of course.

If you have sane-utils installed already (quite likely if you installed
a graphical desktop environment), could you also provide the output of
running `sane-find-scanner`?

# Normally I see rather little value in running this command, but seeing
# that the Irisscan Express 2 is Plustek manufactured and supported by
# the gt68xx backend, it might give a clue as to the chipset which might
# be of use determining how easy/difficult adding support would be in
# case someone is interested in doing so.
#
# That's a lot of "if"s, so don't hold your breath waiting for support
# if your scanner is not supported already ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

[Alex ARNAUD]

Le 28/09/2017 à 15:45, Olaf Meeuwissen a écrit :

Hi Alex,

Alex ARNAUD writes:


Dear all,

I install Debian GNU/Linux on computer for visual-impaired users and
I've a request about the compatibility of a Irisscan executive 4 scanner.

I've sought on the internet without finding any specific data about this
model.


Based on a quick `git grep -i iris` on the sane-backends source code,
the only Irisscan device known to be supported is the "Express 2".  If
the "executive 4" has a USB port, could you provide the USB product ID?

Connect the device, power it up, run `lsusb` and post the output.


Thank you very much for your reply and the reply of Floris.

I don't have the device at hand (it's not mine) but ASAP I'll post here 
the result of lsusb.


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Re: Compatibility of the Irisscan executive 4 scanner

[Floris]

Op Thu, 14 Sep 2017 11:31:01 +0200 schreef Alex ARNAUD  
:



Dear all,

I install Debian GNU/Linux on computer for visual-impaired users and  
I've a request about the compatibility of a Irisscan executive 4 scanner.


I've sought on the internet without finding any specific data about this  
model.


Do you know if this model is compatible with Sane and if yes where I  
could find a tutorial to install it?


Best regards.



According to the Sane website [1] the IRIS products are unsupported. Maybe  
the Iriscan executive 4 has an other chipset and will work. Is it possible  
to find the USB-id or the manufacturer of the chipset?


[1] http://www.sane-project.org/lists/sane-mfgs-cvs.html#Z-IRIS

Compatibility of the Irisscan executive 4 scanner

[Alex ARNAUD]

Dear all,

I install Debian GNU/Linux on computer for visual-impaired users and 
I've a request about the compatibility of a Irisscan executive 4 scanner.


I've sought on the internet without finding any specific data about this 
model.


Do you know if this model is compatible with Sane and if yes where I 
could find a tutorial to install it?


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Re: Debian hardware compatibility

[Ben Caradoc-Davies]

On 20/04/17 12:33, Ben Caradoc-Davies wrote:

Asus UEFI BIOS (H110I-PLUS BIOS 3202) defaults to incorrect turbo boost
multipliers but I was able to manually set the correct "Per CPU" values
in the BIOS. For a 7700K, these should be 45/44/44/44 if you are not
overclocking (base clock 100MHz):
https://en.wikipedia.org/wiki/Kaby_Lake


For the record, upgrading to H110I-PLUS BIOS 3402 fixed the turbo boost 
multipliers.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Debian hardware compatibility

[Ben Caradoc-Davies]

On 20/04/17 17:12, John Elliot V wrote:

Will stretch RC3 smoothly transition to stable (with an apt-get
dist-upgrade) when stretch is released?


You should not need to do anything. When stretch is released as stable, 
you will already be on it. Just make sure that, when stretch is 
released, you have the security repo so you start getting stable 
security updates.



Will that apply to me? I.e. I should purge xserver-xorg-video-intel?


It is recommended.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Debian hardware compatibility

[Ben Caradoc-Davies]

On 21/04/17 00:15, John Elliot V wrote:

On 20/04/17 01:14, Joshua Schaeffer wrote:

I would recommend the 850 Evo vs the 850 Pro

Thanks for the tip. I had considered the Evo but this:
 https://www.kosagi.com/forums/viewtopic.php?id=421
had me a little spooked.


That is the 840 Evo. Completely different animal.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Debian hardware compatibility

[songbird]

John Elliot V wrote:
> On 20/04/17 10:33, Ben Caradoc-Davies wrote:
>> why not just install stretch from RC3? stretch is close to release.
>
> Sounds like a good idea! Thanks Ben.
>
> Will stretch RC3 smoothly transition to stable (with an apt-get
> dist-upgrade) when stretch is released?

  if you install it as stretch (by name) then it
will not need anything at all to remain as is
until you choose to make it something else.


  songbird

Re: Debian hardware compatibility

[solitone]

On Thursday, 20 April 2017 08:07:51 CEST Greg Wooledge wrote:
> On Thu, Apr 20, 2017 at 03:12:33PM +1000, John Elliot V wrote:
> > Will stretch RC3 smoothly transition to stable (with an apt-get
> > dist-upgrade) when stretch is released?
> 
> Yes.  In fact there's a very strong possibility you won't even need to
> do a whole dist-upgrade.  A simple "apt-get update; apt-get upgrade"
> may work, if the freeze proceeds smoothly.

This was exactly what happened to me when jessie transitioned from testing to 
stable. I would expect stretch be the same.

Re: Debian hardware compatibility

[John Elliot V]

On 20/04/17 01:14, Joshua Schaeffer wrote:
> I would recommend the 850 Evo vs the 850 Pro

Thanks for the tip. I had considered the Evo but this:

 https://www.kosagi.com/forums/viewtopic.php?id=421

had me a little spooked.

I've already parted with my money for the Pro. I've made bigger mistakes
in life... :)

-- 
E: j...@jj5.net
P: +61 4 3505 7839
W: https://www.jj5.net/
<>

Re: Debian hardware compatibility

[Greg Wooledge]

On Thu, Apr 20, 2017 at 03:12:33PM +1000, John Elliot V wrote:
> Will stretch RC3 smoothly transition to stable (with an apt-get
> dist-upgrade) when stretch is released?

Yes.  In fact there's a very strong possibility you won't even need to
do a whole dist-upgrade.  A simple "apt-get update; apt-get upgrade"
may work, if the freeze proceeds smoothly.

Re: Debian hardware compatibility

[John Elliot V]

On 20/04/17 10:33, Ben Caradoc-Davies wrote:
> why not just install stretch from RC3? stretch is close to release.

Sounds like a good idea! Thanks Ben.

Will stretch RC3 smoothly transition to stable (with an apt-get
dist-upgrade) when stretch is released?

> HD 630 iGPU is working fine for me with XFCE on an i7 7700 with one HDMI
> output on 4.9.18-1 amd64. I am on sid, but stretch has the same kernel.
> I purged xserver-xorg-video-intel because the modesetting driver is
> preferred for modern hardware.

Will that apply to me? I.e. I should purge xserver-xorg-video-intel?

> Asus UEFI BIOS (H110I-PLUS BIOS 3202) defaults to incorrect turbo boost
> multipliers but I was able to manually set the correct "Per CPU" values
> in the BIOS. For a 7700K, these should be 45/44/44/44 if you are not
> overclocking (base clock 100MHz):
> https://en.wikipedia.org/wiki/Kaby_Lake

OK, cool, thanks.

...and what if I am overclocking? I've never overclocked a system
before, but I heard I could safely overclock my new CPU to 5GHz, which
sounded pretty exciting..! :P

-- 
E: j...@jj5.net
P: +61 4 3505 7839
W: https://www.jj5.net/
<>

Re: Debian hardware compatibility

[Ben Caradoc-Davies]

On 19/04/17 19:52, John Elliot V wrote:

I'm getting a new workstation. Proposed specs are here:
 https://au.pcpartpicker.com/list/7MCfjc
I tried to find out if my new hardware would run Debian stable, but
couldn't confirm.
CPU is Intel Core i7-7700K on an Asus STRIX Z270F mobo. I'm planning to
drive two monitors from the onboard graphics controller, one via DVI the
other via HDMI.
Will Debian (w/ KDE Plasma) run on my new kit, does anybody know?
Cheers,
John.


Both your 7th generation Kaby Lake and the previous 6th generation 
Skylake have serious problems with older kernels such as the 3.16.39 in 
jessie, especially with integrated graphics. Older kernels also likely 
lack support for the i219v ethernet adapter on this board (but it is on 
the e1000e module support list for later kernels). You can get 4.9.18 
from backports, but why not just install stretch from RC3? stretch is 
close to release.


HD 630 iGPU is working fine for me with XFCE on an i7 7700 with one HDMI 
output on 4.9.18-1 amd64. I am on sid, but stretch has the same kernel. 
I purged xserver-xorg-video-intel because the modesetting driver is 
preferred for modern hardware.


Asus UEFI BIOS (H110I-PLUS BIOS 3202) defaults to incorrect turbo boost 
multipliers but I was able to manually set the correct "Per CPU" values 
in the BIOS. For a 7700K, these should be 45/44/44/44 if you are not 
overclocking (base clock 100MHz):

https://en.wikipedia.org/wiki/Kaby_Lake

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Debian hardware compatibility

[Joshua Schaeffer]

I don't think you'll have any issue with that set of hardware. If you've
never done water cooling before then you'll be very happy with your H80i
purchase. I have a Corsair Hydro H100i in both my Linux and Windows boxes
and absolutely love them. I'll never do anything but CPU water cooling
anymore. Also I would recommend the 850 Evo vs the 850 Pro. The pro's are
typically more expensive and only offer slightly better write performance
[1]. I've bought over 10 850 Evo's over the last few years and never been
dissatisfied with any of them. Just my personal opinion, but thought I
would mention it.

Thanks,
Joshua Schaeffer

[1]
http://ssd.userbenchmark.com/Compare/Samsung-850-Pro-256GB-vs-Samsung-850-Evo-250GB/2385vs2977

On Wed, Apr 19, 2017 at 3:57 AM, Dan Purgert  wrote:

> John Elliot V wrote:
> > This is a multi-part message in MIME format.
> > --50ECA958FA859516FB3191E9
> > Content-Type: text/plain; charset=utf-8
> > Content-Transfer-Encoding: 7bit
> >
> > I'm getting a new workstation. Proposed specs are here:
> >
> >  https://au.pcpartpicker.com/list/7MCfjc
> >
> > I tried to find out if my new hardware would run Debian stable, but
> > couldn't confirm.
> >
> > CPU is Intel Core i7-7700K on an Asus STRIX Z270F mobo. I'm planning to
> > drive two monitors from the onboard graphics controller, one via DVI the
> > other via HDMI.
> >
> > Will Debian (w/ KDE Plasma) run on my new kit, does anybody know?
> >
>
> I don't see anything that screams "linux incompatibility" on that list.
> Might have some "fun" with the graphics, but then I've not kept up on
> Intel's offerings in that regard.
>
>
> --
> |_|O|_| Registered Linux user #585947
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
>
>

Re: Debian hardware compatibility

[Dan Purgert]

John Elliot V wrote:
> This is a multi-part message in MIME format.
> --50ECA958FA859516FB3191E9
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
>
> I'm getting a new workstation. Proposed specs are here:
>
>  https://au.pcpartpicker.com/list/7MCfjc
>
> I tried to find out if my new hardware would run Debian stable, but
> couldn't confirm.
>
> CPU is Intel Core i7-7700K on an Asus STRIX Z270F mobo. I'm planning to
> drive two monitors from the onboard graphics controller, one via DVI the
> other via HDMI.
>
> Will Debian (w/ KDE Plasma) run on my new kit, does anybody know?
>

I don't see anything that screams "linux incompatibility" on that list.
Might have some "fun" with the graphics, but then I've not kept up on
Intel's offerings in that regard.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Debian hardware compatibility

[John Elliot V]

I'm getting a new workstation. Proposed specs are here:

 https://au.pcpartpicker.com/list/7MCfjc

I tried to find out if my new hardware would run Debian stable, but
couldn't confirm.

CPU is Intel Core i7-7700K on an Asus STRIX Z270F mobo. I'm planning to
drive two monitors from the onboard graphics controller, one via DVI the
other via HDMI.

Will Debian (w/ KDE Plasma) run on my new kit, does anybody know?

Cheers,
John.
-- 
E: j...@jj5.net
P: +61 4 3505 7839
W: https://www.jj5.net/
<>

RE: Debian Compatibility for CISCO UCS Servers

[Dilan Wijesooriya]

Hi Florian,

Noted and Really Appreciated your support , we will get the correct answer
from CISCO , 

Thank You.
Best Regards,

Dilan Wijesooriya
Data Center Specialist Engineer

Sumathi Information Technologies (Pvt) Ltd  
| Office: + 94.11.555.3311 Extn: 520  | Fax: +94.11.555.3312 | Mobile: + 94
77 041 | 
Email: di...@sit.lk | web: www.sit.lk 



-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de] 
Sent: Tuesday, October 13, 2015 12:09 AM
To: Dilan Wijesooriya
Cc: debian-user@lists.debian.org; listmas...@lists.debian.org;
ow...@bugs.debian.org; 'Noufel Ibrahim'; 'Asanaka Jayakody'
Subject: Re: Debian Compatibility for CISCO UCS Servers

* Dilan Wijesooriya:

> We need to install (bare metal ) Dabian 7 and Dabian 8 for bellow 
> CISCO Server model (Quantity 2) , can you pls let us know the 
> compatibility Of this , much appreciated your kind support and help for
this project .

Dear Dilan,

you need to ask your hardware provider to self-certify Debian compatibility,
ideally before buying their hardware.

Regards,
Florian

Re: Debian Compatibility for CISCO UCS Servers

[Florian Weimer]

* Dilan Wijesooriya:

> We need to install (bare metal ) Dabian 7 and Dabian 8 for bellow CISCO
> Server model (Quantity 2) , can you pls let us know the compatibility 
> Of this , much appreciated your kind support and help for this project .

Dear Dilan,

you need to ask your hardware provider to self-certify Debian
compatibility, ideally before buying their hardware.

Regards,
Florian

Re: Wifi compatibility

[Brian]

On Thu 26 Mar 2015 at 19:45:27 +, Ricardo Cardante wrote:

> Hi there. I have a Toshiba Satellite S50-B-131. Is my wifi driver supported?
> Thanks in advance.

Definitely.

Get back to us when you have set it up successfully.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/26032015195312.c7add9f87...@desktop.copernicus.demon.co.uk

Re: Wifi compatibility

[Mark Carroll]

Ricardo Cardante  writes:

> Hi there. I have a Toshiba Satellite S50-B-131. Is my wifi driver supported?
> Thanks in advance.

I don't have one but some looking online suggests that it has the Intel
AC 3160 which should work if you install firmware-iwlwifi from non-free,
and a newer kernel like jessie's.

-- Mark


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twx7k002@ixod.org

Wifi compatibility

[Ricardo Cardante]

Hi there. I have a Toshiba Satellite S50-B-131. Is my wifi driver supported?
Thanks in advance.

Re: 32bit compatibility for NVidia binary drivers in wheezy backports

[Aleksandar Dimitrov]

> And that's not impossible. libgl1-nvidia-glx depend on
> xserver-xorg-video-nvidia.

> And xserver-xorg-video-nvidia is not Multiarch-aware, i.e. you cannot
> co-install xserver-xorg-video-nvidia:i386 and
> xserver-xorg-video-nvidia:amd64 at the same time.

It seems this problem has been fixed in jessie, no? I had no trouble
installing libgl1-nvidia-glx:i386 in jessie — just wheezy was giving
me trouble. Anyway, I ended up just dist-upgrading, to skirt the
issue. Thanks for your help.

Aleks


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

Re: 32bit compatibility for NVidia binary drivers in wheezy+backports

[Reco]

 Hi.

On Sun, 15 Feb 2015 20:41:54 +0100
Aleksandar Dimitrov  wrote:

> But if I try to install the 32 bit compatibility package from multiarch…
> 
> > % aptitude install -t wheezy-backports nvidia-kernel-dkms:i386

Are you sure that you need to do this? This will install DKMS'ed nvidia
kernel module source and all it's i386 dependencies, including i386-only
toolchain.

Even if you manage to build such kernel module, it just won't load into
your kernel due to architecture mismatch.


> The same if I try to install any other part of the NVidia driver. For example:
> 
> > % aptitude install -t wheezy-backports libgl1-nvidia-glx:i386

And that's not impossible. libgl1-nvidia-glx depend on
xserver-xorg-video-nvidia.

And xserver-xorg-video-nvidia is not Multiarch-aware, i.e. you cannot
co-install xserver-xorg-video-nvidia:i386 and
xserver-xorg-video-nvidia:amd64 at the same time.

> Is there a way to install without a dist-upgrade (or pinning) to jessie?

There's one. Make i386-only chroot with debootstrap, install
nvidia-glx:i386 in there.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150216003945.34ea4a06cab2f0d0c30b1...@gmail.com

32bit compatibility for NVidia binary drivers in wheezy+backports

[Aleksandar Dimitrov]

Hi list,

I'm trying to install the NVidia binary package in Debian wheezy from
wheezy-backports on a 64bit system — which went fine. I've added multiarch:

> % dpkg --print-architecture
> amd64
> 
> % dpkg --print-foreign-architectures
> i386

But if I try to install the 32 bit compatibility package from multiarch…

> % aptitude install -t wheezy-backports nvidia-kernel-dkms:i386
> The following NEW packages will be installed:
>   nvidia-kernel-dkms:i386{b} 
> The following packages are RECOMMENDED but will NOT be installed:
>   libcuda1:i386 nvidia-driver:i386 
> 0 packages upgraded, 1 newly installed, 0 to remove and 155 not upgraded.
> Need to get 9,919 kB of archives. After unpacking 26.4 MB will be used.
> The following packages have unmet dependencies:
>  nvidia-kernel-dkms : Conflicts: nvidia-kernel-dkms:i386 but 340.65-2~bpo70+1 
> is to be installed.
>  nvidia-kernel-dkms:i386 : Depends: dkms:i386 (>= 2.1.0.0) which is a virtual 
> package.
>Depends: nvidia-kernel-common:i386 (>= 20110213) 
> but it is not going to be installed.
>Conflicts: nvidia-kernel-dkms but 340.65-2 is 
> installed.
> The following actions will resolve these dependencies:
> 
>  Keep the following packages at their current version:
> 1) nvidia-kernel-dkms:i386 [Not Installed]

The same if I try to install any other part of the NVidia driver. For example:

> % aptitude install -t wheezy-backports libgl1-nvidia-glx:i386
> The following NEW packages will be installed:
>   libgl1-nvidia-glx:i386{b} 
> 0 packages upgraded, 1 newly installed, 0 to remove and 155 not upgraded.
> Need to get 10.6 MB of archives. After unpacking 41.0 MB will be used.
> The following packages have unmet dependencies:
>  libgl1-nvidia-glx : Breaks: libgl1-nvidia-glx:i386 (!= 340.65-2) but 
> 340.65-2~bpo70+1 is to be installed.
>  libgl1-nvidia-glx:i386 : Breaks: libgl1-nvidia-glx (!= 340.65-2~bpo70+1) but 
> 340.65-2 is installed.
> The following actions will resolve these dependencies:
> 
>  Remove the following packages:
> 1) libgl1-nvidia-glx
> 2) nvidia-driver
> 3) nvidia-glx
> 4) xserver-xorg-video-nvidia

Needless to say, I'm not keen on deinstalling the 64bit variants of these
packages. The -ia32 variants of the packages (for example
libgl1-nvidia-glx-ia32) fail with similar error messages.

As far as I know, these problems don't exist in jessie, and all my Googling got
me to jessie results, or to wheezy w/o backports. Is there a way to install
without a dist-upgrade (or pinning) to jessie?

Thanks!
A.


signature.asc
Description: Digital signature

Re: Software compatibility between different architectures?

[Joel Rees]

2014/08/10 20:30 "Martin T" :
>
> >> how compatible are drivers on ports for different CPU architectures,
> >> e.g. I have a USB HSDPA modem which works great on Wheezy port for x86
> >> architecture, but can I expect it to work on Wheezy port for ARM?
> >
> > If your ARM platform's USB driver works, then yes, you can expect the
> > exact same support for any USB device you plug into it.
>
> I see. So usually there are no driver or other software issues because
> of different CPU architecture, i.e. once the kernel successfully boots
> up on ARM platform one can expect everything work exactly same as on
> wide-spread x86/x86-64 architecture?

In theory, C, with a bit of help from the pre-processor, hides all the
strangeness. You still hit bumps every now and then. (Byte order is an
example, see the little-endian PPC port, but there can be other issues.)

--Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: Software compatibility between different architectures?

[Sven Hartge]

Martin T  wrote:

>>> how compatible are drivers on ports for different CPU architectures,
>>> e.g. I have a USB HSDPA modem which works great on Wheezy port for
>>> x86 architecture, but can I expect it to work on Wheezy port for
>>> ARM?

>> If your ARM platform's USB driver works, then yes, you can expect the
>> exact same support for any USB device you plug into it.

> I see. So usually there are no driver or other software issues because
> of different CPU architecture, i.e. once the kernel successfully boots
> up on ARM platform one can expect everything work exactly same as on
> wide-spread x86/x86-64 architecture?

Only if your devices uses in kernel drivers. If you need to use a
binary-only driver supplied by the manufacturer of the device, it will
not work.

Note: Some ARM-systems (Raspberry Pi for example) don't provide enough
(read: only about 200mW and not the full 500mW) power on their on-board
USB ports. Devices which want to draw more power than provided will fail
to work and in most cases hard reset the ARM-system.

Usage of a seperate powered USB hub is advised.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/cataatven...@mids.svenhartge.de

Re: Software compatibility between different architectures?

[Martin T]

>> how compatible are drivers on ports for different CPU architectures,
>> e.g. I have a USB HSDPA modem which works great on Wheezy port for x86
>> architecture, but can I expect it to work on Wheezy port for ARM?
>
> If your ARM platform's USB driver works, then yes, you can expect the
> exact same support for any USB device you plug into it.

I see. So usually there are no driver or other software issues because
of different CPU architecture, i.e. once the kernel successfully boots
up on ARM platform one can expect everything work exactly same as on
wide-spread x86/x86-64 architecture?


thanks,
Martin


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJx5YvGD3zUhoVKCxgSF=fNDOuoLDjHO6wnx2w6+pON=vhs...@mail.gmail.com

Re: Software compatibility between different architectures?

[Stefan Monnier]

> how compatible are drivers on ports for different CPU architectures,
> e.g. I have a USB HSDPA modem which works great on Wheezy port for x86
> architecture, but can I expect it to work on Wheezy port for ARM?

If your ARM platform's USB driver works, then yes, you can expect the
exact same support for any USB device you plug into it.


Stefan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/jwvk36hxdqi.fsf-monnier+gmane.linux.debian.u...@gnu.org

Software compatibility between different architectures?

[Martin T]

Hi,

how compatible are drivers on ports for different CPU architectures,
e.g. I have a USB HSDPA modem which works great on Wheezy port for x86
architecture, but can I expect it to work on Wheezy port for ARM? Can
one expect the same options(modprobe parameters) for drivers on all
platforms? What about firmware(for example firmware files for warious
Wi-Fi adapters)? I guess all more or less not so hardware-related
software(for example iptables/netfilter) works exactly the same
between different ports?


regards,
Martin


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

Re: capitalone banking website compatibility with iceweasel

[kamaraju kusumanchi]

On Sun, Jul 27, 2014 at 11:46 PM, Bret Busby  wrote:

> On 28/07/2014, kamaraju kusumanchi  wrote:
> >
> > As a temporary work around, I am using chromium which works fine.
> >
>
> Have you tried using Opera (http://www.opera.com/) as a web browser
> for online banking?
>
> It could be worth trying.


Hi Bret,

As mentioned in my original email, I am using chromium as a work around.
The website works fine with it.

raju

Re: capitalone banking website compatibility with iceweasel

[Lisi Reisz]

Sorry, John.  This was meant to go on list.

On Monday 28 July 2014 15:19:34 John Hasler wrote:
> Lisi writes:
> > I want to change [from Iceweasel] to Firefox, which can't be worse...
>
> It can't be any different.

Yes, it can.  It is a later version.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201407290655.16485.lisi.re...@gmail.com

Re: capitalone banking website compatibility with iceweasel

[Marc Auslander]

Ok - to firefox 101.  Try in safe mode and see if the problem
persists.  If it doesn't, you have an add-in that's causing the
problem.

As for your bookmarks etc - you can always find your profile with
about:support if you don't know where is is.

You can save the whole profile directory using normal unix stuff and
then copy it over the profile of firefox to get back all your setting.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx612ih4@aptiva.optonline.net

Re: capitalone banking website compatibility with iceweasel

[John Hasler]

Lisi writes:
> I want to change [from Iceweasel] to Firefox, which can't be worse...

It can't be any different.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbqhtvk9@thumper.dhh.gt.org

Re: capitalone banking website compatibility with iceweasel

[Lisi Reisz]

On Monday 28 July 2014 13:21:24 Marc Auslander wrote:
> For what its worth, the site is fine with the latest build of firefox
> on debian (the 34a nightly).  What firefox version is iceweasel?

31 on Wheezy using backports.  (And it is awful.  I want to change to Firefox, 
which can't be worse, but am afraid of losing my bookmarks, or even worse, 
messing up my system.)

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201407281500.26581.lisi.re...@gmail.com

Re: capitalone banking website compatibility with iceweasel

[Marc Auslander]

For what its worth, the site is fine with the latest build of firefox
on debian (the 34a nightly).  What firefox version is iceweasel?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738dl4qt7@aptiva.optonline.net

Re: capitalone banking website compatibility with iceweasel

[Bret Busby]

On 28/07/2014, kamaraju kusumanchi  wrote:
> The capitalone banking website (https://banking.capitalone.com/) is not
> working with iceweasel. It does not display the login form. The error
> message is
>
> "We're sorry, our system experienced an error displaying the login form."
>
> I tried installing xul-ext-useragentswitcher and used Iceweasel -> Tools ->
> Default User Agent -> Internet Explorer -> Internet Explorer 8. This
> displays the login form but does not let me log in. Has anyone been able to
> get it to work with iceweasel?
>
> rajulocal@hogwarts:~/chess$ dpkg -l iceweasel xul-ext-useragentswitcher
> chromium
> ii  chromium
> 35.0.1916.153-2  amd64Chromium web
> browser
> ii  iceweasel
> 30.0-2   amd64Web browser based
> on Firefox
> ii  xul-ext-useragentswitcher
> 0.7.3-1  all  Iceweasel/Firefox
> addon that allows the user to choose user agents
>
>
> As a temporary work around, I am using chromium which works fine.
>
> I tried calling capitalone online banking support ( 877-442-3764 ) who said
> "we support IE, firefox, google chrome but do not support Iceweasel". In
> fact the tech support person has not even heard of Iceweasel before. I
> tried making a point that Iceweasel is just a rebranded version of
> firefox... but their answer is the same. If you are a capital one banking
> customer and if you use Debian, please call them and make them aware of the
> problem. May be if enough customers complain, they would do something about
> it.
>
> thanks
> raju
> --
> Kamaraju S Kusumanchi
> http://malayamaarutham.blogspot.com/
>

Have you tried using Opera (http://www.opera.com/) as a web browser
for online banking?

It could be worth trying.

-- 
Bret Busby
Armadale
West Australia
..

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cacx6j8nnmb9um1b1fdzaovv0e++j_olp5qtenrafmtdf1vu...@mail.gmail.com

Re: capitalone banking website compatibility with iceweasel

[Richard Owlett]

[TopPosting with appropriate apologies ;/

Contacting "Tech Support" not ALWAYS best route to solving tech 
problem.


Contact your local branch manager with supporting documentation.
For this approach to work you must:
  1. supply good trouble shooting documentation
  2. have established relationship with local branch

"Been there", "Done that", "Have the tee-shirt"
When my bank first rolled out "online banking", it had problems.
I passed USEFUL diagnostic info to local branch manager.
It got passed up on internal network as I had established 
creditability.

Now [~5 years later] there is a different problem.
I went up "chain of responsibility". Response coming down was not 
as desired.

HOWEVER communication still open.
Now I must persuade them that "solving the problem" is in *THEIR* 
best interest.



kamaraju kusumanchi wrote:

The capitalone banking website (https://banking.capitalone.com/)
is not working with iceweasel. It does not display the login
form. The error message is

"We're sorry, our system experienced an error displaying the
login form."

I tried installing xul-ext-useragentswitcher and used Iceweasel
-> Tools -> Default User Agent -> Internet Explorer -> Internet
Explorer 8. This displays the login form but does not let me log
in. Has anyone been able to get it to work with iceweasel?

rajulocal@hogwarts:~/chess$ dpkg -l iceweasel
xul-ext-useragentswitcher chromium
ii  chromium
35.0.1916.153-2  amd64
Chromium web browser
ii  iceweasel
30.0-2   amd64Web
browser based on Firefox
ii  xul-ext-useragentswitcher
0.7.3-1  all
Iceweasel/Firefox addon that allows the user to choose user agents


As a temporary work around, I am using chromium which works fine.

I tried calling capitalone online banking support ( 877-442-3764
) who said "we support IE, firefox, google chrome but do not
support Iceweasel". In fact the tech support person has not even
heard of Iceweasel before. I tried making a point that Iceweasel
is just a rebranded version of firefox... but their answer is the
same. If you are a capital one banking customer and if you use
Debian, please call them and make them aware of the problem. May
be if enough customers complain, they would do something about it.

thanks
raju
--
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/53d54b74.50...@cloud85.net

Re: capitalone banking website compatibility with iceweasel

[Bzzzz]

On Sun, 27 Jul 2014 12:46:31 -0400
kamaraju kusumanchi  wrote:

> The capitalone banking website (https://banking.capitalone.com/)
> is not working with iceweasel. It does not display the login form.
> The error message is
> 
> "We're sorry, our system experienced an error displaying the login
> form."

The same here (fr, sid, amd64).

> please call them and make them aware of the problem. May be if
> enough customers complain, they would do something about it.

Bad bank, change bank…

First, get a real FF user agent string and re-create it exactly
into useragentswitcher; if that doesn't work, then download 
FF for Linux and install it into your $HOME or /usr/local/.

-- 
CocO : I hope she's gonna like my poem, it comes from my guts!
HiM : Is it shit?


signature.asc
Description: PGP signature

capitalone banking website compatibility with iceweasel

[kamaraju kusumanchi]

The capitalone banking website (https://banking.capitalone.com/) is not
working with iceweasel. It does not display the login form. The error
message is

"We're sorry, our system experienced an error displaying the login form."

I tried installing xul-ext-useragentswitcher and used Iceweasel -> Tools ->
Default User Agent -> Internet Explorer -> Internet Explorer 8. This
displays the login form but does not let me log in. Has anyone been able to
get it to work with iceweasel?

rajulocal@hogwarts:~/chess$ dpkg -l iceweasel xul-ext-useragentswitcher
chromium
ii  chromium
35.0.1916.153-2  amd64Chromium web
browser
ii  iceweasel
30.0-2   amd64Web browser based
on Firefox
ii  xul-ext-useragentswitcher
0.7.3-1  all  Iceweasel/Firefox
addon that allows the user to choose user agents


As a temporary work around, I am using chromium which works fine.

I tried calling capitalone online banking support ( 877-442-3764 ) who said
"we support IE, firefox, google chrome but do not support Iceweasel". In
fact the tech support person has not even heard of Iceweasel before. I
tried making a point that Iceweasel is just a rebranded version of
firefox... but their answer is the same. If you are a capital one banking
customer and if you use Debian, please call them and make them aware of the
problem. May be if enough customers complain, they would do something about
it.

thanks
raju
-- 
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/

OT: Roxterm US English compatibility

[Ralf Mardorf]

$ roxterm --help | grep max
  -m, --maximise   Maximise the window, overriding profile
  --maximize   Synonym for --maximise

$ xfce4-terminal --help | grep max
  --startup-id=string; -I, --icon=icon; --fullscreen; --maximize;

:D




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399110164.18808.103.camel@archlinux

re: Compatibility of libs for Berkeley DB (libdb5.1-dev or libdb4.8-dev)

[peter green]

I cannot install libdb4.8-dev + libdb4.8, because it conflicts with libdb5.1.
This does not seem to be true, the dev packages conflict but afaict the 
libraries themselves (at least the versions from debian squeeze and 
wheezy) do not. So as long as you don't need libdb5.1-dev installed you 
should be fine.


If you need to use other dev packages that depend on the db dev packages 
to build bitcoind then I would suggest building it in a squeeze chroot. 
Once you have built it it should be easy enough to install required 
binary libraries on your wheezy system as unlike dev packages they 
rarely conflict.


Please direct further queries to debian-user.


--
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/52544833.7060...@p10link.net

Compatibility with Asus A42?

[Robert]

Hi guys,


Just wondering if there are hardware drivers available for the Asus A42 
laptop on the FreeBSD version of Debian?


Kind regards,

Robert Kochanski


--
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/51fe1adb.3090...@uqconnect.edu.au