[gentoo-user] Midori: Couldn't find a place to store the pinned certificate
Hello! I am trying to access bugs.gentoo.org using www-client/midori-0.4.8 and here is what I get: bugs.gentoo.org/ Error granting trust: Couldn't find a place to store the pinned certificate pkcs11:library-manufacturer=GNOME%20Keyring I get the same message also for my own web-site which uses HTTPS protocol. Could somebody please give me a hint on how to resolve this issue? Thanks! Vladimir - v...@ukr.net
Re: [gentoo-user] unmerge sys-fs/udev-171-r9
On Thu, 14 Feb 2013 18:06:03 -0700, Joseph wrote: Is it safe to unmerge sys-fs/udev-171-r9 it is blocking udev-197 It's difficult to give a definitive answer without seeing the emerge output. -- Neil Bothwick We can't solve problems by using the same kind of thinking we used when we created them. (Albert Einstein) signature.asc Description: PGP signature
[gentoo-user] Robot Font
Hi, I installed media-fonts/roboto from asux overlay and configured /etc/fonts/local.conf as follows: ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig match target=font edit mode=assign name=hinting booltrue/bool /edit /match match target=font edit mode=assign name=hintstyle consthintslight/const /edit /match match target=font edit mode=assign name=antialias booltrue/bool /edit /match match target=font test qual=any name=size compare=less double9.0/double /test edit name=size mode=assign double9.0/double /edit /match match target=font test qual=any name=size compare=less double10.0/double /test test qual=any name=family stringmonospace/string /test edit name=size mode=assign double10.0/double /edit /match alias familyserif/family default familyRoboto/family /default /alias alias familysans-serif/family default familyRoboto/family /default /alias alias familymonospace/family default familyMonaco/family /default /alias /fontconfig And these are the symlinks in /etc/fonts/conf.d - 10-autohint.conf 10-sub-pixel-rgb.conf 11-lcdfilter-default.conf 49-sansserif.conf 50-user.conf 51-local.conf 66-lohit-hindi.conf 66-lohit-marathi.conf But I'm facing a weird issue with the Roboto font. It matches by default to Roboto Medium, but I don't want that. Titlebar, Menubar and Toolbar texts look bold. Even the mail list in Thunderbird looks bold so I can't distinguish between read and unread mail easily. $ fc-match Roboto Roboto-Medium.ttf: Roboto Medium How to fix this? There are no user configuration files and I have configured KDE to use default system settings (sansserif, monospace families). -- Nilesh Govindarajan http://nileshgr.com
Re: [gentoo-user] Delayed update semantics
On 2013-02-14 2:26 PM, James wirel...@tampabay.rr.com wrote: So, my latest ideas is to sync up and then wait one week before acutally installing those new packages. This would allow the fodder that the good folks on this list catch, bitch about (um, I mean file bug reports) and fix, to occur first; then I can complete the package update cautiously avoiding an emerge sync. I do something similar, but on a rolling basis... 1. Sync daily, keeping track of what updates appear *and when* 2. Once a package that wants to be updated has been in the list for at least 3 days, I update it/them, although I will usually wait a little longer (week or two) for some things, like things that are critical to booting (like grub, udev, etc) 3. Rinse, repeat I started doing it this way ever since I got bit by the mailman minor update that broke things horribly (moved where all of its files were located without any warning, news item, or anything - ugh), and it has served me well. I do this manually, but I only have a couple of systems to manage. Obviously if you manage multiple systems, the more systems you manage, the more unwieldy doing this manually becomes, so scripting the process (or at least part of it) would become necessary at some point.
[gentoo-user] [Slightly, but not entirely, OT] Help Python!
I don't know whether this has percolated to Gentoo users yet. http://pyfound.blogspot.ch/2013/02/python-trademark-at-risk-in-europe-we.html A company in the UK is trying to trademark the use of Python for IT related products. The Python Software Foundation is seeking evidence for consistent prior use of the term Python in the software and related goods context to defeat the trademark application. Considering that portage is largely python under the hood, I think it would not be wrong to say that Gentoo has a bit of a stake in this. Cheers, W
Re: [gentoo-user] Midori: Couldn't find a place to store the pinned certificate
On Friday 15 Feb 2013 08:33:04 v...@ukr.net wrote: Hello! I am trying to access bugs.gentoo.org using www-client/midori-0.4.8 and here is what I get: bugs.gentoo.org/ Error granting trust: Couldn't find a place to store the pinned certificate pkcs11:library-manufacturer=GNOME%20Keyring I get the same message also for my own web-site which uses HTTPS protocol. Could somebody please give me a hint on how to resolve this issue? Read the section on Certificate Handling here: http://wiki.xfce.org/midori/faq I don't use Gnome to be able to check, but it seems that gnome-keyring (assuming it's running) has not registered itself with your environment. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] pam_get_uid: no such user
On 02/14/2013 04:15 PM, Adam Carter wrote: This particular machine doesn't have ssh/xinetd or the like routed from outside the local LAN. Unless someone made a mistake with the config somewhere. Run tcpdump to be sure. Well, an `emerge -1 libtool glibc gcc emerge -e world` fixed the problem completely. Now that I went through that I'll have to get a proper backup! Dan
Re: [gentoo-user] udev-197: what to do -- S0LVED
Am 28.01.2013 00:00, schrieb Allan Gottlieb:
Thanks for all the suggestions. I did the following, which worked.
1. Built and installed kernel with CONFIG_DEVTMPFS=y
2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
rc-update add udev-postmount default.
3. Reboot with new kernel (udev unchanged). Success.
4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
eliminated clauses so have only (on one line)
SUBSYSTEM==net, ACTION==add, ATTR{address}==00:1e:c9:48:f9:a0,
NAME=net0
Corresponding changes to /etc/init.d /etc/runlevels/default
5. Emerge update world to get new udev (just -1 udev has blocks)
6. Change kernel configs as per udisks emerge output
7. /usr/lib/udev already empty (due to make world?) so nothing to do
8. Reboot with new kernel. Success
As I prepare/consider to upgrade a remote gentoo server later this
evening I prefer to ask twice:
the running kernel 3.5.7 does not have CONFIG_DEVTMPFS=y
I built a new kernel (upgrading it to 3.6.11 btw) with CONFIG_DEVTMPFS=y
and plan to reboot the server at first.
After a hopefully correct reboot (can't access that server physically) I
plan to upgrade udev ... (I won't enable the new networking naming, btw).
Right now I upgrade lvm2 in advance as it doesn't pull in udev yet.
Pls comment or correct my plans ;-) thanks, Stefan
[gentoo-user] Re: udev-197: what to do -- S0LVED
On 2013-02-15, Stefan G. Weichinger wrote:
Am 28.01.2013 00:00, schrieb Allan Gottlieb:
Thanks for all the suggestions. I did the following, which worked.
1. Built and installed kernel with CONFIG_DEVTMPFS=y
2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
rc-update add udev-postmount default.
3. Reboot with new kernel (udev unchanged). Success.
4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
eliminated clauses so have only (on one line)
SUBSYSTEM==net, ACTION==add, ATTR{address}==00:1e:c9:48:f9:a0,
NAME=net0
Corresponding changes to /etc/init.d /etc/runlevels/default
5. Emerge update world to get new udev (just -1 udev has blocks)
6. Change kernel configs as per udisks emerge output
7. /usr/lib/udev already empty (due to make world?) so nothing to do
8. Reboot with new kernel. Success
As I prepare/consider to upgrade a remote gentoo server later this
evening I prefer to ask twice:
the running kernel 3.5.7 does not have CONFIG_DEVTMPFS=y
I built a new kernel (upgrading it to 3.6.11 btw) with CONFIG_DEVTMPFS=y
and plan to reboot the server at first.
After a hopefully correct reboot (can't access that server physically) I
plan to upgrade udev ... (I won't enable the new networking naming, btw).
If you depend in the network device order in any way, and you used names
like the ones the kernel uses, you *have* to do something about the
network device naming.
For example, if you have eth0 and eth1 and you rely on eth0 being A and
eth1 B, you can't do that anymore with plain udev, even if the rules
are still in place. eth0 may become B and eth1 A.
Right now I upgrade lvm2 in advance as it doesn't pull in udev yet.
Pls comment or correct my plans ;-) thanks, Stefan
--
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED
Am 15.02.2013 18:41, schrieb (Nuno Silva):
If you depend in the network device order in any way, and you used
names like the ones the kernel uses, you *have* to do something
about the network device naming.
For example, if you have eth0 and eth1 and you rely on eth0 being A
and eth1 B, you can't do that anymore with plain udev, even if the
rules are still in place. eth0 may become B and eth1 A.
No order needed as there is only one adapter in there:
# lspci | grep net
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 01)
# cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:21:85:62:4f:0b,
KERNEL==eth*, NAME=eth0
thanks, Stefan
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED
Am 15.02.2013 18:45, schrieb Stefan G. Weichinger:
Am 15.02.2013 18:41, schrieb (Nuno Silva):
If you depend in the network device order in any way, and you used
names like the ones the kernel uses, you *have* to do something
about the network device naming.
For example, if you have eth0 and eth1 and you rely on eth0 being A
and eth1 B, you can't do that anymore with plain udev, even if the
rules are still in place. eth0 may become B and eth1 A.
No order needed as there is only one adapter in there:
# lspci | grep net
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 01)
# cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:21:85:62:4f:0b,
KERNEL==eth*, NAME=eth0
successful reboot done already:
# cat /proc/version
Linux version 3.6.11-gentoo
# zgrep -i devtm /proc/config.gz
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# mount | grep tmpfs
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
I should edit /etc/fstab, I assume:
# grep tmpfs /etc/fstab
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
shm /dev/shmtmpfs nodev,nosuid,noexec 0 0
Same mistake as I mentioned a few days before ... the syntax seems to
have changed to:
tmpfs /dev/shmtmpfs nodev,nosuid,noexec 0 0
Right?
---
So I might be ready to upgrade udev, correct?
*sigh*
;-)
Stefan
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED
Stefan G. Weichinger writes: # cat /proc/version Linux version 3.6.11-gentoo # zgrep -i devtm /proc/config.gz CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # mount | grep tmpfs udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) I should edit /etc/fstab, I assume: # grep tmpfs /etc/fstab # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 I still have this line in my fstab on one host... Same mistake as I mentioned a few days before ... the syntax seems to have changed to: tmpfs /dev/shmtmpfs nodev,nosuid,noexec 0 0 Right? ... but I don't have it at all on another. /dev/shm is mounted just fine though. CONFIG_DEVTMPFS_MOUNT seems to be responsible for that, although the help text says that it does not work when using an initramfs, which I do: CONFIG_DEVTMPFS_MOUNT: This will instruct the kernel to automatically mount the devtmpfs filesystem at /dev, directly after the kernel has mounted the root filesystem. The behavior can be overridden with the commandline parameter: devtmpfs.mount=0|1. This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the roots is mounted. With this option enabled, it allows to bring up a system in rescue mode with init=/bin/sh, even when the /dev directory on the rootfs is completely empty. Alex
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED
Am 15.02.2013 20:07, schrieb Alex Schuster: Stefan G. Weichinger writes: # cat /proc/version Linux version 3.6.11-gentoo # zgrep -i devtm /proc/config.gz CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # mount | grep tmpfs udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) I should edit /etc/fstab, I assume: # grep tmpfs /etc/fstab # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 I still have this line in my fstab on one host... Same mistake as I mentioned a few days before ... the syntax seems to have changed to: tmpfs /dev/shmtmpfs nodev,nosuid,noexec 0 0 Right? ... but I don't have it at all on another. /dev/shm is mounted just fine though. CONFIG_DEVTMPFS_MOUNT seems to be responsible for that, although the help text says that it does not work when using an initramfs, which I do: CONFIG_DEVTMPFS_MOUNT: This will instruct the kernel to automatically mount the devtmpfs filesystem at /dev, directly after the kernel has mounted the root filesystem. The behavior can be overridden with the commandline parameter: devtmpfs.mount=0|1. This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the roots is mounted. With this option enabled, it allows to bring up a system in rescue mode with init=/bin/sh, even when the /dev directory on the rootfs is completely empty. I just keep that fstab-line for now ... thanks for your explanation! Right now I already upgraded udev and I am currently rebuilding lvm2 and libvirt (first one needed, 2nd one not important anymore on that box). Should I restart udev before I reboot? For a test ... ? # dmesg | grep udevd only shows version 171 right now ... - I was already able to test for the shiny new network name for the NIC: # cat /root/bin/udev_testing.sh #!/bin/bash #network name testing for i in /sys/class/net/*; do echo ==$i udevadm test-builtin net_id $i; echo done 2/dev/null enp2s0 instead of eth0 I don't really care about using that new naming ... doesn't matter to me right now. AFAI understand things won't change if I don't touch the udev-rules? - revdep-rebuild is through now ... no more /lib64/libudev.so.0 needed ... Thanks, Stefan
Re: [gentoo-user] unmerge sys-fs/udev-171-r9
On 02/15/13 07:58, Florian Philipp wrote: Am 15.02.2013 03:38, schrieb Canek Peláez Valdés: On Thu, Feb 14, 2013 at 7:06 PM, Joseph syscon...@gmail.com wrote: Is it safe to unmerge sys-fs/udev-171-r9 it is blocking udev-197 As long as you don't stop udev, nor try to reboot before merging the new version, yes. Regards. The more important question is: Why does it block? udev is not slotted. An update shouldn't block itself. Something's not right here. Regards, Florian Philipp That is a good question. I had three blocks: [blocks B ] sys-fs/lvm2-2.02.97-r1 (sys-fs/lvm2-2.02.97-r1 is blocking sys-fs/udev-197-r4) [blocks B ] sys-fs/udev-186 (sys-fs/udev-186 is blocking sys-fs/udev-init-scripts-22) [blocks B ] sys-kernel/genkernel-3.4.25 (sys-kernel/genkernel-3.4.25 is blocking sys-fs/udev-197-r4) I upgraded genkernel and lvm2 and the udev bloc resolved itself. -- Joseph
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED for ME as well ;-)
Am 15.02.2013 20:20, schrieb Stefan G. Weichinger: enp2s0 instead of eth0 I don't really care about using that new naming ... doesn't matter to me right now. AFAI understand things won't change if I don't touch the udev-rules? Bit the bullet and rebooted after checking and reading everything twice at least. Server came up fine again, udev-197-r4 running fine ... still with good old eth0. For me that is enough upgrading for today, especially on a remote box like this ... new kernel, pam, lvm2, openrc, openssl, postfix etc etc phew ... Thanks for the help, I took lots of bits and bytes regarding this upgrade from the various threads in this mailing list. Regards, Stefan
[gentoo-user] Turn backlight off with XScreensaver only when explicitly locked
Hello! I am trying to make XScreensaver turn off the backlight of my laptop screen when I lock it, however I cannot achieve exactly what I want. I have the following situation: 1. If I set XScreensaver to activate the Blak Screen Only mode after some very-very long time (in order it not to start automatically) and then turn the option Quick Power-off in Blank Only Mode on, the backlight does not get turned off when I lock the screen, although XScreensaver starts and indeed makes it blank. 2. If I set Power management enabled just above the previous one and then set Suspend/Standby/Off times to some large values (for example, 720 min), XScreensaver turns the backlight off just after I lock it. But if I touch a mouse or keyboard (which calls the unlock dialogue), it does not turn the backlight off again after the unlock dialogue disappears. 3. If I set the Off After parameter to e.g. 1 min, XScreensaver does turn off the backlight on locking and about 1 minute after the last activity (that caused unlock dialogue to appear). But in this case XScreensaver also turns the screen off when I don't need it, i.e. when I just do not move mouse or touch keyboard for 1 minute -- even without the explicit screen locking. If I recall correctly, I had this feature working properly some time ago (probably a year or more). It did not blank the screen until I click the Lock button and did turn off the backlight again when the unlock dialogue disappeared. So could somebody please give me a hint on how to do the trick? Thanks! Vladimir - v...@ukr.net
Re: [gentoo-user] unmerge sys-fs/udev-171-r9
Joseph wrote: On 02/15/13 07:58, Florian Philipp wrote: Am 15.02.2013 03:38, schrieb Canek Peláez Valdés: On Thu, Feb 14, 2013 at 7:06 PM, Joseph syscon...@gmail.com wrote: Is it safe to unmerge sys-fs/udev-171-r9 it is blocking udev-197 As long as you don't stop udev, nor try to reboot before merging the new version, yes. Regards. The more important question is: Why does it block? udev is not slotted. An update shouldn't block itself. Something's not right here. Regards, Florian Philipp That is a good question. I had three blocks: [blocks B ] sys-fs/lvm2-2.02.97-r1 (sys-fs/lvm2-2.02.97-r1 is blocking sys-fs/udev-197-r4) [blocks B ] sys-fs/udev-186 (sys-fs/udev-186 is blocking sys-fs/udev-init-scripts-22) [blocks B ] sys-kernel/genkernel-3.4.25 (sys-kernel/genkernel-3.4.25 is blocking sys-fs/udev-197-r4) I upgraded genkernel and lvm2 and the udev bloc resolved itself. I ran into something like this too but no genkernel here. I switched to eudev so not sure how to get around it since I had to unmerge udev to install eudev anyway. I would suggest going to the boot runlevel at least tho. Then unmerge things until it is happy. That was what I had to do. Don't forget udev is a service so after the update, either reboot or restart the service. I would restart the sservice because the device nodes should already be there but will be gone if you reboot. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
