Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting
Mailing Lists: lists.debian.org > debian-user > 07 > 1217339.html (Request Expert lists.debian.org Support)

debian-user-digest Digest V2007 #3078

From: <debian-user-digest-request(at)lists.debian.org>
Date: Mon Dec 31 2007 - 20:34:58 EST


Content-Type: text/plain

debian-user-digest Digest Volume 2007 : Issue 3078

Today's Topics: 

  Re: character encoding                [ "Kelly Clowers"  ]
  Re: run-parts not running cron.daily  [ W Paul Mills  ]
  Re: Weird gnome mount problem         [ David Purton 
  Re: Terminal issues in fresh install  [ Daniel Burrows <dburrows@debian.org ]



Date: Mon, 31 Dec 2007 15:08:24 -0800


From: "Kelly Clowers" <kelly.clowers@gmail.com>
To: debian <debian-user@lists.debian.org>
Subject: Re: character encoding

Message-ID: <1840f6970712311508h39990605t77556f8bfd156b68@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


On Dec 31, 2007 1:41 PM, ChadDavis <chadmichaeldavis@gmail.com> wrote:

> When I run 'ls' on a given directory, some of the file names show a question
> mark in the place of a non-supported character.  In trying to understand
> what is happening, I find that I don't understand a couple of fundamentals.
>
> 1) what is the default encoding of my debian system?

On new Etch installs, UTF-8 is the default. On older systems, it depends
on you locale (I'm not sure if a system upgraded to Etch would be UTF-8
or not). In the US it would be ISO-8859-1 or ISO-8859-15, I think. Use the
command "locale" and see what it says. Mine says en_US.UTF-8


> 2) It seems that a file itself doesn't have any encoding as it is sitting on
> the hard drive -- its just bytes, right?  when a given application picks it
> up, that application will try to read it as a certain encoding -- how is
> that determiniation made?
Do you need help?X

All files have encoding. Text files do, of course, but so binary files
like .jpg or .mp3. Even binary executables and libraries have a
specific format (binary executables are in ELF format on
non-ancient Linux systems).



When a text file is opened, I believe most simple apps try to interpret
it based on your systems locale. Some smarter programs may apply
fairly complicated heuristics to determine the encoding. Some
plain-text-based file types, such as xml, declare the encoding near
the beginning of the file.


> 3) What is the encoding of the file name?  Is this a feature of the
> filesystem?

This is also based on your locale.



Note that if you download a text file that is in, say, Shift-JIS (a common
Japanese encoding), the file and perhaps the filename will still be in
Shift-JIS. Even if your system is UTF-8 and has Japanese fonts installed,
it will not display the file correctly if it simply interprets it based on your
locale.



There are programs that can convert between encodings, including the
"convmv" package, which converts only filenames, the package
"utf8-migration-tool" and the "recode" package.


> I realize these questions may not be that "smart"; please tell me what I'm
> missing if so.  Also, point me to documentation if you know of some that
> explains all of this.  I couldn't find anything on the topic searching the
> web or debian docs.

For general info start with these wiki pages and some of the other pages
they link to:


Do you need more help?X
http://en.wikipedia.org/wiki/Locale
http://en.wikipedia.org/wiki/Character_encoding

If you want more in-depth programmer-oriented info on unicode, check
out Joel's article:


http://www.joelonsoftware.com/articles/Unicode.html

There is more Debian-specific info about charsets, locales, etc. in the
Debian Reference section on L10n (Localization) [take out 10 letters]:


http://www.debian.org/doc/manuals/debian-reference/ch-tune.en.html#s-l10n

and in the Debian i18n (internationalization) [take out 18 letters] Guide:


http://www.debian.org/doc/manuals/intro-i18n/index.en.html

Cheers,


Kelly Clowers


Can we help you?X

Date: Mon, 31 Dec 2007 18:34:55 -0500


From: charlie derr <cderr@simons-rock.edu>
To:  debian-user@lists.debian.org


Subject: Re: upgrading in sid

Message-ID: <47797C9F.3050504@simons-rock.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>> ii  zlib1g                1:1.2.3.3.dfsg-8      compression library - runtime
>> ni@delete:/var/cache/apt$
>> ni@delete:/var/cache/apt$ ldd /usr/bin/gconftool-2 | grep libz
>>         libz.so.1 => /usr/local/lib/libz.so.1 (0xb7be0000)
>> ni@delete:/var/cache/apt$
>> ni@delete:/var/cache/apt$ ldd /usr/lib/libxml2.so.2 | grep libz
>>         libz.so.1 => /usr/local/lib/libz.so.1 (0xb7dc0000)
>> ni@delete:/var/cache/apt$

>> ni@delete:/var/cache/apt$ nm -D /usr/lib/libz.so.1 | grep gzopen64
>> 00003f80 T gzopen64
> 
> You have the latest version of the zlib1g package, but you also have a
> non-Debian libz.so.1 in /usr/local/lib/ (probably an older version
> installed together with some non-Debian software). Until September 2007
> the default behavior would have been to use the Debian library in
> /usr/lib/ (therefore you might not have noticed this problem earlier),
> but now the default is for /usr/local/lib/ to take precedence. You have
> to get your system to use the proper file when libz.so.1 is needed. 
> 
> The most straightforward approach is to delete or to rename
> /usr/local/lib/libz.so.1 and to run "ldconfig" (without arguments as
> root). Afterwards you should see something like this:
> 
> $ ldconfig -pNX | grep 'libz\.so'
>         libz.so.1 (libc6,x86-64) => /usr/lib64/libz.so.1
>         libz.so.1 (libc6) => /usr/lib/libz.so.1
>         libz.so (libc6) => /usr/lib/libz.so

ni@delete:~$ /sbin/ldconfig -pNX | grep 'libz\.so'

         libz.so.1 (libc6) => /usr/local/lib/libz.so.1
         libz.so.1 (libc6) => /usr/lib/libz.so.1
         libz.so (libc6) => /usr/local/lib/libz.so
         libz.so (libc6) => /usr/lib/libz.so


ni@delete:~$



I'm not aware of ever intentionally doing anything to install any 64bit libs.  My whole system is running as 32-bit.



> $ ldd /usr/lib/libxml2.so.2 | grep libz
>         libz.so.1 => /usr/lib/libz.so.1 (0xb7e43000)

ni@delete:~$ ldd /usr/lib/libxml2.so.2 | grep libz


         libz.so.1 => /usr/local/lib/libz.so.1 (0xb7e83000)




> 
> This tells you that /usr/lib/libz.so.1 will be used from now on, and we
> already verified that this one has gzopen64 defined (the "nm ..."
> command above). This should allow you to (un)install all the currently
> broken packages.
Can't find what you're looking for?X

I think I'd like to understand why this first attempt didn't work.




aptitude is still very broken, full output here at http://www.assembla.com/wiki/show/door/AptitudeUpgradeStillFailing
> 
> If you need to keep /usr/local/lib/libz.so.1 then you have to set
> LD_LIBRARY_PATH to make sure that /usr/lib/ has a higher priority than
> /usr/local/lib/. I would advise not to keep alternate versions of
> Debian-provided libraries around, at least not if they have the same
> soname. If you want to check which other "local" libraries might cause
> problems in the future, you can run:
> 
> ldconfig -pNX | grep local
> 

i'm totally lost by now (but eagerly trying to keep up), here's the output from that one:



$ /sbin/ldconfig -pNX | grep local

         libz.so.1 (libc6) => /usr/local/lib/libz.so.1
         libz.so (libc6) => /usr/local/lib/libz.so
         libsvn_ra_local-1.so.1 (libc6) => /usr/lib/libsvn_ra_local-1.so.1
         liblocalkonnector.so (libc6) => /usr/lib/liblocalkonnector.so

Don't know where to look next?X



so should i get rid of all those (or rename them) and see if that helps?


	thanks again,
		~c


Date: Mon, 31 Dec 2007 16:02:01 -0800


From: Daniel Burrows <dburrows@debian.org>
To: debian-user@lists.debian.org


Subject: Re: upgrading in sid

Message-id: <20080101000201.GA29972@alpaca>
Content-type: text/plain; charset=us-ascii
Content-disposition: inline

Confused? Frustrated?X

On Mon, Dec 31, 2007 at 03:59:16PM -0500, charlie derr <cderr@simons-rock.edu> was heard to say:

> Daniel Burrows wrote:
>>   It would be interesting to know what ldd /usr/lib/libxml2.so.2 says.
>
> ni@delete:/var/cache/apt$ ldd /usr/lib/libxml2.so.2
>         linux-gate.so.1 =>  (0xb7fb7000)
>         libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e7e000)
>         libz.so.1 => /usr/local/lib/libz.so.1 (0xb7e6a000)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


  You may not know it's there, but you have a local version of libz.so.1
that isn't binary-compatible with the Debian-supplied libz.  You're
probably better off just deleting this (or moving it to some other name,
like was-libz.1); as it is, you risk random breakage and security holes
(because you probably aren't getting security updates for your local
version of the library).



  You may want to check if anything else has been placed in
/usr/local/bin or /usr/local/lib, and what the timestamps are (run
"ls -l /usr/local/bin /usr/local/lib"), as any other files in there
will override the system libraries.

  


>>   Erk.  That means something is hosed in your apt cache.  I would guess
>> this isn't related to your earlier problems, but it would be interesting
>> to know whether running "aptitude update" fixes this problem, 
>
> it hasn't yet (subsequent upgrades/removals won't all succeed (all of the gnome related stuff is foobared)) -- this is why i've

  Huh, interesting.


> delete:~# apt-cache showpkg desktop-base shared-mime-info
> Package: desktop-base
> Versions:
> 4.0.4(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)
> 4.0.3(/var/lib/dpkg/status)

  OK, apt believes that version 4.0.4 is available from unstable.  But
when it goes to actually install that version, it apparently blows up,
complaining that no file in the archive actually provides version 4.0.4.
At least, that's how I interpret that message
(pkgAcqArchive::pkgAcqArchive generates it if QueueNext
fails)...although from the source it looks like there are a few other
things it could be caused by, such as unusual trust errors.  You didn't
mention trust problems, though, so I assume that's not what's happening.



  I wonder what these commands will show:


Call Pantek today for Open Source Technical Support at 1-877-546-8934 - 24/7/365X

    grep -A 1000 "^Package: desktop-base$" /var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages | sed '/^$/,$d'



    apt-cache policy desktop-base



    apt-get -s install desktop-base



    apt-get -s install desktop-base=4.0.4



    aptitude -s install desktop-base=4.0.4



    aptitude -vvvv show desktop-base



  Actually, if you have a way to post large files on the internet, it
would be interesting if you could run


"aptitude-create-state-bundle snapshot.tar.bz2" and then let me know how
to get access to it; then I might be able to reproduce your problems
here and find out exactly what's happening.



  Daniel


Do you need help?X

Date: Mon, 31 Dec 2007 16:13:31 -0800


From: Daniel Burrows <dburrows@debian.org>
To: debian-user@lists.debian.org


Subject: Re: upgrading in sid

Message-id: <20080101001331.GB29972@alpaca>
Content-type: text/plain; charset=us-ascii
Content-disposition: inline


On Mon, Dec 31, 2007 at 04:02:01PM -0800, Daniel Burrows <dburrows@debian.org> was heard to say:

>   You may want to check if anything else has been placed in
> /usr/local/bin or /usr/local/lib, and what the timestamps are (run
> "ls -l /usr/local/bin /usr/local/lib"), as any other files in there
> will override the system libraries.

  Just to clarify, the reason for checking the timestamps is that it
might give you a notion of when and why the files were created.



  Daniel



Date: Mon, 31 Dec 2007 16:08:04 -0500


From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org


Subject: Re: run-parts not running cron.daily?

Message-ID: <20071231210804.GA8008@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


On Mon, Dec 31, 2007 at 11:58:28AM -0800, Todd A. Jacobs wrote:

> It turns out that this is caused by moving a shell script (with a .sh
> extension) into the run-parts directory. Run-parts won't run filenames
> with dots in them. If this is documented clearly anywhere, I couldn't
> find it, but removing the filename extensions fixed the problem.
> 
Do you need more help?X

Paragraph 2 of the run-parts man page.



Doug.



Date: Mon, 31 Dec 2007 16:24:29 -0800 (PST)
From: Angus Auld <aonghas_auld@yahoo.com>
To: debian-user <debian-user@lists.debian.org>
Subject: Re: wine - resource hog

Message-ID: <419755.32880.qm@web53010.mail.re2.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

  •   David <davidpalmer@westnet.com.au> wrote:



> joseph lockhart wrote:
> > ok, here is my system info, basically the hardinfo
> > report generated by Hardinfo for my primary
> partition,
> > if i switch over to my etch install i will post
> the
> > same for it if necessary
> >=20
> > Computer
> > ********
> >=20
> >=20
> > Summary
> > -------
> >=20
> > -Computer-
> > Processor		: Intel(R) Celeron(R) CPU 2.60GHz
> > Memory		: 247MB (217MB used)
>=20
> If you are going to be running translators/emulators
> on top -=20
> /definitely/ more ram. At least 1G.
> That's why it runs slowly.
> Regards,
> --=20
> David Palmer
> Linux User - #352034
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Indeed, 256MB of ram is inadequate for a system doing
most anything these days.


It's unlikely anything would work properly at all.
There must be a lot of thrashing of the hd trying to
swap anything but the most basic functions.
More ram is necessary, and the price is well worth it.
=20




  •   Angus




######Linux Laptop powered by Debian Linux######
###########Reg. Linux User #278931###########



      ___________________________________________________________________=
_________________



Never miss a thing.  Make Yahoo your home page.=20
http://www.yahoo.com/r/hs

Date: Mon, 31 Dec 2007 18:01:32 -0600


From: W Paul Mills <Paul-NOT@Mills-USA.com>
To: debian-user@lists.debian.org


Subject: Re: run-parts not running cron.daily?

Message-ID: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Can we help you?X
-----BEGIN PGP SIGNED MESSAGE-----


Hash: SHA1



Todd A. Jacobs wrote:

> It turns out that this is caused by moving a shell script (with a .sh
> extension) into the run-parts directory. Run-parts won't run filenames
> with dots in them. If this is documented clearly anywhere, I couldn't
> find it, but removing the filename extensions fixed the problem.
> 

man run-parts


-----BEGIN PGP SIGNATURE-----


Version: GnuPG v1.4.5 (MingW32)


Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHeYLZu4tRirKTPYwRAo++AJ0YVtuYCf5PHebOQ6h1QToiysBEuQCfYent
qd1qy0wXe0ZC0l7+yLT6fnw=


=35Gc

-----END PGP SIGNATURE-----


Date: Tue, 1 Jan 2008 01:18:49 +0100


From: Florian Kulzer <florian.kulzer+debian@icfo.es>
To: debian-user@lists.debian.org


Subject: Re: upgrading in sid

Message-ID: <20080101001849.GA13909@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


On Mon, Dec 31, 2007 at 18:34:55 -0500, charlie derr wrote:



[...]


Can't find what you're looking for?X
> ni@delete:~$ /sbin/ldconfig -pNX | grep 'libz\.so'
>         libz.so.1 (libc6) => /usr/local/lib/libz.so.1
>         libz.so.1 (libc6) => /usr/lib/libz.so.1
>         libz.so (libc6) => /usr/local/lib/libz.so
>         libz.so (libc6) => /usr/lib/libz.so
> ni@delete:~$
>
> I'm not aware of ever intentionally doing anything to install any
> 64bit libs.  My whole system is running as 32-bit.

Your system is OK, except for the fact that there is a non-Debian
libz.so.1 in /usr/local/lib/. Wherever this file came from, it does not
implement the gzopen64 function which is needed by gconftool-2. Your
problem will persist as long as the linker gives precedence to
/usr/local/lib/libz.so.1.



[...]


> ni@delete:~$ ldd /usr/lib/libxml2.so.2 | grep libz
>         libz.so.1 => /usr/local/lib/libz.so.1 (0xb7e83000)

Same as above: You need to see /usr/lib/libz.so.1 here (no "/local/").


> I think I'd like to understand why this first attempt didn't work.

I don't think you did anything so far. ("/sbin/ldconfig -pNX" is a
diagnostic command; I was trying to tell you how to check which
locations are known for the libz library.)  


> aptitude is still very broken, full output here at
> http://www.assembla.com/wiki/show/door/AptitudeUpgradeStillFailing
Don't know where to look next?X

The main issue seems to be the gconftool-2 problem. Whenever you call
aptitude it will first try to fix the broken packages and it will
continue to fail until the libz.so.1 issue is addressed.


> i'm totally lost by now (but eagerly trying to keep up), here's the output from that one:
>
> $ /sbin/ldconfig -pNX | grep local
>         libz.so.1 (libc6) => /usr/local/lib/libz.so.1
>         libz.so (libc6) => /usr/local/lib/libz.so
>         libsvn_ra_local-1.so.1 (libc6) => /usr/lib/libsvn_ra_local-1.so.1
>         liblocalkonnector.so (libc6) => /usr/lib/liblocalkonnector.so
>
> so should i get rid of all those (or rename them) and see if that helps?

AFAICT, your only two problems are /usr/local/lib/libz.so.1 and
/usr/local/lib/libz.so. My problem is that I don't know why these files
are on your system, therefore I am hesitant to tell you to delete or
rename them, because this might break other things.



In my opinion you have three options:



  1.   Tells us exactly how and why these /usr/local/lib/ files got on your
   system. We might be able to figure out what the safest approach is if
   we know that.

  
  2.   Read up on the basics of linking and shared libraries, then make an
   informed decision yourself after you fully understand the present
   problem.

  
  3.   Remove or rename the /usr/local/lib/libz.so* files, run "ldconfig"
   (as root, without any arguments or options), make sure that "ldd
   /usr/lib/libxml2.so.2 | grep libz" shows /usr/lib/libz.so.1 will be
   used, and run "aptitude install -f". 



-- 
Regards,            | 
http://users.icfo.es/Florian.Kulzer
          Florian   |


Date: Mon, 31 Dec 2007 19:49:17 -0500
From: Mitchell Laks <mlaks@post.harvard.edu>
To: debian-user@lists.debian.org
Subject: Re: kernel-source package in Etch?
Message-ID: <20080101004917.GC8175@earthlink.net>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On 22:14 Mon 31 Dec     , Rodolfo Medina wrote:

> Hi to all Debian users.
> 
> In Sarge, in order to configure Debian for my modem, I started with:
> 
>  # apt-get install kernel-source-2.4.27
> 
> .  Now, in Etch, what should the package be in place of that?  I couldn't find
> it!  I tried with ...2.6, ...2.6.18,... but none was the right one.


they now call the kernel package

linux-image-2.6.18-4-686 or something like that and 
the headers package  is
linux-headers-2.6.18-4-686 
the source package is
linux-source-2.6.18 


do uname -a 
to find out what kernel you have

then do 


apt-cache search linux-headers
or 
apt-cache search linux-source

mitchell




> 
> Thanks for any help
> Rodolfo
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

Date: Mon, 31 Dec 2007 19:30 -0500
From: "Pls check this new site" <acro3451@tss.com.ar>
To: debian-user@lists.debian.org
Subject: www.chequexpress.com.ar
Message-Id: <20080101003023.81B0F13A677F@liszt.debian.org>
Content-Type: multipart/alternative; boundary="--=_Mail_SendEasy_kQsCUwG_19623_1199147402"

This is a multi-part message in MIME format.
This message is in 2 versions: TXT and HTML
You need a reader with MIME to read this message!

----=_Mail_SendEasy_kQsCUwG_19623_1199147402
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=62=6A=
=65=63=74


----=_Mail_SendEasy_kQsCUwG_19623_1199147402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<=62>=50=6C=65=61=73=65 =73=65=65 =74=68=69=73 =73=69=74=65 =69=6E =53=75=
=62=6A=65=63=74<=2F=62>
----=_Mail_SendEasy_kQsCUwG_19623_1199147402--



Date: Mon, 31 Dec 2007 18:23:52 -0600
From: Dave Sherohman <dave@sherohman.org>
To: Debian-User <debian-user@lists.debian.org>
Subject: Terminal issues in fresh install
Message-ID: <20080101002352.GB22483@sherohman.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Greetings, all!

I've just moved over from an ancient self-hosted Debian box onto some
more modern hardware and things are going mostly smoothly, but I'm
having some issues with mutt's thread indicators (extended-ASCII arrows)
displaying improperly.  I've double-checked that I've got all locale
settings set to en_US.UTF-8 (with the sole exception of LC_COLLATE,
which I prefer to keep at C) and done a dkpg-reconfigure locales to
verify that en_US.UTF-8 is generated (it is; actually, it's the only
thing that is).  mutt is at the latest version from stable and, noticing
that there's a mutt-utf8 mentioned as conflicting with it, I tried
installing that, but it appears to be an obsolete UTF-8 support package
which no longer exists.

Is it significant that the old machine was using the basic en_US locale
or that I've been accessing both of them via ssh from a workstation with
its locale set to C?  I also am using a customized terminfo (to prevent
the screen from resetting when I exit less/vi/etc.), but tried disabling
that and relogging, which had no effect, so I don't think it's likely to
be the cause.

As a side question, this new install was done by the hosting provider,
who is primarily familiar with Red Hat, so everything was configured to
the defaults.  Package configurations are also displaying the same
symptoms as mutt, since they're using the (default) curses interface.
Which I've never liked anyway.  How do I switch it over to the plain-text
(readline?) interface?  I've tried dpkg-reconfigure dpkg and apt, since
they seemed the likely suspects, but neither one offered any options to
configure.

-- 
I reckon we are now the only monastry ever that had a dungeon stuffed with
sixteen thousand zombies.
  - perlmonks.org



Date: Tue, 1 Jan 2008 11:36:52 +1030
From: David Purton <dcpurton@marshwiggle.net>
To: debian-user@lists.debian.org
Subject: Re: Weird gnome mount problem
Message-ID: <20080101010652.GA6428@marshwiggle.net>
Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 31, 2007 at 11:42:26AM +1000, Julian De Marchi wrote:

> <snip>
>=20
> >Any theories, suggestions, tips, thoughts, or anything else that might
> >be useful?
>=20
> Maybe another usb port while in gnome, if your card reader is an=20
> external usb device.


Yeah, I'd thought of this, but I hadn't tried a different machine. It
works fine with my sid laptop, so I'll put it down to a bug in the etch
version of Gnome.

cheers

dc

--=20
David Purton
dcpurton@marshwiggle.net
=20
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
                                 2 Chronicles 16:9a

--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHeZIsFtfqMu4ICewRAk2oAKCBSzDvrZbS4oCS2ro6NTVfnIe7dQCeIBIA
p0VJYqkhF22NVaHYhE7K/D4=
=uYKg
-----END PGP SIGNATURE-----

--OXfL5xGRrasGEqWY--


Confused? Frustrated?X

Date: Mon, 31 Dec 2007 17:15:58 -0800
From: Daniel Burrows <dburrows@debian.org>
To: debian-user@lists.debian.org
Subject: Re: upgrading in sid
Message-id: <20080101011558.GA29864@alpaca>
Content-type: text/plain; charset=us-ascii
Content-disposition: inline

On Mon, Dec 31, 2007 at 06:34:55PM -0500, charlie derr <cderr@simons-rock.edu> was heard to say:

> I'm not aware of ever intentionally doing anything to install any 64bit libs.  My whole system is running as 32-bit.


  Note that this has nothing to do with 64-bit libraries.  The "64" in
gzopen64 means, essentially, that the function can handle large files
(whose sizes cannot be represented in 32 bits, so 64 bits are used).

  Daniel



Date: Mon, 31 Dec 2007 17:19:52 -0800
From: Daniel Burrows <dburrows@debian.org>
To: debian-user@lists.debian.org
Cc: Dave Sherohman <dave@sherohman.org>
Subject: Re: Terminal issues in fresh install
Message-id: <20080101011952.GB29864@alpaca>
Content-type: text/plain; charset=us-ascii
Content-disposition: inline

On Mon, Dec 31, 2007 at 06:23:52PM -0600, Dave Sherohman <dave@sherohman.org> was heard to say:

> Is it significant that the old machine was using the basic en_US locale
> or that I've been accessing both of them via ssh from a workstation with
> its locale set to C?


  I'd guess that the locale of the workstation is relevant here.  Your
terminal is going to be running in your locale (you didn't mention if
was the system console or an X terminal, but I assume an X terminal),
and so it won't know how to deal with UTF-8 sequences output by the
commands you're running remotely.

  Probably your best bet is to either enable UTF-8 locally or disable it
remotely.

  Daniel

End of debian-user-digest Digest V2007 Issue #3078
**************************************************

Received on Mon Dec 31 20:35:10 2007

This archive was generated by hypermail 2.1.8 : Fri Feb 29 2008 - 16:00:33 EST

Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library