Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread J. Roeleveld
On Thursday, July 17, 2014 06:52:20 AM J. Roeleveld wrote:
 On 16 July 2014 19:26:39 CEST, Dale rdalek1...@gmail.com wrote:
 Dark Templar wrote:
  When I reinstalled gcc and glibc, migrating from non-multilib amd64
 
 arch
 
  to multilib one, I just unpacked gentoo stage3 into temporary
 
 directory,
 
  chrooted there, made binary packages out of installed ones 
(quickpkg
  name), copied resulted binary packages and their metadata to 
host
  system (i.e. moved $chroot/usr/portage/packages into
  /usr/portage/packages) and installed those binary packages 
replacing
  current ones. It's fast (you don't have to build packages from
 
 scratch),
 
  and it didn't fail me even once, although I heard playing with glibc
  such way may be dangerous (particularly, downgrading it). I guess it
  works for other purposes too.
  
  I don't like installing from scratch if there is a way to fix it. I
  don't like that approach 'unpack stage on top of your system',
 
 because
 
  it will lead to system pollution: a lot of files might be no longer
  tracked by package manager after that.
  
  But that's just my experience and opinion. I hope it can help you.
 
 If I can install something as a binary and then get a clean emerge -e
 system/world out of it, I think it would be OK.  Thing is, I'm
 concerned
 something is amiss with the stage3 tarball.  If that is the case, I
 want
 to inform the person that overseas that so it can be fixed.  Installing
 Gentoo is hard enough for someone seasoned but would be a 
nightmare for
 someone new to Gentoo.
 
 Now to figure out what is the root problem on this thing.
 
 Dale
 
 :-)  :-)
 
 Dale.
 
 I will try to use the x86 stage3 on a VM today. Will let you know how far I
 get.
 
 --
 Joost

Update:
Using a 32bit VM with current x86 stage3 file, glibc builds succesfully. (On 
first run)

Will do a second  emerge -ve @system  when this one is finished.

I used the following stage file:
stage3-i686-20140708.tar.bz2

I have not change anything in /etc/portage

--
Joost


Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Alan McKinnon
On 16/07/2014 18:45, Volker Armin Hemmann wrote:
 Am 16.07.2014 09:07, schrieb Dale:
 Alan McKinnon wrote:
 I use KDE's plasma pager. It gives a nice MacOS-like grid layout that
 pops up when switching virtual desktops. Trouble is, the thing doesn't
 enable itself when starting KDE, I have to do that manually:

 right click pager in panel - pager settings - Virtual desktops -
 Switching - Show desktop layout indicators

 disable and re-enable it brings the popup back. It's now getting
 annoying, and things like .xsesssion-errors are devoid of useful info on
 the matter. Tips anyone?

 Note this is the virtual desktop layout popup, it shows up in the middle
 of the screen. It's not the keyboard layout widget in the panel.


 I have noticed something else odd as well.  I use folder layout, like
 KDE3 had, for my KDE desktop setup.  When I login to KDE, I have to
 switch to some other layout then switch back to folder to get my icons
 to show up.  Once in a blue moon, it works as it should but most of the
 time, I have to go through this to get it to look like I have it set to
 look. 

 It's a different issue but could have a common cause.  It seems some
 setting/config doesn't get stored properly.  Then when we login, we have
 to undo/redo to get it to work. 

 I have been putting up with my issue for about a year or so.  I haven't
 done any research as to bug reports etc because I'm not real sure what
 to look for.

 Could be totally different, could be related.  Just thought it worth
 adding to the pot.  ;-)

 Dale

 :-)  :-) 


 
 easiest way to test: new user. Copy over config files until problem occurs.


doh
Yes of course, that's the best way. Didn't think of that


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread Dale
J. Roeleveld wrote:

 Update:

 Using a 32bit VM with current x86 stage3 file, glibc builds
 succesfully. (On first run)

  

 Will do a second  emerge -ve @system  when this one is finished.

  

 I used the following stage file:

 stage3-i686-20140708.tar.bz2

  

 I have not change anything in /etc/portage

  

 --

 Joost



Sounds good.  I'm downloading that one and will try to install it next. 
Let's hope it was a one time event.

Thanks for testing it. 

Dale

:-)  :-) 


Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread J. Roeleveld
On Thursday, July 17, 2014 04:03:34 AM Dale wrote:
 J. Roeleveld wrote:
  Update:
  
  Using a 32bit VM with current x86 stage3 file, glibc builds
  succesfully. (On first run)
  
  
  
  Will do a second  emerge -ve @system  when this one is finished.
  
  
  
  I used the following stage file:
  
  stage3-i686-20140708.tar.bz2
  
  
  
  I have not change anything in /etc/portage
  
  
  
  --
  
  Joost
 
 Sounds good.  I'm downloading that one and will try to install it next.
 Let's hope it was a one time event.
 
 Thanks for testing it.

2nd run active, doing it with @world now instead of @system.
211 packages.
Only change done to /etc/portage/make.conf:

Added   FEATURES=buildpkg  

Will let you know when this run has finished.
I should also be able to provide the package-dir to you if needed.
Am using the latest stable gentoo-sources (3.12.21-r1) using the default 
config:
# make mrproper
# make distclean
# make menuconfig
(Only unset the 64bit kernel option)

# make
# make modules_install

(This actually worked ;) )
--
Joost



Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread Peter Humphrey
On Thursday 17 July 2014 04:03:34 Dale wrote:

---8

 Sounds good.  I'm downloading that one and will try to install it next.
 Let's hope it was a one time event.
 
 Thanks for testing it.

I've just started installing a 64-bit chroot to do the emerge work for my 
laptop and I fell into the same error as you, Dale. Well, I haven't checked 
all the details but it seems similar.

The odd thing is that I used a not-very-recent stage-3 that I'd already used 
to install from - without problems that time. So I emerged glib and glibc in 
the new, raw system and ran 'emerge --config sys-libs/timezone-data' again 
with no problem. I had copied in a /etc/locale.gen and /etc/timezone from 
another system first.

I don't know whether I needed to emerge glib, or just glibc. I'm going to have 
to emerge glib again after I've emerged and set up gentoo-sources.

-- 
Regards
Peter




Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread J. Roeleveld
On Thursday, July 17, 2014 11:19:36 AM J. Roeleveld wrote:
 On Thursday, July 17, 2014 04:03:34 AM Dale wrote:
  J. Roeleveld wrote:
   Update:
   
   Using a 32bit VM with current x86 stage3 file, glibc builds
   succesfully. (On first run)
   
   
   
   Will do a second  emerge -ve @system  when this one is finished.
   
   
   
   I used the following stage file:
   
   stage3-i686-20140708.tar.bz2
   
   
   
   I have not change anything in /etc/portage
   
   
   
   --
   
   Joost
  
  Sounds good.  I'm downloading that one and will try to install it next.
  Let's hope it was a one time event.
  
  Thanks for testing it.
 
 2nd run active, doing it with @world now instead of @system.
 211 packages.
 Only change done to /etc/portage/make.conf:
 
 Added   FEATURES=buildpkg  
 
 Will let you know when this run has finished.
 I should also be able to provide the package-dir to you if needed.
 Am using the latest stable gentoo-sources (3.12.21-r1) using the default
 config:
 # make mrproper
 # make distclean
 # make menuconfig
 (Only unset the 64bit kernel option)
 
 # make
 # make modules_install
 
 (This actually worked ;) )
 --
 Joost

Update:
No issues with glibc.
I am not doing any parallel builds (eg. default of -j 1 is used)

Let me know if you want any files for comparison.

--
Joost


Re: [gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

2014-07-17 Thread Peter Humphrey
On Thursday 17 July 2014 10:20:59 I wrote:
 On Thursday 17 July 2014 04:03:34 Dale wrote:
 
 ---8
 
  Sounds good.  I'm downloading that one and will try to install it next.
  Let's hope it was a one time event.
  
  Thanks for testing it.
 
 I've just started installing a 64-bit chroot to do the emerge work for my
 laptop and I fell into the same error as you, Dale. Well, I haven't checked
 all the details but it seems similar.
 
 The odd thing is that I used a not-very-recent stage-3 that I'd already used
 to install from - without problems that time. So I emerged glib and glibc
 in the new, raw system and ran 'emerge --config sys-libs/timezone-data'
 again with no problem. I had copied in a /etc/locale.gen and /etc/timezone
 from another system first.

Some other things were going wrong with the new installation, so I downloaded 
the latest amd64 stage-3, installed afresh using that and all is going 
swimmingly. Emerge -e world is in progress now.

HTH. HaND.

-- 
Regards
Peter




Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Dale
Alan McKinnon wrote:
 On 16/07/2014 18:45, Volker Armin Hemmann wrote:

 easiest way to test: new user. Copy over config files until problem occurs.

 doh
 Yes of course, that's the best way. Didn't think of that



I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
in, set up enough that I could test things and then logged out.  When I
logged back in, it worked like it should.  Let's see how long that lasts. 

Alan, make sure you change the permissions on those file.  I have a test
account that I rarely use as well.  In the past, I had to change the
owner from dale to dale2 which is my account names.  Usually the group
is the same so the owner is all that needs changing. 

Hope that helps.

Dale

:-)  :-) 



Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Neil Bothwick
On Thu, 17 Jul 2014 14:42:27 -0500, Dale wrote:

 I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
 in, set up enough that I could test things and then logged out.  When I
 logged back in, it worked like it should.  Let's see how long that
 lasts. 

I just emerge the latest KDE upgrades, on two systems, without
renaming .kde4 and everything works just as it should. How long will it
last? Well, KDE updates are every two months, and each of the previous
one has survived the two months until the next one.

But then, I'm not Dale


-- 
Neil Bothwick

QOTD:
The only easy way to tell a hamster from a gerbil is that the
gerbil has more dark meat.


signature.asc
Description: PGP signature


Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Alan McKinnon
On 17/07/2014 21:42, Dale wrote:
 Alan McKinnon wrote:
 On 16/07/2014 18:45, Volker Armin Hemmann wrote:

 easiest way to test: new user. Copy over config files until problem occurs.

 doh
 Yes of course, that's the best way. Didn't think of that


 
 I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
 in, set up enough that I could test things and then logged out.  When I
 logged back in, it worked like it should.  Let's see how long that lasts. 
 
 Alan, make sure you change the permissions on those file.  I have a test
 account that I rarely use as well.  In the past, I had to change the
 owner from dale to dale2 which is my account names.  Usually the group
 is the same so the owner is all that needs changing. 

Why change the permissions? They must be rw for the user using them
which means chmod 6xx, the group being entirely irrelevant as it will
never be referenced. If the new user is doing the copy then they will be
owned by that new user anyway. cp -a will just always do the right
thing in this case :-)


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Dale
Alan McKinnon wrote:
 On 17/07/2014 21:42, Dale wrote:
 Alan McKinnon wrote:
 On 16/07/2014 18:45, Volker Armin Hemmann wrote:
 easiest way to test: new user. Copy over config files until problem occurs.
 doh
 Yes of course, that's the best way. Didn't think of that


 I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
 in, set up enough that I could test things and then logged out.  When I
 logged back in, it worked like it should.  Let's see how long that lasts. 

 Alan, make sure you change the permissions on those file.  I have a test
 account that I rarely use as well.  In the past, I had to change the
 owner from dale to dale2 which is my account names.  Usually the group
 is the same so the owner is all that needs changing. 
 Why change the permissions? They must be rw for the user using them
 which means chmod 6xx, the group being entirely irrelevant as it will
 never be referenced. If the new user is doing the copy then they will be
 owned by that new user anyway. cp -a will just always do the right
 thing in this case :-)



Well, I usually copy as root which leaves the permissions the same. 
Since you do it as user then you are right. 

Dale

:-)  :-) 



Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Dale
Neil Bothwick wrote:
 On Thu, 17 Jul 2014 14:42:27 -0500, Dale wrote:

 I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
 in, set up enough that I could test things and then logged out.  When I
 logged back in, it worked like it should.  Let's see how long that
 lasts. 
 I just emerge the latest KDE upgrades, on two systems, without
 renaming .kde4 and everything works just as it should. How long will it
 last? Well, KDE updates are every two months, and each of the previous
 one has survived the two months until the next one.

 But then, I'm not Dale



Well, this broke a good while back after a upgrade.  It could be that it
is the way I have my desktop set up that few if anyone else uses.  I've
had to do this a couple times before for sure.  It just breaks sometimes
and I get to start our fresh.

Dale

:-)  :-)



Re: [gentoo-user] Can emerge play a sound on either a successful/unsuccessful build?

2014-07-17 Thread john
On Wed, 16 Jul 2014 21:00:42 +0200
J. Roeleveld jo...@antarean.org wrote:

 On 16 July 2014 18:46:16 CEST, galiza.ce...@gmail.com wrote:
 J. Roeleveld jo...@antarean.org writes:
 
  On Monday, July 14, 2014 12:46:48 PM Neil Bothwick wrote:
 
  I actually have it send an alert to my phone with Posterous but
  you
  can
 
  do whatever you want.
 
   
 
  Which Posterous is this?
 
  When I google it, I only get information that it actually got shut
  down after being bought by Twitter.
 
   
 
  I am looking for a cheap method to get notifications to my mobile
  phone. I used to use a free SMS service via a company in SA.
 
 
 Maybe Telegram[1] fits your needs. You'd need:
 
 - The appropriate client on the phone side.
 - Telegram CLI [2] on the computer.
 - A little shell script, such as (usage: script USER MESSAGE)
   #!/bin/sh
   /path/to/telegram -B -k /path/to/tg.pub AAA
 
   msg $1 $2
   safe_quit
   AAA
 You could also send logfiles (^msg^send_text, $2 being the path to
 text
   file)
 
 HTH
 
 [1] http://www.telegram.org
 [2] https://github.com/vysheng/tg
 
 
  --
 
  JOOST
 
 
 
 
 This and pushover look interesting.
 
 But I also need something that doesn't require a data connection.
 I am occasionally in places with bad reception and SMS is often still
 usable. Never mind the cost of maintaining a data connection while
 roaming. (Receiving SMS is free in any country I care to visit with
 my contract)
 
 I don't mind paying for the service. But it needs to be affordable.
 
 --
 Joost

Hmm,

From this there should be a change to Gentoo policy. For every
sucessful ebuild emerged there should be a rendition of Run Like Hell

I wonder what songs are appropriate to Gentoo?

-- 
John D Maunder



Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Dale
Howdy, different rig but similar issue.  This is on my main rig now.  It
is AMD64 multilib.  I am doing a emerge -e world, which I do from time
to time.  After that got to the point where it is almost done, I started
getting this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = en_US.UTF8,
LANG = en_US.UTF8
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

and like this:

/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
 Regenerating /etc/ld.so.cache...
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8) 

The error seems to vary depending on command run.  This is my locale.gen
file:

LANG=en_US.UTF8
LC_CTYPE=en_US.UTF8
LC_NUMERIC=en_US.UTF8
LC_TIME=en_US.UTF8
LC_COLLATE=en_US.UTF8
LC_MONETARY=en_US.UTF8
LC_MESSAGES=en_US.UTF8
LC_PAPER=en_US.UTF8
LC_NAME=en_US.UTF8
LC_ADDRESS=en_US.UTF8
LC_TELEPHONE=en_US.UTF8
LC_MEASUREMENT=en_US.UTF8

I'm on sys-libs/glibc-2.17 right now. 

Now riddle me this, why is this popping up all of a sudden?  Did
something change and I missed it?  When I google, I find folks with
settings like mine and it works.  Is this something new that just hasn't
hit everyone yet? 

Confused.

Dale

:-)  :-)



Re: [gentoo-user] KDE plasma pager layout indicator

2014-07-17 Thread Alan McKinnon
On 17/07/2014 23:31, Dale wrote:
 Alan McKinnon wrote:
 On 17/07/2014 21:42, Dale wrote:
 Alan McKinnon wrote:
 On 16/07/2014 18:45, Volker Armin Hemmann wrote:
 easiest way to test: new user. Copy over config files until problem 
 occurs.
 doh
 Yes of course, that's the best way. Didn't think of that


 I just did my KDE upgrade so I renamed the .kde4 directory.  I logged
 in, set up enough that I could test things and then logged out.  When I
 logged back in, it worked like it should.  Let's see how long that lasts. 

 Alan, make sure you change the permissions on those file.  I have a test
 account that I rarely use as well.  In the past, I had to change the
 owner from dale to dale2 which is my account names.  Usually the group
 is the same so the owner is all that needs changing. 
 Why change the permissions? They must be rw for the user using them
 which means chmod 6xx, the group being entirely irrelevant as it will
 never be referenced. If the new user is doing the copy then they will be
 owned by that new user anyway. cp -a will just always do the right
 thing in this case :-)


 
 Well, I usually copy as root which leaves the permissions the same. 
 Since you do it as user then you are right. 


DO NOT DO THAT COPY AS ROOT. That's just needlessly
asking for trouble.

Do it as the destination user, as long as it can read the source user's
home dir it all works out fine. Group membership is usually sufficient
and the only case where it's an issue is if home dirs are set to
rwx-- or encrypted


-- 
Alan McKinnon
alan.mckin...@gmail.com




[gentoo-user] Root Certificate not trusted

2014-07-17 Thread Mick
Hi All,

Recently (in the last month or so) I noticed that one of my SSL certificates 
that I use for email, issued by Comodo is no longer recognised as 'trusted'.

In particular, it is the Root CA which is not trusted which is confusing me.  
The certificate in question is:

$ ls -la /etc/ssl/certs/AddTrust_External_Root.pem
lrwxrwxrwx 1 root root 61 Jul 14 21:49 
/etc/ssl/certs/AddTrust_External_Root.pem - /usr/share/ca-
certificates/mozilla/AddTrust_External_Root.cr


Its contents are:

$ openssl x509 -in /etc/ssl/certs/AddTrust_External_Root.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
CN=AddTrust External CA Root
Validity
Not Before: May 30 10:48:38 2000 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
CN=AddTrust External CA Root
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b7:f7:1a:33:e6:f2:00:04:2d:39:e0:4e:5b:ed:
1f:bc:6c:0f:cd:b5:fa:23:b6:ce:de:9b:11:33:97:
a4:29:4c:7d:93:9f:bd:4a:bc:93:ed:03:1a:e3:8f:
cf:e5:6d:50:5a:d6:97:29:94:5a:80:b0:49:7a:db:
2e:95:fd:b8:ca:bf:37:38:2d:1e:3e:91:41:ad:70:
56:c7:f0:4f:3f:e8:32:9e:74:ca:c8:90:54:e9:c6:
5f:0f:78:9d:9a:40:3c:0e:ac:61:aa:5e:14:8f:9e:
87:a1:6a:50:dc:d7:9a:4e:af:05:b3:a6:71:94:9c:
71:b3:50:60:0a:c7:13:9d:38:07:86:02:a8:e9:a8:
69:26:18:90:ab:4c:b0:4f:23:ab:3a:4f:84:d8:df:
ce:9f:e1:69:6f:bb:d7:42:d7:6b:44:e4:c7:ad:ee:
6d:41:5f:72:5a:71:08:37:b3:79:65:a4:59:a0:94:
37:f7:00:2f:0d:c2:92:72:da:d0:38:72:db:14:a8:
45:c4:5d:2a:7d:b7:b4:d6:c4:ee:ac:cd:13:44:b7:
c9:2b:dd:43:00:25:fa:61:b9:69:6a:58:23:11:b7:
a7:33:8f:56:75:59:f5:cd:29:d7:46:b7:0a:2b:65:
b6:d3:42:6f:15:b2:b8:7b:fb:ef:e9:5d:53:d5:34:
5a:27
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: 
AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
X509v3 Key Usage: 
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier: 

keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
DirName:/C=SE/O=AddTrust AB/OU=AddTrust External TTP 
Network/CN=AddTrust External CA Root
serial:01

Signature Algorithm: sha1WithRSAEncryption
 b0:9b:e0:85:25:c2:d6:23:e2:0f:96:06:92:9d:41:98:9c:d9:
 84:79:81:d9:1e:5b:14:07:23:36:65:8f:b0:d8:77:bb:ac:41:
 6c:47:60:83:51:b0:f9:32:3d:e7:fc:f6:26:13:c7:80:16:a5:
 bf:5a:fc:87:cf:78:79:89:21:9a:e2:4c:07:0a:86:35:bc:f2:
 de:51:c4:d2:96:b7:dc:7e:4e:ee:70:fd:1c:39:eb:0c:02:51:
 14:2d:8e:bd:16:e0:c1:df:46:75:e7:24:ad:ec:f4:42:b4:85:
 93:70:10:67:ba:9d:06:35:4a:18:d3:2b:7a:cc:51:42:a1:7a:
 63:d1:e6:bb:a1:c5:2b:c2:36:be:13:0d:e6:bd:63:7e:79:7b:
 a7:09:0d:40:ab:6a:dd:8f:8a:c3:f6:f6:8c:1a:42:05:51:d4:
 45:f5:9f:a7:62:21:68:15:20:43:3c:99:e7:7c:bd:24:d8:a9:
 91:17:73:88:3f:56:1b:31:38:18:b4:71:0f:9a:cd:c8:0e:9e:
 8e:2e:1b:e1:8c:98:83:cb:1f:31:f1:44:4c:c6:04:73:49:76:
 60:0f:c7:f8:bd:17:80:6b:2e:e9:cc:4c:0e:5a:9a:79:0f:20:
 0a:2e:d5:9e:63:26:1e:55:92:94:d8:82:17:5a:7b:d0:bc:c7:
 8f:4e:86:04
-BEGIN CERTIFICATE-
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN

Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Mick
On Thursday 17 Jul 2014 22:41:45 Dale wrote:
 Howdy, different rig but similar issue.  This is on my main rig now.  It
 is AMD64 multilib.  I am doing a emerge -e world, which I do from time
 to time.  After that got to the point where it is almost done, I started
 getting this:
 
 perl: warning: Setting locale failed.
 perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = en_US.UTF8,
 LANG = en_US.UTF8
 are supported and installed on your system.
 perl: warning: Falling back to the standard locale (C).
 sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
 
 and like this:
 
 /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
 
  Regenerating /etc/ld.so.cache...
 
 sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
 
 The error seems to vary depending on command run.  This is my locale.gen
 file:
 
 LANG=en_US.UTF8
 LC_CTYPE=en_US.UTF8
 LC_NUMERIC=en_US.UTF8
 LC_TIME=en_US.UTF8
 LC_COLLATE=en_US.UTF8
 LC_MONETARY=en_US.UTF8
 LC_MESSAGES=en_US.UTF8
 LC_PAPER=en_US.UTF8
 LC_NAME=en_US.UTF8
 LC_ADDRESS=en_US.UTF8
 LC_TELEPHONE=en_US.UTF8
 LC_MEASUREMENT=en_US.UTF8
 
 I'm on sys-libs/glibc-2.17 right now.
 
 Now riddle me this, why is this popping up all of a sudden?  Did
 something change and I missed it?  When I google, I find folks with
 settings like mine and it works.  Is this something new that just hasn't
 hit everyone yet?
 
 Confused.

/etc/locale.gen ought to show something like:

en_US.UTF-8 UTF-8

rather than what you show in your message.  /etc/env.d/02locale can show what 
you have in your message above, but typically only this is necessary:

LANG=en_US.UTF-8

(In mine I also have: LC_TIME=POSIX and LC_COLLATE=C, but most users 
wouldn't).

-- 
Regards,
Mick


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


Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Peter Humphrey
On Thursday 17 July 2014 16:41:45 Dale wrote:

 This is my locale.gen file:
 
 LANG=en_US.UTF8
 LC_CTYPE=en_US.UTF8
 LC_NUMERIC=en_US.UTF8
 LC_TIME=en_US.UTF8
 LC_COLLATE=en_US.UTF8
 LC_MONETARY=en_US.UTF8
 LC_MESSAGES=en_US.UTF8
 LC_PAPER=en_US.UTF8
 LC_NAME=en_US.UTF8
 LC_ADDRESS=en_US.UTF8
 LC_TELEPHONE=en_US.UTF8
 LC_MEASUREMENT=en_US.UTF8

Dale, why are you setting all those values yourself? As far as I know, the 
only one you need to set is the first one: LANG. The rest of them should all 
be taken care of by portage - unless you have very particular (i.e. special) 
requirements. I don't have any of those values set anywhere; look:

$ grep -r LC_ /etc
/etc/init.d/hwclock:if LC_ALL=C hwclock --help 21 | grep -q 
\-\-noadjfile; then
/etc/portage/savedconfig/sys-apps/busybox-1.21.0:# CONFIG_FEATURE_IPCALC_FANCY 
is not set
/etc/portage/savedconfig/sys-apps/busybox-1.21.0:# 
CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
/etc/ssh/ssh_config:SendEnv LANG LC_*

This is my /etc/locale.gen:

en_GB.UTF-8 UTF-8
en_GB ISO-8859-1
en_GB.ISO-8859-15 ISO-8859-15

I don't remember why I still have those last two entries; I expect they date 
from before Gentoo adopted UTF-8. Maybe I'll remove them and see what happens.

It's an easy trap to fall into: over-specifying details just because Gentoo 
lets you do so, in contrast to other distros.

KISS  :)

-- 
Regards
Peter




Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Dale
Mick wrote:
 On Thursday 17 Jul 2014 22:41:45 Dale wrote:
 Howdy, different rig but similar issue.  This is on my main rig now.  It
 is AMD64 multilib.  I am doing a emerge -e world, which I do from time
 to time.  After that got to the point where it is almost done, I started
 getting this:

 perl: warning: Setting locale failed.
 perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = en_US.UTF8,
 LANG = en_US.UTF8
 are supported and installed on your system.
 perl: warning: Falling back to the standard locale (C).
 sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

 and like this:

 /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

 Regenerating /etc/ld.so.cache...
 sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

 The error seems to vary depending on command run.  This is my locale.gen
 file:

 LANG=en_US.UTF8
 LC_CTYPE=en_US.UTF8
 LC_NUMERIC=en_US.UTF8
 LC_TIME=en_US.UTF8
 LC_COLLATE=en_US.UTF8
 LC_MONETARY=en_US.UTF8
 LC_MESSAGES=en_US.UTF8
 LC_PAPER=en_US.UTF8
 LC_NAME=en_US.UTF8
 LC_ADDRESS=en_US.UTF8
 LC_TELEPHONE=en_US.UTF8
 LC_MEASUREMENT=en_US.UTF8

 I'm on sys-libs/glibc-2.17 right now.

 Now riddle me this, why is this popping up all of a sudden?  Did
 something change and I missed it?  When I google, I find folks with
 settings like mine and it works.  Is this something new that just hasn't
 hit everyone yet?

 Confused.
 /etc/locale.gen ought to show something like:

 en_US.UTF-8 UTF-8

 rather than what you show in your message.  /etc/env.d/02locale can show what 
 you have in your message above, but typically only this is necessary:

 LANG=en_US.UTF-8

 (In mine I also have: LC_TIME=POSIX and LC_COLLATE=C, but most users 
 wouldn't).


I got that off a howto somewhere.  I think it is a Gentoo one.  Anyway,
commented all that out and left the one line, ran locale-gen and it
seems to have fixed it.  Keep in mind, it's been that way for quite a
long time.  No clue why it decides to moan about it now. 

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Jc GarcĂ­a
2014-07-17 21:55 GMT-06:00 Dale rdalek1...@gmail.com:

 I got that off a howto somewhere.  I think it is a Gentoo one.  Anyway,
 commented all that out and left the one line, ran locale-gen and it
 seems to have fixed it.  Keep in mind, it's been that way for quite a
 long time.  No clue why it decides to moan about it now.

Well that is suprising, since the contents you have on that file are
totally wrong, locale.gen(5) manpage explicitly states the syntax for
that file is:
locale charset
example:
en_US.UTF-8 UTF-8
The man page also points you to the directories in /usr/share/i18n/
wich are locales/ and charmaps/ with the list of the ones available
for Gentoo, and also a convenient file named 'SUPPORTED' which tells
itself a list of what it has inside.
Also a the file alredy in the /etc/locale.gen in the stage3, has some
examples, since en_US.UTF-8 is the second example (and that's your
locale) you just need to uncomment that and run locale-gen.
Also LANG is an environment variable it has nothing to do in there.
PD: the manpages have the best supported answers, look at it before
going to random howtos online, its already at your installation
anyway.

 Thanks.

 Dale

 :-)  :-)




Re: [gentoo-user] SNIP warning: setlocale: LC_ALL error

2014-07-17 Thread Mick
On Thursday 17 Jul 2014 23:48:51 Peter Humphrey wrote:
 This is my /etc/locale.gen:
 
 en_GB.UTF-8 UTF-8
 en_GB ISO-8859-1
 en_GB.ISO-8859-15 ISO-8859-15
 
 I don't remember why I still have those last two entries; I expect they
 date  from before Gentoo adopted UTF-8. Maybe I'll remove them and see
 what happens.

The last line is for Western European ASCII character encodings, just like 
en_GB ISO-8859-1, but with the Euro symbol and some other accented characters 
missing from the latter.

Nothing will happen if you remove the last two entries, because (I think) that 
the UTF-8 character encodings cover all these.

-- 
Regards,
Mick


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