[OpenWrt-Devel] [PATCH] shellfm: libao support

2011-10-03 Thread christoph . gysin
From: Christoph Gysin christoph.gy...@gmail.com

- remove madplay dependency
- enable libao support (we already depend on it)
- disable external command in default configuration
- add symlink for .libao
   To configure libao, the library looks for a .libao configuration file in
   the users home directory.
   To allow configuring libao for shell-fm running as a daemon, we symlink
   /etc/libao.conf to the temporary HOME for shell-fm.

Signed-off-by: Christoph Gysin christoph.gy...@gmail.com
---
 sound/shell-fm/Makefile|4 ++--
 sound/shell-fm/files/shell-fm.init |1 +
 sound/shell-fm/files/shell-fm.rc   |2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/sound/shell-fm/Makefile b/sound/shell-fm/Makefile
index 8fea1a1..fea1127 100644
--- a/sound/shell-fm/Makefile
+++ b/sound/shell-fm/Makefile
@@ -23,7 +23,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/shell-fm
   SECTION:=sound
   CATEGORY:=Sound
-  DEPENDS:=+libao +madplay +libpthread
+  DEPENDS:=+libao +libpthread
   TITLE:=Console Based Last.FM Radio Player
   URL:=http://nex.scrapping.cc
 endef
@@ -43,7 +43,7 @@ endef
 define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR) \
$(TARGET_CONFIGURE_OPTS) \
-   CFLAGS=$(TARGET_CFLAGS) -I./include/ $(TARGET_CPPFLAGS) \
+   CFLAGS=$(TARGET_CFLAGS) -I./include/ -DLIBAO 
$(TARGET_CPPFLAGS) \
DESTDIR=$(PKG_INSTALL_DIR) \
LDFLAGS=$(TARGET_LDFLAGS) -lmad -lao -lpthread \
all install
diff --git a/sound/shell-fm/files/shell-fm.init 
b/sound/shell-fm/files/shell-fm.init
index 0e68d34..f0403b6 100644
--- a/sound/shell-fm/files/shell-fm.init
+++ b/sound/shell-fm/files/shell-fm.init
@@ -5,6 +5,7 @@ START=99
 start() {
[ -d /tmp/.shell-fm ] || mkdir /tmp/.shell-fm
[ -L /tmp/.shell-fm/shell-fm.rc ] || ln -s /etc/shell-fm.rc 
/tmp/.shell-fm/shell-fm.rc
+   [ -L /tmp/.libao ] || ln -s /etc/libao.conf /tmp/.libao
HOME=/tmp shell-fm -d
 }
 
diff --git a/sound/shell-fm/files/shell-fm.rc b/sound/shell-fm/files/shell-fm.rc
index 43ec7d2..b3f6a2d 100644
--- a/sound/shell-fm/files/shell-fm.rc
+++ b/sound/shell-fm/files/shell-fm.rc
@@ -6,4 +6,4 @@ t-color = 1;32  # light green track titles
 a-color = 0;32  # dark green track artist names
 s-color = 1;37  # white station names
 bind = 0.0.0.0
-extern = madplay -q -
+#extern = madplay -q -
-- 
1.7.6.4

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


Re: [OpenWrt-Devel] [PATCH 0/4] support for make xconfig

2011-10-03 Thread Florian Fainelli
Hello,

On Thursday 23 June 2011 10:42:31 Emmanuel Deloget wrote:
 This patchset brings back the support for the xconfig (and the
 corresponding kernel_xconfig) top-level targets. Since these targets
 depends on qt3 (and more precisely the development packages of qt3),
 some effort has been spent to avoid bringing this huge dependency in
 OpenWRT. If the build machine has the necessary development packages,
 then the user will be able to /make [kernel_]xconfig/. Otherwise,
 a message will be printed when the suer will try to execute these
 targets.
 
 Patch 1/4 to 3/4 in the series are necessary to add support for
 make xconfig. Patch 4/4 will add support for make kernel_xconfig only
 if Patch 3/4 has been applied (both patch are modifying the same file,
 and Patch 4/4 builds upon the tools that are added with Patch 3/4).
 
 The patches with svn diff on svn://svn.openwrt.org/openwrt/trunk.

I gave this a try, and here is what I get with only the 3 first patches 
applied:

florian@flexo:[~/../trunk]$ make xconfig V=99
make[1]: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config'
qconf.cc:26:21: fatal error: qconf.moc: No such file or directory
compilation terminated.
make[1]: *** [qconf.o] Error 1
make[1]: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config'
make: *** [scripts/config/qconf] Error 2
zsh: exit 2 make xconfig V=99

if I touch scripts/config/qconf.moc, the error is now:

make: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config'
g++ -I/usr/include/qt3 -DLKC_DIRECT_LINK   -c -o qconf.o qconf.cc
cc -lqt-mt  qconf.o zconf.tab.o kconfig_load.o   -o qconf
qconf.o: In function `ConfigList::ConfigList(ConfigView*, ConfigMainWindow*, 
ConfigSettings*)':
qconf.cc:(.text+0x15d8): undefined reference to `vtable for ConfigList'
qconf.cc:(.text+0x15e4): undefined reference to `vtable for ConfigList'
qconf.o: In function `ConfigList::updateSelection()':
qconf.cc:(.text+0x1d06): undefined reference to 
`ConfigList::menuSelected(menu*)'
qconf.o: In function `ConfigList::keyPressEvent(QKeyEvent*)':
qconf.cc:(.text+0x24dc): undefined reference to `ConfigList::parentSelected()'
qconf.cc:(.text+0x257d): undefined reference to `ConfigList::parentSelected()'
qconf.cc:(.text+0x2603): undefined reference to 
`ConfigList::menuSelected(menu*)'
qconf.o: In function `ConfigList::contentsMouseReleaseEvent(QMouseEvent*)':
qconf.cc:(.text+0x2861): undefined reference to `ConfigList::parentSelected()'
qconf.cc:(.text+0x28db): undefined reference to 
`ConfigList::menuSelected(menu*)'
qconf.o: In function `ConfigList::contentsMouseDoubleClickEvent(QMouseEvent*)':
qconf.cc:(.text+0x2a12): undefined reference to `ConfigList::parentSelected()'
qconf.cc:(.text+0x2a82): undefined reference to 
`ConfigList::menuSelected(menu*)'
qconf.o: In function `ConfigList::focusInEvent(QFocusEvent*)':
qconf.cc:(.text+0x2b2c): undefined reference to `ConfigList::gotFocus()'
qconf.o: In function `ConfigView::ConfigView(QWidget*, ConfigMainWindow*, 
ConfigSettings*)':
qconf.cc:(.text+0x2b72): undefined reference to `vtable for ConfigView'
qconf.cc:(.text+0x2b7e): undefined reference to `vtable for ConfigView'
qconf.o: In function `ConfigView::~ConfigView()':
qconf.cc:(.text+0x2c7b): undefined reference to `vtable for ConfigView'
qconf.cc:(.text+0x2c87): undefined reference to `vtable for ConfigView'
qconf.o: In function `ConfigMainWindow::ConfigMainWindow()':
qconf.cc:(.text+0x2e0d): undefined reference to `vtable for ConfigMainWindow'
qconf.cc:(.text+0x2e1c): undefined reference to `vtable for ConfigMainWindow'
qconf.o: In function `ConfigLineEdit::ConfigLineEdit(ConfigView*)':
qconf.cc:
(.text._ZN14ConfigLineEditC2EP10ConfigView[_ZN14ConfigLineEditC5EP10ConfigView]+0x2f):
 
undefined reference to `vtable for ConfigLineEdit'
qconf.cc:
(.text._ZN14ConfigLineEditC2EP10ConfigView[_ZN14ConfigLineEditC5EP10ConfigView]+0x3b):
 
undefined reference to `vtable for ConfigLineEdit'
collect2: ld returned 1 exit status
make: *** [qconf] Error 1
make: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config'
zsh: exit 2 make -C scripts/config qconf


 
 Best regards,
 
 -- Emmanuel Deloget
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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


Re: [OpenWrt-Devel] [PATCH 0/4] support for make xconfig

2011-10-03 Thread Emmanuel Deloget

Le 03/10/2011 15:32, Florian Fainelli a écrit :

Hello,


Hi Florian,

On Thursday 23 June 2011 10:42:31 Emmanuel Deloget wrote:

This patchset brings back the support for the xconfig (and the
corresponding kernel_xconfig) top-level targets. Since these targets
depends on qt3 (and more precisely the development packages of qt3),
some effort has been spent to avoid bringing this huge dependency in
OpenWRT. If the build machine has the necessary development packages,
then the user will be able to /make [kernel_]xconfig/. Otherwise,
a message will be printed when the suer will try to execute these
targets.

Patch 1/4 to 3/4 in the series are necessary to add support for
make xconfig. Patch 4/4 will add support for make kernel_xconfig only
if Patch 3/4 has been applied (both patch are modifying the same file,
and Patch 4/4 builds upon the tools that are added with Patch 3/4).

The patches with svn diff on svn://svn.openwrt.org/openwrt/trunk.

I gave this a try, and here is what I get with only the 3 first patches
applied:

florian@flexo:[~/../trunk]$ make xconfig V=99
make[1]: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config'
qconf.cc:26:21: fatal error: qconf.moc: No such file or directory
compilation terminated.
make[1]: *** [qconf.o] Error 1
make[1]: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config'
make: *** [scripts/config/qconf] Error 2
zsh: exit 2 make xconfig V=99
I have to check this again. I believe I remember I had some kind of 
error like this one, but unfortunately, times has passed and my memory's 
blurred.


I will post an update soon.

Anyway, thanks for trying !

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


Re: [OpenWrt-Devel] [PATCH 0/4] support for make xconfig

2011-10-03 Thread Emmanuel Deloget

Le 03/10/2011 15:32, Florian Fainelli a écrit :

Hello,

On Thursday 23 June 2011 10:42:31 Emmanuel Deloget wrote:

snip
Patch 1/4 to 3/4 in the series are necessary to add support for
make xconfig. Patch 4/4 will add support for make kernel_xconfig only
if Patch 3/4 has been applied (both patch are modifying the same file,
and Patch 4/4 builds upon the tools that are added with Patch 3/4).

The patches with svn diff on svn://svn.openwrt.org/openwrt/trunk.

I gave this a try, and here is what I get with only the 3 first patches
applied:

florian@flexo:[~/../trunk]$ make xconfig V=99
make[1]: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config'
qconf.cc:26:21: fatal error: qconf.moc: No such file or directory
compilation terminated.
make[1]: *** [qconf.o] Error 1
make[1]: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config'
make: *** [scripts/config/qconf] Error 2
zsh: exit 2 make xconfig V=99
It seems the culprit for this error (not counting the obvious one: me) 
is a missing line in patch 2/4. Can you test this one as a replacement 
for the faulty patch before I resubmit the whole series ?


Thanks in advance,

--
Emmanuel Deloget
Index: scripts/config/Makefile
===
--- scripts/config/Makefile	(révision 28361)
+++ scripts/config/Makefile	(copie de travail)
@@ -7,6 +7,8 @@
 # conf:	  Used for defconfig, oldconfig and related targets
 # mconf:  Used for the mconfig target.
 # Utilizes the lxdialog package
+# qconf:  Used for the xconfig target. 
+# Utilizes the Qt3-dev package
 # object files used by all kconfig flavours
 
 
@@ -17,10 +19,13 @@
 
 conf-objs	:= conf.o zconf.tab.o
 mconf-objs	:= mconf.o zconf.tab.o
+qconf-objs	:= qconf.o zconf.tab.o kconfig_load.o 
 
 clean-files	:= lkc_defs.h qconf.moc .tmp_qtcheck \
 		   .tmp_gtkcheck zconf.tab.c lex.zconf.c zconf.hash.c
 
+have-qt3-dev:=$(shell [ -d /usr/include/qt3 ]  echo y)
+
 all: conf mconf lxdialog/lxdialog
 
 lxdialog/lxdialog:
@@ -30,14 +35,24 @@
 mconf: $(mconf-objs) 
 
 clean:
-	rm -f *.o $(clean-files) conf mconf
+	rm -f *.o $(clean-files) conf mconf qconf
 	$(MAKE) -C lxdialog clean
 
 zconf.tab.o: lex.zconf.c zconf.hash.c confdata.c
 
 kconfig_load.o: lkc_defs.h
 
-lkc_defs.h: $(src)/lkc_proto.h
+ifneq ($(have-qt3-dev),)
+all: qconf
+qconf: $(qconf-objs)
+qconf: LDFLAGS+=-lqt-mt
+qconf.o: qconf.moc
+qconf.o: CXXFLAGS+=-I/usr/include/qt3 -DLKC_DIRECT_LINK
+qconf.moc: qconf.h
+	cp $@_shipped $@
+endif
+
+lkc_defs.h: lkc_proto.h
 	sed  $  $@ 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/'
 
 zconf.tab.c: zconf.y

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


[OpenWrt-Devel] Introducing me

2011-10-03 Thread David Newall

Hello.

I'm new to this list.  I've been looking at IPv6 modems for a few 
months; found OpenWRT pretty quickly and liked it more than the 
alternatives.  Fine job you all are doing.


I'm using a DG834 (rev 1) and it works rather nicely, even if ADSL 
throughput seems low.  I had no problem getting it loaded, and with 
backups of the original flash partitions it seemed a safe exercise. 
Stupidly, I configured PPP on the LAN interface, which was awkward.  I 
hadn't even cracked the modem's case, let alone got serial converter or 
JTAG cable.  (I've got both, now.)  Enter boot loader's FTP server. 
Strangely, just reloading mtd2 (linux partition) made no difference, so 
I figured to restore the original firmware and start again.  Re-flashing 
the boot-loader's environment turned out to be an unwise decision: it 
hung and, on reboot, proved to have scrambled the environment, leaving 
only the first few-and-a-half entries: not enough for the boot-loader to 
load the OS.  Much fun ensued, including use of a digital scope from 
which I could read the boot-loader's startup messages, thus proving I 
had more than a brick.  One mystery is, by the time I learned what a 
serial level-converter is and why one might be needed, the RX line on 
the modem had blown.  Can't think how that happened.  Finally, I made a 
JTAG cable (an extended wiggler, at the astronomical cost of $2.15 for 
some resistors), reflashed the original firmware, and then reloaded 
OpenWRT and as aforesaid, it's been working very nicely ever since. 
Shame about the RX line; but at least it wasn't TX; losing that would 
be, well, a real loss.


I'm sure glad I spent those many, many hours on this modem (replacement 
cost $87) instead of chucking it away like any sensible person would.


Okay, you lot, enough gas-bagging: get back to work. Heh heh.

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


Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT

2011-10-03 Thread Luka Perkov
Hi,

On Fri, Sep 30, 2011 at 01:52:53PM +0200, Florian Fainelli wrote:
 On Monday 05 September 2011 18:44:39 Michael Büsch wrote:
  On Mon, 05 Sep 2011 18:11:43 +0200
  
  Felix Fietkau n...@openwrt.org wrote:
I am still wondering how enabling preempt could possibly
workaround/hide an alignment bug. sounds strange to me. Does somebody
have an idea?

I didn't look too closely at the function yet, though.
   
   Look at BadVA : 6fbb600f - it's not an alignment bug, the address is
   completely bogus. It just happens to trip on the unhandled unaligned
   access first because of the lowest bits.
   This looks like a nasty memory corruption bug, and hiding it with
   CONFIG_PREEMPT probably eventually makes it show up somewhere else
   instead.
  
  Ok, that makes sense.
  
  So instead of enabling preempt, it would be a way better idea to enable
  various kernel memory debugging options (probably also lockdep) to track
  this down.
 
 It looks like this thread stalled here. Luka, have you been able to run a 
 kernel with lockdep enabled to see what is going one here?

I'll try to do it this week, I'll also send mail to netdev as you
suggested...

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