Re: [arch-general] Jacman. Problem installing packages (don't panic)

2008-02-08 Thread Roman Kyrylych
2008/2/8, Stefano Esposito [EMAIL PROTECTED]:

 Well... I think I'll contribute to that on archlinux-projects and drop
 mine bindings :) Is the project still active? And who's the author (i'm
 not able to find (s)he on archlinux-projects.org :))


Georg Grabler was a TU but resigned due to life chages,
so I'm not sure if he has time and wish to continue his alpm bindings,
but maybe you can continue his development. Drop him a line.

-- 
Roman Kyrylych (Роман Кирилич)


Re: [arch-general] Jacman. Problem installing packages (don't panic)

2008-02-08 Thread Stefano Esposito
On Thu, 07 Feb 2008 19:31:18 +0100
Xavier [EMAIL PROTECTED] wrote:

 Stefano Esposito wrote:
  On Thu, 7 Feb 2008 15:18:24 +0100
  solsTiCe d'Hiver[EMAIL PROTECTED]  wrote:
 
  hi.
  IMHO, at the actually status of pacman, is a suicide go to
  programming a GUI.
  what do you mean by that ?
 
  i wonder why after pacman is finally splitted into two with a
  library like libalpm, we do not see more GUI popping up...
 
  i have tried to use libalpm just to see; it's not easy but i am a
  newbie at programming in C. anyone ?
 
 
 
  I'm trying to write a python binding to be used in the next future
  of gtkpacman. By now i've implemented just alpm_db* (with a Database
  class), alpm_pkg* (with a Package class) and alpm_option* (with an
  Alpm class). If anyone wants to take a look it's on berlios.de,
  project pyalpm (you'll need pyrex to compile the module). Of course
  is totally not documented :). Any help in the project would be very
  appreciated, so if anyone is intersted feel free to contact me ;)
 
 
 Hm, do we have 2 pyalpm now?
 http://svn.berlios.de/svnroot/repos/pyalpm/trunk/
 http://svn.archlinux-projects.org/repos/pyalpm/trunk/src/
 

Well... I think I'll contribute to that on archlinux-projects and drop
mine bindings :) Is the project still active? And who's the author (i'm
not able to find (s)he on archlinux-projects.org :))
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 New Giorno e Notte Plus: ordina il prodotto dimagrante n° 1 in Italia
* 
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7109d=8-2



[arch-general] What should be done with octave?

2008-02-08 Thread Neil Darlow

Hi,

Arch has octave-2.1.73 in extra.

The current stable version of octave is 3.0.0 but it is not backwards 
compatible with the 2.1.x series.


The gcc-4.2.3 migration has broken octave due to a versioned dependency 
on gcc-fortran. Also, the PKGBUILD has no license or md5sum entries.


The octave-2.1.73 PKGBUILD will need fixing but should it be updated to 
3.0.0 and, if so, should a legacy octave2 package be created?


I'm looking for opinions before I file any bug report.

Regards,
Neil Darlow



Re: [arch-general] mozilla /usr move

2008-02-08 Thread w9ya

 On Fri, Feb 08, 2008 at 01:24:49AM -0500, [EMAIL PROTECTED] wrote:

  On Feb 7, 2008 6:40 PM, Petar Bogdanovic [EMAIL PROTECTED]
 wrote:
 
  On Thu, Feb 07, 2008 at 12:10:19AM +0200, Grigorios Bouzakis wrote:
   On Thu, Feb 07, 2008 at 08:26:09PM +0100, Jan de Groot wrote:
Hi all,
   
I've cleaned up testing a bit:
- moved xulrunner/seamonkey/firefox and friends to extra. This
 is
  part of the /usr move
  
   Any idea why an /opt/mozilla/lib directory is still created by
 one
  of those packages? It doesnt seem to be part of any of these
  filelists. I wanted to ask this when the packages were still in
 testing but totally forgot to.
 
  $ sudo pacman -Ql jre | grep /opt/mozilla
  jre /opt/mozilla/
  jre /opt/mozilla/lib/
  jre /opt/mozilla/lib/plugins/
  jre /opt/mozilla/lib/plugins/libjavaplugin_oji.so
 
  Has anybody noticed this?
 
 
 
  Apparently you have.  ;)  I don't know if any devs have tho - file a
 bugreport.

 There is also some lint(ing) in the /opt/mozilla hierarchy you might
 want to  mention in your bug report.

 Could you post an example?

Uh, sure thing !:12 09:24 pkgconfig
drwxr-xr-x 2 root root 4096 2008-02-07 21:25 plugins

The pkgconfig was probably NOT

ls -al /opt/mozilla/lib/
total 16
drwxr-xr-x 4 root root 4096 2008-02-07 21:25 .
drwxr-xr-x 3 root root 4096 2008-02-07 21:25 ..
drwxr-xr-x 2 root root 4096 2007-12-12 09:24 pkgconfig
drwxr-xr-x 2 root root 4096 2008-02-07 21:25 plugins

The pkgconfig might NOT have been created by mozilla et al BUT if mozilla
is removed from /opt for /usr , well this remains nonetheless.

Good question by the way.


Very best regards;

Bob Finch


Liviu Librescu - În veci pomenirea lui.
(May his memory be eternal.)





Re: [arch-general] get pid of daemon in init script

2008-02-08 Thread Dan McGee
On Feb 8, 2008 1:27 PM, Michael Krauss [EMAIL PROTECTED] wrote:
 Hi to .*

 I must write a rc init script for a server I am packaging.
 Therefor I have copied the init script of cups.
 Now I recognized that both pid files, cups.pid and my own, in /var/run
 are empty.

 Further investigations have shown that

 pidof -o %PPID -x /usr/bin/cdvserver

 returns nothing in the start) case but in stop) it seems to work.
 I don't understand why pidof isn't working as expected.

Because you are calling pidof before the process starts- bash does not
do lazy evaluation of your expressions.

If you want to store the PID of the newly started process, you will
have to make another PID=... call to get it in the else block where
you access it.

 Here is my init script:
 #!/bin/bash

 . /etc/rc.conf
 . /etc/rc.d/functions

 PID=`pidof -o %PPID -x /usr/bin/cdvserver`
 PIDFILE=/var/run/cdvserver.pid
 case $1 in
   start)
 stat_busy Starting Codeville Server
 [ -z $PID ]  /usr/bin/cdvserver
 if [ $? -gt 0 ]; then
   stat_fail
 else
   echo Started  $PID
   echo $PID  $PIDFILE
   add_daemon cdv
   stat_done
 fi
 ;;
   stop)
 stat_busy Stopping Codeville Server
 [ ! -z $PID ]   kill $PID  /dev/null
 if [ $? -gt 0 ]; then
   stat_fail
 else
   rm $PIDFILE
   rm_daemon cdv
   stat_done
 fi
 ;;
   restart)
 $0 stop
 sleep 1
 $0 start
 ;;
   *)
 echo usage: $0 {start|stop|restart}
 esac
 exit 0





[arch-general] get pid of daemon in init script

2008-02-08 Thread Michael Krauss
Hi to .*

I must write a rc init script for a server I am packaging.
Therefor I have copied the init script of cups.
Now I recognized that both pid files, cups.pid and my own, in /var/run
are empty.

Further investigations have shown that 

pidof -o %PPID -x /usr/bin/cdvserver

returns nothing in the start) case but in stop) it seems to work.
I don't understand why pidof isn't working as expected.

Kind Regards,
Michael Krauss


Here is my init script:
#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

PID=`pidof -o %PPID -x /usr/bin/cdvserver`
PIDFILE=/var/run/cdvserver.pid
case $1 in
  start)
stat_busy Starting Codeville Server
[ -z $PID ]  /usr/bin/cdvserver
if [ $? -gt 0 ]; then
  stat_fail
else
  echo Started  $PID
  echo $PID  $PIDFILE
  add_daemon cdv
  stat_done
fi
;;
  stop)
stat_busy Stopping Codeville Server
[ ! -z $PID ]   kill $PID  /dev/null
if [ $? -gt 0 ]; then
  stat_fail
else
  rm $PIDFILE
  rm_daemon cdv
  stat_done
fi
;;
  restart)
$0 stop
sleep 1
$0 start
;;
  *)
echo usage: $0 {start|stop|restart}  
esac
exit 0



Re: [arch-general] get pid of daemon in init script

2008-02-08 Thread Travis Willard
On Feb 8, 2008 3:06 PM, Sentinel [EMAIL PROTECTED] wrote:
 Hi!

 It works perfectly (at least for me), just you have to ensure, that you
 call it with appropriate rights while testing:
 my testing:
 [EMAIL PROTECTED]:~$ su
 Password:
 with power comes great responsibility
 [EMAIL PROTECTED]:/home/sentinel# PID=`pidof -o %PPID -x /usr/sbin/proftpd`
 [EMAIL PROTECTED]:/home/sentinel# echo $PID
 7469
 [EMAIL PROTECTED]:/home/sentinel# [ -z $PID ]  echo pid is empty
 [EMAIL PROTECTED]:/home/sentinel#

 Tom

That is because you already have /usr/sbin/proftpd running.  In the
case of running the start initscript, the PID is sampled before the
application ever starts, and hence will return no PID, as Dan already
explained.



Re: [arch-general] get pid of daemon in init script

2008-02-08 Thread Sentinel

Hi!

It works perfectly (at least for me), just you have to ensure, that you 
call it with appropriate rights while testing:

my testing:
[EMAIL PROTECTED]:~$ su
Password:
with power comes great responsibility
[EMAIL PROTECTED]:/home/sentinel# PID=`pidof -o %PPID -x /usr/sbin/proftpd`
[EMAIL PROTECTED]:/home/sentinel# echo $PID
7469
[EMAIL PROTECTED]:/home/sentinel# [ -z $PID ]  echo pid is empty
[EMAIL PROTECTED]:/home/sentinel#

Tom

Dan McGee wrote:

On Feb 8, 2008 1:27 PM, Michael Krauss [EMAIL PROTECTED] wrote:
  

Hi to .*

I must write a rc init script for a server I am packaging.
Therefor I have copied the init script of cups.
Now I recognized that both pid files, cups.pid and my own, in /var/run
are empty.

Further investigations have shown that

pidof -o %PPID -x /usr/bin/cdvserver

returns nothing in the start) case but in stop) it seems to work.
I don't understand why pidof isn't working as expected.



Because you are calling pidof before the process starts- bash does not
do lazy evaluation of your expressions.

If you want to store the PID of the newly started process, you will
have to make another PID=... call to get it in the else block where
you access it.

  

Here is my init script:
#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

PID=`pidof -o %PPID -x /usr/bin/cdvserver`
PIDFILE=/var/run/cdvserver.pid
case $1 in
  start)
stat_busy Starting Codeville Server
[ -z $PID ]  /usr/bin/cdvserver
if [ $? -gt 0 ]; then
  stat_fail
else
  echo Started  $PID
  echo $PID  $PIDFILE
  add_daemon cdv
  stat_done
fi
;;
  stop)
stat_busy Stopping Codeville Server
[ ! -z $PID ]   kill $PID  /dev/null
if [ $? -gt 0 ]; then
  stat_fail
else
  rm $PIDFILE
  rm_daemon cdv
  stat_done
fi
;;
  restart)
$0 stop
sleep 1
$0 start
;;
  *)
echo usage: $0 {start|stop|restart}
esac
exit 0





  





[arch-general] Fw: get pid of daemon in init script

2008-02-08 Thread Michael Krauss
On 08/02/08, Dan McGee wrote:
 Because you are calling pidof before the process starts- bash does not
 do lazy evaluation of your expressions.
 
 If you want to store the PID of the newly started process, you will
 have to make another PID=... call to get it in the else block where
 you access it.

Ohh, you are absolutely right. It is working now. I must get this damn
Common Lisp out of my head before writing shell scripts next time.

I will file a bug report on cups too.


Thanks,
Michael Krauss



Re: [arch-general] get pid of daemon in init script

2008-02-08 Thread Sentinel

yes you are right.

[EMAIL PROTECTED]:/home/sentinel# /etc/rc.d/proftpd stop
:: Stopping ProFTPd Server   
[DONE]

[EMAIL PROTECTED]:/home/sentinel# PID=`pidof -o %PPID -x /usr/sbin/proftpd`
[EMAIL PROTECTED]:/home/sentinel# echo $PID

[EMAIL PROTECTED]:/home/sentinel#

Sorry, I made a mistake. I usually do not have my ftp server running. 
But I forgot, that I was moving something between my computer and laptop. :)


Btw proftpd's init script does the same. The proftpd.pid file is empty.

T

Travis Willard wrote:

On Feb 8, 2008 3:06 PM, Sentinel [EMAIL PROTECTED] wrote:
  

Hi!

It works perfectly (at least for me), just you have to ensure, that you
call it with appropriate rights while testing:
my testing:
[EMAIL PROTECTED]:~$ su
Password:
with power comes great responsibility
[EMAIL PROTECTED]:/home/sentinel# PID=`pidof -o %PPID -x /usr/sbin/proftpd`
[EMAIL PROTECTED]:/home/sentinel# echo $PID
7469
[EMAIL PROTECTED]:/home/sentinel# [ -z $PID ]  echo pid is empty
[EMAIL PROTECTED]:/home/sentinel#

Tom



That is because you already have /usr/sbin/proftpd running.  In the
case of running the start initscript, the PID is sampled before the
application ever starts, and hence will return no PID, as Dan already
explained.

  





Re: [arch-general] mozilla /usr move

2008-02-08 Thread Petar Bogdanovic
On Fri, Feb 08, 2008 at 12:20:31AM -0500, Travis Willard wrote:
 On Feb 7, 2008 6:40 PM, Petar Bogdanovic [EMAIL PROTECTED] wrote:
 
  On Thu, Feb 07, 2008 at 12:10:19AM +0200, Grigorios Bouzakis wrote:
   On Thu, Feb 07, 2008 at 08:26:09PM +0100, Jan de Groot wrote:
Hi all,
   
I've cleaned up testing a bit:
- moved xulrunner/seamonkey/firefox and friends to extra. This is part
of the /usr move
  
   Any idea why an /opt/mozilla/lib directory is still created by one of
   those packages? It doesnt seem to be part of any of these filelists.
   I wanted to ask this when the packages were still in testing but totally
   forgot to.
 
  $ sudo pacman -Ql jre | grep /opt/mozilla
  jre /opt/mozilla/
  jre /opt/mozilla/lib/
  jre /opt/mozilla/lib/plugins/
  jre /opt/mozilla/lib/plugins/libjavaplugin_oji.so
 
  Has anybody noticed this?
 
 
 
 Apparently you have.  ;)  I don't know if any devs have tho - file a 
 bugreport.

http://bugs.archlinux.org/task/9498



Re: [arch-general] X11 man pages

2008-02-08 Thread Jan de Groot

On Fri, 2008-02-08 at 17:13 -0600, Aaron Griffin wrote:
 On Feb 8, 2008 5:06 PM, marc[î1] [EMAIL PROTECTED] wrote:
  Hello,
 
  Arch devs put man pages in /usr/share/man like FHS want, ok.
 
  But FHS says :
  « Manual pages for X11R6 are stored in /usr/X11R6/man. It follows that all
  manual page hierarchies in the system must have the same structure
  as /usr/share/man. »
  http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
 
  I don't understand FHS or ArchLinux should put X11 man page
  in /usr/X11R6/man ?
 
 Hmmm, I actually think you might be right here. It seems weird, but
 the FHS is fairly explicit on it. I'd suggest you file a bug report
 about this.
 
 As for Travis' comment, xorg 7 is an implementation of X11R6.

No, not the crappy /usr/X11R6 prefix again. FHS or not, the manpages
don't belong in a directory where the rest isn't installed. Even Debian,
the most FHS-compliant distro I know, isn't installing X11 packages
in /usr/X11R6 anymore.




Re: [arch-general] X11 man pages

2008-02-08 Thread Dan McGee
On Feb 8, 2008 5:35 PM, Roman Kyrylych [EMAIL PROTECTED] wrote:
 2008/2/9, Jan de Groot [EMAIL PROTECTED]:
  No, not the crappy /usr/X11R6 prefix again. FHS or not, the manpages
  don't belong in a directory where the rest isn't installed. Even Debian,
  the most FHS-compliant distro I know, isn't installing X11 packages
  in /usr/X11R6 anymore.

 +1!
 /usr/X11R6 must die! :-P

I will be pissed off if you put this stupid worthless directory back
on my machine. Are we in the 1980s again? This would go against any
removal of things such as installs in /opt/ that we have been working
so hard to fix.

This is even more retarded because we run X11R7 for that matter.
http://en.wikipedia.org/wiki/X_Window_System#Release_history

-Dan