devil-linux-develop — developer discussions

Re: [Devil-linux-develop] arpwatch

[Diego T. <dt...@co...>]

On Sat, May 01, 2004 at 08:22:28AM -0400, Heiko Zuerker wrote:

> I added it to the feature requests, but it won't make it into 1.2 anymore.

it's too late for me to include the arpwatch patches on 1.2?
-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] Ethernet Link Detection

[Heiko Z. <he...@zu...>]

Frischknecht Peter wrote:
> Does anybody have interest in automatic link detection.
> 
> The idea is to be able to run scripts based on the link state of the card.
> 
> This project:
> http://0pointer.de/lennart/projects/ifplugd/
> 
> It was originally designed for laptops, but we could use it as well.  I 
> have already played with it, it works well. 
> 
> Why do I need it? (or want it)
> Let's say we are perfiorming an upgrade of some kind to the network.  
> Instead of getting harassing phone calls from users, we simply unplug 
> the WAN side of the DL router.  Ifplugd will fire up a script that 
> blocks all traffic and redirects WWW to a local web server in the DL box 
> itself (say on port 8080).
> Example:
> iptables -t nat -I PREROUTING -i (LAN interface) -p tcp --dport 80 -j 
> REDIRECT --to-port 8080.
> The users will now see a page that says: "Sorry for the trouble...we 
> will be back up in a little bit.  Go watch TV."
> 
> When we plug the WAN port back in, ifplugd automagically removes the 
> iptables entries and life is good.
> Neat?
> 
> Who is interested?
> 

I think it's a nice feature.

I added it to the feature requests, but it won't make it into 1.2 anymore.

Heiko

[Devil-linux-develop] [ devil-linux-Feature Requests-945875 ] ifplugd (Ethernet Link Detection)

[SourceForge.net <no...@so...>]

Feature Requests item #945875, was opened at 2004-05-01 07:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=945875&group_id=34096

Category: Packages
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: ifplugd (Ethernet Link Detection)

Initial Comment:
The idea is to be able to run scripts based on the link
state of the card.

This project:
http://0pointer.de/lennart/projects/ifplugd/

It was originally designed for laptops, but we could
use it as well.  I have already played with it, it
works well. 

Why do I need it? (or want it)
Let's say we are perfiorming an upgrade of some kind to
the network.  Instead of getting harassing phone calls
from users, we simply unplug the WAN side of the DL
router.  Ifplugd will fire up a script that blocks all
traffic and redirects WWW to a local web server in the
DL box itself (say on port 8080).
Example:
iptables -t nat -I PREROUTING -i (LAN interface) -p tcp
--dport 80 -j REDIRECT --to-port 8080.
The users will now see a page that says: "Sorry for the
trouble...we will be back up in a little bit.  Go watch
TV."

When we plug the WAN port back in, ifplugd
automagically removes the iptables entries and life is
good.
Neat?

Who is interested?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=945875&group_id=34096

Re: [Devil-linux-develop] [PATCH] arpwatch_report

[Peter F. <pe...@em...>]

On Sat, 2004-05-01 at 04:53, Diego Torres wrote:
> On Fri, Apr 30, 2004 at 09:11:22PM -0500, Frischknecht Peter wrote:
> > 
> > For those of us who wish arpwatch did a little more than send an email...here is your new toy.
> 
> I was wondering... can arpwatch send reports to syslog?
It already does.

If DL had "local" logs, we could use utilities that scanned syslog for
changes and then fire up events based on arpwatch entries.  But because
of space constraints, all the event log messages are forwarded to a
different server (syslog-ng).  Hence my need for another utility...hence
arpwatch_report

-- 
Peter Frischknecht <pe...@em...>
Empowering Solutions, Inc.

Re: [Devil-linux-develop] [PATCH] arpwatch_report

[Diego T. <dt...@co...>]

On Fri, Apr 30, 2004 at 09:11:22PM -0500, Frischknecht Peter wrote:
> 
> For those of us who wish arpwatch did a little more than send an email...here is your new toy.

I was wondering... can arpwatch send reports to syslog?
-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

[Devil-linux-develop] Ethernet Link Detection

[Frischknecht P. <pe...@em...>]

Does anybody have interest in automatic link detection.

The idea is to be able to run scripts based on the link state of the =
card.

This project:
http://0pointer.de/lennart/projects/ifplugd/

It was originally designed for laptops, but we could use it as well.  I =
have already played with it, it works well. =20

Why do I need it? (or want it)
Let's say we are perfiorming an upgrade of some kind to the network.  =
Instead of getting harassing phone calls from users, we simply unplug =
the WAN side of the DL router.  Ifplugd will fire up a script that =
blocks all traffic and redirects WWW to a local web server in the DL box =
itself (say on port 8080).
Example:
iptables -t nat -I PREROUTING -i (LAN interface) -p tcp --dport 80 -j =
REDIRECT --to-port 8080.
The users will now see a page that says: "Sorry for the trouble...we =
will be back up in a little bit.  Go watch TV."

When we plug the WAN port back in, ifplugd automagically removes the =
iptables entries and life is good.
Neat?

Who is interested?

Re: [Devil-linux-develop] Missing man pages?

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>>A quick look makes me wonder about these scripts:  acl, attr, xfsprogs
>>>Which all do this:
>>>
>>>cd $CDDIR || exit 1
>>>tar -xzf ...some.tar.file....
>>>copy_docs
>>>
>>>And "copy_docs" is run without a parameter, which defaults to "." as the
>>>first parameter.  And copy_docs does this (in $CDDIR):
>>>
>>>BD=$1
>>>[ -z "$BD" ] && BD=$(pwd)
>>># a whole bunch of "cp" lines removed
>>>rm -rf $BD/{doc,man,info}
>>>rm -rf $BD/usr/{doc,man,info}
>>>rm -rf $BD/usr/local/{doc,man,info}
>>>rm -rf $BD/usr/share/{doc,man,info}
>>>rm -rf $BD/share/{doc,man,info}
>>>
>>>Am I reading this correctly?  (if so, yikes! :)
>>
>>Yes you found the problem.
>>
>>I think there should be a if clause around those rm statements to make sure
>>nothing gets deleted under $CDDIR
> 
> 
> I'll make the change if you explain a couple things to me.
> 
> First, what's the logic behind untar'ing a file in the "make install"
> phase of those scripts?  Does "make build" create a tar file?

make dist
actually does it. Unfortunately theose libs/tools don't have a way of 
redirecting the "make install" target.

> Second, if it's untar'ing the file in $CDDIR, why does it have to run
> copy_docs at all?  Is it untaring the man pages to the wrong path, and
> copy_docs moves them to the correct path?  If so, shouldn't the install
> script also remove the files from the incorrect path? (or does some
> post-install script do the removing?)
> 
> Also (related to 2nd question), doesn't this cp line in copy_docs copy
> files on top of themselves?  cp -dpR $BD/usr/share/man $CDDIR/usr/share
> Isn't that a bad thing?  

Correct.

> Maybe we shouldn't be running copy_docs at all in these scripts?

Actually that would be the right fix.

Heiko

[Devil-linux-develop] CVS hostname change

[William G. <dl-...@gm...>]

All,

You will need to change your CVS host from cvs.devil-linux.sourceforge.net to cvs.sourceforge.net effect 28APR04.  The following is straight from the Sourceforge Status.

(  2004-04-29 14:11:35 - Project CVS Service )   As of 2004-04-28 the CVS services will no longer function with the hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS commands to use the host cvs.sourceforge.net and that should resolve any outstanding issues that you may have. This issue came about as a result of upgrading from BIND 8 to BIND 9 which doesn't allow for a wildcard in the middle of a hostname.

Cheers,

William

Re: [Devil-linux-develop] Missing man pages?

[Bruce S. <bw...@ar...>]

> >A quick look makes me wonder about these scripts:  acl, attr, xfsprogs
> >Which all do this:
> >
> >cd $CDDIR || exit 1
> >tar -xzf ...some.tar.file....
> >copy_docs
> >
> >And "copy_docs" is run without a parameter, which defaults to "." as the
> >first parameter.  And copy_docs does this (in $CDDIR):
> >
> >BD=$1
> >[ -z "$BD" ] && BD=$(pwd)
> ># a whole bunch of "cp" lines removed
> >rm -rf $BD/{doc,man,info}
> >rm -rf $BD/usr/{doc,man,info}
> >rm -rf $BD/usr/local/{doc,man,info}
> >rm -rf $BD/usr/share/{doc,man,info}
> >rm -rf $BD/share/{doc,man,info}
> >
> >Am I reading this correctly?  (if so, yikes! :)
> 
> Yes you found the problem.
>
> I think there should be a if clause around those rm statements to make sure
> nothing gets deleted under $CDDIR

I'll make the change if you explain a couple things to me.

First, what's the logic behind untar'ing a file in the "make install"
phase of those scripts?  Does "make build" create a tar file?

Second, if it's untar'ing the file in $CDDIR, why does it have to run
copy_docs at all?  Is it untaring the man pages to the wrong path, and
copy_docs moves them to the correct path?  If so, shouldn't the install
script also remove the files from the incorrect path? (or does some
post-install script do the removing?)

Also (related to 2nd question), doesn't this cp line in copy_docs copy
files on top of themselves?  cp -dpR $BD/usr/share/man $CDDIR/usr/share
Isn't that a bad thing?  

Maybe we shouldn't be running copy_docs at all in these scripts?

 - BS

Re: [Devil-linux-develop] LFTP

[Bruce S. <bw...@ar...>]

> >Someone point out to me privately that the lftp tarball in:
> >ftp://ftp.devil-linux.org/pub/devel/sources/tools/
> >is older than the one we compile in our src directory.
> >And our docs reference that directory for needed tools:
> >http://www.devil-linux.org/newdoc/ch03s01.html#d0e1068
> >I'd be nice if we could just link it so we don't need 2 copies.
> >Or change the docs to point to the latest lftp in our source
> >and get rid for the tools directory entirely.
> 
> It doesn't really matter. The lftp in the tools directory is in the case
> your OS doesn't have it already.
> We could just update it from time to time or write in our docs the URL of
> the lfp homepage.

I think we should get rid of the tools directory and changes the docs to
point to the LFTP home page.  It'd be less confusing IMO.  (and I'd get
fewer complaints :)

> >Also...
> >Checking the lftp homepage http://lftp.yar.ru/ the current version
> >(3.0.3) is newer than any of our versions (2.6.12).  Is there any
> >reason we shouldn't move to version 3.x.x?
>
> Somebody has to update  & test it, that's all.
> You just volunteered. ;-)

Oops.  :-)

 - BS

Re: [Devil-linux-develop] LFTP

[<hzu...@ra...>]

On 04/30/2004 11:55:12 AM Bruce Smith wrote:
>Someone point out to me privately that the lftp tarball in:
>ftp://ftp.devil-linux.org/pub/devel/sources/tools/
>is older than the one we compile in our src directory.
>And our docs reference that directory for needed tools:
>http://www.devil-linux.org/newdoc/ch03s01.html#d0e1068
>I'd be nice if we could just link it so we don't need 2 copies.
>Or change the docs to point to the latest lftp in our source
>and get rid for the tools directory entirely.

It doesn't really matter. The lftp in the tools directory is in the case
your OS doesn't have it already.
We could just update it from time to time or write in our docs the URL of
the lfp homepage.

>Also...
>Checking the lftp homepage http://lftp.yar.ru/ the current version
>(3.0.3) is newer than any of our versions (2.6.12).  Is there any
>reason we shouldn't move to version 3.x.x?
>

Somebody has to update  & test it, that's all.
You just volunteered. ;-)

Heiko

Re: [Devil-linux-develop] Missing man pages?

[<hzu...@ra...>]

On 04/30/2004 01:39:30 PM Bruce Smith wrote:
>> My 4/28 build is also missing a ton of man pages... I did select to
>have
>> them on CD. Some made it. But lots (sshd, imapd.conf, cyrus.conf, and
>> many more) did not make it. Did this happen to others too?
>
>Yes, my 4/25 build has the same problem.  Good catch!
>
>> I did select "no locales" on the build menu,
>
>I didn't, and I have the same problem.
>
>> but I think thats what I had selected in my previous build and came
>> out ok. I don't see any errors regarding man pages.
>
>I wonder if some script in the middle of "make install" is nuking the
>$CDDIR man directories ...
>
>A quick look makes me wonder about these scripts:  acl, attr, xfsprogs
>Which all do this:
>
>cd $CDDIR || exit 1
>tar -xzf ...some.tar.file....
>copy_docs
>
>And "copy_docs" is run without a parameter, which defaults to "." as the
>first parameter.  And copy_docs does this (in $CDDIR):
>
>BD=$1
>[ -z "$BD" ] && BD=$(pwd)
># a whole bunch of "cp" lines removed
>rm -rf $BD/{doc,man,info}
>rm -rf $BD/usr/{doc,man,info}
>rm -rf $BD/usr/local/{doc,man,info}
>rm -rf $BD/usr/share/{doc,man,info}
>rm -rf $BD/share/{doc,man,info}
>
>Am I reading this correctly?  (if so, yikes! :)

Yes you found the problem.

I think there should be a if clause around those rm statements to make sure
nothing gets deleted under $CDDIR

Heiko

Re: [Devil-linux-develop] Missing man pages?

[Bruce S. <bw...@ar...>]

> My 4/28 build is also missing a ton of man pages... I did select to have 
> them on CD. Some made it. But lots (sshd, imapd.conf, cyrus.conf, and 
> many more) did not make it. Did this happen to others too? 

Yes, my 4/25 build has the same problem.  Good catch!

> I did select "no locales" on the build menu, 

I didn't, and I have the same problem.

> but I think thats what I had selected in my previous build and came
> out ok. I don't see any errors regarding man pages.

I wonder if some script in the middle of "make install" is nuking the
$CDDIR man directories ...

A quick look makes me wonder about these scripts:  acl, attr, xfsprogs
Which all do this:

        cd $CDDIR || exit 1
        tar -xzf ...some.tar.file....
        copy_docs

And "copy_docs" is run without a parameter, which defaults to "." as the
first parameter.  And copy_docs does this (in $CDDIR):

        BD=$1
        [ -z "$BD" ] && BD=$(pwd)
	# a whole bunch of "cp" lines removed
        rm -rf $BD/{doc,man,info}
        rm -rf $BD/usr/{doc,man,info}
        rm -rf $BD/usr/local/{doc,man,info}
        rm -rf $BD/usr/share/{doc,man,info}
        rm -rf $BD/share/{doc,man,info}

Am I reading this correctly?  (if so, yikes! :)

 - BS

[Devil-linux-develop] Missing man pages?

[Tim <t....@co...>]

My 4/28 build is also missing a ton of man pages... I did select to have 
them on CD. Some made it. But lots (sshd, imapd.conf, cyrus.conf, and 
many more) did not make it. Did this happen to others too? I did select 
"no locales" on the build menu, but I think thats what I had selected in 
my previous build and came out ok. I don't see any errors regarding man 
pages.

Tim

[Devil-linux-develop] LFTP

[Bruce S. <bw...@ar...>]

Someone point out to me privately that the lftp tarball in:
ftp://ftp.devil-linux.org/pub/devel/sources/tools/
is older than the one we compile in our src directory.
And our docs reference that directory for needed tools:
http://www.devil-linux.org/newdoc/ch03s01.html#d0e1068
I'd be nice if we could just link it so we don't need 2 copies.
Or change the docs to point to the latest lftp in our source
and get rid for the tools directory entirely.

Also...
Checking the lftp homepage http://lftp.yar.ru/ the current version
(3.0.3) is newer than any of our versions (2.6.12).  Is there any 
reason we shouldn't move to version 3.x.x?

 - BS

[Devil-linux-develop] arpwatch - installation bug

[Peter F. <pe...@em...>]

By default, arpwatch will not run on DL.
In order to make it work, you have to create an empty file called
arp.dat and then FROM THE SAME directory fire up arpwatch

Eg:
cd /root
touch arp.dat
arpwatch -i eth1

At this point, arpwatch WILL run, HOWEVER...the mail functionality still
will not work.
Looking at the original Makefile, it is seeking sendmail under
/usr/lib/sendmail
(guess what...it ain't there)
If you do install postfix, it creates fake links to sendmail under (I
think) /usr/bin/sendmail.  As if that was not enough, the emails are
ONLY sent to ROOT on the localhost.
It is up to you to set up a .forward file on the root home (/root) to
receive these emails elsewhere and not run out of RAMDISK space.

As a side note, the arp.dat file should never grow too large.  It stores
KNOWN ethernet mac addresses, as long as your DL box does not sit in
some major campus backbone with thousands of visible MAC addresses, it
should stay very small.  I have 400Mac addresses on my file, and it is
only 14Kbytes.

I would send in the changes to the source file, but I do not know how to
do it.
1 - The install script has to copy (or create) the arp.dat file to a
place like /var/log
2 - The makefile has to be appropriately updated.  There is a line that
reads ARPDIR=$(prefix)/arpwatch. It should be changed to ARPDIR=/var/log
3 - The default etc.tar.gz should be updated accordingly and contain the
arp.dat file.
4 - You can also update the addresses.h.in and change the dest address
of the arp notifications PRIOR to compilation

NOTE:  I knew I needed arpwatch.  It struck me as very odd that arpwatch
has NO configuration files.  If somebody knows differently, please tell
me.  Because compiling "/var/log" or the dest email address in to the
executable is not elegant at all.

-- 
Peter Frischknecht <pe...@em...>
Empowering Solutions, Inc.

Re: [Devil-linux-develop] apcuspd not created?

[Roland P. <pa...@ta...>]

On Friday 30 April 2004 09:50, Roland Pabel wrote:
> On Friday 30 April 2004 06:40, Tim Tait wrote:
> > My build from the latest on 4/28 failed to make apcupsd though it was
> > selected. Log shows errors but it did not halt the build.
>
> strange...the build doesn't succeed but neither does it fail...the script
> looks sane to me, every command in the build section is followed by '||
> exit 1'
> I'll test if reverting to 3.10.12 helps or if it's related to the kernel
> update
ok, there are three bugs here:
1) why was the build succesful although it obviously failed - i don't know
2) there is a struct introduced 2.4.26 in include/linux/include/hiddev.h which 
uses an undefined constant HID_MAX_USAGES, because it is actually defined in 
drivers/usb/hid.h
This needs to be fixed for any version of apcupsd. (apcupsd doesn't use the 
struct which uses HID_MAX_USAGES, it's just the compiler complaining).
Google shows this has been reported to LKML, but for some reason it was not 
fixed...Please add linux-2.4.26-hiddev-rp.diff to kernel-patches-2.4.tar.bz2
3) Even when that is fixed, the build fails because Makefile targets can't be 
found in several Makefiles. These vanish when using 'make all' instead of 
'make $PMAKE all', looks like apcupsd doesn't like parallel builds now...but 
I'd recommend keeping 3.10.13, it got tons of bugfixes
Please test my patches, they worked for me(tm)...
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] apcuspd not created?

[Roland P. <pa...@ta...>]

On Friday 30 April 2004 06:40, Tim Tait wrote:
> My build from the latest on 4/28 failed to make apcupsd though it was
> selected. Log shows errors but it did not halt the build.
strange...the build doesn't succeed but neither does it fail...the script 
looks sane to me, every command in the build section is followed by '|| exit 
1'
I'll test if reverting to 3.10.12 helps or if it's related to the kernel 
update
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

[Devil-linux-develop] apcuspd not created?

[Tim T. <t....@co...>]

My build from the latest on 4/28 failed to make apcupsd though it was 
selected. Log shows errors but it did not halt the build.

I also noticed I got a few "command not found"'s, like "ed" during the 
Cyrus-Imapd make. Everything seems to be current with the latest cvs.

Tim
 ----------
 In file included from linux-usb.c:21:
 /usr/include/linux/hiddev.h:134: error: `HID_MAX_USAGES' undeclared 
here (not in a function)
 make[4]: *** [linux-usb.o] Error 1

apcupsd.o(.text+0x423): In function `main':
/data/build/tmp/apcupsd-3.10.13/src/apcupsd.c:324: undefined reference 
to `attach_driver'
collect2: ld returned 1 exit status
make[2]: *** [apcupsd] Error 1
make[2]: Leaving directory `/data/build/tmp/apcupsd-3.10.13/src'
make[1]: Leaving directory `/data/build/tmp/apcupsd-3.10.13'
removing debug symbols from binaries
----------

Re: [Devil-linux-develop] Problems accessing CVS

[Friedrich L. <fl...@fl...>]

William Gilmore wrote on 29.04.2004 22:45 MET:
> 
> Thanks for you update.  I suspected it may be something like this but couldn't find any notice on sourceforge about it.  Would you mind pointing me to the link where you found the info?

* http://sf.net/

* left side,
      section "SF.net Resources"
         ==> click "Site Status"

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Problems accessing CVS

[William G. <dl-...@gm...>]

Friedrich,

Thanks for you update.  I suspected it may be something like this but couldn't find any notice on sourceforge about it.  Would you mind pointing me to the link where you found the info?

Thanks,

William

=================================

William Gilmore wrote on 29.04.2004 16:59 MET:

> Has anyone else had problem accessing CVS today?  I could not connect to it last night and I am having the same problems this morning.  It doesn't appear to be responding at all.  I see my TCP SYN SENT and no traffic after that point.

It seems SF had some troubles there:

http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1

(  2004-04-22 10:56:07 - Project CVS Service )   As of 2004-04-22 the CVS
sync process between developer and anonymous CVS is back to it's normal 5
hour delay after resolving the outstanding performance issues of the last
couple of days. Any new performance issues should be reported to the
SourceForge.net staff via a Support Request.

( 2004-04-21 19:38:17 - Project CVS Service )   To address immediate
performance concerns with developer (SSH) CVS, SourceForge.net staff have
decreased the sync frequency between developer CVS and pserver CVS to
alleviate excessive disk load while a more permanent solution is
implemented. We expect to resume normal sync frequency in the next 1-2 days
depending on the amount of time to implement the more permanent solution.

--
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] Problems accessing CVS

[Friedrich L. <fl...@fl...>]

William Gilmore wrote on 29.04.2004 16:59 MET:

> Has anyone else had problem accessing CVS today?  I could not connect to it last night and I am having the same problems this morning.  It doesn't appear to be responding at all.  I see my TCP SYN SENT and no traffic after that point.

It seems SF had some troubles there:

http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1

(  2004-04-22 10:56:07 - Project CVS Service )   As of 2004-04-22 the CVS 
sync process between developer and anonymous CVS is back to it's normal 5 
hour delay after resolving the outstanding performance issues of the last 
couple of days. Any new performance issues should be reported to the 
SourceForge.net staff via a Support Request.

( 2004-04-21 19:38:17 - Project CVS Service )   To address immediate 
performance concerns with developer (SSH) CVS, SourceForge.net staff have 
decreased the sync frequency between developer CVS and pserver CVS to 
alleviate excessive disk load while a more permanent solution is 
implemented. We expect to resume normal sync frequency in the next 1-2 days 
depending on the amount of time to implement the more permanent solution.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

[Devil-linux-develop] Problems accessing CVS

[William G. <dl-...@gm...>]

Has anyone else had problem accessing CVS today?  I could not connect to it last night and I am having the same problems this morning.  It doesn't appear to be responding at all.  I see my TCP SYN SENT and no traffic after that point.

Thanks,

William

Re: [Devil-linux-develop] Update kernel to 2.6.5 (testing)

[<hzu...@ra...>]

On 04/29/2004 05:49:37 AM Oliver Jehle wrote:
>another little bit of improving :-) the kernel 2.6 support ...
>upgrade to 2.6.5... but its in testing state.. but better then nothing
>
>config_linux
>--------------
>
>the config_linux is only a patch against my .config
>as i can see, was the old  config-linux file only a manually updated
>file, and there is a little bit a mess to merge them together...
>
>ideas are welcome !!!

The way I do a kernel update is the following:
I do a full compile with the old Kernel and then replace the sources.
Before you delete the old kernel tree copy over the .config file into the
new kernel tree.
Then go ahead and do a "make oldconfig", which  only show the new entries.
The rest is copy'n'paste into the config_linux file.

Since we have our config split over several files, this is the only
reliable (and actually fastest) way I found on how to do it.

Heiko

Re: [Devil-linux-develop] more boot features

[<hzu...@ra...>]

On 04/29/2004 09:46:33 AM Bruce Smith wrote:
>> >I've been looking at adding "mon" on the feature requests.
>> >
>> >My research shows it needs a bunch of perl modules we don't have,
>> >and I've never added a perl module to DL.  Is anything required
>> >other than uploading the source of the module to the perl-ext
>> >subdirectory?
>>
>> Sometimes you have to patch the Makefile.PL to get rid of the prompts.
>>
>> Just copy the stuff into the perl-ext directory and recompile perl.
>> If it prompts for something, then you know you have to patch it. ;-)
>
>Maybe I won't add "mon" ...
>Any clue what to do about this?
>
>
>Making IO-Tty-1.02 (nonxs)
>Can't load module IO, dynamic loading not available in this perl.
>(You may need to build a new perl executable which either supports
>dynamic loading or has the IO module statically linked into it.)
>at ../../lib/IO/Handle.pm line 260
>Compilation failed in require at ../../lib/IO/Handle.pm line 260.
>BEGIN failed--compilation aborted at ../../lib/IO/Handle.pm line 260.
>Compilation failed in require at ../../lib/IO/Seekable.pm line 101.
>BEGIN failed--compilation aborted at ../../lib/IO/Seekable.pm line 101.
>Compilation failed in require at ../../lib/IO/File.pm line 117.
>BEGIN failed--compilation aborted at ../../lib/IO/File.pm line 117.
>Compilation failed in require at Makefile.PL line 5.
>BEGIN failed--compilation aborted at Makefile.PL line 5.
>Warning: No Makefile!
>make[1]: Entering directory `/data/build/tmp/perl-5.8.3/ext/IO-Tty-1.02'
>make[1]: *** No rule to make target `config'.  Stop.
>make[1]: Leaving directory `/data/build/tmp/perl-5.8.3/ext/IO-Tty-1.02'
>make config failed, continuing anyway...
>make[1]: Entering directory `/data/build/tmp/perl-5.8.3/ext/IO-Tty-1.02'
>make[1]: *** No rule to make target `all'.  Stop.
>make[1]: Leaving directory `/data/build/tmp/perl-5.8.3/ext/IO-Tty-1.02'
>make: *** [ext/IO-Tty-1.02/pm_to_blib] Error 2
>ERROR
>/data/build/scripts/perl build failed
>check log file /data/build/tmp/LOGS/build/perl for details

That problem I saw on other perl-ext packages too, but never found out
where it comes from.

Do we have any perl experts here ?

Heiko