Re: [gentoo-user] Re: Bind9 and Samba4 setup nightmare
On Wed, Mar 21, 2012 at 4:34 PM, walt w41...@gmail.com wrote: On 03/21/2012 08:15 AM, Datty wrote: I've just run ldd against the library thats trying to load and ive pasted the output below. It seems to require libsamdb-common.so twice but is only able to find it once? lddtree (app-misc/pax-utils) may give you a hint why that's happening. Hi, Thanks for the pointer, I haven't used that tool before. I've ended up getting it working by bumping up to bind 9.9.0 which seems about as stable as a 1 legged chair. Now to work out why it crashes every time samba tries to do a dynamic update. Thanks
[gentoo-user] LIRC with kernel 3.2.11
Hello, I'm using a Hauppauge WinTV HVR 1900 (usb), with a self-compiled kernel 3.2.11. The USB device works very well, but I would like to use LIRC 0.9.0 with my kernel. So I have set the LIRC_DEVICES=hauppauge within my make.conf and run emerge. Emerge fetches this packages: [ebuild N ] sys-kernel/gentoo-sources-3.2.11 USE=-build -deblob -symlink [ebuild N ] virtual/linux-sources-0 [ebuild N ] app-misc/lirc-0.9.0 On emerging this error is shown: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: In function 'ir_probe': /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:559:13: error: 'struct i2c_adapter' has no member named 'id' /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: At top level: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:232:12: warning: 'add_to_buf_pvr2000' defined but not used (How) Can I solve this problem? Thanks Phil
[gentoo-user] Re: LIRC with kernel 3.2.11
On 03/22/2012 04:21 AM, Kraus Philipp wrote: Hello, I'm using a Hauppauge WinTV HVR 1900 (usb), with a self-compiled kernel 3.2.11. The USB device works very well, but I would like to use LIRC 0.9.0 with my kernel. So I have set the LIRC_DEVICES=hauppauge within my make.conf and run emerge. Emerge fetches this packages: [ebuild N ] sys-kernel/gentoo-sources-3.2.11 USE=-build -deblob -symlink [ebuild N ] virtual/linux-sources-0 [ebuild N ] app-misc/lirc-0.9.0 error: 'struct i2c_adapter' has no member named 'id' I just found this commit in Linus's git repo: commit c185a9420bd1c645252249018e6887a968d3e1de Author: Jean Delvare khali@ Date: Sun Mar 20 14:50:53 2011 +0100 i2c: Drop i2c_adapter.id There is no user left of i2c_adapter.id, so we can get rid of it. Finally! :) And this comment from last June: -What: i2c_adapter.id -When: June 2011 -Why: This field is deprecated. I2C device drivers shouldn't change their - behavior based on the underlying I2C adapter. The lirc code includes several #ifdefs that test for the adapter id, so the lirc devs *are* changing their driver behavior based on it, obviously. Looks to me like lirc will need to be modified upstream for recent kernel code.
Re: [gentoo-user] LIRC with kernel 3.2.11
On Thu, Mar 22, 2012 at 5:21 AM, Kraus Philipp philipp.kr...@flashpixx.de wrote: Hello, I'm using a Hauppauge WinTV HVR 1900 (usb), with a self-compiled kernel 3.2.11. The USB device works very well, but I would like to use LIRC 0.9.0 with my kernel. So I have set the LIRC_DEVICES=hauppauge within my make.conf and run emerge. Emerge fetches this packages: [ebuild N ] sys-kernel/gentoo-sources-3.2.11 USE=-build -deblob -symlink [ebuild N ] virtual/linux-sources-0 [ebuild N ] app-misc/lirc-0.9.0 On emerging this error is shown: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: In function 'ir_probe': /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:559:13: error: 'struct i2c_adapter' has no member named 'id' /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: At top level: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:232:12: warning: 'add_to_buf_pvr2000' defined but not used (How) Can I solve this problem? I don't know if this will help you in any way. I have a media center with a Thermaltake LCD, which besides the LCD (which is actually a VFD) it includes an imon remote control. I used to have LIRC, and everything was right. After kernel 2.6.36 (or similar), LIRC stopped working (I use vanilla-sources). So I upgraded to the 3.2 kernel, and selected IR_IMON in Device Drivers - Multimedia support - Remote Controller adapters. Now the remote works perfectly, *BUT* I don't have LIRC installed anymore. The remote works as a keyboard, and I didn't had to configure anything in XBMC. I don't see any Hauppauge driver in the Remote Controller adapters menu in the kernel; but maybe it's called differently. If that's the case, then you will need LIRC no more; you can use your remote as any other input device. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] gconfd-2 woes
greets, today I wanted to be clever and ran emerge -e gnome to rebuild all my gnome-3 desktop. Unfortunately things didn't get better from this. I can hardly logon, gconfd-2 produces high load and /var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it fills the disk :-( I removed that file while gdm was not running, no matter, it got created again ... So right now I have no desktop on my desktop, writing this from the thinkpad. Could someone point me at how to start debugging this? I already rebuilt gdm, gconf, gnome-session ... revdep-rebuild shows nothing, dispatch-conf either Thanks, Stefan
[gentoo-user] Re: gconfd-2 woes
Am 2012-03-22 19:52, schrieb Stefan G. Weichinger: greets, today I wanted to be clever and ran emerge -e gnome to rebuild all my gnome-3 desktop. Unfortunately things didn't get better from this. I can hardly logon, gconfd-2 produces high load and /var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it fills the disk :-( I removed that file while gdm was not running, no matter, it got created again ... addon: it seems full of pulseaudio-related lines ... maybe I should rebuild that one now as well
[gentoo-user] Re: gconfd-2 woes
On 03/22/2012 12:03 PM, Stefan G. Weichinger wrote: Am 2012-03-22 19:52, schrieb Stefan G. Weichinger: greets, today I wanted to be clever and ran emerge -e gnome to rebuild all my gnome-3 desktop. Unfortunately things didn't get better from this. I can hardly logon, gconfd-2 produces high load and /var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it fills the disk :-( I removed that file while gdm was not running, no matter, it got created again ... addon: it seems full of pulseaudio-related lines ... maybe I should rebuild that one now as well Or delete it ;) If that doesn't work I would start by creating a new test user account and run gnome-3 from there. The problem may be caused by one of the zillion gnome config files in your home directory.
Re: [gentoo-user] Re: gconfd-2 woes
You El 22/03/2012 13:04, Stefan G. Weichinger li...@xunil.at escribió: Am 2012-03-22 19:52, schrieb Stefan G. Weichinger: greets, today I wanted to be clever and ran emerge -e gnome to rebuild all my gnome-3 desktop. Unfortunately things didn't get better from this. I can hardly logon, gconfd-2 produces high load and /var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it fills the disk :-( I removed that file while gdm was not running, no matter, it got created again ... addon: it seems full of pulseaudio-related lines ... maybe I should rebuild that one now as well You can remove /var/lib/gdm, and reemerge gdm. It usually works for me. Regards.
Re: [gentoo-user] HP PSC 1410 USB
On 3/21/12, Nilesh Govindrajan cont...@nileshgr.com wrote: Make sure that you have hplip installed (with hpcups scanner USE flags enabled). Also cups with USE flag usb if you have not enabled kernel usb printer support. I have the same piece and it's working like a charm for the past four years :D My printer is seven years old though. -- Nilesh Govindarajan http://nileshgr.com Fantastic! It's looks like not configurin usb printer in the kernel and rebuilding cups with USE usb did the job :) Final cuestion: when I run hp-setup installed the HP PSC 1400 and not 1410, is that ok? is that Nilesh the one you have installed and working? Many thanks to all suggestion, I appreciate your time very much. Sebas
[gentoo-user] Re: LIRC with kernel 3.2.11
On 2012-03-22 17:53:51 +0100, Canek Peláez Valdés said: On Thu, Mar 22, 2012 at 5:21 AM, Kraus Philipp philipp.kr...@flashpixx.de wrote: Hello, I'm using a Hauppauge WinTV HVR 1900 (usb), with a self-compiled kernel 3.2.11. The USB device works very well, but I would like to use LIRC 0.9.0 with my kernel. So I have set the LIRC_DEVICES=hauppauge within my make.conf and run emerge. Emerge fetches this packages: [ebuild N ] sys-kernel/gentoo-sources-3.2.11 USE=-build -deblob -symlink [ebuild N ] virtual/linux-sources-0 [ebuild N ] app-misc/lirc-0.9.0 On emerging this error is shown: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: In function 'ir_probe': /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:559:13: error: 'struct i2c_adapter' has no member named 'id' /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c: At top level: /var/tmp/portage/app-misc/lirc-0.9.0/work/lirc-0.9.0/drivers/lirc_i2c/lirc_i2c.c:232:12: warning: 'add_to_buf_pvr2000' defined but not used (How) Can I solve this problem? I don't know if this will help you in any way. I have a media center with a Thermaltake LCD, which besides the LCD (which is actually a VFD) it includes an imon remote control. I used to have LIRC, and everything was right. After kernel 2.6.36 (or similar), LIRC stopped working (I use vanilla-sources). So I upgraded to the 3.2 kernel, and selected IR_IMON in Device Drivers - Multimedia support - Remote Controller adapters. Thanks for this information. In the 3.2.11 sources the Remote Controller option is named CONFIG_RC_CORE and I have set the options Compile Remote Controller keymap modules (CONFIG_RC_MAP) Enable IR raw decoder for the NEC protocol (CONFIG_IR_NEC_DECODER) Enable IR raw decoder for the RC-5 protocol (CONFIG_IR_RC5_DECODER) Enable IR raw decoder for the RC6 protocol (CONFIG_IR_RC6_DECODER) Enable IR raw decoder for the JVC protocol (CONFIG_IR_JVC_DECODER) Enable IR raw decoder for the Sony protocol (CONFIG_IR_SONY_DECODER) Enable IR raw decoder for the RC-5 (streamzap) protocol (CONFIG_IR_RC5_SZ_DECODER) Enable IR raw decoder for the MCE keyboard/mouse protocol (CONFIG_IR_MCE_KBD_DECODER) Enable IR to LIRC bridge (CONFIG_IR_LIRC_CODEC) for building as modules. Now the remote works perfectly, *BUT* I don't have LIRC installed anymore. The remote works as a keyboard, and I didn't had to configure anything in XBMC. Can you run the emerge build command for lirc and take a look if the build process crashs at the same source code line, like my sources? Thanks a lot for your help Phil
[gentoo-user] Re: LIRC with kernel 3.2.11
On 2012-03-22 17:39:19 +0100, walt said: On 03/22/2012 04:21 AM, Kraus Philipp wrote: Hello, I'm using a Hauppauge WinTV HVR 1900 (usb), with a self-compiled kernel 3.2.11. The USB device works very well, but I would like to use LIRC 0.9.0 with my kernel. So I have set the LIRC_DEVICES=hauppauge within my make.conf and run emerge. Emerge fetches this packages: [ebuild N ] sys-kernel/gentoo-sources-3.2.11 USE=-build -deblob -symlink [ebuild N ] virtual/linux-sources-0 [ebuild N ] app-misc/lirc-0.9.0 error: 'struct i2c_adapter' has no member named 'id' I just found this commit in Linus's git repo: commit c185a9420bd1c645252249018e6887a968d3e1de Author: Jean Delvare khali@ Date: Sun Mar 20 14:50:53 2011 +0100 i2c: Drop i2c_adapter.id There is no user left of i2c_adapter.id, so we can get rid of it. Finally! :) And this comment from last June: -What: i2c_adapter.id -When: June 2011 -Why: This field is deprecated. I2C device drivers shouldn't change their - behavior based on the underlying I2C adapter. The lirc code includes several #ifdefs that test for the adapter id, so the lirc devs *are* changing their driver behavior based on it, obviously. Looks to me like lirc will need to be modified upstream for recent kernel code. I think so, but I have posted the error message on the lirc mailinglist with actually no answer Phil
RE: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
From: Walter Dnes [mailto:waltd...@waltdnes.org] Sent: Thursday, March 22, 2012 5:14 PM On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. You know the old adage, if you ask 5 geeks a question you get 6 different answers. This whole discussion is somewhat surreal to me, when taken in conjunction with the other heated debate we just finished having: * udev is evil and horrible because it's trying to do too much and is too complex. * system is evil and horrible because it isn't doing enough and is too simple. And I'm pretty I've seen at least one person making both arguments simultaneously. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. It works fine for mysql, or postfix, or apache, or any of the dozens of other programs that have helper scripts whose sole purposes is to act as an entry point to starting up the actual service. It's a common and well-accepted way of performing required initialization on startup. I don't see why sshd has to be special here. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. You are absolutely correct; the discussion of who owns the init script is completely tangential to the system vs openrc argument; in both cases, the required startup files will be provided by the package maintainer and installed by the ebuild, not by the rc system. I think the confusion may have started way back when Canek tried to compare the simplicity of sshd.service to the complexity of /etc/init.d/sshd. That's the unfair, apples-to-oranges comparison that triggered this entire debate. The part that's been lost here is that system doesn't run init scripts(*); it launches configured services. These are *not* shell scripts; they are ini-file-like things that define parameters, much like xinetd's configuration files. Of course, I don't see why this is a problem: configure system to launch sshd's init script, which keeps doing the same thing it always has been doing. This is why the comparison between systemd's service config and openrc's script is unfair. You /cannot/ get rid of the complexity of /etc/init.d/sshd, you can only make it so that openrc and systemd can *both* take advantage of that complexity when starting sshd. That may, of course, require the package maintainer to provide 3 items instead of one: an openrc init script, a systemd service description, and an rc-agnostic helper script, in order to be fully systemd-compatible. In the meantime, the systemd package maintainer will likely be forced to provide some kind of compatibility shims to run existing openrc scripts that have not yet been refactored, but that's the cost of choice. It may already do this, I don't know. I have not yet installed systemd anywhere but I am curious enough to try it on my laptop. So I will be that much more informed in the near future :) (*) As I understand it, systemd *can* run SysV-style init scripts, but Gentoo's startup scripts are too dependent on openrc-supplied logic to be reusable in any meaningful sense. --Mike
Re: [gentoo-user] Grub2 can't find any commands
Here's a marvelous program crying out for an ebuild; https://launchpad.net/boot-repair It's part of my Ubuntu setup. With one click it goes out and finds all the boot partitions on your hd(s) and automatically writes the proper grub2 configuration for them. It even pastebins a copy of grub.cfg for troubleshooting purposes, though I have never needed it, sof far. When you boot all your OSes are there in the menu ready to be selected. In my case Ubuntu, Gentoo and Sabayon. . On 3/21/12, Julian Simioni julian.simi...@gmail.com wrote: Hi all, I'm working on the exciting and challenging task of installing Gentoo on a new Macbook Pro with grub2 and EFI. I've got things booting, but every time grub complains of many missing commands including search, echo, and most surprisingly '['. It also can't find any modules, and in order to get everything to work I had to specify about 10 modules to be built in using grub2-mkimage. This feels a little suboptimal to me, but I can't figure out where various things need to be for grub to find them happily. My partition layout at least is simple since I don't plan on dual booting: /dev/sda1: big root partition using ext4 /dev/sda2: 200MB vfat EFI partition, set to bootable (yes this should be sda1: I didn't know you needed an EFI partition until after I had already made the root partition and started installing things. I was able to add this partition later with gparted) Of course I'm using GPT, not MBR. On /dev/sda2 I've got the grub2 image at /EFI/BOOT/BOOTX64.EFI as is standard, and I have been mounting /dev/sda2 at /boot/efi. I can put either a grub2 image or a 3.3 kernel with EFI stub support at /EFI/BOOT/BOOTX64.EFI and it gets detected just fine, so I'm on the right track. I've tried messing with various permutations of the -p parameter to grub2-mkimage, but haven't gotten anywhere. Right now the *.mod and *.lst files from /usr/lib/grub/x86_64-efi/ can be found at both /boot/grub2/x86_64-efi and /boot/efi/EFI/BOOT/. Where is it that they actually should be? Thanks, Julian
Re: [gentoo-user] Re: gconfd-2 woes
Am 2012-03-22 20:47, schrieb walt: On 03/22/2012 12:03 PM, Stefan G. Weichinger wrote: Am 2012-03-22 19:52, schrieb Stefan G. Weichinger: greets, today I wanted to be clever and ran emerge -e gnome to rebuild all my gnome-3 desktop. Unfortunately things didn't get better from this. I can hardly logon, gconfd-2 produces high load and /var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it fills the disk :-( I removed that file while gdm was not running, no matter, it got created again ... addon: it seems full of pulseaudio-related lines ... maybe I should rebuild that one now as well Or delete it ;) If that doesn't work I would start by creating a new test user account and run gnome-3 from there. The problem may be caused by one of the zillion gnome config files in your home directory. The problem starts even before I log in! S
Re: [gentoo-user] Re: gconfd-2 woes
Am 2012-03-22 21:14, schrieb Canek Peláez Valdés:
You
El 22/03/2012 13:04, Stefan G. Weichinger li...@xunil.at
mailto:li...@xunil.at escribió:
Am 2012-03-22 19:52, schrieb Stefan G. Weichinger:
greets,
today I wanted to be clever and ran emerge -e gnome to rebuild all my
gnome-3 desktop.
Unfortunately things didn't get better from this.
I can hardly logon, gconfd-2 produces high load and
/var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it
fills the disk :-(
I removed that file while gdm was not running, no matter, it got created
again ...
addon: it seems full of pulseaudio-related lines ... maybe I should
rebuild that one now as well
You can remove /var/lib/gdm, and reemerge gdm. It usually works for me.
that helped a bit the saved_state file now peaks at around 500 MB
... but the shell(?) crashes again.
I see lots of:
gconfd-2[18280] general protection ip:7f24944dfa5f sp:7fffc4f6bfe8
error:0 in libc-2.14.1.so[7f24943c7000+181000]
in dmesg.
As mentioned, gconf has been rebuilt already.
I also didn't change anything in terms of (un)masking stuff when I
re-emerged gnome today.
[I] gnome-base/gconf
Available versions: (2) 2.32.3 2.32.4 (~)3.2.3
{{debug doc +introspection ldap +orbit policykit}}
Installed versions: 3.2.3(2)(18:50:53 22.03.2012)(introspection
orbit policykit -debug -doc -ldap)
[I] sys-libs/glibc
Available versions: (2.2) (~)2.9_p20081201-r3!s 2.10.1-r1!s
2.11.3!s (~)2.12.1-r3!s 2.12.2!s (~)2.13-r2!s 2.13-r4!s (~)2.14!s
(~)2.14.1!s (~)2.14.1-r1!s (~)2.14.1-r2!s **2.15!s **!s
{{crosscompile_opts_headers-only debug gd glibc-omitfp hardened
multilib profile selinux vanilla}}
Installed versions: 2.14.1-r2(2.2)!s(00:48:53 20.01.2012)(multilib
-crosscompile_opts_headers-only -debug -gd -glibc-omitfp -hardened
-profile -selinux -vanilla)
restarted xdm, saved_state grows again, and this is *before* I even get
the login.
S
[gentoo-user] cryptsetup with static libs
Hello, I try to build the cryptsetup tools, but all depended library should be build with +static-libs use flag. I have set my packages.use to: sys-fs/cryptsetup -static-libs dev-libs/libgcrypt static-libs dev-libs/popt static-libs dev-libs/libgpg-error static-libs sys-apps/util-linux static-libs Can I build the cryptsetup without the static libs? Is there a reason that I must build it with static libs? Thanks Phil
Re: [gentoo-user] Re: gconfd-2 woes
Am 2012-03-22 23:44, schrieb Stefan G. Weichinger:
Am 2012-03-22 21:14, schrieb Canek Peláez Valdés:
You
El 22/03/2012 13:04, Stefan G. Weichinger li...@xunil.at
mailto:li...@xunil.at escribió:
Am 2012-03-22 19:52, schrieb Stefan G. Weichinger:
greets,
today I wanted to be clever and ran emerge -e gnome to rebuild all my
gnome-3 desktop.
Unfortunately things didn't get better from this.
I can hardly logon, gconfd-2 produces high load and
/var/lib/gdm/.gconfd/saved_state grows quickly to around 4 GB until it
fills the disk :-(
I removed that file while gdm was not running, no matter, it got created
again ...
addon: it seems full of pulseaudio-related lines ... maybe I should
rebuild that one now as well
You can remove /var/lib/gdm, and reemerge gdm. It usually works for me.
that helped a bit the saved_state file now peaks at around 500 MB
... but the shell(?) crashes again.
I see lots of:
gconfd-2[18280] general protection ip:7f24944dfa5f sp:7fffc4f6bfe8
error:0 in libc-2.14.1.so[7f24943c7000+181000]
in dmesg.
As mentioned, gconf has been rebuilt already.
I also didn't change anything in terms of (un)masking stuff when I
re-emerged gnome today.
[I] gnome-base/gconf
Available versions: (2) 2.32.3 2.32.4 (~)3.2.3
{{debug doc +introspection ldap +orbit policykit}}
Installed versions: 3.2.3(2)(18:50:53 22.03.2012)(introspection
orbit policykit -debug -doc -ldap)
[I] sys-libs/glibc
Available versions: (2.2) (~)2.9_p20081201-r3!s 2.10.1-r1!s
2.11.3!s (~)2.12.1-r3!s 2.12.2!s (~)2.13-r2!s 2.13-r4!s (~)2.14!s
(~)2.14.1!s (~)2.14.1-r1!s (~)2.14.1-r2!s **2.15!s **!s
{{crosscompile_opts_headers-only debug gd glibc-omitfp hardened
multilib profile selinux vanilla}}
Installed versions: 2.14.1-r2(2.2)!s(00:48:53 20.01.2012)(multilib
-crosscompile_opts_headers-only -debug -gd -glibc-omitfp -hardened
-profile -selinux -vanilla)
sure, I rebuilt glibc now and gconf after that.
Still same symptoms :-(
S
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. waltdnes@d530 ~ $ equery b /etc/init.d/sshd * Searching for /etc/init.d/sshd ... net-misc/openssh-5.8_p1-r1 (/etc/init.d/sshd) Having the shell script be part of the package associated with the service keeps bugs related to that script associated with that package. That's the way it is right now. See above. At least, that's the way I see it. Any issue of compatibility between the two can be addressed by the service's package manager, either by adaption via that script, or by expressing an explicit dependency on one init architecture or another. My point in this whole argument is that there is some checking and setup that has to be done before launch. Therefore shuffling off some or all of the shellscript code to another script is a pointless shell game (sorry) that adds no value. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Thu, Mar 22, 2012 at 5:13 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. No. In a system V scenario, you'd probably just symlink to the genericized init script. In the systemd scenario, as I understand it, you have a configuration file (distinct from a script), and you'd include the path to the genericized init script there. What I'm talking about is an implementation of the adapter pattern. http://en.wikipedia.org/wiki/Adapter_pattern If there are going to be competing init systems (and there will be), and a service needs to be compatible with both (and there will be such services), then that's going to be the most elegant solution. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. waltdnes@d530 ~ $ equery b /etc/init.d/sshd * Searching for /etc/init.d/sshd ... net-misc/openssh-5.8_p1-r1 (/etc/init.d/sshd) Sure. And that's what I was arguing. Though by the sound of it, there's stuffed in the openrc package which doesn't need to be there, and a blog post flameeyes posted today suggests the systemd package is intended to absorb the hardware database. ( http://blog.flameeyes.eu/2012/03/refreshing-a-4-years-old-problem ) Having the shell script be part of the package associated with the service keeps bugs related to that script associated with that package. That's the way it is right now. See above. And that's the way it should be. At least, that's the way I see it. Any issue of compatibility between the two can be addressed by the service's package manager, either by adaption via that script, or by expressing an explicit dependency on one init architecture or another. My point in this whole argument is that there is some checking and setup that has to be done before launch. Therefore shuffling off some or all of the shellscript code to another script is a pointless shell game (sorry) that adds no value. See reference to the adapter pattern above. Systemd has its merits in its capabilities. System V init has merits in that it's far more portable. Open source software which operates as a system service will need to support both. There are, of course, things I loathe. I loathe the apparent mindset behind systemd and behind udev, wherein all things belong as part of a monolithic system. That runs counter to principles of modular design, portability and even systemic stability in changing things. I loathe the desire to lunge forward without working out a transition plan, or even having the appearance of interest in one. And I loathe the terrible PR. -- :wq
Re: [gentoo-user] HP PSC 1410 USB
On Mar 23, 2012 2:10 AM, G. Sebastián Pedersen sebas...@gmail.com wrote: On 3/21/12, Nilesh Govindrajan cont...@nileshgr.com wrote: Make sure that you have hplip installed (with hpcups scanner USE flags enabled). Also cups with USE flag usb if you have not enabled kernel usb printer support. I have the same piece and it's working like a charm for the past four years :D My printer is seven years old though. -- Nilesh Govindarajan http://nileshgr.com Fantastic! It's looks like not configurin usb printer in the kernel and rebuilding cups with USE usb did the job :) Final cuestion: when I run hp-setup installed the HP PSC 1400 and not 1410, is that ok? is that Nilesh the one you have installed and working? Many thanks to all suggestion, I appreciate your time very much. Sebas Glad that it helped. Yeah the driver reports 1410 as 1400. No issues. All functions work (except scan button, which is limited to just 1-2 scanners via scanbuttond). Also, I don't think you need kernel usb printer support if you enabled usb in cups, in fact I'm wondering how did the ebuild let you build it, because it had emitted me an error and I had to disable usb printer in the kernel. -- Nilesh Govindrajan http://nileshgr.com
Re: [gentoo-user] Masking udev to postpone the update
On Sun, Mar 18 2012, Allan Gottlieb wrote: On Sun, Mar 18 2012, Alan McKinnon wrote: On Sun, 18 Mar 2012 13:14:48 -0700 Allan Gottlieb gottl...@nyu.edu wrote: I will update to the new world order, but would very much prefer to postpone that for a few weeks. Is it enough to put sys-fs/udev-171-r5 in /etc/portage/package.mask ? =sys-fs/udev-181 would be better. Rather mask the first version that causes issues and all subsequent versions. With your suggestions, there may be future updates between 171 and 181 (without initrd issues) that you want, but you can't use them as you masked them. Done, thanks. Thank you volker as well. allan I am now unable to update world Total: 26 packages (20 upgrades, 3 new, 1 in new slot, 2 reinstalls, 1 uninstall), Size of downloads: 604,681 kB Conflict: 3 blocks The following keyword changes are necessary to proceed: #required by sys-auth/consolekit-0.4.5-r3[acl], required by net-misc/networkmanager-0.9.2.0-r5, required by net-im/empathy-3.2.2[networkmanager], required by gnome-base/gnome-core-apps-3.2.1, required by gnome-base/gnome-3.2.1, required by @selected, required by @world (argument) =sys-fs/udev- ** The following mask changes are necessary to proceed: #required by sys-auth/consolekit-0.4.5-r3[acl], required by net-misc/networkmanager-0.9.2.0-r5, required by net-im/empathy-3.2.2[networkmanager], required by gnome-base/gnome-core-apps-3.2.1, required by gnome-base/gnome-3.2.1, required by @selected, required by @world (argument) # /etc/portage/package.mask: =sys-fs/udev- This does not surprise me. I still would like to wait until the semester is over before trying dracut as I assume there is a significant chance of an unbootable system. I could just do nothing now and, in late May, try dracut, unmask udev, and update world. If the world update is very hard after the long wait. I could reinstall. I was wondering if the following alternate procedure is safe. The hope would be to have few enough packages not updated so that when I do try dracut and unmask udev, an update world will eventually succeed. 1. Try emerge update world 2. Note a few of the packages that would have been updated, say A, B, and C 3. emerge -1 --ask A B C If no problems are reported, say yes to the --ask 4. Repeat thanks, allan
Re: [gentoo-user] HP PSC 1410 USB
Glad that it helped. Yeah the driver reports 1410 as 1400. No issues. All functions work (except scan button, which is limited to just 1-2 scanners via scanbuttond). Okey then, thanks for the clarification. Also, I don't think you need kernel usb printer support if you enabled usb in cups, in fact I'm wondering how did the ebuild let you build it, because it had emitted me an error and I had to disable usb printer in the kernel. Yes, I try to say exactly that... usb printer disabled in the kernel and cups with usb use... sorry, my english needs improve, I know ;-) -- Nilesh Govindrajan http://nileshgr.com Thanks again. Sebas
