Re: [OpenWrt-Devel] git.openwrt.org certificate expired

2016-10-10 Thread Mirko Vogt
Thanks, fixed.

On 10/07/2016 10:09 PM, Eric Schultz wrote:
> Just wanted to let folks know that the certificate for git.openwrt.org
>  is expired
> 
> Thanks,
> 
> Eric
> 
> -- 
> Eric Schultz, Community Manager, prpl Foundation
> http://www.prplfoundation.org
> eschu...@prplfoundation.org 
> cell: 920-539-0404
> 
> 
> ___
> 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 1/2] toolchain: The glorious return of glibc, ver 2.21

2015-03-12 Thread Mirko Vogt
On 03/11/2015 06:17 PM, Jeff Waugh wrote:
 It's the eglibc packaging with a bit of spit-polishing. And testing. :-)
 
 Signed-off-by: Jeff Waugh j...@bethesignal.org
 [..]

On 03/11/2015 06:02 PM, Jeff Waugh wrote:
 With
 those applied, a default (VoCore, mipsel) build completes
 successfully.

Please don't just compile test. Right now /usr/lib is not added as a
searchable path for so-libs which renders it pretty much unusable.
That was what the now missing patch 200-add-dl-search-paths.patch dealt
with.

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


Re: [OpenWrt-Devel] platform xburst / maintainer

2014-10-28 Thread Mirko Vogt
That was a long time ago and I guess we should consider that platform
currently unmaintained.

May I ask what's your interest in this platform?

On 10/28/2014 03:29 PM, Bastian Bittorf wrote:
 can somebody please add the maintainer of 'xburst' to
 https://dev.openwrt.org/wiki/platforms
 
 when looking into the commits, it seems 'lars' is it?!
 
 bye, bastian
 ___
 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] Moving all feeds to OpenWrt GitHub organisation

2014-08-12 Thread Mirko Vogt
On 08/12/2014 08:41 PM, valent.turko...@gmail.com wrote:
 Please consider switching from svn to git, and then if possible
 connecting openwrt git with github so patches are synced between them.

http://git.openwrt.org/

 Thanks.

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


Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation

2014-08-12 Thread Mirko Vogt
On 08/12/2014 08:58 PM, valent.turko...@gmail.com wrote:
 I know about git.openwrt.org and user it regularly, but how are svn
 and and git connected? Does current setup allow git.openwrt.org to be
 synced and connected to github?

Why not? It is an exact git-svn clone. Maybe I missed a point here..
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] kernel update to 3.10.12

2013-09-15 Thread Mirko Vogt
On 09/15/2013 12:05 PM, Daniel Petre wrote:
 Hello, can we have 3.10.12 updated to OpenWrt trunk and patches
 refreshed please?

We appreciate your interest in this.
Feel free to send in patches.

Regards

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


Re: [OpenWrt-Devel] [PATCH] pulseaudio: InstallDev installs static libraries *.la

2013-09-06 Thread Mirko Vogt
On 09/06/2013 06:48 PM, Alexander Couzens wrote:
[..]
 - $(PKG_INSTALL_DIR)/usr/lib/*.so* \
 + $(PKG_INSTALL_DIR)/usr/lib/*.{la,so}* \

Unline your subjects suggests, .la-files are _not_ static libraries,
but libtool helper-files which we don't use and don't want for several
reasons.
Static libraries are ar-archives suffixed with .a.

Cheers

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


Re: [OpenWrt-Devel] Adding new tickets to bug tracker has been disabled?

2013-09-02 Thread Mirko Vogt
On 09/02/2013 05:32 PM, Hannu Nyman wrote:
 TICKET_CREATE privileges are required to perform this operation. You
 don't have the required permissions.
 
 Hopefully this is just a temporary bug. :-(

Yep, it was - fixed. Thanks for telling!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Renaming a package during compilation

2013-05-18 Thread Mirko Vogt
On 05/17/2013 09:25 PM, jonsm...@gmail.com wrote:
 PKG_NAME:=avr-binutils
 PKG_VERSION:=2.20.1a
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=binutils-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://ftp.gnu.org/gnu/binutils/

This means you're telling OpenWrt, the unpacked folder is going to be named:

  avr-binutils-2.20.1a

That doesn't mean you _force_ it to be like that. You're just telling
OpenWrt the top-folder within the archive has this name. That makes
sense, if the name of the folder within differs from the name of the
archive.
However in this case the top-folder isn't named 'avr-binutils-2.20.1a',
but 'binutils-2.20.1'.

Check:
$ tar vjxf binutils-2.20.1a.tar.bz2 | head -1
binutils-2.20.1/

So PKG_SOURCE_SUBDIR is supposed to be set to: binutils-2.20.1

 bash: 
 /home/jonsmirl/openwrt/build_dir/target-mipsel_dsp_uClibc-0.9.33.2/avr-binutils-2.20.1a/configure:
 No such file or directory

See above. The extracted folder is named 'binutils-2.20.1'.

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Renaming a package during compilation

2013-05-17 Thread Mirko Vogt
On 05/17/2013 08:48 PM, jonsm...@gmail.com wrote:
 Let's say I want to make a package:
 
 PKG_NAME:=avr-gcc
 PKG_VERSION:=1.0
 
 but my source is named gcc
 PKG_SOURCE:=gcc-$(PACKAGE_VERSION).tar.gz
 
 When this source gets uncompressed it gets put into.
 
 target_mipsel/avr-gcc/..
 The uncompress set goes up a level in directories
 the source ends up in target_mipsel/gcc-1.0
 
 What is the right way to achieve a rename like this?
 I need the source in the avr-gcc tree so that I can apply avr specific
 patches to it.


You can override the default of PKG_SOURCE_SUBDIR to point it to where
the src actually lies after unpacking, which in this case would be:

PKG_SOURCE_SUBDIR:=gcc-$(PACKAGE_VERSION)

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH][V5] Zabbix: add extra packages with discovery/userparameter

2013-05-16 Thread Mirko Vogt
On 04/24/2013 11:53 PM, Etienne Champetier wrote:
 Hi

Hello Etienne,

 Index: admin/zabbix/files/zabbix_extra_mac80211.init
 ===
 --- admin/zabbix/files/zabbix_extra_mac80211.init (révision 0)
 +++ admin/zabbix/files/zabbix_extra_mac80211.init (révision 0)
 @@ -0,0 +1,9 @@
 +#!/bin/sh /etc/rc.common
 +# Copyright (C) 2008-2011 OpenWrt.org
 +
 +START=59
 +
 +start() {
 + chmod -R a+r /sys/kernel/debug/ieee80211/*/statistics/
 +}
 +

I'm sorry, but I still don't think that's the way to go.
That's not just a theoretical issue - one just can't keep track of those
changes made.
If packages start to modify filesystem permissions, this will result in
just a mess (incompatibilities between packages, race-conditions,
security-issues, and probably much more).

I appreciate your work, but I won't commit a patch which results in a
package modifying the permissions of files outside its scope.

Maybe it makes sense to globally change the permissions of
/sys/kernel/debug/ieee80211/*/statistics/ to be world-readable.
However I'll let that to the other devs, since I don't know about what
kind of possibly sensitive information this debug interface exposes.

Cheers

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Buildslave nico destroys snapshot buildbot

2013-05-05 Thread Mirko Vogt
On 05/05/2013 12:48 PM, Hannu Nyman wrote:
 Nico is again failing svn updates, going through several platforms rapidly.
 
 svn: Can't connect to host 'svn.openwrt.org': Connection timed out
 
 
 That causes other buildslaves to site idle and many platforms remain
 unbuilt.
 
 http://buildbot.openwrt.org:8010/buildslaves/nico
 http://buildbot.openwrt.org:8010/one_line_per_build

Thanks - we noticed as well. We'll take care of that by

 - changing from svn to our git mirror
 - implement some monitoring

later today.

Sorry the inconveniences and thanks for reporting once again!

  mirko

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Buildslave nico destroys snapshot buildbot

2013-03-25 Thread Mirko Vogt
On 03/25/2013 08:28 AM, Hannu Nyman wrote:
 Updating feed 'luci' from
 'http://svn.luci.subsignal.org/luci/trunk/contrib/package' ...
 svn: OPTIONS of
 'http://svn.luci.subsignal.org/luci/trunk/contrib/package': Could not
 read status line: Connection timed out (http://svn.luci.subsignal.org)
 failed.

Hey, thanks for reporting. The IP change of the slave caused this
trouble (however that one wasn't DNS related).
Should be fixed by now, running and producing valid images again.

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Buildslave nico destroys snapshot buildbot timing logic

2013-03-22 Thread Mirko Vogt
On 03/23/2013 12:52 AM, Hannu Nyman wrote:
 Buildslave nico seems to have DNS / connectivity trouble.
 [..]
 Please fix nico's connectivity or turn it off.

Nico is indeed not able to connect to the openwrt.org - however all the
other machines (even another VM on the very same host) can.
Reboot doesn't change anything. This needs investigation, so - as
suggested - I turned off the buildslave for now, to not get assigned any
more builds.

Thanks and cheers

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] firewall3 package broken with EGLIBC

2013-03-11 Thread Mirko Vogt
On 03/10/2013 04:07 PM, shazz wrote:
 trunk/build_dir/target-mips_r2_eglibc-2.17/firewall3-2013-03-02/utils.c:
 In function 'fw3_find_command':
 trunk/build_dir/target-mips_r2_eglibc-2.17/firewall3-2013-03-02/utils.c:141:19:
 error: 'PATH_MAX' undeclared (first use in this function)
 trunk/build_dir/target-mips_r2_eglibc-2.17/firewall3-2013-03-02/utils.c:141:19:
 note: each undeclared identifier is reported only once for each
 function it appears in
 trunk/build_dir/target-mips_r2_eglibc-2.17/firewall3-2013-03-02/utils.c:141:14:
 error: unused variable 'path' [-Werror=unused-variable]
 cc1: all warnings being treated as errors
 make[6]: *** [CMakeFiles/firewall3.dir/utils.c.o] Error 1
 make[5]: *** [CMakeFiles/firewall3.dir/all] Error 2
 make[4]: *** [all] Error 2
 make[3]: *** 
 [trunk/build_dir/target-mips_r2_eglibc-2.17/firewall3-2013-03-02/.built]
 Error 2
 make[2]: *** [package/network/config/firewall3/compile] Error 2

If PATH_MAX is undeclared, most likely an
  #include limits.h
is missing. Could you check and try?

Cheers

  mirko

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH][V4] Zabbix: add extra packages with discovery/userparameter

2013-01-30 Thread Mirko Vogt
On 01/08/2013 11:31 PM, Etienne Champetier wrote:
 Hi

Hey,

 +define Package/zabbix-extra-mac80211/postinst
 +[ -n $${IPKG_INSTROOT} ] || /etc/init.d/zabbix_extra_mac80211 enable
 +exit 0
 +endef
 +
 +define Package/zabbix-extra-network/postinst
 +[ -n $${IPKG_INSTROOT} ] || /etc/init.d/zabbix_extra_network enable
 +exit 0
 +endef
 +
 +define Package/zabbix-extra-wifi/postinst
 +[ -n $${IPKG_INSTROOT} ] || /etc/init.d/zabbix_extra_wifi enable
 +exit 0
 +endef
 +

There's a reason for package init scripts not being enabled by default.
Although its intention is indeed worth a discussion, workarounding this
within the package makefiles however doesn't make it any better and is
definitely not the right place to do so.

 Index: files/zabbix_extra_network.init
 ===
 --- files/zabbix_extra_network.init   (révision 0)
 +++ files/zabbix_extra_network.init   (révision 0)
 @@ -0,0 +1,9 @@
 +#!/bin/sh /etc/rc.common
 +# Copyright (C) 2008-2011 OpenWrt.org
 +
 +START=59
 +
 +start() {
 + chmod a+r /var/state/network
 +}
 +

Sorry, this is a no-go. You can't just change the permissions of files
related to another package, the core-system or kernel exposed files from
a package-Makefile for obvious reasons. This needs to be solved some
other way.

 ===
 --- files/zabbix_extra_mac80211.init  (révision 0)
 +++ files/zabbix_extra_mac80211.init  (révision 0)
 @@ -0,0 +1,9 @@
 +#!/bin/sh /etc/rc.common
 +# Copyright (C) 2008-2011 OpenWrt.org
 +
 +START=59
 +
 +start() {
 + chmod -R a+r /sys/kernel/debug/ieee80211/*/statistics/
 +}
 

See above.

 Index: files/zabbix_extra_wifi.init
 ===
 --- files/zabbix_extra_wifi.init  (révision 0)
 +++ files/zabbix_extra_wifi.init  (révision 0)
 @@ -0,0 +1,9 @@
 +#!/bin/sh /etc/rc.common
 +# Copyright (C) 2008-2011 OpenWrt.org
 +
 +START=59
 +
 +start() {
 + chmod a+r /var/state/wireless
 +}
 +

See above.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Wireless Battle Mesh 6 (wbm6) in Aalborg, Denmark (April 2013)

2013-01-10 Thread Mirko Vogt
Hey hackers!
I'd like to inform you about the 6th upcoming Wireless Battle Mesh[1],
taking place in Aalborg, Denmark this time, 15 Apr - 21 Apr 2013.

Although originally its primary focus was (still is?) on comparing and
benchmarking several mesh algorithms in real-world scenarios, it's an
event where all kind of folks interested in wireless, meshing, embedded
linux and - you won't believe it! - OpenWrt! are going to meet.
Last year, at the WBMv5 (which took place in Athens), most of the
OpenWrt team was present and we had quite some productive meetings and
hackathons - it was really an awesome time and I'm pretty sure all the
others will agree.

If you're interested in joining going there, please consider telling[2]
the orga not just last minute, to make organizing things easier - please
also consider subscribing to the mailing list to be kept in the loop[3].

Even though there are people taking care of basic things (such as
accommodation, etc) - it is an community event, from the community for
the community - you decide what this event is gonna be about! :)

See you in Aalborg!

Cheers

  mirko

[1]http://battlemesh.org/BattleMeshV6
[2]http://battlemesh.org/BattleMeshV6#Participant_Registration_and_Fee
[3]http://ml.ninux.org/mailman/listinfo/battlemesh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH][package] make ltq-dsl-app compile with an eglibc-based toolchain

2012-12-03 Thread Mirko Vogt
On 11/22/2012 10:22 AM, Frank Meerkötter wrote:
 Hi,
 
 i had problems building the ltq-dsl-app when switching from
 uclibc to eglibc. This patch is adding a needed include, adds
 a configure test to figure out where clock_gettime() is located
 and runs autoreconfigurer afterwards.
 
 Please review/apply.
 
 Signed-Off-By: Frank Meerkötter fr...@meerkoetter.org
 
 Patch follows:
 [..]

Applied in 34468 - thanks!

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenVPN with netifd

2012-10-04 Thread Mirko Vogt
On 10/04/2012 02:25 PM, Joachim Schlipper wrote:
 Am 04.10.2012 14:05, schrieb Jo-Philipp Wich:
 If I am not mistaken then openvpn-devel is supposed to use the very
 same files as openvpn. Afair its files/ folder is symlinked to the
 openvpn package.
 
 Good to read, that indeed eliminates my concerns about maintaining
 different packages.
 
 Joachim

As far as I see the only advantage of the openvpn package over the
openvpn-devel one is, that it has 'stable' and not 'devel' in its name.
Since the openvpn version used in the openvpn-devel package is close(TM)
to a release, I won't put too much effort into getting the old package
working with netifd as well.

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenVPN with netifd

2012-10-04 Thread Mirko Vogt
On 10/04/2012 05:48 PM, Joachim Schlipper wrote:
 The openvpn-devel package won't disappear once the 2.3 version of
 OpenVPN is released, or does it?

I don't see any reason to continue this once 2.3 is out.
There are currently features in OpenVPN-trunk which are essential to
some users. Once 2.3 is out however, continuing this just for having a
stable as well as a bleeding-edge version doesn't make any sense to me
(and it wouldn't have to do anything with OpenVPN in particular anymore).
I was already about to drop the old package when I was reworking the
-devel package, however this time OpenVPN-trunk was in an alpha state
and we didn't want to have the only OpenVPN-package being an alpha
version in our next release.
However it's not going to be dropped now nor very soon and if there's
any particular reason I also don't mind keeping it the way it is right
now, once 2.3 is released.

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6

2012-09-11 Thread Mirko Vogt
On 09/11/2012 04:35 AM, Gert Doering wrote:
 busybox' ifconfig program does not understand the normal Linux ifconfig
 syntax to configure an IPv6 address on the tun0 interface.
 
 Last time I tested IPv6 with openvpn on openwrt, the openvpn-devel
 package unconditionally built with --enable-iproute2, which handles
 IPv6 just fine.
 --enable-iproute2 depends on CONFIG_OPENVPN_DEVEL_(openssl)_ENABLE_IPROUTE2,
 which defaults to off, which breaks IPv6 in the packages shipped by 
 default.

Ah, that might explain, why openvpn-devel depended on the package ip
previously - i was really wondering why, because everything worked fine
with ifconfig (I obviously didn't test ip6).

 I'd very much like to see this fixed, obviously :-)

Same here :)

 and while I see
 some space benefit in not depending on the ip package, I wonder whether
 this could be changed to have *ENABLE_IPROUTE2 default to 'on', so the
 pre-built packages *work*, and if someone is really space constrained,
 he can turn it off...?
 
 That is, apply the following patch... 

The disadvantage in regard of space is enormous.. if there's no other
way to get this fixed, okay, I'm fine with that.
However busybox's ifconfig IS capable of manage ipv6 settings, so I'd
rather like to see openvpn interacting with ifconfig correctly.

 thanks,

dito,

 gert

mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6

2012-09-11 Thread Mirko Vogt
On 09/12/2012 03:30 AM, Gert Doering wrote:
 Commited to openvpn upstream in cae102ae0c2ff934c456cd584cbf87a33cd95206

Nice - glad to see fixes get applied that fast upstream.
I also committed the fix into OpenWrt yesterday
(https://dev.openwrt.org/changeset/33375) to make sure it goes into the
AA builds.
However it seems meanwhile some other fixes got applied to the OpenVPN
project as well - unlikely to cause regressions, so I went for commit
5d4f5435 (cae102ae+1) in https://dev.openwrt.org/changeset/33376.

 gert

mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/3] build fixes with eglibc toolchain

2012-08-06 Thread Mirko Vogt
Committed (slightly adjusted) - thanks!

On 07/31/2012 05:35 PM, mika.lai...@nokia.com wrote:
 This set of patches include fixes for 3 build errors
 I noticed when building some of the luci modules
 with openwrt trunk where I had selected eglibc instead of uclibc.
 
 Mika Laitio (3):
   libtransmission eglibc build fix
   samba36 eglibc toolchain build fix
   libevent2 eglibc toolchain build fix
 
  libs/libevent2/Makefile   |1 +
  net/samba36/Makefile  |1 +
  .../patches/010_libtransmission_fallocate64_eglibc.patch  |   13 
 +
  3 files changed, 15 insertions(+)
  create mode 100644 
 net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/3] more build fixes to packages with eglibc

2012-08-06 Thread Mirko Vogt
Committed (slightly adjusted) - thanks!

On 08/01/2012 08:06 PM, mika.lai...@nokia.com wrote:
 Here is another set of build fixes to packages when openwrt
 uses eglibc instead of uclibc. I have tested the patches
 by doing builds both with the openwrt/uclibc toolchain
 and openwrt/eglibc toolchain.
 
 Mika Laitio (3):
   eglibc build fix for re
   knock eglibc build fix
   snort eglibc build fix
 
  libs/re/Makefile   |4 
  net/knock/patches/010_eglibc_define_PATH_MAX.patch |   11 +++
  net/snort/Makefile |2 +-
  3 files changed, 16 insertions(+), 1 deletion(-)
  create mode 100644 net/knock/patches/010_eglibc_define_PATH_MAX.patch
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Bug in net/dhcp feed package

2012-07-26 Thread Mirko Vogt
The point is: We want to tell, from the package name, what's inside an
ipkg archive.
This is not possible with so-called 'conditional dependencies', which
influence the
build, taking other config options into account.
Vice versa that means: We want to avoid having one and the same package
(as in
'name', 'version', etc.) with different content.
Sometimes conditional dependencies are wanted or necessary - however if
there's no
particular reason, we try to avoid them.

  mirko

On 07/26/2012 04:41 PM, Oliver wrote:
 On Thursday 26 July 2012 16:07:15 John Crispin wrote:
 i am talking about a version with and without ipv6. Or to make it easy
 to understand, IPV4 and dual stack.
 
 Which is exactly how I originally had it - it sat in its own section as 
 dhcp4 and there was a checkable option to enable IPv6 support.
 
 Regards,
 Oliver
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] why xburst target mark as BROKEN

2012-06-20 Thread Mirko Vogt
On 06/16/2012 10:33 AM, Xiangfu Liu wrote:
 Thanks for reply. attachment is the dmesg log. this kernel build at 'Jun 8 
 16:44:01 CST 2012'
 base on svn://svn.openwrt.org/openwrt/trunk@32117, works just fine under Ben 
 Nanonote(QI_LB60).

Broken flag removed - applied in 32469.

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] openvpn-polarssl: RNG signature change

2012-06-14 Thread Mirko Vogt
On 06/14/2012 04:29 PM, Gert Doering wrote:
 Thanks for your work - this is really so much better than what was
 there before.  Especially using git directly is nice.

Thanks! :)

 
 openvpn-devel-polarssl is not compiling for me right now, though --
 some linkage problem around symbols that should be in pf.o and 
 are not.  Some bits of the code see ENABLE_PF as #define'ed, and
 others as #undef, so the caller compiles the function call in,
 and pf.o is compiled into an empty module...

Hmm.. compiling openvpn-devel-polarssl doesn't cause any issues for me.
Could you attach your config?

 
 This is upstream breakage for the combination of --disable-plugins + 
 PolarSSL, caused by historically accumulated #ifdef brokenness in too
 many places.
 
 As a quick fix, just remove #include config.h from ssl_polarssl.h.

Patch is in the queue, however I'd like to reproduce the problem
on my side before committing.

 
 We'll get this fixed upstream in one way or the other, and I'll send
 over a new commit ID with the fix.

Okay, thanks.

 
 gert

mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] binutils tarball md5 mismatch?

2012-06-03 Thread Mirko Vogt
Hey,

they (GNU-binutils) once silently replaced the binutils-2.20.1 archive with the 
2.20.1a version.
This was an unfortunate move, since it triggered lot's of confusion (as you're 
experiencing now..) -
OpenEmbedded e.g. head to deal with the situation as well 
(http://patches.openembedded.org/patch/11149/).
There were some threads/posts about this on the binutils mailinglist as well - 
no attack
However, actually I thought the checksums got replaced that time, will check.

  mirko


On 06/03/2012 02:31 PM, Daniel A. Nagy wrote:
 Hi,
 
 When trying to do a build from backfire branch, many of the sources of
 GNU binutils used for the cross-compiling environment complain about md5
 mismatch. Eventually it does download a binutils-2.19.1.tar.bz2 file
 that it likes (md5 checksum: 09a8c5821a2dfdbb20665bc0bd680791), but
 quite a few attempts fail before it and not because of network errors.
 Are there different legitimate versions of 2.19.1 out there or is it an
 attack? Any ideas?
 
 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] binutils tarball md5 mismatch?

2012-06-03 Thread Mirko Vogt
On 06/03/2012 03:50 PM, Mirko Vogt wrote:
 However, actually I thought the checksums got replaced that time, will check.

(Kind of) fixed in r32037.
We can't just replace the tarball on our mirror server and change the checksum,
since it will break previous builds/releases. That's why the source now points
directly to our mirror server - avoids trying the GNU ones before.
The change (2.2x.1 - 2.2x.1a) just affected license files by the way,
no actual source code got changed*

  mirko


*http://sourceware.org/ml/binutils/2011-08/msg00198.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] openvpn-polarssl: RNG signature change

2012-06-01 Thread Mirko Vogt
The OpenVPN stuff needs some love in general. I'll try to get openvpn,
openvpn-devel and openvpn-polarssl consolidated and reworked in a
reasonable way this weekend / next week (which includes updating
openvpn-polarssl).

  mirko

On 06/01/2012 07:21 PM, David Favro wrote:
 PolarSSL 1.1 (i.e. as of SVN revision 1132, which is getting pulled in
 current OpenWRT feed) changed the argument signature of havege_rand() [and,
 to avoid confusion, changed its name to havege_random()].  Since
 ssl_set_rng() also changed the signature of the passed-in RNG to match, this
 doesn't cause too many problems.
 
 The master development branch of OpenVPN-PolarSSL has made appropriate
 changes (in fact it does not use havege_random() any longer), but the
 current OpenWRT feed is pulling 03ab4ead which predates the fix and hence
 does not compile.
 
 One option is to update the OpenVPN feed to a more recent version, but this
 requires some care since OpenVPN has since revamped the build system and
 directory structure; another is to downgrade PolarSSL to an older version.
 Attached patch is a third option, a temporary fix to use the new
 havege_random() with the older OpenVPN.  It is only lightly tested (OpenVPN
 establishes connection and can send data) but is a minor change.  It
 presumably should be accompanied by a minor bump of the feed package's 
 version.
 
 -- David
 
 
 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Fwd: [PATCH] nodogsplash crashes when rdir parameter is missing

2012-05-31 Thread Mirko Vogt
The project isn't really maintained anymore, but it's definitely worth a
try getting a fix upstream.
The patch applies and is working, however I wonder whether it creates a
memleak, since strdup is called which allocates memory which doesn't get
free'ed again.

On 05/31/2012 11:33 AM, John Crispin wrote:
 On 31/05/12 11:23, Moritz Warning wrote:
 Sorry, I wasn't very specific; nodogsplash exits rather than crashing.
 It uses a safe_strdup call that exits in this case.

 
 That still makes it a remote DoS exploit :-)
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Fwd: [PATCH] nodogsplash crashes when rdir parameter is missing

2012-05-31 Thread Mirko Vogt
Applied in 32017 - thanks!

On 05/31/2012 07:12 PM, Moritz Warning wrote:
 Mirko is right, my patch creates a memory leak.
 I've attached an alternative patch as proposal.
 
 Btw., I've send the nodogsplash maintainer a mail a year ago but got no reply 
 (patch for a minor issue).
 
 On 05/31/2012 03:21 PM, Outback Dingo wrote:
 On Thu, May 31, 2012 at 8:09 AM, Mirko Vogt mi...@openwrt.org wrote:
 The project isn't really maintained anymore, but it's definitely worth a
 try getting a fix upstream.
 The patch applies and is working, however I wonder whether it creates a
 memleak, since strdup is called which allocates memory which doesn't get
 free'ed again.


 Since Im the OpenWRT maintainer I can get it commit, but, honestly
 it should be
 really resolved upstream, so Ill contact the author, and see if 1)
 hell fix it, 2) if not if
 he wants to release the project to me in its entirety to continue the effort.


 On 05/31/2012 11:33 AM, John Crispin wrote:
 On 31/05/12 11:23, Moritz Warning wrote:
 Sorry, I wasn't very specific; nodogsplash exits rather than crashing.
 It uses a safe_strdup call that exits in this case.


 That still makes it a remote DoS exploit :-)
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] update and move util-linux(-ng) and update e2fsprogs

2012-04-28 Thread Mirko Vogt
On 04/25/2012 01:33 AM, Luka Perkov wrote:
 You think that subject is too big... You did not see the patch yet ;)
 
 This patch makes several changes with util-linux-ng package:
 
  * moves it to util-linux (upstream name)
  * bumps it to last stable version 2.21.1 (was 2.13.0.1)
  * adds several new packages
  * sorts packages inside Makefile
  * removes patch, it has been applied upstream
 
 This patch makes some changes with e2fsprogs package:
  * bumps it to last stable version 1.42.2
  * libraries have migrated from e2fsprogs to util-linux
 
 I could resend the patches separately but both would need to be applied.
 
 I would also like to maintain these packages.
 
 Signed-off-by: Luka Perkov open...@lukaperkov.net

Applied, thanks
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/3 V1] remove the possibility to select eglibc trunk and disable eglibc SVN revision selection

2012-04-28 Thread Mirko Vogt
On 04/23/2012 03:18 PM, Emmanuel Deloget wrote:
 When selecting a specific eglibc version, it comes with a specific SVN
 revision that should not be modified as it (more or less) correspond to
 a tagged release. This patch disable the possibility to select a specific
 SVN revision on known eglib versions.
 
 This patch also disables the possibility to select the trunk branch of
 eglibc. There are multiple reasons for that:
 
 * trunk/HEAD may not even compile
 
 * the OpenWRT built system makes using trunk/HEAD a difficult thing, as
 OpenWRT fetches the source tree and store it in a compressed tar archive.
 Subsequent build get the source from the tar archive - not from SVN,
 making the use of trunk/HEAD largelly innefective.
 
 * we cannot know the corresponding version of trunk/HEAD, meaning that
 we'll face compiling issues when we'll try to copy the libc files -
 unless the build system is fixed with this specific issue in mind.
 
 Signed-off-by: Emmanuel Deloget log...@free.fr

Applied (slightly changed) - thanks

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/3 V1] correct eglibc version numbers

2012-04-28 Thread Mirko Vogt
On 04/23/2012 02:54 PM, Emmanuel Deloget wrote:
 eglibc version number depends on the branch and on the maintenance release
 (i.e. the SVN revision). Changing the revision may change the maintenance
 version. This patch correlate the SVN revision to the correct version
 number - without this change, both eglibc 2.12 and eglibc 2.14 provoke
 build errors when compiling the base-files package (example, for 2.12):
 
 $ make package/base-files/compile V=1
   make[1] package/base-files/compile
   make[2] -C package/opkg host-compile
   make[2] -C package/base-files-network compile
   make[2] -C package/base-files compile
 cp: cannot stat
 `/home/me/openwrt/trunk/staging_dir/toolchain-arm_v7-a_gcc-4.6-linaro_eglibc-trunk_eabi/lib/ld-2.12.so':
 No such file or directory
 make[2]: ***
 [/home/me/openwrt/trunk/bin/omap4/packages/libc_trunk-106_omap4.ipk]
 Error 1
 make[1]: *** [package/base-files/compile] Error 2
 make -r package/base-files/compile: build failed. Please re-run make
 with V=99 to see what's going on
 make: *** [package/base-files/compile] Erreur 1
 
 Signed-off-by: Emmanuel Deloget log...@free.fr

By the way: All your patches didn't apply out of the box due to
whitespace errors.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Can we configure OpenWrt by 'curl' ?

2012-04-27 Thread Mirko Vogt
As part of LuCI there is a JSON-RPC interface which can be used to
configure OpenWrt.
With the uci-package you can easily read/write/apply/commit uci related
things.

http://luci.subsignal.org/trac/wiki/Documentation/JsonRpcHowTo


On 04/27/2012 11:41 AM, Xiangfu Liu wrote:
 Hi
 
 I am think use only curl to configure OpenWrt.
 
 like:
 for get wireless list
curl http://192.168.0.1/cgi-bin/luci/admin/network/wireless/
 for connect to one of them:
   curl
 http://192.168.0.1/cgi-bin/luci/admin/network/wireless/SSID=ssid;PW=passwd
 
 
 I don't know much about 'lua', please give me some advice.
 
 Thanks
 Xiangfu
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Can we configure OpenWrt by 'curl' ?

2012-04-27 Thread Mirko Vogt
As far as I know UVL is unmaintained and got obsoleted.
This still doesn't fix the broken links however :)

On 04/27/2012 01:15 PM, Christian Gagneraud wrote:
 On 27/04/12 12:11, Mirko Vogt wrote:
 As part of LuCI there is a JSON-RPC interface which can be used to
 configure OpenWrt.
 With the uci-package you can easily read/write/apply/commit uci related
 things.

 http://luci.subsignal.org/trac/wiki/Documentation/JsonRpcHowTo
 
 BTW, the links in the UVL section are broken:
 http://luci.subsignal.org/api/luci/modules/luci.uvl.html gives a 404
 
 Chris
 


 On 04/27/2012 11:41 AM, Xiangfu Liu wrote:
 Hi

 I am think use only curl to configure OpenWrt.

 like:
 for get wireless list
 curl http://192.168.0.1/cgi-bin/luci/admin/network/wireless/
 for connect to one of them:
curl
 http://192.168.0.1/cgi-bin/luci/admin/network/wireless/SSID=ssid;PW=passwd



 I don't know much about 'lua', please give me some advice.

 Thanks
 Xiangfu
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] eglibc 2.12 fails to build

2012-04-19 Thread Mirko Vogt
On 04/19/2012 11:43 AM, Emmanuel Deloget wrote:
 Checked with 2.13, and it indeed works.

Glad to hear!

 Regarding eglibc selection, it feels weird to me to be able to select
 both a version AND a revision. If I want version 2.12, I will probably
 stick to its corresponding revision. Same for 2.13 or 2.14. Worse,
 it doesn't work as expected (violation of the principle of least
 surprise): the revision does not change if I change the eglibc
 version.

That's indeed not intuitive and caused me some troubles myself.
Technical reason for that is, CONFIG_EGLIBC_REVISION isn't set by
default but will be set depending on CONFIG_EGLIBC_VERSION_2_1X.
Once however a config symbol is set, it's not affected anymore by
changes which would have effective if they weren't set already.

 
 Should we limit the revision selection to the eglibc trunk version?
 That would make much more sense IMHO, and that would minimize issues
 that are related to version/revision conflicts (I suspect they are
 quite hard to spot).
 
 Something like: [..]

I agree - we should fix the revision to the actual releases. I'll take a
closer look on this later today.

Thanks

  mirko

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] eglibc 2.12 fails to build

2012-04-19 Thread Mirko Vogt
On 04/18/2012 11:17 PM, Peter Naulls wrote:
 Unless something has changed very recently, 2.12 and 2.14 builds have
 been broken for as long as I've been looking at them, which is the
 best part of a year.   Only 2.13 builds, and even then you still
 need some additional e/glibc patches for the rest of the system
 to work correctly.
 
 https://dev.openwrt.org/ticket/9483
 
 So, again.  Old versions of both eglibc and glibc need to be purged,
 since they (a) are ancient (b) don't build (c) cause repeat
 questions of exactly this type on this list.

Hello Peter,

I was just scrolling through your mails regarding glibc/eglibc and have
to admit: yes, you tried several times to get your patches in and I
apologize for the see-saw.
I'm going to purge eglibc 2.12 soon; eglibc 2.13 is what I recommend
right now, since in eglibc = 2.14 the sun-rpc system got pulled out and
quite some packages rely on that. This needs to be dealt with in OpenWrt
- some time.
Looking at #9483: It's confusing. Quite some stuff changed and things
mentioned in the ticket got obsoleted. I also can't understand yet why
eglibc 2.13 is still causing troubles for you. Can you elaborate? Could
you rebase your issues on latest trunk? Things actually happened since
the ticket got created/modified :)
I also noticed complains about glibc - however every time I ask people
why in particular they chose glibc over eglibc I didn't get any
meaningful response. glibc is de facto unmaintained in OpenWrt and I'd
actually like to purge it out - still I'm afraid to affront people using
it for a reason.
Feel free to get into a direct discussion with me, e.g. via IRC:
mirko@freenode

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] eglibc 2.12 fails to build

2012-04-19 Thread Mirko Vogt
On 04/19/2012 11:43 AM, Emmanuel Deloget wrote:
 Force the use of known revision for specific eglibc versions.
 Eglibc revision can only be changed if the user selects the trunk
 version.
 
 Signed-off-by: Emmanuel Deloget log...@free.fr
 
 Index: toolchain/eglibc/Config.in
 ===
 --- toolchain/eglibc/Config.in(révision 31345)
 +++ toolchain/eglibc/Config.in(copie de travail)
 @@ -22,15 +22,19 @@
 
  endchoice
 
 +config EGLIBC_TRUNK_REVISION
 +string
 +prompt eglibc revision
 +depends on TOOLCHAINOPTS  USE_EGLIBC  EGLIBC_VERSION_TRUNK
 +default HEAD
 +
  config EGLIBC_REVISION
  string
 -prompt eglibc revision
  depends on TOOLCHAINOPTS  USE_EGLIBC
  default 14661 if EGLIBC_VERSION_2_12
  default 15508 if EGLIBC_VERSION_2_13
  default 16488 if EGLIBC_VERSION_2_14
 -default HEAD  if EGLIBC_VERSION_TRUNK
 -default 
 +default EGLIBC_TRUNK_REVISION if EGLIBC_VERSION_TRUNK
 
  menu eglibc configuration
  depends on TOOLCHAINOPTS  USE_EGLIBC

The issue with HEAD is, that the fetched source will be packed and put
into dl/ (sth. like eglibc-trunk-HEAD.tar.gz).
In the next run this archive will be taken instead of fetching the new
HEAD, since it doesn't contain and rev-nr (but just 'HEAD') in the
revision-string and therewith in the filename.
There's also no checksum for the archive (obviously), so the build
system will not now when to re-fetch the src or to rely - which is the
default - on using the packed archive in dl/.

Since fetching the latest HEAD of any external source is uncommon and to
be avoided anyway (since builds are non-deterministic and changes to
external repositories might result in unpredictable build behaviours)
I'd like to drop the option of fetching trunk/HEAD at all. Comments?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] eglibc 2.12 fails to build

2012-04-19 Thread Mirko Vogt
On 04/19/2012 04:00 PM, Emmanuel Deloget wrote:
 Good catch. In fact, HEAD is likely to never be the right choice, even
 in other packages. So maybe we can forbid it?

That's what I meant with:
Since fetching the latest HEAD of any external source is uncommon and
to be avoided anyway (since builds are non-deterministic and changes to
external repositories might result in unpredictable build behaviours)
I'd like to drop the option of fetching trunk/HEAD at all.

 Another solution would be to not create the tar.gz if revision is HEAD.
 By definition, HEAD might have changed since your last compile, so if
 you make package/clean, it should fetch a new version.
 
 Something like (not sure that work, so don't apply it; I'm currently
 testing it but in order to do so, I have to make distclean, so it takes
 some time...)
 
 Index: include/download.mk
 ===
 --- include/download.mk(révision 31345)
 +++ include/download.mk(copie de travail)
 @@ -74,9 +74,12 @@
  svn export --non-interactive --trust-server-cert -r$(VERSION)
 $(URL) $(SUBDIR) || \
  svn export --non-interactive -r$(VERSION) $(URL) $(SUBDIR) )  \
  echo Packing checkout...  \
 -$(call dl_pack,$(TMP_DIR)/dl/$(FILE),$(SUBDIR))  \
 -mv $(TMP_DIR)/dl/$(FILE) $(DL_DIR)/  \
 -rm -rf $(SUBDIR); \
 +{ [ $(VERSION) = HEAD ] || { \
 +$(call dl_pack,$(TMP_DIR)/dl/$(FILE),$(SUBDIR))  \
 +mv $(TMP_DIR)/dl/$(FILE) $(DL_DIR)/  \
 +rm -rf $(SUBDIR); \
 +} ; \
 +} ; \
  )
  endef
 

I think your ideas to change download.mk make sense and provide benefits
to developers (when $REV is 'HEAD' it should always re-fetch the src
(independent of used SCM)). Quite some people asked yet how to always
fetch HEAD from (custom) repositories and I was missing this
functionality in some custom projects myself.

 +config OPENWRT_BLEEDING_EDGE
 +bool
 +default y
 +

Introducing OPENWRT_BLEEDING_EDGE raises the impression of
over-engineering to me. We still should try to avoid fetching HEAD of
sources (see above), however IF we provide the possibility - which is
opt-in and just for developers anyway - I don't see the point of
un-hide respective options first.

PS: Please try to quote only parts in your replies you're explicitly
referring to. Otherwise threads get unreadable and confusing.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] anybody using glibc over eglibc for a reason?

2012-04-19 Thread Mirko Vogt
Hey all,

as a matter of fact glibc support is currently unmaintained in OpenWrt
and I'd like to drop it entirely.
We received quite some complains about buggy/non-working glibc support -
most people however got happy with using eglibc in the end (which is
supported quite well).
However, before purging glibc support entirely, I'd like to ask:

Is anybody of you guys currently choosing glibc over eglibc for a
particular reason? And if so: what's the reason? :)

Thanks and Cheers

  mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] eglibc 2.12 fails to build

2012-04-17 Thread Mirko Vogt
Hey Emmanuel,

I levelled up all versions of eglibc to it's latest revisions of its
respective branches ( https://dev.openwrt.org/changeset/31300 ) and
therewith I guess broke eglibc version 2.12 which I'd like to purge out
anyway. Is there any reason for you to stay on 2.12 instead of 2.13?
If it id because it doesn't/didn't work please give it another try and
let me know.

Thanks,

  mirko

On 04/17/2012 07:01 PM, Emmanuel Deloget wrote:
 Hello,
 
 (working on trunk...)
 
 It seems (to me; I can be wrong) that patch
 100-do-not-use-implicit-rules.patch
 for eglibc-2.12 is not needed, as this version already contains it.
 
 Can someone confirm this before I send a patch / open a ticket?
 
 Best regards,
 
 -- Emmanuel Deloget
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] new package libssh2

2012-02-07 Thread Mirko Vogt
Commited (slighly adjusted*) in r30348 - thanks!

*setting PKG_INSTALL and 'Build/Install' is redundant, remove former one

On 02/07/2012 01:01 PM, Jiri Slachta wrote:
 Signed-off-by: Jiri Slachta j...@slachta.eu
 Index: feeds/packages/libs/libssh2/Makefile
 ===
 --- feeds/packages/libs/libssh2/Makefile  (revision 0)
 +++ feeds/packages/libs/libssh2/Makefile  (revision 0)
 @@ -0,0 +1,57 @@
 +#
 +# Copyright (C) 2012 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=libssh2
 +PKG_VERSION:=1.4.0
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 +PKG_SOURCE_URL:=http://www.libssh2.org/download/
 +PKG_MD5SUM:=ee670161d8c5dff93ae84a3f34f15669
 +PKG_INSTALL:=1
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/libssh2
 +  SECTION:=libs
 +  CATEGORY:=Libraries
 +  TITLE:=SSH2 library
 +  URL:=http://www.libssh2.org/
 +  DEPENDS:=+libopenssl +zlib
 +endef
 +
 +TARGET_CFLAGS += $(FPIC)
 +CONFIGURE_ARGS += --with-libssl-prefix=$(STAGING_DIR)/usr
 +
 +define Build/Compile
 + $(MAKE) $(MAKE_FLAGS) -C $(PKG_BUILD_DIR)/src all
 +endef
 +
 +define Build/Install
 + $(MAKE) $(MAKE_FLAGS) -C $(PKG_BUILD_DIR)/src install 
 DESTDIR=$(PKG_INSTALL_DIR)
 + $(MAKE) $(MAKE_FLAGS) -C $(PKG_BUILD_DIR) install-includeHEADERS 
 DESTDIR=$(PKG_INSTALL_DIR)
 +endef
 +
 +define Build/InstallDev
 + $(INSTALL_DIR) $(1)/usr/include
 + $(INSTALL_DIR) $(1)/usr/lib
 + $(CP) \
 + $(PKG_INSTALL_DIR)/usr/include/*h \
 + $(1)/usr/include/
 + $(CP) \
 + $(PKG_INSTALL_DIR)/usr/lib/libssh2.so* \
 + $(1)/usr/lib/
 +endef
 +
 +define Package/libssh2/install
 + $(INSTALL_DIR) $(1)/usr/lib
 + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libssh2.so* $(1)/usr/lib/
 +endef
 +
 +$(eval $(call BuildPackage,libssh2))
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] My changes to OpenWRT

2011-11-09 Thread Mirko Vogt
On 11/09/2011 01:20 AM, Peter Naulls wrote:
 On 11/08/2011 02:15 PM, Michael Geddes wrote:
 
 I don't know about the target hardware in question or the 64-bit builds,
 but for any hope of having glibc/eglibc builds work

Building with eglibc should work out of the box.

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v3 1/1] pciutils: need to specify -lresolv explicitly when using eglibc

2011-06-25 Thread Mirko Vogt

On Fri, 24 Jun 2011 19:02:05 -0700, Philip Prindeville wrote:

eglibc's libc doesn't include libresolv as part of it.

Redux: Need to annotate libbsd dependency as well.

Redux: Include support for glibc as well.

Signed-off-by: Philip Prindeville phil...@redfish-solutions.com


Why did you add 'libbsd' as dependency for pciutils when using 
glibc/eglibc?
I just tried building pciutils within an glibc and eglibc toolchain and 
it compiles fine without getting linked against libbsd.


Regarding '-lresolv' you're right - pciutils needs to get linked 
against libresolv.so (commited in 27281).


mirko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [OpenWrt-Commits] r27214 - trunk/toolchain/eglibc

2011-06-20 Thread Mirko Vogt

OK, I reverted the commit.

However as stated in eglibc features ( http://www.eglibc.org/features 
):


==
Building with -Os
EGLIBC supports building the library with compiler optimizing for 
size -Os instead of for speed -O2.

==

This is just wrong then.. *sigh*

Thanks

mirko


On Mon, 20 Jun 2011 09:01:36 +0300, Mika Laitio wrote:

On 06/20/2011 06:16 AM, Philip Prindeville wrote:

On 6/18/11 4:14 AM, openwrt-comm...@openwrt.org wrote:

Author: mirko
Date: 2011-06-18 13:14:01 +0200 (Sat, 18 Jun 2011)
New Revision: 27214

Modified:
trunk/toolchain/eglibc/Makefile
Log:
[toolchain/eglibc} eglibc in fact can be built with -Os

Modified: trunk/toolchain/eglibc/Makefile
===
--- trunk/toolchain/eglibc/Makefile	2011-06-18 07:33:28 UTC (rev 
27213)
+++ trunk/toolchain/eglibc/Makefile	2011-06-18 11:14:01 UTC (rev 
27214)

@@ -52,10 +52,6 @@
  HOST_BUILD_DIR1:=$(HOST_BUILD_DIR)-initial
  HOST_BUILD_DIR2:=$(HOST_BUILD_DIR)-final

-# XXX: {e,}glibc does not build w/ -Os
-# http://sourceware.org/bugzilla/show_bug.cgi?id=5203
-EGLIBC_CFLAGS:=$(subst -Os,-O2,$(TARGET_CFLAGS))
-
  EGLIBC_CONFIGURE:= \
BUILD_CC=$(HOSTCC) \
$(TARGET_CONFIGURE_OPTS) \




I'm seeing a regression:


I got same build failure for
toolchain-mips_r2_gcc-linaro_eglibc-2.12/eglibc-2.12-r10495-initial
target.


/home/lamikr/misc/src/openwrt/openwrt_trunk.git/build_dir/toolchain-mips_r2_gcc-linaro_eglibc-2.12/eglibc-2.12-r10495-initial/config.h:3:3:
error: #error glibc cannot be compiled without optimization
make[6]: ***

[/home/lamikr/misc/src/openwrt/openwrt_trunk.git/build_dir/toolchain-mips_r2_gcc-linaro_eglibc-2.12/eglibc-2.12-r10495-initial/tcb-offsets.h]
Error 1


Mika
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Compiling error after using glibc

2011-06-17 Thread Mirko Vogt
 hotplug2-modwrap.c
powerpc-openwrt-linux-gnu-gcc -g  hotplug2-modwrap.o   -o
hotplug2-modwrap
 make[5]: Entering directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/parser
powerpc-openwrt-linux-gnu-gcc -Os -pipe -fno-caller-saves -mcpu=440
-fhonour-copts -msoft-float -MM buffer.c lexer.c parser.c token.c
token_queue.c  .depend
 make[5]: Leaving directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/parser
make[5]: Entering directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/parser
 make[5]: Leaving directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/parser
make[5]: Entering directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/rules
 powerpc-openwrt-linux-gnu-gcc -Os -pipe -fno-caller-saves -mcpu=440
-fhonour-copts -msoft-float -MM command.c condition.c execution.c
expression.c rule.c ruleset.c  .depend
make[5]: Leaving directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/rules
 make[5]: Entering directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/rules
make[5]: Leaving directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/rules
 make[4]: Leaving directory

`/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201
powerpc-openwrt-linux-gnu-gcc -Os -pipe -fno-caller-saves -mcpu=440
-fhonour-copts -msoft-float
-L/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/usr/lib
-L/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/lib

-L/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/usr/lib

-L/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/lib
-o

/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/udevtrigger
src/udevtrigger.c
 /tmp/cc20wHNr.o: In function `device_list_insert:
udevtrigger.c:(.text+0x94): undefined reference to `strlcpy
udevtrigger.c:(.text+0xa8): undefined reference to `strlcat
udevtrigger.c:(.text+0xe0): undefined reference to `strlcpy
 udevtrigger.c:(.text+0x124): undefined reference to `strlcpy
udevtrigger.c:(.text+0x138): undefined reference to `strlcat
udevtrigger.c:(.text+0x1d4): undefined reference to `strlcat
udevtrigger.c:(.text+0x1e4): undefined reference to `strlcat
 udevtrigger.c:(.text+0x200): undefined reference to `strlcpy
udevtrigger.c:(.text+0x210): undefined reference to `strlcat
udevtrigger.c:(.text+0x224): undefined reference to `strlcat
/tmp/cc20wHNr.o: In function `main:
 udevtrigger.c:(.text+0x3ac): undefined reference to `strlcpy
udevtrigger.c:(.text+0x3c0): undefined reference to `strlcat
udevtrigger.c:(.text+0x410): undefined reference to `strlcpy
udevtrigger.c:(.text+0x420): undefined reference to `strlcat
 udevtrigger.c:(.text+0x430): undefined reference to `strlcat
udevtrigger.c:(.text+0x440): undefined reference to `strlcat
udevtrigger.c:(.text+0x464): undefined reference to `strlcpy
udevtrigger.c:(.text+0x474): undefined reference to `strlcat
 udevtrigger.c:(.text+0x484): undefined reference to `strlcat
udevtrigger.c:(.text+0x4e8): undefined reference to `strlcpy
udevtrigger.c:(.text+0x538): undefined reference to `strlcpy
udevtrigger.c:(.text+0x548): undefined reference to `strlcat
 udevtrigger.c:(.text+0x558): undefined reference to `strlcat
udevtrigger.c:(.text+0x594): undefined reference to `strlcpy
udevtrigger.c:(.text+0x5a4): undefined reference to `strlcat
udevtrigger.c:(.text+0x5b4): undefined reference to `strlcat
 udevtrigger.c:(.text+0x618): undefined reference to `strlcpy
udevtrigger.c:(.text+0x648): undefined reference to `strlcpy
udevtrigger.c:(.text+0x698): undefined reference to `strlcpy
udevtrigger.c:(.text+0x6a8): undefined reference to `strlcat
 udevtrigger.c:(.text+0x6b8): undefined reference to `strlcat
udevtrigger.c:(.text+0x704): undefined reference to `strlcpy
udevtrigger.c:(.text+0x714): undefined reference to `strlcat
udevtrigger.c:(.text+0x724): undefined reference to `strlcat
 collect2: ld returned 1 exit status
make[3]: ***

[/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/.built]
Error 1
make[3]: Leaving directory `/openwrt_trunk-glibc/package/hotplug2
make[2]: *** [package/hotplug2/compile] Error 2
 make[2]: Leaving directory `/openwrt_trunk-glibc
make[1]: ***

[/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/stamp/.package_compile]
Error 2
make[1]: Leaving directory `/openwrt_trunk-glibc
 make: *** [world] Error 2

Thanks,
Pawel
commit 342a0236f277dafd22e16d67dc5f86981bba5121
Author: Mirko Vogt d...@nanl.de
Date:   Fri Jun 17 15:24:53 2011 +

[package/hotplug2] link against 'libbsd' when using glibc

diff --git a/trunk/package/hotplug2/Makefile b/trunk/package/hotplug2/Makefile
index 9625ba2..699976e 100644
--- a/trunk/package/hotplug2/Makefile
+++ b/trunk/package/hotplug2/Makefile
@@ -28,7 +28,7 @@ define Package/hotplug2
   VERSION:=1.0-beta-$(PKG_RELEASE

Re: [OpenWrt-Devel] Compiling error after using glibc

2011-06-17 Thread Mirko Vogt

It got obsoleted by r27169, r27170 and r27209.

mirko

On Fri, 17 Jun 2011 13:26:22 -0400, Pawel Pastuszak wrote:

Thanks guys for the support the last patch did the trick to compile
everything.

Do you think i should include this patch also or is it unneeded

https://dev.openwrt.org/attachment/ticket/9012/hotplug2.patch [4]

Pawel

On Fri, Jun 17, 2011 at 11:31 AM, Mirko Vogt  wrote:


Hello Pawel,

this issue is related to: https://dev.openwrt.org/ticket/9012 [1]

Attached patch should solve the issue - please report if it does
the job.

Cheers

mirko

On Fri, 17 Jun 2011 10:39:26 -0400, Pawel Pastuszak wrote:


Hi gents,

I getting an hotplug complie error after i compiled the gcc 4.4.5
toolcahin with glibc 2.6.1, please not this is a trunk check out

PS. I am using Ubuntu 10.10.

make[3]: Entering directory
`/openwrt_trunk-glibc/package/hotplug2
 . /openwrt_trunk-glibc/include/shell.sh; .
/openwrt_trunk-glibc/include/shell.sh; gzip -dc
/openwrt_trunk-glibc/dl/hotplug2-201.tar.gz | /bin/tar -C






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/..

-xf -

Applying ./patches/100-env_memleak.patch using plaintext:
patching file action.c

Applying ./patches/110-static_worker.patch using plaintext:
patching file common.mak
patching file Makefile

Applying ./patches/120-sysfs_path_fix.patch using plaintext:
 patching file rules/command.c

Applying ./patches/130-cancel_download_fix.patch using plaintext:
patching file rules/command.c

Applying ./patches/140-worker_fork_fix.patch using plaintext:
patching file action.c
 patching file action.h
patching file workers/worker_fork.c

Applying ./patches/150-force_fork_slow.patch using plaintext:
patching file workers/worker_fork.c

Applying ./patches/160-event_block_fix.patch using plaintext:
 patching file uevent.c
patching file workers/worker_fork.c
patching file workers/worker_fork.h

Applying ./patches/170-non_fatal_include.patch using plaintext:
patching file parser/parser.c
touch






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/.prepared_a0868ae0da52f806357cd4d656bea207

 (cd






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/./;

if [ -x ./configure ]; then /usr/bin/find






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/

-name config.guess | xargs -r chmod u+w; /usr/bin/find






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/

-name config.guess | xargs -r -n1 cp
/openwrt_trunk-glibc/scripts/config.guess; /usr/bin/find






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/

-name config.sub | xargs -r chmod u+w; /usr/bin/find






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/

-name config.sub | xargs -r -n1 cp
/openwrt_trunk-glibc/scripts/config.sub;
AR=powerpc-openwrt-linux-gnu-ar AS=powerpc-openwrt-linux-gnu-gcc
-c
-Os -pipe -fno-caller-saves -mcpu=440 -fhonour-copts
-msoft-float
LD=powerpc-openwrt-linux-gnu-ld NM=powerpc-openwrt-linux-gnu-nm
CC=powerpc-openwrt-linux-gnu-gcc
GCC=powerpc-openwrt-linux-gnu-gcc
CXX=powerpc-openwrt-linux-gnu-g++
RANLIB=powerpc-openwrt-linux-gnu-ranlib
STRIP=powerpc-openwrt-linux-gnu-strip
OBJCOPY=powerpc-openwrt-linux-gnu-objcopy
OBJDUMP=powerpc-openwrt-linux-gnu-objdump
SIZE=powerpc-openwrt-linux-gnu-size CFLAGS=-Os -pipe
-fno-caller-saves -mcpu=440 -fhonour-copts -msoft-float 
CXXFLAGS=-Os -pipe -fno-caller-saves -mcpu=440 -fhonour-copts
-msoft-float 






CPPFLAGS=-I/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/usr/include





-I/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/include







-I/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/usr/include







-I/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/include








LDFLAGS=-L/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/usr/lib

-L/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/lib






-L/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/usr/lib







-L/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/lib

   ./configure --target=powerpc-openwrt-linux
--host=powerpc-openwrt-linux --build=i686-linux-gnu
--program-prefix= --program-suffix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share
--localstatedir=/var --mandir=/usr/man --infodir=/usr/info
--disable-nls   ; fi; )
 touch






/openwrt_trunk-glibc/build_dir/target-powerpc_glibc-2.6.1/hotplug2-201/.configured_

CFLAGS=-Os -pipe -fno-caller-saves -mcpu=440 -fhonour-copts
-msoft-float 






-I/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/usr/include





-I/openwrt_trunk-glibc/staging_dir/target-powerpc_glibc-2.6.1/include







-I/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc-4.4.5_glibc-2.6.1/usr/include







-I/openwrt_trunk-glibc/staging_dir/toolchain-powerpc_gcc

Re: [OpenWrt-Devel] [PATCH 1/1] eglibc: Bump default version to 2.12

2011-06-13 Thread Mirko Vogt
Never mind.. a quote of: 
http://lists.debian.org/debian-devel/2009/05/msg00175.html


  And to answer some of the questions:
  [..]
  - strlcpy() and strlcat() won't be added to EGLIBC as it would break 
the

ABI and API. Use libbsd [2] for that, it is already in the archive.

So I packaged libbsd in r27169 and made hotplug2 depend on libbsd if 
eglibc is used in r27170 which should solve the issue and offers a 
simple solution for other packages depending on these functions as well.


mirko

On Mon, 13 Jun 2011 14:11:47 +0200, Mirko Vogt wrote:

Hey Philipp,

are you able to build udevtrigger (part of the hotplug2 package) with
eglibc 2.12?
I'm asking because of this ticket: 
https://dev.openwrt.org/ticket/9012


Cheers

mirko


On Sun, 12 Jun 2011 17:48:57 -0700, Philip Prindeville wrote:

Eglibc doesn't build with the native gnu make if it's 3.82 or later
(which it is for Fedora 14, 15, and later).

2.8 also seems to have issues with cross-compilation of i386 targets
on an x86_64 host.

Signed-off-by: Philip Prindeville phil...@redfish-solutions.com


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH2] Add Protobuf library (Second submit)

2011-06-09 Thread Mirko Vogt
Commit with some adjustments in 27152 ( 
https://dev.openwrt.org/browser/packages/libs/protobuf/Makefile?rev=27152 
).


Changes mostly are related to the use of default rules which apply fine 
in this case and simplify the Makefile.


mirko

On Thu, 9 Jun 2011 12:22:12 +0200, Obinou wrote:

Hello,

This patch adds the Protobuf library into feeds/packages.

Protobuf ( http://code.google.com/p/protobuf/ ) is a way of encoding
structured data in an efficient yet extensible format.
Google uses Protocol Buffers for almost all of its internal RPC
protocols and file formats.

It's vaguely similar to rpcgen, in a (wicked) way, but for C++/python 
or Java

(Here in OpenWRT only C++ is built)

I've tested it on Atheros and BCM63xx plateforms, on OpenWRT trunk.

Notes:
This is the second version of the patch, which takes care of
compiling  installing the protoc application for the host, since
this is required for compiling the target version.
Many thanks to Mirko and Jonas who showed me how to do it, and sorry
for the delay !

When commited, this library will complete the requirements to build
the Seeks package, previously proposed.
I will also answer to any questions, critics and wishes regarding the
packaging of protobuf, tokyocabinet and Seeks.

Obinou


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Add TokyoCabinet library

2011-06-07 Thread Mirko Vogt

Applied in 27123, thanks

On Tue, 7 Jun 2011 11:36:34 +0200, Obinou wrote:

Hello,

This patch adds the TokyoCabinet Library into feeds/packages.

TokyoCabinet ( http://fallabs.com/tokyocabinet/ ) is a DBM-like
library to manage a database.
It's similar to the various *DBM libraries that exists, with a focus
on portability, code size and efficiency.

I've tested it on Atheros and BCM63xx plateforms, on OpenWRT trunk.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Add Seeks package

2011-06-07 Thread Mirko Vogt

Applied in 27124, thanks

On Tue, 7 Jun 2011 11:55:03 +0200, Obinou wrote:

Hello,

This patch adds the Seeks program into feeds/packages.

Seeks ( http://www.seeks-project.info/site/ ) is an experimental
projet to build a distributed, P2P search engine.

While for now it's essentially a query aggregator (i.e. you make a
query, it asks several other engines  returns the results),
the long-term goal is to create a P2P search engine that would be
independant from companies's web crawlers and search engine.

That's the reason why I decided to build the developement (GIT)
version rather than the stable one.
To achieve this P2P goal, Seeks need persistent storage on the
target: So it's *mandatory* to use seeks on an overlay, for exemple.
Installing Seeks on a flash-only device makes no sense.
To handle persistance, Seeks needs the Protobuf and TokyoCabinet
libraries , previously proposed.

For now, the configuration is done through the regulars seeks files
in /etc/seeks: No effort has been made to add a UCI layer, although
it's clearly a goal if the demand is here.

I DO apply as the official maintainer for these packages
(tokyocabinet, protobuf, seeks) for OpenWRT, and can be reached in
particular
on irc (#openwrt and #openwrt-devel) as obinou.

I would be delighted to hear all remarks, advices and ideas
concerning these patches, and I will be able to propose other round 
of

patches
if necessary before commit.

Thanks.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] triggerhappy: update to 0.1.6

2010-11-21 Thread Mirko Vogt
Committed in r24076, thanks.
Please attach patches as files next time, since inlining often screws
them up (in this case spaces - tabs).

mirko

On Mon, 2010-11-22 at 00:07 +0100, Stefan Tomanek wrote:
 Signed-off-by: Stefan Tomanek stefan.tomanek+open...@wertarbyte.de
 ---
  utils/triggerhappy/Makefile |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/utils/triggerhappy/Makefile b/utils/triggerhappy/Makefile
 index 984708d..a0bde02 100644
 --- a/utils/triggerhappy/Makefile
 +++ b/utils/triggerhappy/Makefile
 @@ -6,8 +6,8 @@
  include $(TOPDIR)/rules.mk
  
  PKG_NAME:=triggerhappy
 -PKG_VERSION:=0.1.3
 -PKG_REV:=f7c42167127fb8377f99440f943ab863433b14b5
 +PKG_VERSION:=0.1.6
 +PKG_REV:=01bedc72451f8afd0c35649dd67c428c44a0f737
  PKG_RELEASE:=1
  
  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 @@ -15,7 +15,6 @@
 PKG_SOURCE_URL:=git://github.com/wertarbyte/triggerhappy
  PKG_SOURCE_PROTO:=git
  PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
  PKG_SOURCE_VERSION:=$(PKG_REV)
 -PKG_MD5SUM:=7da137a7d2ba1ce396231e821e68de4e
  
  include $(INCLUDE_DIR)/package.mk
  
 @@ -33,6 +32,7 @@ define Package/triggerhappy/description
  endef
  
  MAKE_FLAGS += \
 +   LINUX_INPUT_H=$(TOOLCHAIN_DIR)/include/linux/input.h \
 $(TARGET_CONFIGURE_OPTS) \
 $(1) 


-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] [packages] add triggerhappy hotkey daemon

2010-11-17 Thread Mirko Vogt
(slightly changed) applied in commit 24018
(https://dev.openwrt.org/changeset/24018) - thanks!

mirko


On Fri, 2010-11-12 at 11:17 +0100, Stefan Tomanek wrote:
 Triggerhappy is a lightweight hotkey daemon that can launch arbitrary commands
 on input events. It supports the hotplugging of devices and the processing of
 key combinations.
 
 Signed-off-by: Stefan Tomanek stefan.tomanek+open...@wertarbyte.de
 ---
  utils/triggerhappy/Makefile|   51 
 
  utils/triggerhappy/files/triggerhappy-example.conf |   14 +
  utils/triggerhappy/files/triggerhappy.hotplug  |   15 ++
  utils/triggerhappy/files/triggerhappy.init |   10 
  4 files changed, 90 insertions(+), 0 deletions(-)
  create mode 100644 utils/triggerhappy/Makefile
  create mode 100644 utils/triggerhappy/files/triggerhappy-example.conf
  create mode 100644 utils/triggerhappy/files/triggerhappy.hotplug
  create mode 100644 utils/triggerhappy/files/triggerhappy.init
 
 diff --git a/utils/triggerhappy/Makefile b/utils/triggerhappy/Makefile
 new file mode 100644
 index 000..b3e122f
 --- /dev/null
 +++ b/utils/triggerhappy/Makefile
 @@ -0,0 +1,51 @@
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=triggerhappy
 +PKG_VERSION:=0.1.3
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_VERSION).tar.gz
 +PKG_SOURCE_URL:=http://github.com/wertarbyte/triggerhappy/tarball/release/
 +PKG_MD5SUM:=7da137a7d2ba1ce396231e821e68de4e
 +
 +PKG_BUILD_DIR:=$(BUILD_DIR)/wertarbyte-triggerhappy-f7c4216/
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/triggerhappy
 +  SECTION:=utils
 +  CATEGORY:=Utilities
 +  TITLE:=handle input events and run configured programs
 +  URL:=http://github.com/wertarbyte/triggerhappy
 +endef
 +
 +define Package/triggerhappy/description
 + triggerhappy - handle input events and run configured programs
 + The daemon thd can handle hotplugged input devices and is configured 
 through
 + simple configuration files in /etc/triggerhappy/triggers.d/.
 +endef
 +
 +MAKE_FLAGS += \
 + $(TARGET_CONFIGURE_OPTS) \
 + $(1)
 +
 +define Package/triggerhappy/install
 + $(INSTALL_DIR) $(1)/usr/sbin
 + $(INSTALL_DIR) $(1)/etc
 + $(INSTALL_DIR) $(1)/etc/init.d
 + $(INSTALL_DIR) $(1)/etc/triggerhappy
 + $(INSTALL_DIR) $(1)/etc/triggerhappy/triggers.d/
 + $(INSTALL_DIR) $(1)/etc/hotplug.d/input/
 + $(INSTALL_BIN) $(PKG_BUILD_DIR)/thd $(1)/usr/sbin
 + $(INSTALL_BIN) $(PKG_BUILD_DIR)/th-cmd $(1)/usr/sbin
 + $(INSTALL_BIN) ./files/triggerhappy.init $(1)/etc/init.d/triggerhappy
 + $(INSTALL_BIN) ./files/triggerhappy.hotplug 
 $(1)/etc/hotplug.d/input/10-triggerhappy
 + $(INSTALL_BIN) ./files/triggerhappy-example.conf 
 $(1)/etc/triggerhappy/triggers.d/example.conf
 +endef
 +
 +$(eval $(call BuildPackage,triggerhappy))
 diff --git a/utils/triggerhappy/files/triggerhappy-example.conf 
 b/utils/triggerhappy/files/triggerhappy-example.conf
 new file mode 100644
 index 000..3a8017a
 --- /dev/null
 +++ b/utils/triggerhappy/files/triggerhappy-example.conf
 @@ -0,0 +1,14 @@
 +# This is an example configuration for the triggerhappy daemon (thd)
 +# please note that every file to be processed must end in .conf
 +#
 +# To view a list of supported event codes, use thd --listevents or
 +# thd --dump /dev/input/event*
 +#
 +# Format:
 +# eventcode value command
 +#
 +# values for key events are 1 (pressed), 0 (released) or 2 (held)
 +#
 +## control an mpd instance
 +# KEY_NEXTSONG   1   /usr/bin/mpc next
 +# KEY_PREVSONG   1   /usr/bin/mpc prev
 diff --git a/utils/triggerhappy/files/triggerhappy.hotplug 
 b/utils/triggerhappy/files/triggerhappy.hotplug
 new file mode 100644
 index 000..78ad349
 --- /dev/null
 +++ b/utils/triggerhappy/files/triggerhappy.hotplug
 @@ -0,0 +1,15 @@
 +#!/bin/sh
 +THD_SOCKET=/tmp/triggerhappy.socket
 +[ -S $THD_SOCKET ] || exit
 +
 +case $ACTION in
 + add)
 + DEVICE=/dev/$DEVNAME
 + [ -c $DEVICE ] || exit
 + # offer device to triggerhappy daemon
 + /usr/sbin/th-cmd --socket $THD_SOCKET --add $DEVICE
 + ;;
 +remove)
 + # nothing to do
 + ;;
 +esac
 diff --git a/utils/triggerhappy/files/triggerhappy.init 
 b/utils/triggerhappy/files/triggerhappy.init
 new file mode 100644
 index 000..e846d29
 --- /dev/null
 +++ b/utils/triggerhappy/files/triggerhappy.init
 @@ -0,0 +1,10 @@
 +#!/bin/sh /etc/rc.common
 +START=93
 +
 +start() {
 + /usr/sbin/thd --socket /tmp/triggerhappy.socket --triggers 
 /etc/triggerhappy/triggers.d/ --daemon /dev/input/event*
 +}
 +
 +stop() {
 + /usr/sbin/th-cmd --socket /tmp/triggerhappy.socket --quit
 +}



-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me 

Re: [OpenWrt-Devel] [PATCH] silence error when package has no patches

2010-10-12 Thread Mirko Vogt
Hey Alan,

I don't think this is an good idea - not because of this particular
change but that kind changes in general.

I'd like to keep our repository _as close as possible_ to the official
openwrt backfire branch upstream.

Your patch is a cosmetic change - nothing critical, nothing which
changes actual functionality.

From my point of view - and yes, I'm not just willing, I _like_ to
discuss that - there's no need to diverge from upstream with that kind
of changes.

So - still just from my point of view - there are two ways how to handle
these kind of changes:

1) Get it upstream, e.g. sending it to the openwrt-devel mailing list or
creating a ticket (http://dev.openwrt.org/) and mark it as feature
request
2) Just do not commit that kind of changes

Discussion is open :)

Cheers

mirko





On Fri, 2010-10-08 at 22:45 -0600, Alan Post wrote:
 My name is Alan Post.  I'm a developer for the NanoNote, which uses
 OpenWrt.
 
 I've ported a package that does not need any patches, so I excluded
 the patches directory.  This resulted in an error from ls during
 make:
 
   ls: cannot access ./patches: No such file or directory
 
 Here is the url to my commit at qi-hardware:
 
   
 http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/commit/d340b5b5332e0c07b53c46040a11b28fc982bafc/
 
 And here is the patch inlined:
 
 ++ nopatches.diff
 diff --git a/include/quilt.mk b/include/quilt.mk
 index 598c6f8..6c4839b 100644
 --- a/include/quilt.mk
 +++ b/include/quilt.mk
 @@ -39,7 +39,7 @@ define PatchDir/Quilt
  endef
  
  define PatchDir/Default
 - @if [ -d $(2) -a (ls $(2) 2/dev/null | wc -l) -gt 0 ]; then \
 + @if [ -d $(2) -a (ls $(2) | wc -l) -gt 0 ]; then \
   if [ -s $(2)/series ]; then \
   $(call filter_series,$(2)/series) | xargs -n1 \
   $(PATCH) $(1) $(2); \
 --
 
 -Alan



-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Question about package dependencies

2010-10-10 Thread Mirko Vogt
On Thu, 2010-10-07 at 08:05 -0600, Alan Post wrote:
 This is very useful, thank you mirko.
 
 Should I include depends on things like libc?  I notice there is a
 variable called PKG_BUILD_DEPENDS.  I've seen it used for host-side
 compilation of the same package.  A package I'm working on also
 needs bison and flex and build-time dependencies.  Is it appropriate
 to put those in PKG_BUILD_DEPENDS?

As long as these are not dependencies while running, PKG_BUILD_DEPENDS
is appropriate.

DEPENDS = X # depends on X while building/compiling and running
PKG_BUILD_DEPENDS = X # depends on X while building/compiling

The latter one is mostly used when host tools are only needed while
compiling, which are compiled/built and referenced by other
(host)packages.

mirko

 
 -Alan
 
 On Thu, Oct 07, 2010 at 03:56:20PM +0200, Mirko Vogt wrote:
  Hey Alan,
  
  let's imagine we have a Makefile/port/package called foo, and the
  following within the respective Makefile:
  
  DEPENDS:=bar # package foo will be only selectable, if bar is
  selected
  
  DEPENDS:=+bar # foo will be always selectable and - if selected - is
  going to select bar automatically as dependency
  
  Greetings
  
  mirko
  
  
  On Mon, 2010-10-04 at 15:05 -0600, Alan Post wrote:
   coi ro do,
   
   Last month I purchased a Ben NanoNote and began working on porting
   packages and understanding how OpenWrt works.
   
   I have commit access to qi-hardware's repository, but this
   repository mostly serves to track OpenWrt's backfire and trunk
   branches.
   
   I have a question about packages and dependencies in OpenWrt, based
   on what I have observed.
   
   I see that a package may list what it depends on.  I don't think
   this dependency is checked if you enable a package in make
   menuconfig.  If you enable a package but don't enable the
   dependencies, the package will be skipped.
   
   Is this true?  I still feel like I'm getting myself oriented in
   using OpenWrt, so please excuse what may be a basic question.=20
   
   Thank you,
   
   -Alan
  
  
  
  -- 
  This email address is used for mailinglist purposes only.
  Non-mailinglist emails will be dropped automatically.
  If you want to get in contact with me personally, please mail to:
  mirko.vogt at nanl dot de
  
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 



-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Question about package dependencies

2010-10-07 Thread Mirko Vogt
Hey Alan,

let's imagine we have a Makefile/port/package called foo, and the
following within the respective Makefile:

DEPENDS:=bar # package foo will be only selectable, if bar is
selected

DEPENDS:=+bar # foo will be always selectable and - if selected - is
going to select bar automatically as dependency

Greetings

mirko


On Mon, 2010-10-04 at 15:05 -0600, Alan Post wrote:
 coi ro do,
 
 Last month I purchased a Ben NanoNote and began working on porting
 packages and understanding how OpenWrt works.
 
 I have commit access to qi-hardware's repository, but this
 repository mostly serves to track OpenWrt's backfire and trunk
 branches.
 
 I have a question about packages and dependencies in OpenWrt, based
 on what I have observed.
 
 I see that a package may list what it depends on.  I don't think
 this dependency is checked if you enable a package in make
 menuconfig.  If you enable a package but don't enable the
 dependencies, the package will be skipped.
 
 Is this true?  I still feel like I'm getting myself oriented in
 using OpenWrt, so please excuse what may be a basic question.=20
 
 Thank you,
 
 -Alan



-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Some (possibly dumb) questions concerning OpenWRT build system

2010-05-19 Thread Mirko Vogt
On Mon, 2010-05-17 at 00:10 +0400, Alexey Loukianov wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Good day.

alike

 
 I've been using OpenWRT build system for making specialized firmwares for
 various D-Link routers for about a year. The need to build up a fresh firmware
 arises from time to time so it is common for me to get into a situation when
 checked out local working copy lags several months behind trunk's HEAD.
 
 Common problem that usually arises in process of bumping working copy to the
 current HEAD is the task of keeping .config file up with the introduced 
 changes.
 Somewhere in the past I've been told by somebody on the dd-wrt forums that the
 correct procedure of upgrading config file to the newer SVN revision is to 
 use
 the sequence like this:
 
 # make clean
 # svn update
 # make oldconfig
 
 Is this the right way? How to cope with updates to the packages from OpenWRT
 feeds? OpenWRT is ever-changing project, and it is perfectly normal to switch
 kernel versions on a regular basis. Will the config file updated using make
 oldconfig automatically follow the changes in the default versions of the
 kernel/gcc/uClibc for the selected target platform?

make oldconfig drops out obsolete parameters and will ask you how to
handle new ones (n/y/m).
kernel-parameters are not part of the file - the equivalent call would
be make kernel_oldconfig (saved in target/linux/*/config-*).

 
 Second thing that seems unclear to me is the feeds management system.
 make package/symlinks approach was told to be obsolete on a some page in the
 new wiki, and it is now recommended to use the feeds script instead.
 
 As far as my understanding is correct this script basically does three sorts 
 of
 things:
 1. svn checkout/update for the feeds defined in feeds.conf when called with
 update as the second argument. This operation does not create/update any of
 the symlinks in the packages/feeds/*.
 2. List the packages in the checked out revision of the feed or search checked
 out feeds for a specified package (list/search as second argument).
 3. Create/remove symlinks in packages/feeds/* when called with 
 install/uninstall
 as the second argument.
 
 Thus, to correctly update and install all packages in all feeds the command
 sequence might look like this:
 
 # ./scripts/feeds uninstall -a
 # ./scripts/feeds update -a
 # ./scripts/feeds install -a
 
 Am I right? Is it required to do make oldconfig afterwards?

That's the way. This will update the feeds from the corresponding
repositories listed in feeds.conf / feeds.conf.default respectively.

As said before, make oldconfig will now drop obsolete entries and ask
you what to do with new ones (=new packages).

 
 Third question is concerning the possibility of the so-called parallel 
 build.
 Accordingly to the recent SVN logs, there were some commits that fix a number 
 of
 issues related to the parallel build. Most notably, one of the log entries
 instructs user to modify 21st line of the include/host-build.mk to look like
 override MAKEFLAGS=$(MAKE_JOBS) in order to enable parallel build for the
 target toolchain. Does it mean that it is safe now to use something like make
 - -j6 on milticore CPU host in order to gain huge speedups of the build 
 process?
 Will it work normally when used in conjunction with the host CCACHE?

It _should_ work, however I still experience raise-conditions because of
e.g. missing/wrong dependencies.
For production use I do not recommend parallel builds, as binaries _may_
differ.

 
 Another rumor that I've been told by some man on the forums was that the 
 correct
 way to made OpenWRT build proceed with a parallel build is to head on to the
 Advanced development options in the menuconfig and specify the desired 
 number
 of the make jobs there (instead of using make -jN). As far as I can see,
 there's no appropriate option for specifying make job count in that submenu
 today. Was the advice wrong or am I missing something?

Just use make -jX, however be aware that OpenWrt will not pass this
option to the corresponding builds of single packages. It will just
parallelize the build of multiple openwrt-packages, not building a
single package itself.

 
 Thanks in advance for the answers.

You're welcome

mirko

 
 - -- 
 Best regards,
 Alexey Loukianov  mailto:mooro...@mail.ru
 System Engineer,Mob.:+7(926)218-1320
 *nix Specialist
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQEVAwUBS/BROfB9BOdTkBULAQIM+QgAneY8fHcAiFvrYISVpKtVRI7yJp+pILQj
 1Fq2NPGrFwmgeYS6ZCWkTL/LbIEhVr4w5rNdfJ0SkayUMDPCoZT6Zgk+kC/A1IqJ
 0AWq4pK8Iyekt029s48MsQFUr6dKQX0r0ceq7Wk2/dMfI7X3I7EoyDkuhm6bmuse
 vN2XevSLdVFd5eIq+fEyd5eOgTJvzYc4UyLDLuOYDBI2aQFmt2aiYGYw85xqSh2p
 v/eJMdx2j/euQTjaRe6qbU4rgc0UE+iHe3GkCXjUyFHrgnArL6dzjsy2yYzXDql7
 KS+Rged9uoIJKKRc/D26mUq1KwEB03b6lMYiyBCpbulHWPxo6ceqZw==
 =6jlY
 -END PGP 

Re: [OpenWrt-Devel] Some (possibly dumb) questions concerning OpenWRT build system

2010-05-19 Thread Mirko Vogt
On Wed, 2010-05-19 at 19:25 +0400, Alexey Loukianov wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 19.05.2010 19:13, Mirko Vogt wrote:
  make oldconfig drops out obsolete parameters and will ask you how to
  handle new ones (n/y/m).
  kernel-parameters are not part of the file - the equivalent call would
  be make kernel_oldconfig (saved in target/linux/*/config-*).
  
 Thank you for valuable comments.
 As for make kernel_oldconfig - is it required in case I hadn't ever used
 make kernel_menuconfig before? I was pretty sure that the openwrt build 
 system
 uses default kernel configs for the target platform in case there were no user
 customizations to the kernel configuration (i.e. there were no calls to make
 kernel_menuconfig).

Usually - if you accept the kernel-config(s) OpenWrt provides - this is
not necessary.
The kernel configs for the supported targets are getting adjusted and
maintained by us so you don't have to care about.

mirko

 
 - -- 
 Best regards,
 Alexey Loukianov  mailto:mooro...@mail.ru
 System Engineer,Mob.:+7(926)218-1320
 *nix Specialist
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQEVAwUBS/QC3/B9BOdTkBULAQI9aAgAuM3XSpVDkgYL1KmGrWRGohP3wCfdnEnD
 2/OOmhybtAzJdTq4O2HjXqZyigYLQvHKwlDjNlNhlYkuCyyBKIXMuhFqScbIvZXK
 zuXdIYd7rQh53ZwQ5oXdmEFSkKG+ivE1tt7zrUp/l/eADkNS94uoQ90UAV2/He9w
 YFCvWhEFK1pUsYlhVrcrimVQCdV5FBPUx2ZaurNGzUYPKUwNnmcfIDRCjXAcJKoS
 FR/E9Qo+SE3MOiBIIIeWNgM+zy+IIUzvhkvvLnOOHIKj4PrBK2DE2Ggnm/6Av96K
 e7JmkU6NSN2XuCYkpkbT0oAgBBb831aDPI7oZEDRKEAKXlj7UFhCcg==
 =rHKK
 -END PGP SIGNATURE-
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] How to create an OpenWrt Package Makefile for source without a Makefile

2010-05-02 Thread Mirko Vogt
Hey,

as the Build/Compile template assumes that the source provides a
Makefile, you should override the whole section and should not call
Build/Compile/Default.

You may want to take a look at the Makefile of schedtools
(packages/utils/schedtools/Makefile).

Have a nice sunday

mirko


On Sun, 2010-05-02 at 13:54 +0200, Matthias Buecher / Germany wrote:
 Tried to create an OpenWrt of a small VoIP proxy for a friend.
 Unfortunately the source itself does not have a Makefile.
 It just says Use: gcc -o mjproxy md5.c mjproxy.c.
 
 How must the Build/Compile section look like for such a case?
 Looked at wiki and forum, but couldn't find any fitting information.
 If I missed a link then please tell me.
 Thanks in advance.
 
 Following is the current result of the OpenWrt Package Makefile.
 
 [packages]
 net/magicjack-proxy/Makefile
 #
 # Copyright (C) 2010 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
 #
 
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=magicjack-proxy
 PKG_VERSION:=1
 PKG_RELEASE:=1
 
 PKG_SOURCE:=mjproxy.c.tar.gz
 PKG_SOURCE_URL:=http://www.mediafire.com/file/yzwmjzotmyy
 PKG_MD5SUM:=01262075cc72ad804f1d6b5dc181113b
 
 PKG_INSTALL:=1
 
 include $(INCLUDE_DIR)/package.mk
 
 define Package/magicjack-proxy
   SECTION:=net
   CATEGORY:=Network
   TITLE:=MagicJack Proxy
   URL:=http://www.magicjacksupport.com/post42750.html#42750
 # DEPENDS:=
 endef
 
 define Package/magicjack-proxy/description
   Proxy for MagicJack (VoIP service provider, http://www.magicjack.com/)
 endef
 
 #define Package/magicjack-proxy/conffiles
 #endef
 
 define Build/Compile
 #No Makefile available
 #gcc -o mjproxy md5.c mjproxy.c
 #ToDo: How to do it the right OpenWrt way?
 #???  $(call Build/Compile/Default)
   $(MAKE) -C $(PKG_BUILD_DIR) \
   $(TARGET_CONFIGURE_OPTS) \
   CFLAGS=$(TARGET_CFLAGS) \
   USELIBWRAP= \
   all
 endef
 
 define Package/magicjack-proxy/install
   $(INSTALL_DIR) $(1)/usr/bin
   $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/mjproxy $(1)/usr/bin/
 endef
 
 $(eval $(call BuildPackage,magicjack-proxy))
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] First boot script name ?

2009-11-23 Thread Mirko Vogt
Hey,

here's an example shell script which is setting a uci autostart-value
within the desktop-table:
https://dev.openwrt.org/browser/feeds/efl/enlightenment/files/uci-defaults/x11_standard
The files are autodeleted once they were executed.

mirko


On Mon, 2009-11-23 at 11:19 +0100, Jo-Philipp Wich wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi.
 
 I believe you mean the uci-defaults mechanism, put the script in
 /etc/uci-defaults/some-name and do the required uci stuff. It will be
 evaluated once at firstboot and removed afterwards.
 
 ~ JoW
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAksKYY4ACgkQdputYINPTPNQdACdGLxvIIYo/pfO0l1jnOV5TjWE
 4kUAnRhplU05DIkt2t9sKT4OYRWiWMJz
 =FHP5
 -END PGP SIGNATURE-
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] seems typo in [package/base-files/files/etc/hosts] file

2009-10-16 Thread Mirko Vogt
According commit log this was done by purpose:

Revision 6292: Change localhost into a fully qualified name[..]

However this change causes applications/libraries to fail which try to
resolve localhost which is used quite often.

mirko


On Fri, 2009-10-16 at 11:11 +0800, Xiangfu Liu wrote:
 Hi list
 
 seems there is a type in package/base-files/files/etc/hosts file
 there are a . after localhost
 
 
 
 diff --git a/package/base-files/files/etc/hosts 
 b/package/base-files/files/etc/hosts
 index 8d9d14f..75721cd 100644
 --- a/package/base-files/files/etc/hosts
 +++ b/package/base-files/files/etc/hosts
 @@ -1 +1 @@
 -127.0.0.1 localhost.
 +127.0.0.1 localhost
 
 
 




-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] KVM images for OpenWRT?

2009-08-10 Thread Mirko Vogt
On Mon, 2009-08-10 at 18:38 +0200, Benjamin Henrion wrote:
 Hi,
 
 Are there any images ready to download I could use to boot an OpenWRT on a 
 KVM?
Yep - the default x86-images are - for kamikaze 8.09.1:
http://downloads.openwrt.org/kamikaze/8.09.1/x86/openwrt-x86-ext2.image

$ kvm openwrt-x86-ext2.image
should work.
 
 Best,
Greets
mirko
 
 --
 Benjamin Henrion bhenrion at ffii.org
 FFII Brussels - +32-484-566109 - +32-2-4148403
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Stop at Please be patient, while OpenWrt loads

2009-07-27 Thread Mirko Vogt
Please be patient, while OpenWrt loads ... is the last message shown
by the kernel.
That indicates, the userspace isn't working / entered at this state, but
mounted successfully.

Mostly that is one of the following cases:
 - wrong binary format
 - /etc/preinit isn't executed by default (the bootloader _must not_
override the init= argument to the kernel)

mirko (the other one)

On Mon, 2009-07-27 at 11:12 +0800, Xiangfu Liu wrote:
 Hi there
 I work on a jz4740 cpu device. there[1] is all the code.
 your can find the kernel patch at [2]
 
 the .24 kernel is work, but the .28 boot to Please be patient, while OpenWrt 
 loads
 then stop. I put rootfs in mmcblk0p1 with ext2.
 
 I use tar jxvf openwrt-xburst-rootfs.tgz[3] /media/MMCBLK0P1 to cp the 
 rootfs to sd card.
 
 is there something wrong with rootfs?
 
 thanks for help.
 
 
 [1] http://github.com/lindnermarek/openwrt-x-burst/commits/x-burst
 [2] 
 http://github.com/lindnermarek/openwrt-x-burst/tree/76e7e9d1590d2f1a742c5dc96420e22bc4e5d234/target/linux/xburst
 [3] 
 http://www.openmobilefree.net/other/file/Ben_NanoNote/openwrt-xburst-rootfs.tgz
 plain text document attachment (error.message.txt)
 NAND Secondary Program Loader 
   
  
   
   
   
 U-Boot 2009.06-dirty (Jul 26 2009 - 16:40:30) 
   
   
   
 Board: Qi LB60 (Ingenic XBurst Jz4740 SoC, Speed 252 MHz) 
   
 DRAM:  32 MB  
   
 NAND:  2048 MiB   
   
 Linux version 2.6.28.10-ge8db213 (xian...@openmobilefree.net) (gcc version 
 4.1.9
 CPU revision is: 0ad0024f (Ingenic JZRISC)
   
 CPU clock: 252MHz, System clock: 84MHz, Peripheral clock: 84MHz, Memory 
 clock: z
 Qi Hardware JZ4740 QI_LB60 setup  
   
 Determined physical RAM map:  
   
  memory: 0400 @  (usable) 
   
 User-defined physical RAM map:
   
  memory: 0200 @  (usable) 
   
 Zone PFN ranges:  
   
   Normal   0x - 0x2000   
   
 Movable zone start PFN for each node  
   
 early_node_map[1] active PFN ranges   
   
 0: 0x - 0x2000   
   
 Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 8128
   
 Kernel command line: mem=32M console=ttyS0,57600n8 rootfstype=ext2 
 root=/dev/mm2
 Primary instruction cache 16kB, VIPT, 4-way, linesize 32 bytes.   
   
 Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 32 bytes   
   
 PID hash table entries: 128 (order: 7, 512 bytes) 
   
 [ cut here ]  
   
 WARNING: at kernel/time/clockevents.c:175 ()  
   
 Modules linked in:
   
 Call Trace:[80024890] 0x80024890
   
 [80024890] 0x80024890   
   
 [80041188] 0x80041188   
   
 [803df198] 0x803df198   
   
 [80041810] 0x80041810   
   
 [803debd8] 0x803debd8   
   
 [803f2e14] 0x803f2e14   
   
 [803f12c8] 0x803f12c8   
   
 [803ded54] 0x803ded54   
   
 [80067640] 0x80067640   
   
 [80069f28] 0x80069f28   
   
 [80068764] 0x80068764   
   
 [803d95d8] 0x803d95d8   
   
 [803d5938] 0x803d5938   
   
 [803d50d8] 0x803d50d8   
   
   
   
 ---[ end trace 4eaa2a86a8e2da22 ]---  
   

Re: [OpenWrt-Devel] correct place for target-dependent host tools

2009-07-25 Thread Mirko Vogt
Why - btw - do you want to have the xburst-tools packaged in OpenWrt?

Looking at the Openmoko Neo - OpenWrt target, there's also no
dfu-util packaged (ok, there is - but because some people wanted use
their routers to flash their Openmoko Neo - it's not compiled for the
host system).

The way I see it (maybe it's only me :)), these are two different
things:

OpenWrt is for...
...building software for the target (including host tools which are
needed to get other software compiled for the target), which finally
results in a target-spedific (bootloader/)kernel/rootfs

OpenWrt is not for...
...building software for the host which is then not used by OpenWrt but
used manually (e.g. usbboot of xburst-tools to flash the device).

But maybe this general question was already raised / answered - I'm not
sure how this is handled for other targets which need to be
flashed/programmed in a special way.

Greets,

mirko

On Sat, 2009-07-25 at 11:33 +0200, Mirko Vogt wrote:
 Hey Wolfgang,
 
 On Sat, 2009-07-25 at 14:01 +0800, Wolfgang Spraul wrote:
  Hi,
  I am working on adding support for our upcoming 'XBurst' board into
  OpenWrt [1]. Sources are here [2].
  
  In addition to all the stuff that targets the device, I have a reflashing 
  tool
  running on the host. This tool can boot the device over USB and reflash it.
  It's called 'usbboot' and part of a package called 'xburst-tools' (the CPU
  is an XBurst (MIPS-compatible) CPU).
  Sources for that package are here [3].
  
  Now, in the OpenWrt there is a directory 'tools' at the root level. Should I
  create a subfolder (+Makefile etc) for xburst-tools inside there?
  However, the tool depends on my target.
  Is the 'tools' directory only for target-independent host tools?
 
 The tools/-directory contains OpenWrt-Makefiles for essential tools
 which are needed on the host system to get an OpenWrt build done, so -
 yes - they're target-independent.
 In my view tools/ would not be the appropriate location to store the
 xburst tools.
 
 This could be either done within the target-directory (as it is done for
 e.g. u-boot) or the usual way of building specific host-tools in
 OpenWrt (like it's done for e.g. bjam).
 The latter way is usually used for building host-tools that are needed
 by other packages as dependencies (e.g. bjam is needed as host-tool
 for getting boost compiled) so it's just used within the OpenWrt build
 process - however the host-tools remains in staging_dir/host/bin/ and
 can still be used afterwards.
 
  
  Another possible place would be in target/linux/xburst. But I see no host
  tools in any of the other targets, so I'm not sure it's a good place.
 Maybe xburst tools can be splitted in:
  - xburst-staging-binaries (compiled for the target)
  - usbboot (compiled for the host)
  
  Any help appreciated, thanks!
  Wolfgang
 mirko :)
  
  [1] http://www.qi-hardware.com/products/ben-nanonote/
  [2] http://github.com/lindnermarek/openwrt-x-burst
  [3] http://github.com/xiangfu/xburst-tools
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Trac on openwrt

2009-05-25 Thread Mirko Vogt

Henning Meyer wrote:

Hi All,

I'd like to get Trac running on openwrt. Unfortunatly Trac requires
easy_install, setuptools and Genshi
(http://trac.edgewall.org/wiki/TracInstall).

I think easy_install and setuptools are just needed for the build - not
needed for the running system.


You may take a look at the python-bindings for the 
enlightenment-foundation-libraries (e.g. python-ecore: 
https://dev.openwrt.org/browser/feeds/efl/python-ecore/patches/000-prevent-using-setuptools.patch).
Here it was possible to use distutils instead of setuptools and replace 
used setuptools-functions with static values.
Otherwise it shouldn't be too hard to also port setuptools; e.g. 
build-only utility (like it was done e.g. with bjam).




Can anybody give any hints how to start porting theses modules to
openwrt buildroot?

Thank you,

Henning

mirko


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] x86 image name confusion

2009-03-23 Thread Mirko Vogt
Jan Hetges wrote:
 Hi
 i'm confused by the new xyz.fs xyz.image xyz.image.kernel
fs = filesystem
kernel = kernel
image = kernel+filesystem
 is there any docs about what is what?
above
 
 thanks
 
   --Jan
 
 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] How to use library and header files in an other packages?

2009-03-13 Thread Mirko Vogt
mike xu wrote:
 Hi,
 
 I am trying to use libuci libraries and uci*.h header files in an
 other package, is there a way in openwrt to using them in another
 package without copying them into the other package?
 
 Thanks,
 Mike
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Hey,

header-files are usually not part of a package.
They are copied within the buildroot to a staging_dir.
All things which are going to be cross-compiled access this staging_dir
automatically (cflags: -I[..]/staging_dir/ARCH/usr/include ldflags:
-L[..]/staging_dir/ARCH/usr/lib) and use the header-files (libraries)
copied by previous e.g. libs.
The section which do so is called Build/InstallDev - take a look at
some Makefile's and you'll see :)

Greetz

mirko

-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] enlightenment RequireCommand

2008-12-29 Thread Mirko Vogt
Michael Buesch wrote:
 Why do we need the following RequireCommand in enlightenment?
 
 $(eval $(call RequireCommand,edje_cc, \
   Command edje_cc not found - please install edje with edje-cc enabled \
 ))
 $(eval $(call RequireCommand,eet, \
   Command eet not found - please install eet \
 ))
 
 As far as I understand, this checks for the two commands on the build host 
 system.
Yep.
 Why? Why don't we simply build the tools?
Because building native host tools isn't possible in a nice way yet.
 Don't we actually _do_ the build already?
No, building of edje_cc is disabled in the Makefile.
 I guess so, because the configure target redirects these commands to staging:
 
 define Build/Configure
   (cd $(PKG_BUILD_DIR); NOCONFIGURE=YES ./autogen.sh );
   $(call Build/Configure/Default, 
 --with-edje-cc=$(STAGING_DIR_HOST)/usr/bin/edje_cc  
 --with-eet-eet=$(STAGING_DIR_HOST)/usr/bin/eet)
 endef
That just refers to the host edje_cc. $(STAGING_DIR_HOST)/usr/bin/edje_cc is a 
symlink, same with eet.
 
mirko


-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] enlightenment RequireCommand

2008-12-29 Thread Mirko Vogt
Michael Buesch wrote:
 On Monday 29 December 2008 23:10:21 Mirko Vogt wrote:
 Michael Buesch wrote:
 Why do we need the following RequireCommand in enlightenment?

 $(eval $(call RequireCommand,edje_cc, \
 Command edje_cc not found - please install edje with edje-cc enabled \
 ))
 $(eval $(call RequireCommand,eet, \
 Command eet not found - please install eet \
 ))

 As far as I understand, this checks for the two commands on the build host 
 system.
 Yep.
 Why? Why don't we simply build the tools?
 Because building native host tools isn't possible in a nice way yet.
 Don't we actually _do_ the build already?
 No, building of edje_cc is disabled in the Makefile.
 
 Ok, which debian package do I need for edje_cc?
 I installed e16, but it still bails out.
 
 

I'm sorry - no common distribution provides actual e17-packages - you have to 
compile them on your own :/
I attached a crappy bash-script which might save you some time.
Also I talked with some other devs at the congress and I'll append the 
@BROKEN-flag to that packages,
until native-compiling isn't possible in a nice way *hint nbd hint*.

mirko

-- 
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt at nanl dot de


svn_co_e.sh
Description: Bourne shell script
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel