[OpenWrt-Devel] [PATCH] [packages] exim: new package
This adds support for building the Exim MTA as a package. The standard options are configurable through the menuconfig system, with support in place for some of the more advanced options (currently flagged as BROKEN), should someone wish to add support for those in future. Signed-off-by: Adam Nielsen a.niel...@shikadi.net --- mail/exim/Config.in| 332 + mail/exim/Makefile | 284 ++ mail/exim/files/Local-Makefile | 16 + mail/exim/files/exim.init | 20 ++ .../patches/001-buildconfig-crosscompile.patch | 13 + 5 files changed, 665 insertions(+) create mode 100644 mail/exim/Config.in create mode 100644 mail/exim/Makefile create mode 100644 mail/exim/files/Local-Makefile create mode 100644 mail/exim/files/exim.init create mode 100644 mail/exim/patches/001-buildconfig-crosscompile.patch diff --git a/mail/exim/Config.in b/mail/exim/Config.in new file mode 100644 index 000..0382b46 --- /dev/null +++ b/mail/exim/Config.in @@ -0,0 +1,332 @@ +# Exim configuration +menu Configuration + depends on PACKAGE_exim + +config EXIM_VERBOSE_BUILD + depends on DEVEL || BROKEN + bool Verbose build + default n + help +Show detailed output including commands from the Exim build process. + +menuconfig EXIM_ICONV + bool Support charset conversion + default y + + config EXIM_DEF_CHARSET + depends on EXIM_ICONV + string + prompt Default charset for headers + default ISO-8859-1 + help +HEADERS_CHARSET option in Exim Makefile + +menu Router support + + config EXIM_ROUTER_ACCEPT + bool accept + default y + help +Include support for the accept router. + + config EXIM_ROUTER_DNSLOOKUP + bool dnslookup + default y + help +Include support for the dnslookup router. + + config EXIM_ROUTER_IPLITERAL + bool ipliteral + default n + help +Include support for the ipliteral router. + + config EXIM_ROUTER_MANUALROUTE + bool manualroute + default y + help +Include support for the manualroute router. + + config EXIM_ROUTER_QUERYPROGRAM + bool queryprogram + default y + help +Include support for the queryprogram router. + + config EXIM_ROUTER_REDIRECT + bool redirect + default y + help +Include support for the redirect router. + + config EXIM_ROUTER_IPLOOKUP + bool iplookup + default n + help +Include support for the iplookup router. This is very special-purpose +and almost always disabled. + +endmenu + +menu Transport support + + config EXIM_TRANSPORT_APPENDFILE + bool appendfile + default y + help +Include support for the appendfile transport. This is needed to deliver +mail to local mailboxes. You can omit this if you will not be delivering +messages to mailboxes stored on the machine running this copy of Exim. + + config EXIM_TRANSPORT_AUTOREPLY + bool autoreply + default y + help +Include support for the autoreply transport. + + config EXIM_TRANSPORT_PIPE + bool pipe + default y + help +Include support for the pipe transport. This is needed to pass messages +to scripts. + + config EXIM_TRANSPORT_SMTP + bool smtp + default y + help +Include support for the smtp transport. This is needed to pass outgoing +mail along to other MTAs via SMTP (e.g. with a smarthost). It is not +required to receive mail over SMTP. + + config EXIM_TRANSPORT_LMTP + bool lmtp + default n + help +Include support for the lmtp transport. This is rarely needed. + +endmenu + +# This option controls which methods are available to Exim to perform various +# types of lookups, such as looking up whether a user with incoming mail +# actually exists on the system. +menu Lookup methods + + config EXIM_LOOKUP_DBM + bool dbm + default y + help +Include support for the dbm lookup method. + + config EXIM_LOOKUP_LSEARCH + bool lsearch + default y + help +Include support for the lsearch lookup method.
Re: [OpenWrt-Devel] [PATCH] Fix jffs2reset properly (requires -y to cause reset action) bug 15371
Hi, NAK, incorrect fix. this patch fixes the behavior of a script that is not even in trunk. jffs2reset on purpose asks for you to press y/N. Your patch breaks this behavior. the correct fix is to pass $@ and then have your script pass -y. please send a patch that does that. John On 05/04/2014 11:57, Hannu Nyman wrote: A patch to properly fix bug 15371 is attached. r39895 removed the symlink to jffs2reset and broke reset capability. r40018 added back /sbin/jffs2reset to comply with the new fstools package, but a required -y parameter is missing from the script and reset is still broken. https://dev.openwrt.org/ticket/15371#comment:4 My patch adds the -y parameter to the call in /sbin/jffs2reset thus restoring the reset capability. Tested with revision 40380. signed-off-by: hnyman hannu.ny...@iki.fi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix jffs2reset properly (requires -y to cause reset action) bug 15371
NAK, incorrect fix. this patch fixes the behavior of a script that is not even in trunk. jffs2reset on purpose asks for you to press y/N. Your patch breaks this behavior. the correct fix is to pass $@ and then have your script pass -y. You are right reagrding the arguments. I didn't think properly about the pass-through. This should fix the default reset button script action that is broken. It calls jffs2reset with -y, but the current /sbin/jffs2reset calls fs-state without arguments. So, reset action never happens via reset button. https://dev.openwrt.org/browser/trunk/package/base-files/files/etc/rc.button/reset Patch v2 attached. --- package/system/fstools/files/jffs2reset +++ package/system/fstools/files/jffs2reset @@ -1,3 +1,3 @@ #!/bin/sh -fs-state overlay jffs2reset +fs-state overlay jffs2reset $@ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Decentralized Chat Application
On 03/25/2014 03:19 PM, Justyn wrote: Hello list, I'm currently running a few wireless nodes (Ubiquiti PicoStations) with OpenWrt to form an 802.11s mesh network. beware bandwidth degradation on single-radio mesh nodes. https://startpage.com/do/search?q=bandwidth+degradation+on+single-radio+mesh+nodes I'm also interested in writing a completely decentralized multicast chat application and interfacing it with LuCI. So I've saved up some questions that I'd appreciate if anyone skimmed over and could provide some help on a couple things: check out * http://bmx6.net sms plugin which piggybacks into bmx6 packets and does what you envision, but in a bmx6 mesh. * http://qmp.cat has a PoC implementation of your chat idea using bmx6 * alfred, which does something equivalent on a pure link-local (be it wired, made with batman-adv magic, or -hipotetically- 802.11s) http://www.open-mesh.org/projects/alfred/ cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Decentralized Chat Application
I use https://code.google.com/p/kouchat/ On 03/25/2014 02:19 PM, Justyn wrote: Hello list, I'm currently running a few wireless nodes (Ubiquiti PicoStations) with OpenWrt to form an 802.11s mesh network. I'm also currently writing a package to manage these nodes that are set up on the network as well. I'd like to get information about each node (name, IP, MAC, lat, lon, all stored in /etc/config/mypackage). To accomplish this, I've written a client/server package that uses multicast UDP to send requests from one node to all the other nodes that are set up on my network, and receive back the relevant information about them all. Each node has both the server side running on it and the client side available for network status requests. In this manner, any node can get information about the network on-the-fly without any connection to a centralized server. Then this information is displayed in LuCI. Obviously using multicast UDP packets over the air presents reliability challenges. I'm also interested in writing a completely decentralized multicast chat application and interfacing it with LuCI. So I've saved up some questions that I'd appreciate if anyone skimmed over and could provide some help on a couple things: 1) To overcome the reliability problem with multicast UDP, my program sends multiple UDP packets, and on receive, weeds out the duplicates. This has helped tremendously when it comes to reliability, but at the cost of increased network traffic. Also, although the reliability /appears/ to be there, it doesn't guarantee packet 100% reliable transmission/reception. a) Is there a way and/or has anyone implemented any form of 'reliable multicasting' within the OpenWrt package framework? Is it possible, and where would I start? b) Is it possible to set the multicast rate on my particular nodes? I see in the wiki that there is an mcast_rate option in the wireless configuration settings, but warns that Only supported by |madwifi|, and |mac80211| (for type |adhoc| in trunk). I have a virtual interface in mesh mode, so does this mean this option doesn't work for me? Lowering the multicast rate would help even more for reliability. Again, I'm just sending information about the network around, not streaming 1080p video. 2) Does there exist a chat application available for OpenWrt, or something that I've not heard of in which I can port for compilation in OpenWrt? The biggest issue is that it can't rely on any sort of centralized server/node. Which means I can't use any sort of reliable network communication protocols (TCP, basically). Is there a design that doesn't involve a centralized server that I haven't thought of? The immediate solution is to do what I did for managing the nodes via multicast, and just send multiple chat messages to all the nodes, and discard duplicates. But I admit this is hacky, ugly, and will add a lot in terms of network traffic. Thanks for any help, Justyn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel 0x15C4B382.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd issue with openwrt
On 2014-03-27 20:57, James Wood wrote: Hi Felix We’re recently come up against a problem whereby when you switch protocol to 3G/PPPoE, and then switch back to DHCP on the WAN interface, netifd is failing to bring up the WAN interface. Should be fixed in r40384, thanks for reporting. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any plans to support WD My Net N900 (Ubicom IP8K 600MHz, 8x GigE, 256MB)?
Constantine, The JP1 headers are present on the N900 just as they are on the N750. I'll put a copy of the boot output on the console next week. The original firmware for these devices seems to be linux based ( the GPL code from the manufacturer ). I've used the recovery procedure to install my custom version of the original firmware on my N900. The WD MyNet range are really developer friendly and very hard to brick. Regards, Luis E. Garcia On Sat, Apr 5, 2014 at 2:16 PM, Constantine A. Murenin muren...@gmail.comwrote: Hi Luis, I'm also interested in trying out the waters by porting OpenWrt over. I've noticed reports that WD My Net routers appear to be developer-friendly -- according to the reports like https://wikidevi.com/wiki/Western_Digital_My_Net_N750, the models sold to end-users still do have the serial header present (JP1 on N750); and also have the special recovery procedure from a failed firmware update (http://wiki.openwrt.org/toh/wd/n900#recovery.procedure and http://wdc.custhelp.com/app/answers/detail/a_id/9618/~/how-to-recover-a-my-net-router-from-a-failed-firmware-update ). Do you at all know if the recovery procedure could be used to test out custom firmwares without the possibility of bricking the device? Cheers, Constantine. On 3 April 2014 14:31, Luis E. Garcia l...@bitamins.net wrote: Constantine, I'm looking into porting OpenWRT to the WD MyNet N900. Since the IP8K has an mmu it should be able to compile without too much issues. I'm currently trying to get the toolchain from trunk to work. Regards, Luis E. Garcia On Thu, Apr 3, 2014 at 3:55 AM, José Vázquez ppvazquez...@gmail.com wrote: 2014-04-03 6:58 GMT+02:00, Constantine A. Murenin muren...@gmail.com: Hello, It has come to my attention that the recently discontinued WD My Net line of dual-band routers is just about the best bang for the buck -- they're currently selling N900 (w/ 8x GigE and 256MB of RAM) for 49,99 USD at Staples, or 39,99 USD if you order it in person from the store with the 20% in-store coupon, off from the original price of 149,99 USD. This firesale appears to come and go since late 2013, even before the whole line was discontinued in early 2014 (for example, Staples still appears to have some N750 left, but it's not on sale this week, unlike N900). http://wiki.openwrt.org/toh/wd/n900 http://www.staples.com/WD-My-Net-N900-HD-Dual-Band-Router/product_937135 However, N900 it's not supported by OpenWRT -- the whole Ubicom IP8K platform is not supported. Is there a reason for that? What would it take to add the support? WD My Net N900 looks like just about the best piece of hardware over at http://wiki.openwrt.org/toh/start list, this repeated firesale price of 39,99 USD is just insane and is easily 3x less than the competition -- might be a good motivator for adding support to OpenWRT. Cheers, Constantine. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel AFAIK ubicom32 was deprecated because it was hard to maintain, need a different toolchain, ip6k and ip5k had not mmu and some other things. IP8k seems to have mmu and some interesting features, but still has its own architecture. Take a look at this link to check the status: https://dev.openwrt.org/browser/branches/attitude_adjustment/target/linux/ubicom32 The GCC version is 4.4.7. Regards: Pepe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Does anyone have used Ralink i2s under openwrt?
Hi, My borad consists of a rt5350 core module and a bottom board. The bottom board is layouted by my colleague. I buy rt5350 core module on taobao.com in china as follow:http://item.taobao.com/item.htm?spm=a230r.1.14.169.DH7HWhid=35442287707 But I don't think you need to get a rt5350 board to look at this bug. The bug is in ralink-gdma.c, so youcan test it on your own board. Best Regards, zhenjun_...@icloudaegis.com From: John CrispinDate: 2014-04-04 22:13To: openwrt-develSubject: Re: [OpenWrt-Devel] Does anyone have used Ralink i2s under openwrt? On 04/04/2014 08:14, zhenjun_...@icloudaegis.com wrote: Hi, I have checked that drivers/dma/ralink-gdma.c works with an bug. In function gdma_dma_start_transfer, dma buffer contains the correct data. But buffer data changes when transimision is done in function gdma_dma_chan_irq. It seem like that after start action the caller update the data in buffer. This is the reason why I heard Left...Left. I wrote some code to save data in an another buffer, then to transmite. The wave file sounds well now. My board still have some problem. The codec doesn't sound sometimes. I have to fight against it. Do the author of ralink-dma driver or any others have time to fix this bug completely? Best Regards, Hi, once i fixed the codec problem on my unit i will look at the bug. can you help me get one of the rt5350 boards that you have ? can you tell me a link the the board ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-develel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
