date:20080619

Re: [OpenWrt-Devel] missing /etc/config/network in firmware

2008-06-19 Thread Brian J. Murrell

On Thu, 2008-06-19 at 20:26 -0400, Brian J. Murrell wrote:
> If yes, any idea why /etc/config/network is not being included in my
> firmware image?

NM.  I just found /etc/init.d/netconfig.  :-)

b.



signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] missing /etc/config/network in firmware

2008-06-19 Thread Brian J. Murrell

So I'm looking at the "model" of my firmware's root filesystem in
build_dir/mipsel/root-brcm47xx and I'm looking specifically
at /etc/config.  I notice there is no /etc/config/network.  I fear that
means my flashed firmware is not going to configure a network interface
when it comes up.  Is this so?

If yes, any idea why /etc/config/network is not being included in my
firmware image?

Thanx,
b.



signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Patch-set for Freescale Coldifre 547x/548x cpus.

2008-06-19 Thread Luigi 'Comio' Mantellini

Hu guys,


Finally I ported OpenWRT on coldfire/m68k with gcc4.3. I created a set
of patches (~3MBytes) to add:
 - gcc4.3.1 support (need to compile coldfire code);
 - m68k fixes for gcc4.3 and uClibc;
 - kernel patch from Freescale for 547x/548x cpu and linux kernel
2.6.23;
 - coldfire MCF54x5yFE board target (with x in {7,8}, y in {A, B, C, D,
E, F}).

I just tested the compilation and I don't have tested the file directly
image on the targets. (I DON'T KNOW IF THE OBJECT CODE IS CORRECT!).
Anyway, I think that these patches should be a good start point in order
to create a complete and powerful building environment for these "new"
CPUs from Freescale...

If anyone is interested contact me and I will happily send these
patches. of course, I can post the patches on this forum... but the
files are very huge...

ciao ciao

luigi

-- 
 __   Luigi Mantellini
   .'__'. R&D - Software
  (.'  '.)Industrie Dial Face S.p.A.
  ( :==: )Via Canzo, 4
  ('.__.')20068 Peschiera Borromeo (MI), Italy
   '.__.' Tel.: +39 02 5167 2813
  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: [EMAIL PROTECTED]
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
   B003 175F E979 907E 1650




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to submit patches to OpenWRT

2008-06-19 Thread Johannes Ballé

BTW, sorry for posting to the wrong thread. I need to switch to a different 
mail agent.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core

2008-06-19 Thread Steve Brown

Felipe Maya wrote:
> Ooops, Sorry for the confusion... The patch (ehci-ssb support) wasn't
> applied correctly in my distribution. I had to apply the patch manually.
>
> Something wrong happens applying this patch (wl500gp-v2):
>
> //ping message/
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> >From 192.168.1.15 icmp_seq=2 Destination Host Unreachable
> >From 192.168.1.15 icmp_seq=3 Destination Host Unreachable
> >From 192.168.1.15 icmp_seq=4 Destination Host Unreachable
> >From 192.168.1.15 icmp_seq=6 Destination Host Unreachable
> >From 192.168.1.15 icmp_seq=7 Destination Host Unreachable
> >From 192.168.1.15 icmp_seq=8 Destination Host Unreachable
> 64 bytes from 192.168.1.1: icmp_seq=9 ttl=100 time=1807 ms
> 64 bytes from 192.168.1.1: icmp_seq=10 ttl=100 time=808 ms
> 64 bytes from 192.168.1.1: icmp_seq=11 ttl=100 time=1.92 ms
> 64 bytes from 192.168.1.1: icmp_seq=25 ttl=100 time=4.80 ms
> 64 bytes from 192.168.1.1: icmp_seq=39 ttl=100 time=4.62 ms
> 64 bytes from 192.168.1.1: icmp_seq=53 ttl=100 time=4.49 ms
> 64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=5.73 ms
>
> --- 192.168.1.1 ping statistics ---
> 59 packets transmitted, 7 received, +6 errors, 88% packet loss, time
> 58002ms
> rtt min/avg/max/mdev = 1.924/376.922/1807.924/646.814 ms, pipe 3
> ---
>
>
> The ohci-ssb attach function looks as follow:
>
>
>
> static int ssb_ohci_attach(struct ssb_device *dev)
> {
>   struct ssb_ohci_device *ohcidev;
>   struct usb_hcd *hcd;
>   int err = -ENOMEM;
>   u32 tmp, flags = 0;
>
>   if (!(ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET))
>   goto core_already_enabled;
>
>   /*
>* THE FOLLOWING COMMENTS PRESERVED FROM GPL SOURCE RELEASE
>*
>* The USB core requires a special bit to be set during core
>* reset to enable host (OHCI) mode. Resetting the SB core in
>* pcibios_enable_device() is a hack for compatibility with
>* vanilla usb-ohci so that it does not have to know about
>* SB. A driver that wants to use the USB core in device mode
>* should know about SB and should reset the bit back to 0
>* after calling pcibios_enable_device().
>*/
>
>   if (dev->id.coreid == SSB_DEV_USB11_HOSTDEV) {
>   if (ssb_device_is_enabled(dev))
>   goto core_already_enabled;
>   flags |= SSB_OHCI_TMSLOW_HOSTMODE;
>   ssb_device_enable(dev, flags);
>   }
>
>   /*
>* USB 2.0 special considerations:
>*
>* 1. Since the core supports both OHCI and EHCI functions, it must
>*only be reset once.
>*
>* 2. In addition to the standard SB reset sequence, the Host Control
>*Register must be programmed to bring the USB core and various
>*phy components out of reset.
>*/
>   
>   //else if (dev->id.coreid == SSB_DEV_USB20_HOST) {
>   else if (dev->id.coreid == SSB_DEV_USB11_HOST) {
>   if (ssb_device_is_enabled(dev))
>   goto core_already_enabled;
>
>   ssb_device_enable(dev, 0);
>   ssb_write32(dev, 0x200, 0x7ff);
>   udelay(1);
>   
>   if (dev->id.revision == 1) { /* bug in rev 1 */
>
>   /* Change Flush control reg */
>   tmp = ssb_read32(dev, 0x400);
>   tmp &= ~8;
>   ssb_write32(dev, 0x400, tmp);
>   tmp = ssb_read32(dev, 0x400);
>   printk(KERN_INFO "USB20H fcr: 0x%0x\n", tmp);
>
>   /* Change Shim control reg */
>   tmp = ssb_read32(dev, 0x304);
>   tmp &= ~0x100;
>   ssb_write32(dev, 0x304, tmp);
>   tmp = ssb_read32(dev, 0x304);
>   printk(KERN_INFO "USB20H shim: 0x%0x\n", tmp);
>   }
>   } else
>   ssb_device_enable(dev, 0);
>
> core_already_enabled:
>   /*
>* Set dma mask - 32 bit mask is just an assumption
>*/
>   if (ssb_dma_set_mask(dev, DMA_32BIT_MASK))
>   return -EOPNOTSUPP;
>
>   hcd = usb_create_hcd(&ssb_ohci_hc_driver, dev->dev,
>   dev->dev->bus_id);
>   if (!hcd)
>   goto err_dev_disable;
>   ohcidev = hcd_to_ssb_ohci(hcd);
>   ohcidev->enable_flags = flags;
>
>   tmp = ssb_read32(dev, SSB_ADMATCH0);
>   hcd->rsrc_start = ssb_admatch_base(tmp);
>   hcd->rsrc_len = ssb_admatch_size(tmp);
>   hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
>   if (!hcd->regs)
>   goto err_put_hcd;
>   err = usb_add_hcd(hcd, dev->irq, IRQF_DISABLED | IRQF_SHARED);
>   if (err)
>   goto err_iounmap;
>
>   ssb_set_drvdata(dev, hcd);
>
>   return err;
>
> err_iounmap:
>   iounmap(hcd->regs);
> err_put_hcd:

[OpenWrt-Devel] How to submit patches to OpenWRT

2008-06-19 Thread Johannes Ballé

Dear devs,

on Fri Jun 13 21:57:24 CEST 2008, Conrad Hirano wrote:
> Sorry, I didn't mean to offend or insult you and the other developers.  
> I realize you all have lives and are busy, and I sincerely appreciate  
> the time and effort you have all spent in developing OpenWRT. It's  
> just a bit frustrating to submit a patch and get no response, only to  
> see the identical patch submitted a few weeks later and committed in a  
> day. It's hard not to feel the original patch went to the great bit  
> bucket in the sky for whatever reason.

I know exactly what Conrad is talking about. I made a patch for vpnc in March; 
admittedly, it's not the most important package, and I would be glad to 
unsubscribe from the list and move on to other things. But after all, I made 
it so that others wouldn't have to replicate the work I did. So I'd like to 
get some kind of reassurance that it's really going to help and not be 
forgotten. Otherwise, I might not feel the urge to contribute to this project 
any longer. Especially if I have to go through the pain of reconfiguring my 
mail agent (which was a bit tricky) just to get the patch "accepted."

So I have been reading the list now for 3 months, waiting for any reaction to 
my patch. But nothing happened. Just to make clear what my position is: I'm 
not interested in all the gory development details of OpenWRT (although I 
really, really appreciate your efforts). I'm just scanning the list in order 
not to miss comments on my patch, and I begin to get tired of it.

Can we get to some conclusion as to what the procedure would be for an 
occasional contributor like me _after_ submitting a patch to the list? Maybe 
a submission to the bug tracking system would be more useful? Or can we be 
reassured that you won't forget about it? I mean, do you developers really go 
back through the mailing list archives looking for patches that haven't been 
included yet?

I agree that developers are only humans, and sometimes things just have to 
wait. But I'm human, too. I don't think you can expect from me to bug you on 
a regular basis just to get some unsignificant (but useful) patch applied. At 
least, that's my current understanding of what we're supposed to do.

It would probably already help if we could get some faint idea of how the devs 
manage incoming patches. Perhaps one or two additional sentences on 
https://dev.openwrt.org/wiki/SubmittingPatches would suffice.

Thanks,

Johannes.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] m68k & OpenWRT

2008-06-19 Thread Luigi 'Comio' Mantellini

Hi Felix
Hi All,

I found this article: http://bbs.archlinux.org/viewtopic.php?id=45882

the patch seems to solve the issue (that is manifested only using
gcc4.3).

luigi

On gio, 2008-06-19 at 16:21 +0200, Felix Fietkau wrote:
> Luigi 'Comio' Mantellini wrote:
> > Hi All,
> > 
> > how you should know, I'm working to port OpenWRT on m68k/coldfire arch.
> > I compiled with success (and some patch) the toolchain... but I have
> > this error during the kernel build:
> We had similar issues with mips in the past. If you look through the mips 
> arch directory, you should find such functions there. You can probably take 
> the missing pieces for m68k either by finding an arch that implements those 
> in a generic way (i think mips might even do this), or you port the code 
> from the gcc/libgcc source. Shouldn't be very hard to do.
> 
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
-- 
 __   Luigi Mantellini
   .'__'. R&D - Software
  (.'  '.)Industrie Dial Face S.p.A.
  ( :==: )Via Canzo, 4
  ('.__.')20068 Peschiera Borromeo (MI), Italy
   '.__.' Tel.: +39 02 5167 2813
  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: [EMAIL PROTECTED]
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
   B003 175F E979 907E 1650




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core

2008-06-19 Thread Felipe Maya


Ooops, Sorry for the confusion... The patch (ehci-ssb support) wasn't
applied correctly in my distribution. I had to apply the patch manually.

Something wrong happens applying this patch (wl500gp-v2):

//ping message/
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.15 icmp_seq=2 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=3 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=4 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=6 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=7 Destination Host Unreachable
>From 192.168.1.15 icmp_seq=8 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_seq=9 ttl=100 time=1807 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=100 time=808 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=100 time=1.92 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=100 time=4.80 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=100 time=4.62 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=100 time=4.49 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=5.73 ms

--- 192.168.1.1 ping statistics ---
59 packets transmitted, 7 received, +6 errors, 88% packet loss, time
58002ms
rtt min/avg/max/mdev = 1.924/376.922/1807.924/646.814 ms, pipe 3
---


The ohci-ssb attach function looks as follow:



static int ssb_ohci_attach(struct ssb_device *dev)
{
struct ssb_ohci_device *ohcidev;
struct usb_hcd *hcd;
int err = -ENOMEM;
u32 tmp, flags = 0;

if (!(ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET))
goto core_already_enabled;

/*
 * THE FOLLOWING COMMENTS PRESERVED FROM GPL SOURCE RELEASE
 *
 * The USB core requires a special bit to be set during core
 * reset to enable host (OHCI) mode. Resetting the SB core in
 * pcibios_enable_device() is a hack for compatibility with
 * vanilla usb-ohci so that it does not have to know about
 * SB. A driver that wants to use the USB core in device mode
 * should know about SB and should reset the bit back to 0
 * after calling pcibios_enable_device().
 */

if (dev->id.coreid == SSB_DEV_USB11_HOSTDEV) {
if (ssb_device_is_enabled(dev))
goto core_already_enabled;
flags |= SSB_OHCI_TMSLOW_HOSTMODE;
ssb_device_enable(dev, flags);
}

/*
 * USB 2.0 special considerations:
 *
 * 1. Since the core supports both OHCI and EHCI functions, it must
 *only be reset once.
 *
 * 2. In addition to the standard SB reset sequence, the Host Control
 *Register must be programmed to bring the USB core and various
 *phy components out of reset.
 */

//else if (dev->id.coreid == SSB_DEV_USB20_HOST) {
else if (dev->id.coreid == SSB_DEV_USB11_HOST) {
if (ssb_device_is_enabled(dev))
goto core_already_enabled;

ssb_device_enable(dev, 0);
ssb_write32(dev, 0x200, 0x7ff);
udelay(1);

if (dev->id.revision == 1) { /* bug in rev 1 */

/* Change Flush control reg */
tmp = ssb_read32(dev, 0x400);
tmp &= ~8;
ssb_write32(dev, 0x400, tmp);
tmp = ssb_read32(dev, 0x400);
printk(KERN_INFO "USB20H fcr: 0x%0x\n", tmp);

/* Change Shim control reg */
tmp = ssb_read32(dev, 0x304);
tmp &= ~0x100;
ssb_write32(dev, 0x304, tmp);
tmp = ssb_read32(dev, 0x304);
printk(KERN_INFO "USB20H shim: 0x%0x\n", tmp);
}
} else
ssb_device_enable(dev, 0);

core_already_enabled:
/*
 * Set dma mask - 32 bit mask is just an assumption
 */
if (ssb_dma_set_mask(dev, DMA_32BIT_MASK))
return -EOPNOTSUPP;

hcd = usb_create_hcd(&ssb_ohci_hc_driver, dev->dev,
dev->dev->bus_id);
if (!hcd)
goto err_dev_disable;
ohcidev = hcd_to_ssb_ohci(hcd);
ohcidev->enable_flags = flags;

tmp = ssb_read32(dev, SSB_ADMATCH0);
hcd->rsrc_start = ssb_admatch_base(tmp);
hcd->rsrc_len = ssb_admatch_size(tmp);
hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
if (!hcd->regs)
goto err_put_hcd;
err = usb_add_hcd(hcd, dev->irq, IRQF_DISABLED | IRQF_SHARED);
if (err)
goto err_iounmap;

ssb_set_drvdata(dev, hcd);

return err;

err_iounmap:
iounmap(hcd->regs);
err_put_hcd:
usb_put_hcd(hcd);
err_dev_disable:
ssb_device_disable(dev, flags);
retur

Re: [OpenWrt-Devel] m68k & OpenWRT

2008-06-19 Thread Felix Fietkau

Luigi 'Comio' Mantellini wrote:
> Hi All,
> 
> how you should know, I'm working to port OpenWRT on m68k/coldfire arch.
> I compiled with success (and some patch) the toolchain... but I have
> this error during the kernel build:
We had similar issues with mips in the past. If you look through the mips 
arch directory, you should find such functions there. You can probably take 
the missing pieces for m68k either by finding an arch that implements those 
in a generic way (i think mips might even do this), or you port the code 
from the gcc/libgcc source. Shouldn't be very hard to do.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] m68k & OpenWRT

2008-06-19 Thread Luigi 'Comio' Mantellini

Hi All,

how you should know, I'm working to port OpenWRT on m68k/coldfire arch.
I compiled with success (and some patch) the toolchain... but I have
this error during the kernel build:


make[5]: Leaving directory
`/mnt/devel/openwrt/OpenWRT.git/build_dir/linux-cf547x/linux-2.6.23'
make[5]: Entering directory
`/mnt/devel/openwrt/OpenWRT.git/build_dir/linux-cf547x/linux-2.6.23'
  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CALLscripts/checksyscalls.sh
  CHK include/linux/compile.h
  GZIPkernel/config_data.gz
  IKCFG   kernel/config_data.h
  CC  kernel/configs.o
  LD  kernel/built-in.o
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
kernel/built-in.o: In function `timespec_add_ns':
/mnt/devel/openwrt/OpenWRT.git/build_dir/linux-cf547x/linux-2.6.23/include/linux/time.h:177:
 undefined reference to `__umoddi3'
/mnt/devel/openwrt/OpenWRT.git/build_dir/linux-cf547x/linux-2.6.23/include/linux/time.h:177:
 undefined reference to `__udivdi3'

umoddi3 and udivdi3 are helper functions that support the long long
arithmetic. the libcc.a has these function:

$ m68k-linux-gnu-objdump -t libgcc.a
In archive libgcc.a:

_udivdi3.o: file format elf32-m68k

SYMBOL TABLE:
 ldf *ABS*   libgcc2.c
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .debug_abbrev   .debug_abbrev
 ld  .debug_info .debug_info
 ld  .debug_line .debug_line
 ld  .debug_frame    .debug_frame
 ld  .eh_frame   .eh_frame
 ld  .debug_loc  .debug_loc
 ld  .debug_pubnames .debug_pubnames
 ld  .debug_aranges  .debug_aranges
 ld  .debug_str  .debug_str
 ld  .note.GNU-stack .note.GNU-stack
 ld  .comment    .comment
 g F .text  00b6 .hidden __udivdi3



_umoddi3.o: file format elf32-m68k

SYMBOL TABLE:
 ldf *ABS*   libgcc2.c
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .debug_abbrev   .debug_abbrev
 ld  .debug_info .debug_info
 ld  .debug_line .debug_line
 ld  .debug_frame    .debug_frame
 ld  .eh_frame   .eh_frame
 ld  .debug_loc  .debug_loc
 ld  .debug_pubnames .debug_pubnames
 ld  .debug_aranges  .debug_aranges
 ld  .debug_str  .debug_str
 ld  .note.GNU-stack .note.GNU-stack
 ld  .comment    .comment
 g F .text  00d6 .hidden __umoddi3


I found the keyword ".hidden" placed before the symbols __umoddi3 and
__udivdi3 also on mipsel-compiled libgcc.a...

Any idea?

luigi


-- 
 __   Luigi Mantellini
   .'__'. R&D - Software
  (.'  '.)Industrie Dial Face S.p.A.
  ( :==: )Via Canzo, 4
  ('.__.')20068 Peschiera Borromeo (MI), Italy
   '.__.' Tel.: +39 02 5167 2813
  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: [EMAIL PROTECTED]
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
   B003 175F E979 907E 1650




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] package/gnutls: update to 2.4.0

2008-06-19 Thread Simon Josefsson

Hi!  This patch updates the gnutls package to v2.4.0.  It also enables
PSK+SRP.  Before the psktool was shipped in openwrt, but PSK was
disabled in the library which seemed rather pointless.  Also, I think
PSK/SRP can be useful features on openwrt boxes, so it makes sense to
enable it.  Further, LZO compression has been disabled by default in
v2.4, so the --without-lzo flag can be removed too, which the patch
does.

In case the patch isn't clear, the 002-disable_openpgp.patch file is
removed.

Thanks,
Simon

Signed-off-by: Simon Josefsson <[EMAIL PROTECTED]>

Index: patches/002-disable_openpgp.patch
===
--- patches/002-disable_openpgp.patch   (revision 11539)
+++ patches/002-disable_openpgp.patch   (working copy)
@@ -1,20 +0,0 @@
-Index: gnutls-2.2.3/libextra/gnutls_extra.c
-===
 gnutls-2.2.3.orig/libextra/gnutls_extra.c  2008-05-08 21:18:29.0 
+0200
-+++ gnutls-2.2.3/libextra/gnutls_extra.c   2008-05-08 21:18:29.0 
+0200
-@@ -137,6 +137,7 @@
- }
- #endif
- 
-+#ifdef ENABLE_OPENPGP
-   /* Register the openpgp functions. This is because some
-* of them are defined to be NULL in the main library.
-*/
-@@ -152,6 +153,7 @@
-gnutls_openpgp_crt_deinit,
-gnutls_openpgp_keyring_deinit,
-gnutls_openpgp_privkey_deinit);
-+#endif
- 
-   return 0;
- }
Index: Makefile
===
--- Makefile(revision 11539)
+++ Makefile(working copy)
@@ -9,7 +9,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gnutls
-PKG_VERSION:=2.2.3
+PKG_VERSION:=2.4.0
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
@@ -17,7 +17,7 @@
ftp://ftp.gnutls.org/pub/gnutls/ \
ftp://ftp.mirrors.wiretapped.net/pub/security/network-security/gnutls/ \
http://josefsson.org/gnutls/releases/
-PKG_MD5SUM:=71d9b7ec32a2a67854940a8848c2b229
+PKG_MD5SUM:=dce4000841ba5f80d310c4972b5f3efe
 
 PKG_FIXUP = libtool
 
@@ -62,8 +62,8 @@
 
 define Package/gnutls-utils/description
 $(call Package/gnutls/Default/description)
- This package contains the GnuTLS gnutls-cli, gnutls-serv and psktool
- utilities.
+ This package contains the GnuTLS gnutls-cli, gnutls-serv, psktool,
+ and srptool utilities.
 endef
 
 
@@ -106,13 +106,10 @@
--enable-shared \
--enable-static \
--disable-openpgp-authentication \
-   --disable-psk-authentication \
-   --disable-srp-authentication \
--with-libgcrypt-prefix="$(STAGING_DIR)/usr" \
--with-libreadline-prefix="$(STAGING_DIR)/usr" \
--with-libz-prefix="$(STAGING_DIR)/usr" \
-   --with-libtasn1-prefix="$(STAGING_DIR)/usr" \
-   --without-lzo
+   --with-libtasn1-prefix="$(STAGING_DIR)/usr"
 
 # XXX: AM_CFLAGS duplicates with CFLAGS
 MAKE_ARGS:= \
@@ -152,6 +149,7 @@
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/gnutls-{cli,serv} 
$(1)/usr/bin/
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/psktool $(1)/usr/bin/
+   $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/srptool $(1)/usr/bin/
 endef
 
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] missing /etc/config/network in firmware

[OpenWrt-Devel] missing /etc/config/network in firmware

[OpenWrt-Devel] Patch-set for Freescale Coldifre 547x/548x cpus.

Re: [OpenWrt-Devel] How to submit patches to OpenWRT

Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core

[OpenWrt-Devel] How to submit patches to OpenWRT

Re: [OpenWrt-Devel] m68k & OpenWRT

Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core

Re: [OpenWrt-Devel] m68k & OpenWRT

[OpenWrt-Devel] m68k & OpenWRT

[OpenWrt-Devel] [PATCH] package/gnutls: update to 2.4.0

11 matches

Site Navigation

Mail list logo

Footer information