Re: [gentoo-user] Nginx with Python

2013-01-26 Thread Nilesh Govindrajan 
Typing from mobile, sorry for top post.

I haven't worked with Django, so don't know. Ping @unbit on twitter. He
might be knowing.

--
Nilesh Govindrajan
http://nileshgr.com
On Jan 26, 2013 3:51 AM, "Silvio Siefke"  wrote:

> Hello,
>
> On Fri, 25 Jan 2013 08:35:33 +0530
> Nilesh Govindrajan  wrote:
>
> > Does your python application implement WSGI?
>
> Yes. Now all is okay, webpy is running. Next is Django and then i like
> my nginx again.
>
>
> Regards & Thank you
> Silvio
>
>

Re: [gentoo-user] Nginx with Python

2013-01-26 Thread Silvio Siefke 
On Sat, 26 Jan 2013 14:05:53 +0530
Nilesh Govindrajan  wrote:

> Typing from mobile, sorry for top post.

No Problem.
 
> I haven't worked with Django, so don't know. Ping @unbit on twitter. He
> might be knowing.

It's run fine. Thank you. Twitter i can not write, no account. 


Regards & Thank you
Silvio

[gentoo-user] Subdirectories on NFS server missing 'executable' permission

2013-01-26 Thread Ralph Seichter 
Hi list members,

I set up Gentoo as an NFS server, and I am experiencing problems with
one of my NFS clients. When this specific client creates new directories
within the NFS-exported directory, the permissions are 0644 instead of
0755 ('executable' is missing). The client does not allow passing any
arguments when mounting a remote directory, so I wonder if this can be
fixed on the server side? My exports configuration looks like this:

# /etc/exports
/mnt/foo 
192.168.235.0/24(rw,async,all_squash,no_subtree_check,anonuid=1003,anongid=1003,insecure)
/mnt/bar 
192.168.235.0/24(rw,sync,no_root_squash,no_subtree_check,anonuid=1003,anongid=1003,insecure)

Both /mnt/foo and /mnt/bar were created like this:

mkdir /mnt/foo && chown root:root /mnt/foo && chmod 1777 /mnt/foo

It does not matter whether the client creates a new directory in /mnt/foo
or /mnt/bar, the executable bit is always missing.

Your ideas are appreciated. Thanks!

-Ralph

[gentoo-user] udev-197: what to do

2013-01-26 Thread Allan Gottlieb 
I have read the news item and still have questions.  The news item
covers several points.

1. remove udev-postmount:
   I did this but worry that I now cannot reboot until I upgrade
   udev.  Is that correct?

2. Add CONFIG_DEVTMPFS=y.  Easy.  Kernel rebuilt and installed
   in /boot (but have not rebooted).

3. Predictable network interface names.
   I have the problematic udev rule.
   Specifically 70-persistent-net.rules has (on one line)

   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
   ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
   KERNEL=="eth*", NAME="eth0"

   I read the bug report, but it is not as clear as I would like.
   Is it true that I can change my file to simply

   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
   ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
   KERNEL=="eth*", NAME="net0"

   That is just change the NAME from eth0 to net0 ?

4. No support for kernels older than 2.6.39.  No problem.

5. Separate /usr not affected.  Good.

The news item does not mention the problem of moving files
from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
believing that we still need one of the equivalents of
   equery belongs -n /usr/lib/udev | xargs emerge -pv

I used that successfully when one of my testing systems went to
udev-197.  I would think it is needed (before reboot) on my stable
systems as well so I am surprised it is not in the news item.

thanks,
allan

Re: [gentoo-user] Re: Boost version problem [solved but dirty]

2013-01-26 Thread Jacques Montier 
2013/1/25 Florian Philipp 

> Am 25.01.2013 20:02, schrieb Nikos Chantziaras:
> > On 24/01/13 21:15, Florian Philipp wrote:
> >> Am 24.01.2013 18:57, schrieb Jacques Montier:
> >>> 2013/1/24 microcai  >>> >
> >> [...]
> >>>  
> >>>   Libreoffice-4.0 needs boost > 1.49 (so works with
> >>>  boost-1.52.0-r5) and
> >>>   Nightshade LSS (for planetarium but not in portage) needs
> >>> boost
> >>>  < 1.5
> >>>   (so works with 1.49.0-r2).
> >>>   Is it possible to install both 1.49 and 1.52 (in new slot) ?
> >>>
> >>>  update Nightshade to work with boost 1.52 is the only way to go.
> >> [...]
> >>> I already tried that, but Nightshade doesn't compile with
> >>> boost-1.52... :-((
> >>>
> >>
> >> I could rant about the stupidity that is boost and/or packages that
> >> depend on it for some time but Flameeyes does a far better job at that.
> >
> > I wonder what the view on bundled boost headers is with Gentoo devs. I'm
> > currently working on a project where I need boost, and now I'm thinking
> > about using BCP (http://www.boost.org/doc/libs/1_52_0/tools/bcp) to
> > bundle what I need within the project.  At least this would guarantee
> > that the package wouldn't be affected by this issue.
> >
> >
>
> As I understand it, bundling the headers is exactly what you are
> supposed to do with boost.
>
> Regards,
> Florian Philipp
>
>
Hello everybody,

Finally i solved my problem, but in a dirty manner i don't like, but no
choice for me...
I noticed Nightshade needed 3 files :
/usr/lib64/libboost_filesystem-mt-1_46.so.1.46.1
/usr/lib64/libboost_system-mt-1_46.so.1.46.1
/usr/lib64/libboost_regex-mt-1_46.so.1.46.1

- I downloaded boost-1.46 (not in portage anymore) and some patches in an
overlay.
- Installed boost-1.46
- backup the 3 files.
- Uninstalled 1.46 and upgraded to boost-1.52 (needed by LibreOffice-4.0)
and symlinked the 3 files in /usr/lib64.

LibreOffice works, Nightshade does not see anything and works nice too.

Dirty as i said before, but i couldn't solve that issue otherwise.

Cheers,

--
Jacques

Re: [gentoo-user] Subdirectories on NFS server missing 'executable' permission

2013-01-26 Thread Alan McKinnon 
On Sat, 26 Jan 2013 17:13:47 +0100
Ralph Seichter  wrote:

> Hi list members,
> 
> I set up Gentoo as an NFS server, and I am experiencing problems with
> one of my NFS clients. When this specific client creates new
> directories within the NFS-exported directory, the permissions are
> 0644 instead of 0755 ('executable' is missing). The client does not
> allow passing any arguments when mounting a remote directory, so I
> wonder if this can be fixed on the server side? My exports
> configuration looks like this:
> 
> # /etc/exports
> /mnt/foo
> 192.168.235.0/24(rw,async,all_squash,no_subtree_check,anonuid=1003,anongid=1003,insecure)
>  /mnt/bar
> 192.168.235.0/24(rw,sync,no_root_squash,no_subtree_check,anonuid=1003,anongid=1003,insecure)
> 
> Both /mnt/foo and /mnt/bar were created like this:
> 
> mkdir /mnt/foo && chown root:root /mnt/foo && chmod 1777 /mnt/foo
> 
> It does not matter whether the client creates a new directory
> in /mnt/foo or /mnt/bar, the executable bit is always missing.
> 
> Your ideas are appreciated. Thanks!

What sort of client is this, and what umask is it using?

That's regular shell umask, not some fancy thing related to fs mounts.


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

[gentoo-user] Re: udev-197: what to do

2013-01-26 Thread walt 
On 01/26/2013 10:30 AM, Allan Gottlieb wrote:
> I have read the news item and still have questions.  The news item
> covers several points.
> 
> 1. remove udev-postmount:
>I did this but worry that I now cannot reboot until I upgrade
>udev.  Is that correct?

A reasonable question and I don't know the answer, but you can get
that file back by re-emerging your existing version of udev first.
You can always remove it later after everything is working okay,
which is what I did.

> 3. Predictable network interface names.
>I have the problematic udev rule.
>Specifically 70-persistent-net.rules has (on one line)
> 
>SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>KERNEL=="eth*", NAME="eth0"
> 
>I read the bug report, but it is not as clear as I would like.
>Is it true that I can change my file to simply
> 
>SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>KERNEL=="eth*", NAME="net0"
> 
>That is just change the NAME from eth0 to net0 ?

I kept my persistent-net rules and I still have a working eth0. Am
I politically incorrect to run this way?  Dunno (and don't care ;)

> The news item does not mention the problem of moving files
> from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
> believing that we still need one of the equivalents of
>equery belongs -n /usr/lib/udev | xargs emerge -pv

Yes -- if you still have any files in /usr/lib/udev/rules.d you should
re-emerge those packages so they are re-installed in /lib/udev/rules.d
before rebooting.  At least, I know that's what I should have done :)

Re: [gentoo-user] Subdirectories on NFS server missing 'executable' permission

2013-01-26 Thread Ralph Seichter 
On 27.01.13 00:04, Alan McKinnon wrote:

> What sort of client is this, and what umask is it using?

The client is an Edision Argus Pingulux Plus satellite receiver.

[root@stlinux]#uname -a
Linux stlinux 2.6.32.42_stm24_V4.1-SAT7111_7111-STSDK #56 PREEMPT Tue Oct 16 
16:17:14 CST 2012 sh4 GNU/Linux

> That's regular shell umask, not some fancy thing related to fs mounts.

[root@stlinux]#umask
0022

This umask looks OK to me.

-Ralph

[gentoo-user] nvidia-drivers-304.64 build failure against vanilla linux-3.7.4

2013-01-26 Thread staticsafe 
I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself
went fine but when I did a modules-rebuild, the nvidia module failed to
build. As requested by the error message:

output of `emerge --info '=x11-drivers/nvidia-drivers-304.64'`:
http://sprunge.us/QLUN

output of `emerge -pqv '=x11-drivers/nvidia-drivers-304.64'`
http://sprunge.us/PfcV

complete build log:
http://sprunge.us/AQfS

Anyone have any ideas?

-- 
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb

[gentoo-user] udev-197 USE=kmod

2013-01-26 Thread Florian Philipp 
Hi list!

Quick question: If I deactivate the kmod use flag in udev and keep
sys-apps/module-init-tools, does udev still load modules or is kmod a
required flag for that?

Thanks in advance!
Florian Philipp



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: nvidia-drivers-304.64 build failure against vanilla linux-3.7.4

2013-01-26 Thread walt 
On 01/26/2013 04:06 PM, staticsafe wrote:
> I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself
> went fine but when I did a modules-rebuild, the nvidia module failed to
> build. 

Yes, this happens fairly often with proprietary drivers.  Once upon a time
I would spend hours hacking away at the nvidia install scripts and I got
pretty good at fixing the problems (always caused by sudden changes to
the linux kernel header files) but now I just can't work up enough energy
to do it any longer.

The nvidia-drivers you need still compile against linux-3.6.11, but no
later than that.  I know because I use the same drivers.

The nvidia devs will eventually get around to patching the kernel drivers
for older nvidia hardware, but they're getting slower as the hardware ages.

Re: [gentoo-user] udev-197 USE=kmod

2013-01-26 Thread Canek Peláez Valdés 
On Sat, Jan 26, 2013 at 6:15 PM, Florian Philipp  wrote:
> Hi list!
>
> Quick question: If I deactivate the kmod use flag in udev and keep
> sys-apps/module-init-tools, does udev still load modules or is kmod a
> required flag for that?

I'm not 100% sure, but I don't think so. The git repository has not a
single instance of the strings "modprobe" or "insmod", apparently the
only way to load modules in udev is to use kmod. I think the kmod
configure option (which is the one the USE flag activate/deactivate),
is for systems where all the modules are built-in, like embedded ones.

Unless udev has no other means to load modules, I think disabling kmod
assumes then that all the modules are built-in. And if you use
modules, may I ask why you would prefer module-init-tools over kmod?
Specially when the later is a drop-in, better supported replacement?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot

2013-01-26 Thread Canek Peláez Valdés 
On Sat, Jan 26, 2013 at 7:08 PM, João Matos  wrote:
> Hi list,
>
> I'm having this problem for a while, but I've decided to solve it know.
> Every time I boot my system (couple times a day), I have to hid Ctrl + D
> when the boot process is interrupted by the "emergency mode".
>
> I think it started when I was compiling the kernel myself, and removing lot
> of stuff. Although, I checked and the mandatory options for systemd are ok.
>
> When I run "journalctl -b -p err" the only information I get is:
>
> Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion
> `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed
> Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign
> requested address
> Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon
> already running.
> Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon
> already running.
>
>  It give me no clue.
>
> Attached the .conf from my gentoo-3.7.1
>
> After I hit Ctrl + D, the system works normally.
>
> Any help will be appreciated :)

Are you using udev-197 with systemd-197? mgorny masked it, and said
this in package.mask:

# Does not boot. Something with udev is probably broken. Feel free
# to unmask, debug and provide me with a patch.

You need to be using the same version for udev and systemd (they are
the same package). If you are using the same version for udev and
systemd, are you using an initramfs? When was the last time you built
it, if you do?

Could you boot with "systemd.log_target=kmsg" and
"systemd.log_level=debug", and post the whole output of "journalctl
-b"? It prints only the logs from the last boot.

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] openpty() failing with UNIX98 ptys

2013-01-26 Thread Mike Edenfield 
At some point recently, one of my systems has begun having problems
allocating pseudo-terminals via the UNIX98 pty scheme. I am using the same
kernel configuration I've had for years, and running the latest ~amd64
version of all the relevant packages. The problem manifests itself on any
program that attempts to allocate a pseudo-terminal, including portage and
openssh. I first noticed the problem when I could no longer ssh into the
server because it would not allocate a pty. 

I have the latest udev installed, and udev-mount is running on boot. Both
/dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable:

basement package.use # mount | grep /dev
/dev/root on / type ext3
(rw,seclabel,noatime,errors=continue,barrier=1,data=writeback)
devpts on /dev/pts type devpts
(rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755)

basement package.use # ls -alF /dev/ptmx /dev/pts
crw-rw-rw-. 1 root tty  5, 2 Jan 26 13:18 /dev/ptmx

/dev/pts:
total 0
drwxr-xr-x.  2 root root40 Jan 26 13:18 ./
drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../

When I trace sshd's attempt to open a new pty, I see it doing this:

* open /dev/ptmx
* stat /dev/pts
* stat /dev
* try (and fail) to open /dev/ptyp0

Since I know that last bit is openssh trying to open an old-style BSD pty, I
can only assume that something is going wrong trying to allocate the pty the
correct way.

For the time being I've added BSD pty support into my kernel and everything
seems to be working now, but I'm at a loss as to what I did to break things
in the first place.