ipcop-devel Mailing List for IPCop Firewall

----- Mail original -----
> De: "Olaf Westrik" <wei...@ip...>
> À: "g esp" <g....@fr...>
> Cc: "IPCop devel" <ipc...@li...>
> Envoyé: Vendredi 30 Mars 2012 21:33:41
> Objet: Re: [IPCop-devel] glib /pkg-config upgrade
> 
> On 2012-03-24 19:49, g....@fr... wrote:
> > I figured how to solve or hide the glib test failures during glib
> > upgrade to 2.30.3.
> > I really solve GDateTime issue using
> > TZDIR=/usr/share/zoneinfo/posix during tests.
> > For the dbus error, I managed to skip bus tests as we have no usage
> > if dbus.
> >
> > But I am still battling  to build glib-2.30 without python.
> > Probably building Python before glib will the easiest.
> >
> > What do you mind about the python move?
> 
> My first preference would be to drop it completely.
> Failing that, I do not mind moving it.
> 
> IIRC we have only 1 use for python at the moment, mklibs.
> The main reason for having mklibs is size reduction for floppy
> images,
> but since we can't build those anymore, how about we drop mklibs?
> 
> 
> Olaf
> 
I slightly disagree for "can't build anymore". I have uncommited changes that could fix that.
This stay uncommited as there is no request, I haven't yet run tested that and there is still some minor fixes needed in the changes.

I think a x86_64 build is a much higher priority.

Anyway, I was not able to build glib-2.30 without python.
I am sure that could be done, but that may not be easy and maybe not so maintainable.
For thoses reasons, the python move is the easiest.

Gilles

On 2012-03-24 19:49, g....@fr... wrote:
> I figured how to solve or hide the glib test failures during glib upgrade to 2.30.3.
> I really solve GDateTime issue using TZDIR=/usr/share/zoneinfo/posix during tests.
> For the dbus error, I managed to skip bus tests as we have no usage if dbus.
>
> But I am still battling  to build glib-2.30 without python.
> Probably building Python before glib will the easiest.
>
> What do you mind about the python move?

My first preference would be to drop it completely.
Failing that, I do not mind moving it.

IIRC we have only 1 use for python at the moment, mklibs.
The main reason for having mklibs is size reduction for floppy images, 
but since we can't build those anymore, how about we drop mklibs?


Olaf

I figured how to solve or hide the glib test failures during glib upgrade to 2.30.3.
I really solve GDateTime issue using TZDIR=/usr/share/zoneinfo/posix during tests.
For the dbus error, I managed to skip bus tests as we have no usage if dbus.

But I am still battling  to build glib-2.30 without python.
Probably building Python before glib will the easiest.

What do you mind about the python move?

When glib build is ok, I will next work on pgkconfig-0.26 (and build both at the beginning of ipcop stage).

Gilles

Eric,


thanks for the reminder.

>> While manually installing the 2.1.0 upgrade, I get an error message
>> from mkinitramfs while running the 'setup' command.
>> It says:
>>
>> depmod: chdir(lib/modules/2.6.32-6) No such file or directory
>> ERROR: Error during initramfs depmod
>> 2.1.0 update installed

I think the error message is misleading, root cause is busybox depmod 
not acceting the 3.0 version number as a valid linux kernel.
See also commit #6346

We need to integrate the newer busybox into our initramfs.

> And here's the update transcript, which indicates something is going
> wrong on Line 3...
>
> IPCop diagnostics
> Section: Update transcript
> Date: 2012-03-17
>
> 17:05:44 installpackage Shifting boot configfile from 2.6.32-6 to 3.0-1
> 17:05:45 installpackage Removing kernel 2.6.32-5
> 17:05:48 installpackage Shifting boot configfile from 2.6.32-5 to 2.6.32-6
> 17:06:03 installpackage 2.1.0 update installed.

The message lines are OK, which actually is not OK. The errormessage 
from mkinitramfs should also be shown there.


Olaf

On 17 March 2012 17:31, Eric Oberlander <eri...@gm...> wrote:
> Hi Olaf
>
> While manually installing the 2.1.0 upgrade, I get an error message
> from mkinitramfs while running the 'setup' command.
> It says:
>
> depmod: chdir(lib/modules/2.6.32-6) No such file or directory
> ERROR: Error during initramfs depmod
> 2.1.0 update installed
>
> I can still see the directory /lib/modules/2.6.32-6 and is contents...
>
> Is the leading / significant?
>
> Let me know if I can provide any more information.
>
> Eric

And here's the update transcript, which indicates something is going
wrong on Line 3...

IPCop diagnostics
Section: Update transcript
Date: 2012-03-17

17:05:44 installpackage Shifting boot configfile from 2.6.32-6 to 3.0-1
17:05:45 installpackage Removing kernel 2.6.32-5
17:05:48 installpackage Shifting boot configfile from 2.6.32-5 to 2.6.32-6
17:06:03 installpackage 2.1.0 update installed.

Eric

Hi Olaf

While manually installing the 2.1.0 upgrade, I get an error message
from mkinitramfs while running the 'setup' command.
It says:

depmod: chdir(lib/modules/2.6.32-6) No such file or directory
ERROR: Error during initramfs depmod
2.1.0 update installed

I can still see the directory /lib/modules/2.6.32-6 and is contents...

Is the leading / significant?

Let me know if I can provide any more information.

Eric

I recently changed the machine I was using for IPCOP, I guess the running
history up to that point didn't "restore" to the new unit.

Thanks,
Levi

On Sun, Mar 11, 2012 at 7:28 AM, Eric Oberlander
<eri...@gm...>wrote:

> On 10 March 2012 19:27, MyStiC <mys...@gm...> wrote:
>
> > Hello,
> > My ISP just sent a notice that they will be capping Internet usage &
> > imposing fines for those who exceed it.  How can I set the "start/end"
> > points to match w/their monthly cycle?
>
> In 2.0, you can set the first day of the monthly cycle on the 'Traffic
> Accounting Configuration' page, reached from the button on the Traffic
> Accounting Page.
>
> http://ipcop.org/2.0.0/en/admin/html/status-traffic-accounting.html
>
> Eric
>

On 10 March 2012 19:27, MyStiC <mys...@gm...> wrote:

> Hello,
> My ISP just sent a notice that they will be capping Internet usage &
> imposing fines for those who exceed it.  How can I set the "start/end"
> points to match w/their monthly cycle?

In 2.0, you can set the first day of the monthly cycle on the 'Traffic
Accounting Configuration' page, reached from the button on the Traffic
Accounting Page.

http://ipcop.org/2.0.0/en/admin/html/status-traffic-accounting.html

Eric

Hello,
My ISP just sent a notice that they will be capping Internet usage &
imposing fines for those who exceed it.  How can I set the "start/end"
points to match w/their monthly cycle?

forgot to reply all

----- Mail transféré -----
De: "g esp" <g....@fr...>
À: her...@gm...
Envoyé: Vendredi 9 Mars 2012 17:33:20
Objet: Re: [IPCop-devel] IPCop Devel - latest svn



----- Mail original -----
> De: "herauthon" <her...@gm...>
> À: ipc...@li...
> Envoyé: Vendredi 9 Mars 2012 15:44:23
> Objet: [IPCop-devel] IPCop Devel - latest svn
> 
> 
> Dear fellows,
> 
> I keep it short as possible
> i did
> svn checkout
> https://ipcop.svn.sourceforge.net/svnroot/ipcop/ipcop/trunk
> then
> cd trunk
> then
> ./make.sh prefetch
> 
> it slurpted alot of files but failed a few
> _________________
> 
> lsof (Attempt: 3) [ FAIL ] [ FAIL ]
> perl (Attempt: 3) [ FAIL ] [ FAIL ]
> vlan (Attempt: 3) [ FAIL ] [ FAIL ]
> __________________
> 
> How can i fix this lil issue and proceed ?
> 
> Thanks to you!
> 
> 
Failure details are in log_i486/preparation.log

For perl, that should be debian that released a newer patch set.
I will fix that unless Olaf beat me. 
Or you may dowwload the new .diff and update md5 and that would work.

For lsof and vlan, maybe this is temporary site issue.
You could use google with package file name, usually that work well. Put the file in cache and everything will be right and secure if md5 match as it should.

Gilles

Dear fellows,

I keep it short as possible
i did
 svn checkout https://ipcop.svn.sourceforge.net/svnroot/ipcop/ipcop/trunk
then
cd trunk
then
./make.sh prefetch

it slurpted alot of files but failed a few
_________________

lsof (Attempt: 3)  [ FAIL ] [ FAIL ]
perl (Attempt: 3)  [ FAIL ] [ FAIL ]
vlan (Attempt: 3)  [ FAIL ] [ FAIL ]
__________________

How can i fix this lil issue and proceed ?

*Thanks to you!*

Begging your pardon if this is better on the user mailing list...

I've been running IPcop 1.4 on an HP Proliant (PC server) for a while,
where it works well (thank you). Upon trying to install 2.0 on the
machine, I (and others
http://www.ipcops.com/phpbb3/viewtopic.php?f=16&t=16918 ) have found
that it does not support the hardware RAID controller in these machines.

In more detail, the problem appears to be that the installer does not
handle 'unusual' disk device names. My machine (Proliant DL380 G3)
contains an integrated "SmartArray 5i", this is handled by the "cciss"
driver, which is definitely included in the IPcop 2.0 kernel, however
that driver presents the configured RAID disks as block devices (rather
than SCSI disks) with names in /dev like
/dev/cciss/c0d0     first controller, first disk
/dev/cciss/c1d2p1   second controller, third disk, first partition (yes,
controller and disk are zero-indexed, partitions are indexed from 1)

This is handled fine by the 1.4 installer routine. The following is from
my current 1.4 machine:
root@milton:~ # ls -l /dev/harddisk*
lrwxrwxrwx 1 root root 15 2006-02-09 11:35 /dev/harddisk
-> /dev/cciss/c0d0
lrwxrwxrwx 1 root root 17 2006-02-09 11:35 /dev/harddisk1
-> /dev/cciss/c0d0p1
lrwxrwxrwx 1 root root 17 2006-02-09 11:35 /dev/harddisk2
-> /dev/cciss/c0d0p2
lrwxrwxrwx 1 root root 17 2006-02-09 11:35 /dev/harddisk3
-> /dev/cciss/c0d0p3
lrwxrwxrwx 1 root root 17 2006-02-09 11:35 /dev/harddisk4
-> /dev/cciss/c0d0p4

I have tried switching to a VC with a shell while the 2.0 installer is
running, and linking /dev/sda to /dev/cciss/c0d0 and /dev/sda1
to /dev/cciss/c0d0p1 etc, then back to the ncurses interface and
pressing the "Rescan" button, however that did not make it work.

I work for an HP reseller and have access to a number of Proliants, so I
can do some testing on various configurations if that helps.


Further detail on Linux on the "Proliant" range:
Older Compaq-badged proliants (e.g.
http://marc.info/?l=ipcop-devel&m=127844232704113&w=2) usually have the
cpqarray module, and devices like /dev/ida/c0d0 (I don't think we have
any of these for testing - they're bit too old)
More recent (generation 3 to 5 or 6) HP-badged proliants have
"SmartArray" hardware, driven by the cciss module, and device nodes
like /dev/cciss/c0d0     http://cciss.sourceforge.net/
The latest generation of SmartArray hardware is handled by a the 'hpsa'
module, which presents the disks as standard SCSI disks, so that they
have /dev/sda entries, and should not need any special case handling.

- Daniel Challen

________________________________

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This communication may be legally privileged. If you are not the intended recipient, please be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error, please notify the OCSL switchboard on +44 845 6052100. OCSL Registered Office: East House, New Pound Common, Wisborough Green, West Sussex, RH14 0AZ. Registered No: 2563193

----- Original Message ----- 
From: john s wolter
To: IPCOP devel
Sent: Sunday, March 04, 2012 5:53 PM
Subject: Re: [IPCop-devel] kmod not for 2.1


> What are the list of issues to change to the latest LINUX kernel?
>
This is not our plan to switch to linux-3.2 or 3.3 yet.
The reason to change from 2.6.32 to 3.0 is that 2.6.32 start to be old.
So there is a decline in actual hardware support. We had to add some
external driver update again.
As Greg KH announced he will no more release 2.6.32 stable update (he will
probably be replaced), this is a good timing to switch.

Gilles

Something we could consider is dropping floppy disk installation.


Olaf

On 2012-03-04 15:10, Gilles Espinasse wrote:
> Thinking more, I am unsure kmod should be on 2.1 release.

I tend to agree.

> There has been some kernel changes related to kmod.
> It is unlikely now those changes will be backported to kernel 3.0.
>
> We should be able to live with last udev version before kmod,
> module-init-tools-3.16 like everyone else do actually.
> kmod should only be a target for us when switching to the next kernel after
> 3.0.x.

I found changing udev to latest version requires (at least, more 
certainly to come) newer linux-headers, adding /run, make changes in our 
handling of networking interfaces since persistent net devices are gone. 
Our initramfs still does not properly boot after all that fixed.
So I'd be quite happy to stick with "older" udev version, and save all 
those changes to a later day.


Olaf

What are the list of issues to change to the latest LINUX kernel?

Those of you who are not familiar with kmod here's an explanation from the
2ed of the LINUX device driver book from O'Reilly ...
http://www.xml.com/ldd/chapter/book/ch11.html#t1

*..."The idea behind kmod is simple, yet effective. Whenever the kernel
tries to access certain types of resources and finds them unavailable, it
makes a special kernel call to the kmod subsystem instead of simply
returning an error. If kmod succeeds in making the resource available by
loading one or more modules, the kernel continues working; otherwise, it
returns the error..."*


Here's more information from IBM Developer-Work about LINUX Kernel Modules,
LKMs...
http://ibm.co/8VOn2k

...or it is KMOD <http://www.kmod.com/main.html>, a radio station 97.5 in
Tulsa, Oklahoma USA whose racy front page tells you they know nothing about
the LINUX kernel ... and for that matter not much of anything.

Cheers,
John S Wolter
"We love LINUX we just have a funny way of saying it."


On Sun, Mar 4, 2012 at 9:10 AM, Gilles Espinasse <g....@fr...> wrote:

> Thinking more, I am unsure kmod should be on 2.1 release.
>
> There has been some kernel changes related to kmod.
> It is unlikely now those changes will be backported to kernel 3.0.
>
> We should be able to live with last udev version before kmod,
> module-init-tools-3.16 like everyone else do actually.
> kmod should only be a target for us when switching to the next kernel after
> 3.0.x.
>
> Gilles
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>



-- 
Cheers
John S Wolter

Thinking more, I am unsure kmod should be on 2.1 release.

There has been some kernel changes related to kmod.
It is unlikely now those changes will be backported to kernel 3.0.

We should be able to live with last udev version before kmod,
module-init-tools-3.16 like everyone else do actually.
kmod should only be a target for us when switching to the next kernel after
3.0.x.

Gilles

On 03/03/2012 03:07 PM, David W Studeman wrote:
> On 03/03/2012 03:00 PM, David W Studeman wrote:
>> Is anyone else having the build fail at wanpipe? I've tried on both a
>> Debian and an OpenSuSE machine with the same results.
>
>
> Here is where it fails:
>
>     CC [M]  /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.o
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function
> 'wanpipe_make_new':
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:342: error: 'struct
> sock' has no member named 'sk_sleep'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:343: error: 'struct
> sock' has no member named 'sk_sleep'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function
> 'wanpipe_accept':
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:570: error: 'struct
> sock' has no member named 'sk_sleep'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:591: error: 'struct
> sock' has no member named 'sk_sleep'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:666: error: 'struct
> sock' has no member named 'sk_sleep'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:666: error: 'struct
> socket' has no member named 'wait'
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function
> 'wanpipe_poll':
> /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:1802: error: 'struct
> sock' has no member named 'sk_sleep'
> make[3]: *** [/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.o] Error 1
> make[2]: *** [_module_/usr/src/wanpipe-3.5.25/kdrvtmp] Error 2
> make[2]: Leaving directory `/usr/src/linux-3.0-1'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/src/wanpipe-3.5.25/kdrvtmp'
>
>

I built a normal PC version and it does NOT fail. It's just me then.

-- 
Dave Studeman
http://www.raqcop.com

On 03/03/2012 03:00 PM, David W Studeman wrote:
> Is anyone else having the build fail at wanpipe? I've tried on both a
> Debian and an OpenSuSE machine with the same results.


Here is where it fails:

   CC [M]  /usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.o
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function 
'wanpipe_make_new':
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:342: error: 'struct 
sock' has no member named 'sk_sleep'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:343: error: 'struct 
sock' has no member named 'sk_sleep'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function 
'wanpipe_accept':
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:570: error: 'struct 
sock' has no member named 'sk_sleep'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:591: error: 'struct 
sock' has no member named 'sk_sleep'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:666: error: 'struct 
sock' has no member named 'sk_sleep'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:666: error: 'struct 
socket' has no member named 'wait'
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c: In function 
'wanpipe_poll':
/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.c:1802: error: 'struct 
sock' has no member named 'sk_sleep'
make[3]: *** [/usr/src/wanpipe-3.5.25/kdrvtmp/af_wanpipe_src.o] Error 1
make[2]: *** [_module_/usr/src/wanpipe-3.5.25/kdrvtmp] Error 2
make[2]: Leaving directory `/usr/src/linux-3.0-1'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/wanpipe-3.5.25/kdrvtmp'


-- 
Dave Studeman
http://www.raqcop.com

Is anyone else having the build fail at wanpipe? I've tried on both a 
Debian and an OpenSuSE machine with the same results.
-- 
Dave Studeman
http://www.raqcop.com