I found the beginnings of the problem. Does this make sense? Ishtar:/suse11.2> sudo zypper in xorg-x11-libx11 Loading repository data... Reading installed packages... 'xorg-x11-libX11' is already installed. Resolving package dependencies... Nothing to do. Ishtar:/suse11.2> rpm -V xorg-x11-libx11 package xorg-x11-libx11 is not installed Ishtar:/suse11.2> rpm -q xorg-x11-libx11 package xorg-x11-libx11 is not installed --- If zypper says the package is installed, shouldn't rpm also notice that it is installed? This might explain why I can have missing files/packages as I tried to upgrade from 11.1>11.2 using zypper. ( Boy was that ever a disaster -- a week of downtime just to get bootable again! Pray you never have problems with grub. It gets real flakey in handling file systems -- doing reads/writes from disk while the file system is still mounted! After many headaches, I moved back to lilo -- itself a feat, due to changes in the boot process that seemed to presume grub and a ram disk. Now I'm back to ~20 second boots from loading to login prompt, down from ~35-45 with grub and ramdisk ). Anyway...apparently zypper didn't install some things or it thought it did and they didn't get fully there (as noted by rpm not seeing them). I suspect zypper and rpm pck lists *should* be the same.... I don't see an option to zypper to syncrhonize it with rpm or for it to verify packages on disk. Anyone know how to get it to do either? thanks... (on the hunt of another obscure config problem... linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Saturday, 2010-05-01 at 17:52 -0700, Linda Walsh wrote:

...

I found the beginnings of the problem.

Of your “locale xxx.utf8?” problem? You are hijacking your own email! >:-)

Yeppers...I do things like that to myself. But it is related, its not really new topic but a push down on the stack...

(I read it top to bottom, trying to find where your locale problem was found... but no, it is an rpm problem now.)

--- That's why I changed the subject line...for now, my locale problem has become an rpm v. zypper package inconsistency problem. The package (from below xorg.x11-libx11) is the one that contains the locale files. Zypper thinks it is installed. rpm thinks it is not. bash and locale agree with rpm (i.e. they give errors saying the locale can't be set to utf8 --- as though files from xorg.x11-libx11 are missing). At least it's the only one that had en_US.UTF-8 files in it...can't find any others with that filename in my filename list.

...

Does this make sense?

Ishtar:/suse11.2> sudo zypper in xorg-x11-libx11 Loading repository data... Reading installed packages... 'xorg-x11-libX11' is already installed. Resolving package dependencies...

What directory is "/suse11.2"? Do you have a chroot install, perhaps?

--- Sorry...red herring. Just happens to be a package dir I'm in, but it is not what is being referred to in the rpm or zypper commands. No chroot...(it's the dir where I keep rpm packages -- like a 'repo' dir, but not directly 'repo'able -- but I use it to get lists of files from all the RPMS into files-by-arch subfiles where I can search by filename for missing files and get pack packagenames that own those files.

...

Nothing to do. Ishtar:/suse11.2> rpm -V xorg-x11-libx11 package xorg-x11-libx11 is not installed Ishtar:/suse11.2> rpm -q xorg-x11-libx11 package xorg-x11-libx11 is not installed

rpm -qa | grep -i xorg-x11

...

I don't see an option to zypper to syncrhonize it with rpm or for it to verify packages on disk. Anyone know how to get it to do either?

No, zypper has to ask rpm for the list of installed packages, and to do the real install.

--- That makes loads of sense to me... Why then does the first command "zypper in xorg-x11-libx11" return that is is already installed when rpm says it is not? That's where I'm a bit stumped. Note -- the rpm command on my system can be executed by normal users for 'queries' -- only needs to be root for install, so it doesn't matter in my command line above whether I have a sudo before it or not. Does the same thing: rpm doesn't think it is installed (so, of course, won't verify it), but zypper won't install it because it thinks it is installed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

You did:

...

...

...

Ishtar:/suse11.2> rpm -V xorg-x11-libx11 package xorg-x11-libx11 is not installed Ishtar:/suse11.2> rpm -q xorg-x11-libx11 package xorg-x11-libx11 is not installed

I told you to do instad:

Sorry, didn't get that you were asking me to a different command. you are right. It is a case problem. => Red-herring. (Cept' that zypper shouldn't ignore case unless it makes it clear that the match it's returning is based on a different cased spelling -- something fine to do, but wouldn't have dweeb who have spent too much time on Windows ignoring case get confused...:-)) Now I'm back to original prpblem under the xxx.utf8 locale note. So I'll re-answer under that heading/thread for more issues there, as this 'side issue' is mostly closed 'cept' for the two tools accepting different case. IMO, zypper shouldn't ignore case where rpm doesn't. I don't know about how I feel about making "ignore case' the default. My initial feeling is 'neh', as it's not backwards compatible, but it certainly is more user friendly, so I'd have to backoff my initial feeling based on user-friendliness, if it can make it clear to those expecting earlier behavior that a match has only matched using case insensitivity. -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-05-03 04:09, Linda Walsh wrote:

Carlos E. R. wrote:

[sent later]

IMO, zypper shouldn't ignore case where rpm doesn't. I don't know about how I feel about making "ignore case' the default. My initial feeling is 'neh', as it's not backwards compatible, but it certainly is more user friendly, so I'd have to backoff my initial feeling based on user-friendliness, if it can make it clear to those expecting earlier behavior that a match has only matched using case insensitivity.

Perhaps it ignores case because it is searching for a package and so it helps the user "memory" to search for different spellings. Again perhaps it doesn't ignore case when it finds two hits of the same "ignore case" spelling. Lets look the manual... ah, look, there is some documentation: -C, --case-sensitive Perform case-sensitive search. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkveZSsACgkQja8UbcUWM1xa+QD5ATxyleeslZWyknc7GC+0blDP KmfgsPKr3sGiKnOLq5MA/A4aL5PWeU3U3+r6QrCDIYcEyH7M1f6gquBY2xBRVIYM =wfy3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, May 05, 2010 at 02:30:39PM +0200, Jano Kupec wrote:

On 05/03/2010 07:54 AM, Carlos E. R. wrote:

...

On 2010-05-03 04:09, Linda Walsh wrote:

...

Carlos E. R. wrote:

[sent later]

...

IMO, zypper shouldn't ignore case where rpm doesn't. I don't know about how I feel about making "ignore case' the default. My initial feeling is 'neh', as it's not backwards compatible, but it certainly is more user friendly, so I'd have to backoff my initial feeling based on user-friendliness, if it can make it clear to those expecting earlier behavior that a match has only matched using case insensitivity.

Perhaps it ignores case because it is searching for a package and so it helps the user "memory" to search for different spellings.

yes. like 'zypper in mplayer' will indeed install MPlayer.

Probably also due to the provides in the MPlayer RPM: rpm -q --provides MPlayer ... mplayer-... ... Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, May 05, 2010 at 02:30:39PM +0200, Jano Kupec wrote:

But at least it then says: 'xorg-x11-libX11' is already installed. but, yeah, the X is really hard to spot here.

The 'already installed' error is lower case if you use --name, though. This needs fixing... M. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sat, May 01, 2010 at 05:52:41PM -0700, Linda Walsh wrote:

Does this make sense?

Ishtar:/suse11.2> sudo zypper in xorg-x11-libx11 Loading repository data... Reading installed packages... 'xorg-x11-libX11' is already installed. Resolving package dependencies...

Nothing to do. Ishtar:/suse11.2> rpm -V xorg-x11-libx11 package xorg-x11-libx11 is not installed Ishtar:/suse11.2> rpm -q xorg-x11-libx11 package xorg-x11-libx11 is not installed

--- If zypper says the package is installed, shouldn't rpm also notice that it is installed?

That's because zypper lies. If you look at zypper's output you can see that it wrote "xorg-x11-libX11" instead of your "xorg-x11-libx11". I don't think this qualifies as a feature, zypper should be case sensitive. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, May 05, 2010 at 02:40:52PM +0200, Jano Kupec wrote:

I (and i hope many people too) find it annoying to type 'in MPlayer' instead of 'in mplayer', to give an example. So i qualify this as a feature.

I OTOH find it annoying that zypper behaves different then all the other tools. ;-) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Michael Andres wrote:

On Wednesday 05 May 2010 14:40:52 Jano Kupec wrote:

...

I (and i hope many people too) find it annoying to type 'in MPlayer' instead of 'in mplayer', to give an example. So i qualify this as a feature.

IMO not. A human typing the name may say e.g. 'zypper in --ic mplayer' (--ic=ignore case). Or a --no-ic switch for scripts. Anyway I'd like to be able to influence the amount of AI.

agreed, But don't you agree, that to be friendlier to the general populace, that AI should be switched on by default, and that 'expert' mode should require the switch (--no-ic) The point is you want the default to take up little typing... especially, if people are trying for minimal typing, U/l case are more painful than all-lower case, so adding more chars, as in more 'switches', to get the benefit of not remembering case is, 'a bit', like adding salt to get the salt-free option. If you look at multiple groups of users, 1) those who know the case but have forgotten it, or are lazy, vs. 2) those who know the case and have no problem using it, vs. 3) those who have no clue that case makes a difference (3 groups), out of those groups, which groups do you think would expect to know that they needed a "--modify-case" switch for any particular invocation (whether it be -cs(casesensitive)/+cs or whatever)? -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, 05 May, 2010 at 21:01:17 -0400, Patrick Shanahan wrote:

* Linda Walsh [05-05-10 20:35]:

...

Michael Andres wrote:

...

IMO not. A human typing the name may say e.g. 'zypper in --ic mplayer' (--ic=ignore case). Or a --no-ic switch for scripts. Anyway I'd like to be able to influence the amount of AI.

---

agreed, But don't you agree, that to be friendlier to the general populace, that AI should be switched on by default, and that 'expert' mode should require the switch (--no-ic)

No! Linux is case-sensitive. Default should be case-sensitive, no problem about an option to toggle/change that, perhaps with prominent notice.

+1 -- YMMV -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

* Linda Walsh [05-07-10 07:45]:

...

No! Linux is case-sensitive. And linux is famous for not being user-friendly. Something many

Patrick Shanahan wrote: people would like to see changed.

Yes, the command-line is known for not being user-friendly, but not the gooie. The gooie *has* changed that.

...

Default should be case-sensitive, no problem about an option to toggle/change that, perhaps with prominent notice. But default should be least surprise and history would make that case-sensitive.

And now your using Bill Gates logic that linux can't progress because it has to be backward compatible with a poor interface?

"Bill Gates logic", now that's an oxymoron! But, yes, things need to be backward compatable. Poor interface ??

Are you a windows-counter agent?

Are you daft?

You need to think about what experienced users (ah, that would be me, who's used unix/linux since late 80's) can deal with, and what would make linux more popular and optimize the result.

Why, you poor young thing. :^) To be so young.

It's a simple multivariate equation. Solve for maximum. zypper isn't a program with a long history. There are few compatibility issues other than people being stuck in their old ways. But if you cater to them, no progress will ever be made.

You see *only* the small picture. Zypper must accept what the rest of linux accepts or it is different and in this case, that is bad, leads to confusion.

Being the person bitten by this instance of the bug (because I'm not used to differing case being accepted by two different package managers on linux, I am stating what would have made the situation acceptable to me -- as someone who as used unix and/or linux for over 20 years. A simple notification that it had ignored my case to make a match would be fine with me.

Agreed, it should not have ignored case and should have reported that it acted contrary to expected.

It would also make it more user friendly, which I think is a good thing.

User friendly is a "good thing" but not when it deviates from the "norm".

You aren't capable of adapting?

I have been *adapting* for 69 years :^).

-l

+2 -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-05-08 02:56, Linda Walsh wrote:

Patrick Shanahan wrote:

...

The cli is populated by humans. Not machines. Backwards compatibility is not as paramount. Bill Gates wanted to keep same interfacesin Windows because he thought his customers were incapable of adapting. I certainly DON't see as being the case among unix users, depsite some people's feelings that CLI operations should remain case sensitive.

It is poor design to rely on case as a differentiator between different functions. If you were to program constantly re-using variable names that vary only in 'case', you'd be cursed by any maintainers. Why? because it's difficult to maintain. Why is the CLI-interface any different?

C is that way, too.

If it was in any program -- someone would say "re-write the bad portions". Why shouldn't we strive to make CLI operations the best possible as well?

If you/we want case sensitivity/or not, it a global ENV var -- that might allow both sides to have what they want without having to type something 'extra' in at a command prompt.

The filesystem is case-sensitive, and that can not change, it is not possible to let users choose. It would have to be a universal change, and would break lot of things. Thus bash has to be case sensitive. Options/parameters to commands are also case sensitive. And thus rpm archives are also case sensitive. It is zypper which is different.

...

...

Being the person bitten by this instance of the bug (because I'm not used to differing case being accepted by two different package managers on linux, I am stating what would have made the situation acceptable to me -- as someone who as used unix and/or linux for over 20 years. A simple notification that it had ignored my case to make a match would be fine with me.

Agreed, it should not have ignored case and should have reported that it acted contrary to expected.

---

I didn't say it shouldn't have ignored case -- but that it should have *told* me it was doing so (i.e. doing something other than traditional behavior).

I feel that giving warning of non-tradition behavior is enough -- I don't feel that it has to adhere to traditional behavior. Why wouldn't the warning be sufficient (like either of us are going to do anything about this other than hash-at it here...;) )

Yes, zypper should have warned. It is an interesting feature that it searches ignoring case, but it should at least warn the user that if found a match with different case - as you say you were bitten by this. As zypper is a slow command, finding a package with a similar name that can be the one you wanted is an interesting feature. If warned. Then switches could be added to modify the behaviour. And devs have posted on this list, they are going to do something about this. The person who posted wasn't sure what exactly to do, and it will not be for 11.3, anyway. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvlLg0ACgkQU92UU+smfQU8oACfUYVk7UVU2yMWaXAx2zUbDG4l VRUAnjXnOZy9GghDeFw6HdpZZwDlrW1e =tMIN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Linda Walsh said the following on 05/07/2010 08:56 PM:

...

"Bill Gates logic", now that's an oxymoron! But, yes, things need to be backward compatable. Poor interface ??

---

Oxymoron..yeah...but can you argue w/success? 'Ultimately'? ;)

Go, Lemmings, Go! Microsoft shows the "success" of good marketing. In the 50s and 60s IBM demonstrated this too. its not about technical superiority, which neither company ever demonstrated, nor even about giving the customer what it wanted. It was about convincing the customer to buy what they offered. The could have been said about other aggressive advertisers of various eras. Consumers are herd animals. It takes a level of boredom (aka "this years GM is just last years GM without the tail fins and painted a different shade of blue") before consumers look else where. In reality, "fashion" has come to replace "innovation". -- I would rather be exposed to the inconveniences attending too much liberty, than those attending too small a degree of it. --Thomas Jefferson (letter to Archibald Stuart, Dec. 23, 1791, on the encroachments of state governments) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 05/08/2010 01:54 PM, Mihamina Rakotomandimby pecked at the keyboard and wrote:

...

Patrick Shanahan :

...

...

No! Linux is case-sensitive. And linux is famous for not being user-friendly. Something many people would like to see changed. Yes, the command-line is known for not being user-friendly,

It depends on the level on play in. At my level, nothing overtakes the command line.

The CLI *is* user friendly, it is generally the user that is not CLI friendly. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 06 May 2010 02:32:28 Linda Walsh wrote:

Michael Andres wrote:

...

On Wednesday 05 May 2010 14:40:52 Jano Kupec wrote:

...

I (and i hope many people too) find it annoying to type 'in MPlayer' instead of 'in mplayer', to give an example. So i qualify this as a feature.

IMO not. A human typing the name may say e.g. 'zypper in --ic mplayer' (--ic=ignore case). Or a --no-ic switch for scripts. Anyway I'd like to be able to influence the amount of AI.

--- agreed, But don't you agree, that to be friendlier to the general populace, that AI should be switched on by default, and that 'expert' mode should require the switch (--no-ic)

I still think the general populace appreciates predictable and reliable tools, so I can't agree. Not executing the comand as I typed it, is IMO not friendly but insubordinate :) Zypper is not the only command whose behavior I have to remember. If zypper was friendly, it would follow the 'Principle of Least Surprise' and behave like all the other cool commands: It would do exactly what I typed. I also don't think it's friendly to make some novice assume package names were not case sensitive. To me '--ic' is the expert switch, because you need to know that the names outside zypper may look different, and why. And in case you managed zypper to install mplayer and MPlayer at the same time, you need to be able to spot this and you need to know how to recover. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sat, 01 May 2010 17:23:11 -0700 Linda Walsh wrote:

Patrick Shanahan wrote:

...

* Linda Walsh [05-01-10 19:50]:

...

There seems to be a problem in nomemclature.

It seems en_US was equated with en_US.utf8.

I don't think so.

---

Ok...color me confused. Your values are everything that I *used* to see some time ago (Suse10.3). But haven't seen them since 11.1 upgrade when I thought I read something about unicode being made the default, so I thought it odd, but didn't stress it (had other things to stress more about! :-))...

Something is obviously messed up on my system.

Need to investigate further. Thanks for quick response.

-linda

This is from default install of 11.3-M6: tom@laptop= /home/tom $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= I didn't make any changes from default settings during install. -- Tom Taylor - retired penguin openSuSE 11.3-M6 x86_64 KDE 4.4.2, FF 3.6.3 linxt-AT-comcast.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Saturday, 2010-05-01 at 16:50 -0700, Linda Walsh wrote:

...

...

HOWEVER, setting any of my RC vars in /etc/sysconfig/language to en_US.UTF-8 (or utf8 or utf-8)

I have «RC_LANG="en_US.UTF-8"»

cer@nimrodel:~> locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME=en_DK.UTF-8 LC_COLLATE=POSIX LC_MONETARY=es_ES@euro LC_MESSAGES="en_US.UTF-8" LC_PAPER=es_ES@euro LC_NAME=es_ES@euro LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE=es_ES@euro LC_MEASUREMENT=es_ES@euro LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

...

results in errors from various programs that try to set locale (including the locale program), saying that it doesn't exist.

Maybe the locale is missing from your system :-?

Well that's where my 'side' issue (my self-hijack) came (comes?) in.

It works for me on 11.0 and 11.2.

Last time for sure I know all was right was 10.3, though I thought it worked in 11.1. I show

What's the exact output of locale? I once had problems and it turned out I had made a silly mistake when writing the env.

locale locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

This corresponds to me setting RC_LANG="en_US.UTF.8" in /etc/sysconfig/language. If I set "en_US", I get no error, and all of the above say en_US instead of en_US.UTF-8. But then other things that expect UTF-8 don't work correctly (or disable UTF-8 because it isn't in my locale string). See why I went side ways on the bug? This info in this 'bug' doesn't make sense, but in looking for files like the lines in /usr/lib/locale...there I see files for en_US.utf8 -- the only place I find a utf8 for windows. In /usr/share/local, I have only en and en_US, but no en_US.UTF-8 (or anything else for that manner). That's how I finally stumbled onto the package problem -- though it's with an x11 package and I'm not in X11...but looking at that I hoped that solving it might clear up something that might lead me in some positive direction becaue just staring at the problems with the locale alone lead me to a blank. Sorry, if it seems like I go in different directions -- they start out related. just that if I'm stumped on one front, I try to solve problems on another hoping something will affect the logjam at the first. -linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Ok, "check", (not going to bother including everything you wrote -- there'd be no point. Other than to write "I agree". I don't think I've gotten to any solution yet. I put "en_US" in the RC_LANG. Then I upon remote login, I'm getting: -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US): No such file or directory -bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US): No such file or directory -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US): No such file or directory -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US): No such file or directory -bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US) -bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US) -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US) -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US) -bash: warning: setlocale: LC_TIME: cannot change locale (en_US) -bash: warning: setlocale: LC_TIME: cannot change locale (en_US) -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US) -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US) -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US) -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US) Ishtar:law> locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= ---- I had worked around this before with a kluge symlink in /usr/lib/locale: en_US -> en_US.utf8 but en_US -> en_US.C works 'as well' (in not giving the error message). However, this implies that the above error messages come from my "RC_LANG" not existing in /usr/lib/local (recall the advice is to set to 'en_US', no suffix, but that value "en_US" doesn't exist in /usr/lib/locale. So why aren't my env-settings getting set to en_US.utf8 before that point like everyone else's appear to be. Geez this is annoying .. Darn M5 computer -- built before utf8 existed, so it really doesn't like that...(yes, I'm crossing the metaphor beams and this could be 'bad'...:-) ). Sigh ...back to drawing board. Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan wrote:

* Linda Walsh [05-02-10 22:30]:

...

Ok, "check", (not going to bother including everything you wrote -- there'd be no point. Other than to write "I agree".

I don't think I've gotten to any solution yet.

I put "en_US" in the RC_LANG. Then I upon remote login, I'm getting:

what is the matter with setting it to: en_US.UTF-8

note that case and punctuation is necessar, utf8 will NOT work.

--- Got that -- and I get this upon login: -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8) -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8)

locale locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

and every manpage starts with: man: can't set the locale; make sure $LC_* and $LANG are correct and then displays the manpage content... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

Ok, then. I mentioned that the locales come in glib-locale? Run

rpm -qa | grep -i locale ==== (compared to running and interpreting an strace, this one is more quickly done, so more immediate response): rpm -qa|grep -i locale mono-locale-extras-2.4.2.3-2.3.x86_64 gcc-locale-4.4-4.2.x86_64 gcc43-locale-4.3.4_20090804-2.4.x86_64 glibc-locale-2.10.1-10.5.1.x86_64 gcc44-locale-4.4.1_20090817-2.3.4.x86_64 glibc-locale-32bit-2.10.1-10.5.1.x86_64

to check. Then try:

locale -a | grep en

---

locale -a |grep en locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory en_AG en_AU en_AU.utf8 en_BE en_BE.utf8 en_BE@euro en_BW en_BW.utf8 en_CA en_CA.utf8 en_DK en_DK.utf8 en_GB en_GB.iso885915 en_GB.utf8 en_HK en_HK.utf8 en_IE en_IE.utf8 en_IE@euro en_IN en_IN.utf8 en_NG en_NZ en_NZ.utf8 en_PH en_PH.utf8 en_SG en_SG.utf8 en_US.C en_US.iso885915 en_US.utf8 en_ZA en_ZA.utf8 en_ZW en_ZW.utf8

to see what English locales the system finds. Then try running commands with different locales. Like:

---- I don't have any UTF-8 locales. They are all misspelled with utf8. !? I know that's a common misspelling, but I didn't change them (this was why I was trying '.uft8', in LANG, even though some parts claim it is wrong... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 03 May 2010 21:09:42 -0700, Linda Walsh wrote:

I don't have any UTF-8 locales. They are all misspelled with utf8. !? I know that's a common misspelling, but I didn't change them (this was why I was trying '.uft8', in LANG, even though some parts claim it is wrong...

That must be a red hering. I just checked on a working 11.0 installation and there locale also gave the same output. If you had done the strace I mentioned you would have seen that the locale info is in /usr/lib/locale. The error messages result from either /usr/lib/locale/en_US.utf8 or one of the files it contains being absent. Check that glibc-locale is installed and possibly reinstall it. BTW, if you check /usr/lib/locale you'll see that and all locale encodings are in lower case! AFAIR UTF-8 has to be used because of broken X11 locales. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Complete strace output is consistent with what we are seeing -- it looks for xxx.UTF-8, as set in LANG, but the dir's only have xxx.utf8 -- at least that's how I interpret this mess: (with /etc/sysconfig/language non null or not "" vals: RC_LANG="en_US" ROOT_USES_LANG="yes" AUTO_DETECT_UTF8="yes" INSTALLED_LANGUAGES="en_US" RC_LC_CTYPE="en_US.UTF-8" )

strace locale 2>&1 |more execve("/usr/bin/locale", ["locale"], [/* 111 vars */]) = 0 brk(0) = 0x1ab0000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f9a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f99000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/tls/x86_64", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/tls", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/x86_64", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=335305, ...}) = 0 mmap(NULL, 335305, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa4a6f47000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\353\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1408560, ...}) = 0 mmap(NULL, 3516488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa4a6a23000 fadvise64(3, 0, 3516488, POSIX_FADV_WILLNEED) = 0 mprotect(0x7fa4a6b74000, 2097152, PROT_NONE) = 0 mmap(0x7fa4a6d74000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x151000) = 0x7fa4a6d74000 mmap(0x7fa4a6d79000, 18504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6d79000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f46000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f45000 arch_prctl(ARCH_SET_FS, 0x7fa4a6f456f0) = 0 mprotect(0x7fa4a6d74000, 16384, PROT_READ) = 0 mprotect(0x606000, 4096, PROT_READ) = 0 mprotect(0x7fa4a6f9b000, 4096, PROT_READ) = 0 munmap(0x7fa4a6f47000, 335305) = 0 brk(0) = 0x1ab0000 brk(0x1ad1000) = 0x1ad1000 open("/usr/lib/locale/locale-archive", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY) = 3 execve("/usr/bin/locale", ["locale"], [/* 111 vars */]) = 0 brk(0) = 0x1ab0000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f9a000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f99000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/tls/x86_64", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/tls", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64/x86_64", 0x7fffccb910f0) = -1 ENOENT (No such file or directory) open("/usr/lib64/mpi/gcc/openmpi/lib64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib64/mpi/gcc/openmpi/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=335305, ...}) = 0 mmap(NULL, 335305, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa4a6f47000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\353\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1408560, ...}) = 0 mmap(NULL, 3516488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa4a6a23000 fadvise64(3, 0, 3516488, POSIX_FADV_WILLNEED) = 0 mprotect(0x7fa4a6b74000, 2097152, PROT_NONE) = 0 mmap(0x7fa4a6d74000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x151000) = 0x7fa4a6d74000 mmap(0x7fa4a6d79000, 18504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6d79000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f46000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f45000 arch_prctl(ARCH_SET_FS, 0x7fa4a6f456f0) = 0 mprotect(0x7fa4a6d74000, 16384, PROT_READ) = 0 mprotect(0x606000, 4096, PROT_READ) = 0 mprotect(0x7fa4a6f9b000, 4096, PROT_READ) = 0 munmap(0x7fa4a6f47000, 335305) = 0 brk(0) = 0x1ab0000 brk(0x1ad1000) = 0x1ad1000 open("/usr/lib/locale/locale-archive", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2512, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f98000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2512 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa4a6f98000, 4096) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=256316, ...}) = 0 mmap(NULL, 256316, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa4a6f5a000 close(3) = 0 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26050, ...}) = 0 mmap(NULL, 26050, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa4a6f53000 close(3) = 0 open("/usr/lib/locale/en_US/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "locale: ", 8locale: ) = 8 write(2, "Cannot set LC_MESSAGES to defaul"..., 40Cannot set LC_MESSAGES to default locale) = 40 write(2, ": No such file or directory", 27: No such file or directory) = 27 write(2, "\n", 1 ) = 1 open("/usr/lib/locale/en_US/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "locale: ", 8locale: ) = 8 write(2, "Cannot set LC_ALL to default loc"..., 35Cannot set LC_ALL to default locale) = 35 write(2, ": No such file or directory", 27: No such file or directory) = 27 write(2, "\n", 1 ) = 1 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4a6f52000 write(1, "LANG=en_US\nLC_CTYPE=en_US.UTF-8\n"..., 256LANG=en_US LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= ) = 256 exit_group(0) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 04 May 2010 11:21:13 -0700, Linda Walsh wrote:

even though I have RC_LANG="en_US.UTF-8",

Look in /usr/lib/locale, that's where glibc has all the locale specific data :) glibc internally uses all lower case encoding names where even the dashes are missing so you'll get sv_SE.iso885915 which really is sv_SE.ISO-8859-15. When you look at the strace log you'll see that even though LANG is en_US.UTF-8, glibc will first try that and then later search for en_US.utf8 and succeed.

Why it doesn't want en_US.UTF-8, there, I don't know...

Ask the glibc developers upstream.

Why doesn't it have en_US.UTF-8 and en_US there when it only wants to use "en_US"...?

This is the internal organisation of the binary glibc locale data which shouldn't concern you, just like the structure for storing compiled terminfo data. If you're curious read up in libc.info

en_US, en_US.UTF-8, if they are supposed to be the same?

No they are not supposed to be the same.

Nearly all the files are different.

Does that mean it's using a non UTF-8 encoding for most of my 'locale' values? I.e.:

No. But *please* read libc info on locale data before speculating further.

Thanks for helping me what I should have been able to discover on my own...(hitting self on head)...and sorry for time waste...though still confused about why en_US and en_US.utf8 are different when I am choosing UTF-8 in LANG...(but it looks in en_US for messages, not

Message catalogs are below /usr/share/locale, not /usr/lib/locale! Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 05/05/10 03:08, Linda Walsh wrote:

Philipp Thomas wrote:

...

This is the internal organisation of the binary glibc locale data which shouldn't concern you, just like the structure for storing compiled terminfo data. If you're curious read up in libc.info

--- Thanks for the pointer.

Is there an HTML autotranslater function for .info? Seems like it would be a fairly straight forward mapping...would allow style rules to make pages easier to read (larger fonts than my standard programming font, trackball, wheel for scrolling rather than cursor keys...etc.

If you are using KDE, try browsing using the info:/ kio-slave in Konqueror, e.g. type info:/sed into the location bar. This automagically converts everything to a nice html and displays it. This works for man:/ as well. Otherwise if you want to do it manually look for info2html. Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, 02 May 2010 21:14:50 -0700, Linda Walsh wrote:

man: can't set the locale; make sure $LC_* and $LANG are correct

I'd say this calls for running 'strace -e trace=file locale' and then try to detect from the output where it fails. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org