Re: RFC pkgs.staging.openwrt.org

[Ted Hess]

Hi Paul -

Best idea yet! Go for it.

/ted


On 1/5/2024 11:14:53 AM, "Paul Spooren"  wrote:


Hey all,

tl;dr checkout https://pkgs.staging.openwrt.org/

As some may experienced, openwrt.org is slow an one (of many reasons) is that 
it stores and renders tables with all packages.

Based on feedback the experience is neither convincing nor does it perform well 
within a DokuWiki.

After asking our fellow friends from Alpine Linux[1] respectively 
postmarketOS[2] I got an okay to fork and deploy the tool `apkbrowser`, which 
is now `pkgbrowser`[3] since it currently handles OPKG packages.

I’ll refactor and commit the update-script later, essentially it polls our 
buildbots and whenever a build is completed, the database is updated. For that 
reason some packages are still missing. With more time missing packages/archs 
are added.

The tool nor server are tested under load but I fell quite positive it’s more 
fun than our wiki implementation.

If this turns out to fly, I’ll link it in the wiki, move it to pkgs.openwrt.org 
and remove all package functionality from the wiki.

Thanks to Carlo Landmeter et al for implementing such a handy and adoptable 
tool!

Best,
Paul

[1]: http://pkgs.alpinelinux.org
[2]: https://pkgs.postmarketos.org/packages
[3]: https://github.com/aparcar/pkgbrowser




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

Re: Maintenance of openwrt.org and CDN for downloads

[Ted Hess]

Paul -

Thanks for this -- good show!
What do you have planned next for the wiki?

/ted

On 12/13/2023 11:10:20 AM, "Paul Spooren"  wrote:


Dear all,

I plan to upgrade our wiki (openwrt.org ) next Sunday, 
17th of December. I’m expecting just a short downtime since a successful upgrade 
already happened on a staging instance. In case you urgently need to lookup 
information, please use the staging instance during the maintenance[1].

On Tuesday, 19th of December I’m planing a DNS switch to use our sponsored CDN 
for our downloads, which affects both firmware and package downloads. I’m not 
expecting any downtime since the CDN already works for a staging domain[2]. If 
things break, please use on of the many mirrors[3] in the meantime.

Thanks again to fastly.com for their CDN sponsoring, which is already 
extensively used as a fallback for our external sources hosting[4].

Sunshine,
Paul

[1]: https://wiki.staging.openwrt.org/
[2]: https://downloads.cdn.openwrt.org/
[3]: https://openwrt.org/downloads?s%5B%5D=mirror#mirrors
[4]: https://sources.cdn.openwrt.org/


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



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

Re: Job board support on openwrt.org?

[Ted Hess]

On 1/23/2021 11:06:53 AM, "Petr Štetiar"  wrote:


Ted Hess  [2021-01-23 14:55:05]:

Hi,


 we don't want to be in the business of certifying contractors.


exactly.


 If we get complaints


Do we want new source for a potential bad press?


 their reference gets reviewed and most likely removed.


You can't review business cases as patches, this is quite different territory.



Point taken
/ted


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

Re: Job board support on openwrt.org?

[Ted Hess]

On 1/23/2021 1:25:31 AM, "Alberto Bursi"  
wrote:





On 22/01/21 20:03, Daniel Golle wrote:

Hi Philip,

On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:

Hi,

Is anyone interested in adding a page to the openwrt.org site about developers 
willing to do commercial work?

It could be as simple as:

* name
* email address
* mobile (if wanted)
* packages/platforms/architectures you maintain or have competence in
* whether you're available full-time, part-time, or currently unavailable

Might be useful for matching up devs with work.


While I like the idea and would probably benefit from it myself, I'm
a bit sceptical when it comes to making OpenWrt.org an institution
certifying developers. Too much trouble was caused over having
'@openwrt.org' addresses and I doubt we are able to handle the
moderation needs (think: classic fraud, fishing, ...) of such a thing
if it is even a wiki, ie. free to edit for all.


the site/wiki has user-restricted pages already (the front page, the releases 
page and personal developer pages I think, probably more) because otherwise it 
would be a field day for spambots.
So this would not be a "free to edit for all", and more of a "ask a wiki admin to 
add your data to the page".
I and Tmomas won't be able to do a through vetting process on anybody, but we 
are more than enough to stop basic spammers and such, and can also respond to 
complaints and remove somebody in case issues arise later.
I'm also thinking about having some rules of thumb to limit access to people 
that have actually been involved in OpenWrt for a bit and can prove it (some 
relevant commits, some useful mail in the list, a core developer vouching for 
them, whatever).


I pretty much agree with Alberto here - It seems like a good idea. 
Additionally, there must be some sort of criteria (contributions, 
legitimate business site or references) to get your name/outfit listed. 
And, as Daniel said, we don't want to be in the business of certifying 
contractors. If we get complaints, their reference gets reviewed and 
most likely removed.


My 2 cents,
/ted


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

Re: [OpenWrt-Devel] Inquery

[Ted Hess]

On 11/12/2019 15:22, Daniel Golle wrote:

As a community, we decided to give our self a set of minimal rules[1].
And even though it is in the last position, rule #12 "Be nice to each
other." is meant just as serious as all the other rules.

So here, not for the first time, you are using language which has the
only purpose to hurt other people (for which reason ever, it doesn't
matter). This is therefore a very clear violation to the above
mentioned rule. You statement "suck it" (guess what) is also an obvious
and disgusting example of a masculist culture which hurts our community
as a whole and I strongly believe we should not tolerate that.

And yes this was a spam mail. And it's even needless to say that
replying to a spam email in which ever way will always make it worse.
But that's not the point here and I will not engage in any discussion
on that matter.

Please learn to behave or leave us alone.

[1]:https://openwrt.org/rules


+1



And, +1 from me - thanks.

/ted


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

Re: [OpenWrt-Devel] [RFC] additional Docker images and CI testing

[Ted Hess]

Hi Paul -

This sounds like a good idea - would giving you commit 
access to our
docker hub [0] repo be of any help? Is there anything else I 
could help with?


I don't know if you saw this posting I made last year about 
a simple
use of our Docker image for test buiilds. Issue #7735 [1]. I 
had pinned it

but for some reason @heil un-pinned it and I left it be.

/ted

[0]: https://hub.docker.com/u/openwrtorg
[1]: https://github.com/openwrt/packages/issues/7735


-Original Message- 
From: Paul Spooren

Sent: Saturday, June 01, 2019 10:26 AM
To: openwrt-devel@lists.openwrt.org
Cc: Etienne Champetier ; Ted Hess ; Rosen Penev
Subject: [OpenWrt-Devel] [RFC] additional Docker images and 
CI testing


Hi all,

currently OpenWrt only offers a very basic Docker image[0] 
for testing
of the packages.git repo. The image is not directly usable 
as the CI
does most of the work, like setting up the SDK and adding 
feeds[1]. I'd
like to propose two additional images and added CI test 
examples for

illustration, `openwrt` and `openwrt-sdk`

## openwrt:x86-64

Now that OpenWrt can run within Docker containers[2] (thanks 
@mikma,

@dangowrt and @ynezz) it's possible for local or CI tests:

* Running the image locally:

   docker run --rm -it aparcar/openwrt:x86-64

* Test example via CircleCI

Checks if procd starts basic services[3].

The container image is created via a config.yml similar to 
the one from

packages.git[4].

## openwrt-sdk:x86-64

The OpenWrt SDK in a Docker container, also usable for local 
building or CI:


* Using the SDK locally

   docker run --rm -v ./bin/:/sdk/bin -it 
aparcar/openwrt-sdk:x86-64

   # within the Docker container
   ./scripts/feeds update base
   make defconfig
   ./scripts/feeds install firewall
   make package/firewall/{clean,compile} -j$(nproc)

The compiled output is found in ./bin/

* Test example via CircleCI

Compiles firewall package[5].

The openwrt-sdk container image is also created via CI[6].

All examples are based on this[7] repo and the *interesting* 
branches are:


* openwrt
* openwrt-test
* openwrt-sdk
* openwrt-sdk-test

I'd be happy if OpenWrt offers OS, SDK and ImageBuilder 
container images
in the future. Currently only the x86/64 target is 
supported, however

it'd be easy to support all (popular) targets via tags.

Eventually we could use this to develop test cases for 
OpenWrt specific

tools like netifd, procd, ubus, firewall3, etc...

Best,
Paul

[0]: https://hub.docker.com/r/openwrtorg/packages-cci
[1]:
https://git.openwrt.org/?p=feed/packages.git;a=blob;f=.circleci/config.yml;h=02a87146d91f19638bfbfc1fbc46913256cf358d;hb=refs/heads/master
[2]:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6a92eb5b382860017fd00cd05350a648c4a4ac56
[3]: 
https://circleci.com/gh/aparcar/openwrt-ci-test/53#config/containers/0
[4]: 
https://circleci.com/gh/aparcar/openwrt-ci-test/41#config/containers/0
[5]: 
https://circleci.com/gh/aparcar/openwrt-ci-test/45#config/containers/0
[6]: 
https://circleci.com/gh/aparcar/openwrt-ci-test/46#config/containers/0

[7]: https://github.com/aparcar/openwrt-ci-test



___
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] bugs.openwrt.org

[Ted Hess]

I am in the process of moving our Flyspray system to a new host on DO. 
It is currently
hosted on our download server and occasionally gets bogged down due to 
download
activity. I plan on taking the site offline for about an hour to move 
the database
starting about 18:00 UTC/13:00 EST tomorrow (Feb 21). After the move, 
the new site
should be exactly the same as before the move - all data and accounts 
preserved.


I am not anticipating any problems that won't sort out in a day or 2 due 
to DNS
name changes and obtaining new SSL certs. The interim plan is to 
re-direct the
old site to the new using existing certs and after the DNS changes are 
settled, we
can re-provision the new site. Please report any problems reaching the 
new site,
SSO using Github or email issues here and I will handle them as time 
permits.


/ted


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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Ted Hess]

Etienne - AFAICT, I have enabled CircleCI on 10/25 for openwrt/packages repo. 
It looks like github is posting PRs to CircleCI but
nothing is happening. The POST response says DENY without any reason. Does CircleCI also need organization access to 
lede-project?


The deploy key is registered, but hasn't been used.
Is the docker image reference correct?
There must be some"may I" thing missing that allows CircleCI to access our 
repository?


I've started experimenting months ago so maybe I changed some of the
defaults settings and I don't remember
can you have a look at:
https://circleci.com/gh/openwrt/packages/edit#advanced-settings

GitHub Status updates: on
Free and Open Source: on
Build forked pull requests: off --> on
Pass secrets to builds from forked pull requests: off
Only build pull requests: off --> on
Auto-cancel redundant builds: off -> on
Enable build processing (preview): on --> off


OK - I changed some settings to match what you have (as noted above). Waiting 
to see what happens now.

/ted 



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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Ted Hess]

-Original Message- 
From: Etienne Champetier

Sent: Friday, October 26, 2018 6:10 PM
To: OpenWrt Development List
Subject: [OpenWrt-Devel] Enabling CircleCI for packages repo

Hi All,

Can one of the github admin enable CircleCI for the packages repo ?
The configuration was merged:
https://github.com/openwrt/packages/pull/5993

But it needs to be installed / configured
https://github.com/marketplace/circleci
(at the bottom of the page)

Thanks
Etienne

___

Etienne - AFAICT, I have enabled CircleCI on 10/25 for openwrt/packages repo. It looks like github is posting PRs to CircleCI but 
nothing is happening. The POST response says DENY without any reason. Does CircleCI also need organization access to lede-project?


The deploy key is registered, but hasn't been used.
Is the docker image reference correct?
There must be some"may I" thing missing that allows CircleCI to access our 
repository?

/ted




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

[OpenWrt-Devel] [PATCH] toolchain: Replace YASM with NASM

[Ted Hess]

Rather than doing this directly without warning - I am making this request
for review...

Packages libx264 and ffmpeg are built with ASM options on x86 platforms.
The current libx264 version no longer builds with YASM and requires NASM.
ffmpeg 3.x can be built with either YASM or NASM however, furture 4.x versions
will require NASM.

This change will replace the YASM assembler in the toolchain with NASM. Both
packages have been test with this change. I don't know of any other packages
which explicitly use an external assembler so I feel comfortable with
replacing the assembler instead of adding another.

After this patch is merged, the PR for these packages on Github
https://github.com/openwrt/packages/pull/6383
needs to be merged.

/ted

Signed-off-by: Ted Hess 
---
 toolchain/Config.in   |  6 +++---
 toolchain/Makefile|  2 +-
 toolchain/{yasm => nasm}/Makefile | 25 +
 3 files changed, 13 insertions(+), 20 deletions(-)
 rename toolchain/{yasm => nasm}/Makefile (65%)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 96acf1e5c4..47e1c787df 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -224,13 +224,13 @@ comment "Compiler"
 
 source "toolchain/gcc/Config.in"
 
-config YASM
+config NASM
bool
depends on ( i386 || x86_64 )
-   prompt "Build yasm" if TOOLCHAINOPTS
+   prompt "Build nasm" if TOOLCHAINOPTS
default y
help
- Enable if you want to build yasm
+ Enable if you want to build nasm
 
 comment "C Library"
depends on TOOLCHAINOPTS
diff --git a/toolchain/Makefile b/toolchain/Makefile
index 409955c23a..9432990f4f 100644
--- a/toolchain/Makefile
+++ b/toolchain/Makefile
@@ -29,7 +29,7 @@
 curdir:=toolchain
 
 # subdirectories to descend into
-$(curdir)/builddirs := $(if $(CONFIG_GDB),gdb) $(if 
$(CONFIG_EXTERNAL_TOOLCHAIN),wrapper,kernel-headers binutils gcc/initial 
gcc/final $(LIBC) fortify-headers) $(if $(CONFIG_YASM),yasm)
+$(curdir)/builddirs := $(if $(CONFIG_GDB),gdb) $(if 
$(CONFIG_EXTERNAL_TOOLCHAIN),wrapper,kernel-headers binutils gcc/initial 
gcc/final $(LIBC) fortify-headers) $(if $(CONFIG_NASM),nasm)
 ifdef CONFIG_USE_UCLIBC
   $(curdir)/builddirs += $(LIBC)/utils
 endif
diff --git a/toolchain/yasm/Makefile b/toolchain/nasm/Makefile
similarity index 65%
rename from toolchain/yasm/Makefile
rename to toolchain/nasm/Makefile
index e5cdac6fe9..a39c71f65f 100644
--- a/toolchain/yasm/Makefile
+++ b/toolchain/nasm/Makefile
@@ -1,34 +1,26 @@
 #
-# Copyright (C) 2016 Daniel Golle 
-#
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
 #
 include $(TOPDIR)/rules.mk
 
-PKG_NAME:=yasm
-PKG_VERSION:=1.3.0
+PKG_NAME:=nasm
+PKG_VERSION:=2.13.03
 
-PKG_SOURCE_URL:=http://www.tortall.net/projects/yasm/releases/
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=https://www.nasm.us/pub/nasm/releasebuilds/$(PKG_VERSION)/
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 
-PKG_HASH:=3dce6601b495f5b3d45b59f7d2492a340ee7e84b5beca17e48f862502bd5603f
+PKG_HASH:=812ecfb0dcbc5bd409aaa8f61c7de94c5b8752a7b00c632883d15b2ed6452573
 
 HOST_BUILD_PARALLEL:=1
 
 include $(INCLUDE_DIR)/toolchain-build.mk
 
-YASM_CONFIGURE:= \
-   ./configure \
-   --prefix=$(TOOLCHAIN_DIR) \
-   --build=$(GNU_HOST_NAME) \
-   --host=$(GNU_HOST_NAME) \
+HOST_CONFIGURE_ARGS+= \
--target=$(REAL_GNU_TARGET_NAME) \
--with-sysroot=$(TOOLCHAIN_DIR) \
-   --disable-multilib \
+   --enable-lto \
--disable-werror \
-   --disable-nls \
-   --disable-sim \
--disable-gdb \
$(SOFT_FLOAT_CONFIG_OPTION) \
 
@@ -40,8 +32,9 @@ endef
 
 define Host/Configure
(cd $(HOST_BUILD_DIR); \
-   $(YASM_CONFIGURE) \
+   ./autogen.sh \
);
+   $(call Host/Configure/Default)
 endef
 
 define Host/Compile
-- 
2.17.1


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

[OpenWrt-Devel] Collecting issues on github

[Ted Hess]

Hi folks,

I would like to propose we close the issues tab on the github/openwrt/openwrt 
source repository as we did for the lede-project/source repo. We can continue 
to re-direct people to our bug-tracker for the mainline sources.

The packages repo remains as it is now.

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

Re: [OpenWrt-Devel] CVE-2016-2108 - OpenSSL remote code execution

[Ted Hess]

Last time I looked - both OpenWrt(trunk & CC) and LEDE are using 1.0.2h - updated a month ago. This report is for releases prior to 
1.0.2c.


/ted

-Original Message- 
From: yanosz

Sent: Tuesday, August 02, 2016 3:46 PM
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] CVE-2016-2108 - OpenSSL remote code execution

Hello,

plz check CVE-2016-2108 - when will there be a fix in OpenWRT?
Please consider unpublishing the OpenSSL packages until you can provide
a fix.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to pass argument while autoloading kernelmodule/driver

[Ted Hess]

I want to pass an argument to one of the driver, but couldn't found any example 
for it.
I know that argument can be passed in /etc/modules.d/ but I don't know 
what should I write and where,
before building OpenWrt so that, that option  gets reflected in /etc/modules.d/ and 
it will have content:  


Hi Pratik -

You can add new files and overwrite existing files by putting them in the /files directory path before building the 
image. In your case, you want to create /files/etc/modules.d/. It will then end up in the correct place in 
/build_dir//root-xxx/...


See "Custom files" at: https://wiki.openwrt.org/doc/howto/build

/ted 
___

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

Re: [OpenWrt-Devel] [PATCH] netdata: import new package

[Ted Hess]

Hi Sebastian -

I don't think this is part of the core packages necessary for OpenWrt base 
systems.
I think it better that you submit this as a PR on 
https://github.com/openwrt/packages.

Thanks,
/ted

-Original Message- 
From: Sebastian Careba

Sent: Wednesday, May 11, 2016 9:03 AM
To: openwrt-devel@lists.openwrt.org
Cc: Sebastian Careba
Subject: [OpenWrt-Devel] [PATCH] netdata: import new package

Netdata (https://github.com/firehol/netdata) is a real-time performance monitoring tool. This submission uses the current Git 
prerelease, as the latest stable (1.1.0)doesn't build cleanly.


The default configuration makes a few changes for OpenWrt:
- access log is disabled by default; too verbose for the circular
syslog buffer, and logging to /tmp is risky memory-wise.
Some sort of external device would be ideal for this.

- error and debug logs are sent to OpenWrt's syslog

- history and frequency times are halved to reduce memory usage,
as recommended in the netdata wiki

- external plugins are disabled to eliminate the dependency on bash
and node.js. Those could be installed from OpenWrt packages if
you wish to enable that functionality.

All of those files are still present in the package. The installed
size could be reduced by eliminating those files first.

Signed-off-by: Claudio Leite 
Signed-off-by: Sebastian Careba 

---
package/network/utils/netdata/Makefile   | 61 

package/network/utils/netdata/files/netdata.conf | 16 +++
package/network/utils/netdata/files/netdata.init | 11 
3 files changed, 88 insertions(+)
create mode 100644 package/network/utils/netdata/Makefile
create mode 100644 package/network/utils/netdata/files/netdata.conf
create mode 100644 package/network/utils/netdata/files/netdata.init

diff --git a/package/network/utils/netdata/Makefile 
b/package/network/utils/netdata/Makefile
new file mode 100644
index 000..d08b317
--- /dev/null
+++ b/package/network/utils/netdata/Makefile
@@ -0,0 +1,61 @@
+#
+# Copyright (C) 2008-2016 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:=netdata
+PKG_VERSION:=devel-20160508
+PKG_RELEASE:=1
+PKG_MAINTAINER:=Sebastian Careba 
+PKG_LICENSE:=GPL-3.0
+PKG_LICENSE_FILES:=COPYING
+
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL=https://github.com/firehol/netdata
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=0ec2db444011f5b6ebf41dab45502c27cd544af2
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+
+PKG_INSTALL:=1
+PKG_FIXUP:=autoreconf
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/netdata
+  SECTION:=package/network/utils
+  CATEGORY:=package/network/utilsistration
+  DEPENDS:=+zlib
+  TITLE:=Real-time performance monitoring tool
+  URL:=http://netdata.firehol.org/
+endef
+
+define Package/netdata/description
+  netdata is a highly optimized Linux daemon providing real-time performance
+  monitoring for Linux systems, applications and SNMP devices over the web.
+endef
+
+define Package/netdata/conffiles
+/etc/netdata/
+endef
+
+define Package/netdata/install
+ $(INSTALL_DIR) $(1)/etc/netdata
+ $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/apps_groups.conf 
$(1)/etc/netdata
+ $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/netdata/charts.d.conf $(1)/etc/netdata
+ $(INSTALL_CONF) ./files/netdata.conf $(1)/etc/netdata
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) ./files/netdata.init $(1)/etc/init.d/netdata
+ $(INSTALL_DIR) $(1)/usr/sbin
+ $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/netdata $(1)/usr/sbin/
+ $(INSTALL_DIR) $(1)/usr/share/netdata
+ $(INSTALL_DIR) $(1)/usr/lib/netdata
+ $(CP) $(PKG_INSTALL_DIR)/usr/share/netdata $(1)/usr/share
+ $(CP) $(PKG_INSTALL_DIR)/usr/lib/netdata $(1)/usr/lib
+ chmod 4755 $(1)/usr/lib/netdata/plugins.d/apps.plugin
+endef
+
+$(eval $(call BuildPackage,netdata))
diff --git a/package/network/utils/netdata/files/netdata.conf 
b/package/network/utils/netdata/files/netdata.conf
new file mode 100644
index 000..e1f0964
--- /dev/null
+++ b/package/network/utils/netdata/files/netdata.conf
@@ -0,0 +1,16 @@
+[global]
+ run as user = nobody
+ web files owner = root
+ web files group = root
+ update every = 2
+ history = 1800
+ access log = none
+ debug log = syslog
+ error log = syslog
+ memory mode = ram
+
+[plugins]
+ charts.d = no
+ apps = no
+ node.d = no
+ tc = no
diff --git a/package/network/utils/netdata/files/netdata.init 
b/package/network/utils/netdata/files/netdata.init
new file mode 100644
index 000..448e56d
--- /dev/null
+++ b/package/network/utils/netdata/files/netdata.init
@@ -0,0 +1,11 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+start() {
+ service_start /usr/sbin/netdata
+}
+
+stop() {
+ service_stop /usr/sbin/netdata
+}
--
2.1.4
___
openwrt-devel mailing list

[OpenWrt-Devel] procd warning about respawn

[Ted Hess]

[ Sorry if duplicate -- first attempt was returned as spam!? ]

John C. -- rather than continue this on a closed Github PR...

Since changeset (https://dev.openwrt.org/changeset/48915), procd_close_instance 
issues a
WARNING about respawn not defined if 'procd_set_param respawn' is not in ones 
startup script.

Is respawn now a required parameter or is this an extraneous buglet?

Example:

   #/etc/init.d/squeezelite start
   WARNING: Variable 'respawn' does not exist or is not an array/object
   #

/ted 
___

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

[OpenWrt-Devel] *****SPAM***** procd warning about respawn

[Ted Hess]

Spam detection software, running on the system "arrakis.dune.hu",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  @blogic – rather than continue this on a closed Github PR...
   Since changeset (https://dev.openwrt.org/changeset/48915), 
procd_close_instance
   issues a WARNING about respawn not defined if 'procd_set_param respawn' is
   not in ones startup script. [...] 

Content analysis details:   (6.0 points, 5.0 required)

 pts rule name  description
 -- --
 1.9 STOX_REPLY_TYPENo description available.
 3.1 STOX_REPLY_TYPE_WITHOUT_QUOTES No description available.
 1.0 XPRIO  Has X-Priority header


--- Begin Message ---

@blogic – rather than continue this on a closed Github PR...

Since changeset (https://dev.openwrt.org/changeset/48915), procd_close_instance issues a WARNING about respawn not defined if 
'procd_set_param respawn' is not in ones startup script.


Is respawn now a required parameter or is this an extraneous buglet?

Example:

root@OpenWrt:~# /etc/init.d/squeezelite start
WARNING: Variable 'respawn' does not exist or is not an array/object
root@OpenWrt:~#

/ted 

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

Re: [OpenWrt-Devel] [PATCH] ncurses: Fix build of libncursew

[Ted Hess]

Date: Thu, 10 Dec 2015 09:30:44 +0100
From: John Crispin <blo...@openwrt.org>
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] ncurses: Fix build of libncursew

On 09/12/2015 19:45, Ted Hess wrote:
Packages using libncursesw can fail to build if both libncurses and libncursesw
are not installed. Currently the ncurses.h file is installed in 
"usr/include/ncursesw"
directory and includes other .h files in the "usr/include" directory 
incorrectly.
For example: Including  fails due to these references. 
These build
changes will set the correct include paths within the developer includes. 


Packages that expect ncurses.h (or curses.h) in the default "usr/include" path 
fail
even when expecting to build with libncursesw and will need to be fixed as 
well. However,
they cannot be fixed until this patch is applied.


will this require that we fix packages linked against the w version to
lib as the headers are now at a different location int he staging area ?

John


No, it should not. The actual include path in the staging_directory does not 
change. The
patch just fixes the headers built for that location to work as intended. 
Packages that can
build with the 'w' version without needing the non-w version installed can now 
remove
that requirement and maybe fix them if they are just wrong (as was with zile). 
There
should be no immediate changes required since the headers were broken in the 
first
place and the installation of the non-w version of the headers made it work.

/ted


Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 package/libs/ncurses/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/libs/ncurses/Makefile b/package/libs/ncurses/Makefile
index 1f7ea9b..924033f 100644
--- a/package/libs/ncurses/Makefile
+++ b/package/libs/ncurses/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2013 OpenWrt.org
+# Copyright (C) 2006-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ncurses

 PKG_VERSION:=5.9
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)

 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
@@ -91,6 +91,7 @@ endif
 ifeq ($(BUILD_VARIANT),libncursesw)
 CONFIGURE_ARGS += \
 --enable-widec \
+ --includedir="/usr/include/ncursesw" \
 --with-build-cppflags=-D_GNU_SOURCE
 endif
 
@@ -138,7 +139,7 @@ endef

 ifeq ($(BUILD_VARIANT),libncursesw)
 define Build/InstallDev
 $(INSTALL_DIR) $(1)/usr/include/ncursesw/
- $(CP) $(PKG_INSTALL_DIR)/usr/include/*.h $(1)/usr/include/ncursesw/
+ $(CP) $(PKG_INSTALL_DIR)/usr/include/ncursesw/*.h $(1)/usr/include/ncursesw/
 
 $(INSTALL_DIR) $(1)/usr/lib

 $(CP) $(PKG_INSTALL_DIR)/usr/lib/lib{ncurses,panel,menu,form}w.{a,so*} 
$(1)/usr/lib/


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

[OpenWrt-Devel] [PATCH] kernel: Add dummy sound driver

[Ted Hess]

Useful when using sound players that can send to icecast, etc. without any 
sound device attached.

Signed-off-by: Ted Hess <th...@kitschensync.net>

---
diff --git a/package/kernel/linux/modules/sound.mk 
b/package/kernel/linux/modules/sound.mk
index 603bb70..d09cf21 100644
--- a/package/kernel/linux/modules/sound.mk
+++ b/package/kernel/linux/modules/sound.mk
@@ -273,3 +273,19 @@ define KernelPackage/pcspkr/description
 endef
 
 $(eval $(call KernelPackage,pcspkr))
+
+define KernelPackage/sound-dummy
+  $(call AddDepends/sound)
+  TITLE:=Null sound output driver (sink)
+  KCONFIG:= \
+   CONFIG_SND_DUMMY
+  FILES:= \
+   $(LINUX_DIR)/sound/drivers/snd-dummy.ko
+  AUTOLOAD:=$(call AutoLoad,32,snd-dummy)
+endef
+
+define KernelPackage/sound_dummy/description
+ Dummy sound device for Alsa when no hardware present
+endef
+
+$(eval $(call KernelPackage,sound-dummy))
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ncurses: Fix build of libncursew

[Ted Hess]

Packages using libncursesw can fail to build if both libncurses and libncursesw
are not installed. Currently the ncurses.h file is installed in 
"usr/include/ncursesw"
directory and includes other .h files in the "usr/include" directory 
incorrectly.
For example: Including  fails due to these references. 
These build
changes will set the correct include paths within the developer includes. 

Packages that expect ncurses.h (or curses.h) in the default "usr/include" path 
fail
even when expecting to build with libncursesw and will need to be fixed as 
well. However,
they cannot be fixed until this patch is applied.

Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 package/libs/ncurses/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/libs/ncurses/Makefile b/package/libs/ncurses/Makefile
index 1f7ea9b..924033f 100644
--- a/package/libs/ncurses/Makefile
+++ b/package/libs/ncurses/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2013 OpenWrt.org
+# Copyright (C) 2006-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ncurses
 PKG_VERSION:=5.9
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
@@ -91,6 +91,7 @@ endif
 ifeq ($(BUILD_VARIANT),libncursesw)
CONFIGURE_ARGS += \
--enable-widec \
+   --includedir="/usr/include/ncursesw" \
--with-build-cppflags=-D_GNU_SOURCE
 endif
 
@@ -138,7 +139,7 @@ endef
 ifeq ($(BUILD_VARIANT),libncursesw)
 define Build/InstallDev
$(INSTALL_DIR) $(1)/usr/include/ncursesw/
-   $(CP) $(PKG_INSTALL_DIR)/usr/include/*.h $(1)/usr/include/ncursesw/
+   $(CP) $(PKG_INSTALL_DIR)/usr/include/ncursesw/*.h 
$(1)/usr/include/ncursesw/
 
$(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/lib{ncurses,panel,menu,form}w.{a,so*} 
$(1)/usr/lib/
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mac80211: Add dependency on ip (iproute2) to cfg80211

[Ted Hess]

Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
a client association. 'ip' is not automatically included with cfg80211
custom builds -- association fails.

Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 package/kernel/mac80211/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index f2427de..8d5c302 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -78,7 +78,7 @@ endef
 define KernelPackage/cfg80211
   $(call KernelPackage/mac80211/Default)
   TITLE:=cfg80211 - wireless configuration API
-  DEPENDS+= +iw
+  DEPENDS+= +iw +ip
   FILES:= \
$(PKG_BUILD_DIR)/compat/compat.ko \
$(PKG_BUILD_DIR)/net/wireless/cfg80211.ko
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: Fix environment pointer setup in ar71xx/ath79

[Ted Hess]

Hi John -

I don't think this patch needs to be backported to CC. Bug does not exist in the 3.18 patch-set. Environment pointer is setup 
correctly in prom_init().


/ted

--


Date: Mon, 26 Oct 2015 10:35:04 +0100
From: John Crispin <blo...@openwrt.org>
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] kernel: Fix environment pointer setup in 
ar71xx/ath79
Message-ID: <562df3c8.7050...@openwrt.org>
Content-Type: text/plain; charset=windows-1252

On 21/10/2015 17:53, Ted Hess wrote:
Observed on ar71xx/ath79 platforms such as Ubiquiti RouterStations.Reported in 
#20642.:
(https://dev.openwrt.org/ticket/20642).

If embedded command-line text exists with CONFIG_IMAGE_CMDLINE_HACK=y,firmware
init doesn't initialize environment pointer (fw_init_cmdline not called).

arcs_cmdline is not initialized before calling strlcat.

Signed-off-by: Ted Hess <th...@kitschensync.net>

Hi,

can you send a backported version for CC aswell please

John



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

[OpenWrt-Devel] [PATCH] kernel: Fix environment pointer setup in ar71xx/ath79

[Ted Hess]

Observed on ar71xx/ath79 platforms such as Ubiquiti RouterStations.Reported in 
#20642.:
(https://dev.openwrt.org/ticket/20642). 

If embedded command-line text exists with CONFIG_IMAGE_CMDLINE_HACK=y,firmware
init doesn't initialize environment pointer (fw_init_cmdline not called).

arcs_cmdline is not initialized before calling strlcat.

Signed-off-by: Ted Hess <th...@kitschensync.net>

---
Index: 
target/linux/ar71xx/patches-4.1/508-MIPS-ath79-prom-image-command-line-hack.patch
===
--- 
a/target/linux/ar71xx/patches-4.1/508-MIPS-ath79-prom-image-command-line-hack.patch
+++ 
b/target/linux/ar71xx/patches-4.1/508-MIPS-ath79-prom-image-command-line-hack.patch
@@ -1,6 +1,6 @@
 --- a/arch/mips/ath79/prom.c
 +++ b/arch/mips/ath79/prom.c
-@@ -33,6 +33,35 @@ static void __init ath79_prom_append_cmd
+@@ -33,6 +33,41 @@ static void __init ath79_prom_append_cmd
strlcat(arcs_cmdline, ath79_cmdline_buf, sizeof(arcs_cmdline));
  }
  
@@ -27,6 +27,12 @@
 +  strlcat(arcs_cmdline, p, sizeof(arcs_cmdline));
 +  }
 +
++  /* Validate and setup environment pointer */
++  if (fw_arg2 < CKSEG0)
++  _fw_envp = NULL;
++  else
++  _fw_envp = (int *)fw_arg2;
++
 +  return 1;
 +}
 +#else
@@ -36,7 +42,7 @@
  static int __init ath79_prom_init_myloader(void)
  {
struct myloader_info *mylo;
-@@ -61,6 +90,8 @@ static int __init ath79_prom_init_myload
+@@ -61,6 +96,8 @@ static int __init ath79_prom_init_myload
  
ath79_prom_append_cmdline("ethaddr", mac_buf);
  
@@ -45,7 +51,7 @@
return 1;
  }
  
-@@ -71,7 +102,8 @@ void __init prom_init(void)
+@@ -71,7 +108,8 @@ void __init prom_init(void)
if (ath79_prom_init_myloader())
return;
  
@@ -55,3 +61,13 @@
  
env = fw_getenv("ethaddr");
if (env)
+--- a/arch/mips/fw/lib/cmdline.c
 b/arch/mips/fw/lib/cmdline.c
+@@ -35,6 +35,7 @@ void __init fw_init_cmdline(void)
+   else
+   _fw_envp = (int *)fw_arg2;
+ 
++  arcs_cmdline[0] = '\0';
+   for (i = 1; i < fw_argc; i++) {
+   strlcat(arcs_cmdline, fw_argv(i), COMMAND_LINE_SIZE);
+   if (i < (fw_argc - 1))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add 4.1 support

[Ted Hess]

On 18-10-15 20:20, Roman Yeryomin wrote:
On 18 October 2015 at 00:16, Stijn Tintel  wrote:

On 17-07-15 19:35, Roman Yeryomin wrote:

Signed-off-by: Roman Yeryomin 
---


Hi Roman,

Since ar71xx uses 4.1 kernel by default, MAC addresses on my Ubiquiti
RSPro's are random. I suspect it is due to the changes in
506-MIPS-ath79-prom-parse-redboot-args.patch. I reported the problem
here: https://dev.openwrt.org/ticket/20642. Do you mind having a look at it?

Those changes didn't affect functionality, it was a port to new prom API.
Also seems you have the board correctly detected - it means prom code
is working.
Are you sure the bootloader is passing ethaddr as it should? Sorry, I
don't have the hw to test.

The bootloader is passing it:

RedBoot> exec
Now booting linux kernel:
Base address 0x8005 Entry 0x8006
memsize=0x0800
modetty0=0,n,8,1,hw
board=RouterStation PRO
ethaddr=00.15.6d.c3.31.57
[0.00] Linux version 4.1.10 (stijn@taz) (gcc version 4.8.3
(OpenWrt/Linaro GCC 4.8-2014.04 r47070) ) #1 Tue Oct 13 04:36:06 CEST 2015

And I don't have the problem with the 3.18 kernel, tested on 2 different
RSPro's.

Kind regards,
Stijn



It looks like the cmdline used is forced to be the one embedded by the image 
generation
build step and then data passed via RedBoot is no longer queried. Board 
recognition is not
from RedBoot, but from the embedded command line. Hence, no ethaddr=.

See CONFIG_IMAGE_CMDLINE_HACK in the ar71xx/config-4.1 file.

Ought to be a simple code fix in prom.c - looking at it tomorrow.

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

Re: [OpenWrt-Devel] [PATCH] nls.mk: add -rpath-link when needed

[Ted Hess]

+1 on this. I have tested this already on about 10 packages OK.

After this patch is applied, I think there are approx. 24 packages which are potentially affected - though somewhat benign. Updating 
them to remove unnecessary LDFLAGS fixups would be a good thing to do. I have put together a list of candidates for these updates 
and will be submitting patches for them after the new nls.mk has been checked in and new builds are tested.


/ted

Here's the list I am working on at the moment:

The following are in the dev repo:
package/libs/elfutils(remove TARGET_LDFLAGS)

The following are in the packages repo:
mail/alpine(remove unecessary DISABLE_NLS; package-defaults.mk sets it 
correctly)
utils/crelay(remove TARGET_LDFLAGS)
utils/lcd4linux(remove EXTRA_LDFLAGS)
utils/dosfstools(fixup LDFLAGS, LDLIBS)
utils/smstools3(remove TARGET_LDFLAGS; fixup USER_LDFLAGS)

net/seafile-server(fixup TARGET_LDFLAGS)
net/seafile-ccnet(fixup TARGET_LDFLAGS)
net/dmapd  (remove TARGET_LDFLAGS)

lang/vala(remove TARGET_LDFLAGs)

multimedia/minidlna(remove LDFLAGS and ICONV_LIBS)
multimedia/gstreamer1(remove EXTRA_LDFLAGS)
multimedia/gst1-plugins-*(remove EXTRA_LDFLAGS)

sound/mpd(remove TARGET_LDFLAGS)

Remove TARGET_LDFLAGS from:
--
libs/vips
libs/libsoup
libs/libmms
libs/libsearpc
libs/libimobiledevice
libs/libdmapsharing
libs/apr-util(remove explicit -liconv)


-Original Message- 
Date: Sat, 29 Aug 2015 14:33:33 +0300

From: Paul Fertser fercer...@gmail.com
To: openwrt-devel@lists.openwrt.org
Cc: Paul Fertser fercer...@gmail.com
Subject: [OpenWrt-Devel] [PATCH] nls.mk: add -rpath-link when needed
for NLS support
Message-ID: 1440848013-1222-1-git-send-email-fercer...@gmail.com

When a package links to a shared library that depends on libiconv or
libintl shared libraries, specifying directory pathes to them via -L
switches is not enough, see man 1 ld -rpath-link description.

Signed-off-by: Paul Fertser fercer...@gmail.com
---
include/nls.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/nls.mk b/include/nls.mk
index 118000d..51463b9 100644
--- a/include/nls.mk
+++ b/include/nls.mk
@@ -28,12 +28,12 @@ PKG_BUILD_DEPENDS += !BUILD_NLS:libiconv !BUILD_NLS:libintl
ICONV_DEPENDS:=+BUILD_NLS:libiconv-full
ICONV_CFLAGS:=-I$(ICONV_PREFIX)/include
ICONV_CPPFLAGS:=-I$(ICONV_PREFIX)/include
-ICONV_LDFLAGS:=-L$(ICONV_PREFIX)/lib
+ICONV_LDFLAGS:=-L$(ICONV_PREFIX)/lib -Wl,-rpath-link=$(ICONV_PREFIX)/lib

INTL_DEPENDS:=+BUILD_NLS:libintl-full
INTL_CFLAGS:=-I$(INTL_PREFIX)/include
INTL_CPPFLAGS:=-I$(INTL_PREFIX)/include
-INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib
+INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib -Wl,-rpath-link=$(INTL_PREFIX)/lib

TARGET_CFLAGS += $(ICONV_CFLAGS) $(INTL_CFLAGS)
TARGET_CPPFLAGS += $(ICONV_CPPFLAGS) $(INTL_CPPFLAGS)
--
2.0.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands (from Silicon Labs)

[Ted Hess]

Thanks for the info and explanation. No need for the pointers.

I'd already decided on dropping this request 'cause it did seem a bit hacky and was looking at a better solution. Your suggestion to 
take a look at libusb seems like a good thing to do for this app.


/ted

-Original Message- 
From: Karl Palsson

Sent: Friday, August 07, 2015 9:14 PM
To: Ted Hess
Cc: Felix Fietkau ; OpenWrt developers
Subject: Re: Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl 
commands (from Silicon Labs)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ted Hess th...@kitschensync.net wrote:

After a bit more research - This is what I know:

The upstream cp210x driver is not completely up-to-date with the driver
silabs maintains on
their site. In their own words: ... unfortunately GPIO is not something
that has been
committed to the Linux kernel yet for community maintenance. We leave
the drivers on our
website, even though they are a bit behind the curve of the maintained
kernels, to
demonstrate how to do this quickly using an ioctl() call.

I also noted that the patch I submitted is not up-to-date with their
latest devices which are
supported in their driver - whoops.

I could try to submit this upstream even if it was snatched from their
driver. Is this OK?


There 's two people working on this on the linux-usb mailing list right
now  (I'm on apalling internet right now, so I can't find links for you
to the archives)  The ioctl approach has been totally vetoed, any ioctl
for gpios on this chips will never merge upstream, the silabs driver is
for people who don't care about those sorts of things.  gpios for ftdi
is also landing, and it's finally being accepted that all of these
things are actually, you know, important, so it's finally getting there,
but the ioctl approach is out.  I wouldn't personally be a fan of
openwrt putting in ioctls even for just for now as it's something you
can maintain in your own tree if you really need this sort of
functionality.



There is a small relay controller package (crelay) that I am going to
submit to the packages
repo it this patch gets accepted. It uses the cp210x ioctl interface.


What's happening is it's getting the whole gpiolib interface.  so this
app will only ever work with people using the vendor driver _if_ you
need to do it in the kernel.  You can always use libusb to make the same
control requests if you like, and if you're only poking a relay, I'd
imagine it's more than sufficient.  (of course depending on what you
want to be doing at the same time and all that)

Cheers,
Karl P



-Original Message- 
From: Felix Fietkau

Sent: Monday, August 03, 2015 2:33 PM
To: Ted Hess ; OpenWrt developers
Subject: Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl
commands (from Silicon Labs)

On 2015-08-03 20:17, Ted Hess wrote:
 It would probably make sense to do it that way however, there are apps which 
already use the ioctl interface on this device and
 this
 code came directly from the the manufacturer's linux driver.

 I'm not sure how to add general GPIO support for a specific USB device? 
Things to research...
Did the manufacturer submit this upstream already, or is somebody else
(maybe you) going to do so?

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


- -- 
Sent using Mailpile, Free Software from www.mailpile.is


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVxVfqAAoJEBmotQ/U1cr2SWUP/jpwCwpCoTwidPoR3PbHOy8W
xjDuV1yseAV9HDrFjiCgLC0sOXfoaRWHJrGV7lvADLvYMNJb4nfGzShCzMPqJb3K
xvD1snvZu/mFCFVzuxv8OYImMzdfPw6zVpRjjgwrpnytCejfc6wqADopL418XFSZ
PFgN5n9sxDgrM1BkPEvMJoBB58IrN1w2M/zDq+IWN4uJgEfdSosjiP++sRngB8dA
YAcmqhg1RBbv6tilr8jcXaKlgIc+iriEN2sGpe8cVjkhefkyO5MtNVbo9yFxco7n
nNdcjh1hhf+DoUmrO7YImjmIFVO1UU37yKbg3tMFg4XWh55O/BEkk0Q6+ljfzeZz
nj+mW3rARjYXDNX8AKYFTS3TdlA/4rphtQ/ReleeK77SzZIwlKEr+RLES8q/2Lde
sf8TEP/EpXXgwfhJFeVnpP10p/2DS8khOWb80enPBfM6+N6c+/+LDijj/1UHpi2k
Zoin3Kcwa/vuMRWHill0me3bvBbiK2ZJY+sQCt+VMKisH42CJpDYi7CY5FG9W4aD
oR2Nf4jAPiA/VB4+KNzeoO5CoBGBLDqZPeiYfsZfB5g/OuvNHzbG/on7fyNZTR+Z
q/e5iMXmRYqCT0VmK/AqVdZgyBSkHg/knLvwbC8U1onudYDMz88BrBlRpTztVagr
i5qDhzH6yhRiPZSIo9VM
=2eLL
-END PGP SIGNATURE- 
___

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

[OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands (from Silicon Labs)

[Ted Hess]

Silicon Labs driver has ioctl support on devices which have GPIO pins. The 
driver

in the kernel repo does not have this feature.

Ref: 
http://www.silabs.com/Support%20Documents/Software/Linux_CP210x_VCP_3.x.x_Release_Notes.txt


Signed-off-by: Ted Hess th...@kitschensync.net
---
.../patches-3.18/824-cp210x_add_gpio_ioctl.patch   | 194 +
.../patches-4.1/824-cp210x_add_gpio_ioctl.patch| 194 +
2 files changed, 388 insertions(+)
create mode 100644 
target/linux/generic/patches-3.18/824-cp210x_add_gpio_ioctl.patch
create mode 100644 
target/linux/generic/patches-4.1/824-cp210x_add_gpio_ioctl.patch


diff --git a/target/linux/generic/patches-3.18/824-cp210x_add_gpio_ioctl.patch 
b/target/linux/generic/patches-3.18/824-cp210x_add_gpio_ioctl.patch

new file mode 100644
index 000..695647a
--- /dev/null
+++ b/target/linux/generic/patches-3.18/824-cp210x_add_gpio_ioctl.patch
@@ -0,0 +1,194 @@
+--- a/drivers/usb/serial/cp210x.c
 b/drivers/usb/serial/cp210x.c
+@@ -24,13 +24,15 @@
+ #include linux/uaccess.h
+ #include linux/usb/serial.h
+
+-#define DRIVER_DESC Silicon Labs CP210x RS232 serial adaptor driver
++#define DRIVER_DESC Silicon Labs CP210x RS232 serial adaptor driver (with 
GPIO support)

+
+ /*
+  * Function Prototypes
+  */
+ static int cp210x_open(struct tty_struct *tty, struct usb_serial_port *);
+ static void cp210x_close(struct usb_serial_port *);
++static int cp210x_ioctl(struct tty_struct *tty,
++unsigned int cmd, unsigned long arg);
+ static void cp210x_get_termios(struct tty_struct *, struct usb_serial_port *);
+ static void cp210x_get_termios_port(struct usb_serial_port *port,
+ unsigned int *cflagp, unsigned int *baudp);
+@@ -185,6 +187,7 @@
+
+ struct cp210x_serial_private {
+ __u8bInterfaceNumber;
++__u8bPartNumber;
+ };
+
+ static struct usb_serial_driver cp210x_device = {
+@@ -198,6 +201,7 @@
+ .bulk_out_size= 256,
+ .open= cp210x_open,
+ .close= cp210x_close,
++.ioctl= cp210x_ioctl,
+ .break_ctl= cp210x_break_ctl,
+ .set_termios= cp210x_set_termios,
+ .tiocmget= cp210x_tiocmget,
+@@ -211,6 +215,17 @@
+ cp210x_device, NULL
+ };
+
++/* Part number definitions */
++#define CP2101_PARTNUM0x01
++#define CP2102_PARTNUM0x02
++#define CP2103_PARTNUM0x03
++#define CP2104_PARTNUM0x04
++#define CP2105_PARTNUM0x05
++
++/* IOCTLs */
++#define IOCTL_GPIOGET0x8000
++#define IOCTL_GPIOSET0x8001
++
+ /* Config request types */
+ #define REQTYPE_HOST_TO_INTERFACE0x41
+ #define REQTYPE_INTERFACE_TO_HOST0xc1
+@@ -244,11 +259,17 @@
+ #define CP210X_SET_CHARS0x19
+ #define CP210X_GET_BAUDRATE0x1D
+ #define CP210X_SET_BAUDRATE0x1E
++#define CP210X_VENDOR_SPECIFIC0xFF
+
+ /* CP210X_IFC_ENABLE */
+ #define UART_ENABLE0x0001
+ #define UART_DISABLE0x
+
++/* CP210X_VENDOR_SPECIFIC */
++#define CP210X_WRITE_LATCH0x37E1
++#define CP210X_READ_LATCH0x00C2
++#define CP210X_GET_PARTNUM0x370B
++
+ /* CP210X_(SET|GET)_BAUDDIV */
+ #define BAUD_RATE_GEN_FREQ0x384000
+
+@@ -469,6 +490,96 @@
+ cp210x_set_config_single(port, CP210X_IFC_ENABLE, UART_DISABLE);
+ }
+
++static int cp210x_ioctl(struct tty_struct *tty,
++unsigned int cmd, unsigned long arg)
++{
++struct usb_serial_port *port = tty-driver_data;
++struct usb_serial *serial = port-serial;
++struct cp210x_serial_private *port_priv = usb_get_serial_data(serial);
++int result = 0;
++unsigned int latch_setting = 0;
++
++switch (cmd) {
++
++case IOCTL_GPIOGET:
++if ((port_priv-bPartNumber == CP2103_PARTNUM) ||
++(port_priv-bPartNumber == CP2104_PARTNUM)) {
++result = usb_control_msg(port-serial-dev,
++usb_rcvctrlpipe(port-serial-dev, 0),
++CP210X_VENDOR_SPECIFIC,
++REQTYPE_DEVICE_TO_HOST,
++CP210X_READ_LATCH,
++port_priv-bInterfaceNumber,
++latch_setting, 1,
++USB_CTRL_GET_TIMEOUT);
++if (result != 1)
++return -EPROTO;
++*(unsigned long *)arg = (unsigned long)latch_setting;
++return 0;
++} else if (port_priv-bPartNumber == CP2105_PARTNUM) {
++result = usb_control_msg(port-serial-dev,
++usb_rcvctrlpipe(port-serial-dev, 0),
++CP210X_VENDOR_SPECIFIC,
++REQTYPE_INTERFACE_TO_HOST,
++CP210X_READ_LATCH,
++port_priv-bInterfaceNumber,
++latch_setting, 1,
++USB_CTRL_GET_TIMEOUT);
++if (result != 1)
++return -EPROTO;
++*(unsigned long *)arg = (unsigned long)latch_setting;
++return 0;
++} else {
++return

Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands (from Silicon Labs)

[Ted Hess]

It would probably make sense to do it that way however, there are apps which already use the ioctl interface on this device and this 
code came directly from the the manufacturer's linux driver.


I'm not sure how to add general GPIO support for a specific USB device? Things 
to research...

(I think I may have to re-submit this without the gratuitous word-wrapping too)

/ted

-Original Message- 
From: Felix Fietkau

Sent: Monday, August 03, 2015 2:08 PM
To: Ted Hess ; OpenWrt developers
Subject: Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands 
(from Silicon Labs)

On 2015-08-03 19:55, Ted Hess wrote:

Silicon Labs driver has ioctl support on devices which have GPIO pins. The
driver
in the kernel repo does not have this feature.

Ref:
http://www.silabs.com/Support%20Documents/Software/Linux_CP210x_VCP_3.x.x_Release_Notes.txt

Signed-off-by: Ted Hess th...@kitschensync.net

Wouldn't it make more sense to expose this as a GPIO controller instead
of a driver specific ioctl interface?

- Felix 
___

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

Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands (from Silicon Labs)

[Ted Hess]

After a bit more research - This is what I know:

The upstream cp210x driver is not completely up-to-date with the driver silabs 
maintains on
their site. In their own words: ... unfortunately GPIO is not something that 
has been
committed to the Linux kernel yet for community maintenance. We leave the 
drivers on our
website, even though they are a bit behind the curve of the maintained kernels, 
to
demonstrate how to do this quickly using an ioctl() call.

I also noted that the patch I submitted is not up-to-date with their latest 
devices which are
supported in their driver - whoops.

I could try to submit this upstream even if it was snatched from their driver. 
Is this OK?

There is a small relay controller package (crelay) that I am going to submit to 
the packages
repo it this patch gets accepted. It uses the cp210x ioctl interface.

I will also submit this patch again here with the correct format and all the 
latest fixes from
the old Silicon Labs driver.

/ted

-Original Message- 
From: Felix Fietkau

Sent: Monday, August 03, 2015 2:33 PM
To: Ted Hess ; OpenWrt developers
Subject: Re: [OpenWrt-Devel] [PATCH] [kernel] cp201x: Add GPIO ioctl commands 
(from Silicon Labs)

On 2015-08-03 20:17, Ted Hess wrote:
It would probably make sense to do it that way however, there are apps which already use the ioctl interface on this device and 
this

code came directly from the the manufacturer's linux driver.

I'm not sure how to add general GPIO support for a specific USB device? Things 
to research...

Did the manufacturer submit this upstream already, or is somebody else
(maybe you) going to do so?

- Felix 
___

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

[OpenWrt-Devel] Alsa-lib (libasound) segfaults on TLS variable (musl on mips)

[Ted Hess]

I believe this to be an independent problem from the pthread_detach() 
discussion: musl breaks python. I’m re-posting this to openwrt-devel to get 
more devos aware of the issue. Note that I am using the latest musl/gcc patches 
as of today (23-Jun).


FWIW -- Here's what I know...
To easily reproduce:

   Build alsa-lib  alsa-utils
   Execute: 'aplay -L'(fails - see below)

--
Segfault in 'snd_lib_error_set_local' (error.c) referencing
static __thread snd_local_error_handler_t local_error;

Program received signal SIGSEGV, Segmentation fault.
0x0041b164 in snd_lib_error_set_local ()
(gdb) bt
#0 0x0041b164 in snd_lib_error_set_local ()
#1 0x0041fb68 in try_config ()
#2 0x00420d80 in snd_device_name_hint ()
#3 0x0040a3be in pcm_list ()
#4 0x0040e92a in main ()
(gdb) disas
Dump of assembler code for function snd_lib_error_set_local:
0x0041b12c +0: lui gp,0x8
0x0041b130 +4: addiu gp,gp,23668
0x0041b134 +8: addu gp,gp,t9
0x0041b138 +12: addiu sp,sp,-16
0x0041b13c +16: lw t9,-29872(gp)
0x0041b140 +20: sw ra,12(sp)
0x0041b144 +24: sw s0,8(sp)
0x0041b148 +28: sw gp,0(sp)
0x0041b14c +32: move s0,a0
0x0041b150 +36: addiu a0,gp,-29376
0x0041b154 +40: jalr t9
0x0041b158 +44: nop
0x0041b15c +48: lui v1,0x0
0x0041b160 +52: addu v1,v1,v0
= 0x0041b164 +56: lw v0,-32768(v1)
0x0041b168 +60: sw s0,-32768(v1)
0x0041b16c +64: lw ra,12(sp)
0x0041b170 +68: lw s0,8(sp)
0x0041b174 +72: jr ra
0x0041b178 +76: addiu sp,sp,16
End of assembler dump.


Fails on ar71xx and ramips. Works OK on armeb (NSLU2)
Removing __thread qualifier, rebuild, works OK.

/ted 
___

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

Re: [OpenWrt-Devel] procd/libubox mangles command-line arguments

[Ted Hess]

This gets more curious... You are certainly correct that the strings passed to 
procd are marshaled correctly. It turns out that the shells I have tried to pass 
the numeric-colon-separated list as an option value gets the list split apart as 
I noted earlier. Barring any quick solution to this issue I may develop a patch 
to the application source to accept a different delimiter. Go figure


Thanks,/ted

-Original Message- 
From: Yousong Zhou

Sent: Sunday, June 14, 2015 10:10 PM
To: Ted Hess
Cc: OpenWrt developers
Subject: Re: [OpenWrt-Devel] procd/libubox mangles command-line arguments

Hi, Ted,

On 15 June 2015 at 04:57, Ted Hess th...@kitschensync.net wrote:

Somewhere in the processing of procd_set_param command ... certain
command-line parameters which have colons (:) get treated as argument
delimiters. Example:

procd_set_param command foo -a 200:4:16:0 -o hw:0,0



The correct usage should be something like the following.

 procd_set_param command foo -a 200:4:16:0 -o hw:0,0


gets the command-line string -a 200 4 16 0 -o hw:0,0 actually passed to
the program. This is not what I wanted. Is there special handling for colon
delimited numbers?? The 2nd parameter does not get this treatment - why?



AFAIK, procd will not try any shell-like command line parsing.  I
tried the following script

 . /lib/functions/procd.sh
 service_triggers() { true; }
 procd_open_service foo foo
 procd_open_instance bar
 procd_set_param command 'baz -a 200:4:16:0 -o hw:0,0'
 procd_close_instance
 procd_close_service

 ubus call service list  | jsonfilter -e '$[foo]'

And the result seems expected.

 root@OpenWrt:/# ubus call service list  | jsonfilter -e '$[foo]'
 { instances: { bar: { running: false, command: [ baz -a
200:4:16:0 -o hw:0,0 ] } } }

   yousong 
___

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

Re: [OpenWrt-Devel] [PATCH 2/5] argp-standalone: import

[Ted Hess]

OK, I will remove it from Github

/ted

-Original Message- 
Date: Sun, 14 Jun 2015 19:23:32 +0200

From: Felix Fietkau n...@openwrt.org
To: Mathieu Olivari math...@codeaurora.org, blo...@openwrt.org

On 2015-05-19 01:40, Mathieu Olivari wrote:

argp-standalone is required by elfutils, itself required by perf. So
we'll move this package from packages.git and make it part of the core
distribution.

Signed-off-by: Mathieu Olivari math...@codeaurora.org

I will apply this package. Please make sure it gets removed from github.
Ted, whenever you have updates to this package, please send them to this
list.

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

[OpenWrt-Devel] procd/libubox mangles command-line arguments

[Ted Hess]

Somewhere in the processing of procd_set_param command ... certain 
command-line parameters which have colons (:) get treated as argument 
delimiters. Example:


procd_set_param command foo -a 200:4:16:0 -o hw:0,0

gets the command-line string -a 200 4 16 0 -o hw:0,0 actually passed to the 
program. This is not what I wanted. Is there special handling for colon 
delimited numbers?? The 2nd parameter does not get this treatment - why?


Can this be fixed in my procd startup script or do I need to fall-back to a 
non-procd init.


TIA,/ted 
___

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

Re: [OpenWrt-Devel] [PATCH 1/1] Fix bridge-utils file offset

[Ted Hess]

Nikolay -

bridge-utils has not been moved to Github since it has no owner/maintainer who 
has volunteered to do that. It is still in the oldpackages repo which is no 
longer supported. If you want to do the work to contribute to the Github repo, 
please read our guidelines 
(https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md) and submit a 
pull-request. Otherwise, post an issue there and see if someone does it for you.


/ted


On 22 May 2015 17:01:56, Nikolay Martynov wrote:
Hi.

 Thanks for you response!

 Please forgive my noobiness but I wasn't able to find brigde-utils
in https://github.com/openwrt/packages. Is it supposed to be somo
other feed? I would really appreciate if you could clarify.

Thanks.
Nikolay.

2015-05-22 14:43 GMT-04:00 John Crispin blo...@openwrt.org:
Hi,

brigde-utils is part of the github feed. please file an issue there

John

On 12/05/2015 03:48, Nikolay Martynov wrote:
Make sure brctl build uses appropriate defines (_FILE_OFFSET_BITS) that match 
uClibc settings.
Without this patch running brctl leads to 'unresolved alphasort symbol' 
message.


Signed-off-by: Nikolay Martynov mar.ko...@gmail.com
---
 net/bridge-utils/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bridge-utils/Makefile b/net/bridge-utils/Makefile
index ad95b87..10e44c5 100644
--- a/net/bridge-utils/Makefile
+++ b/net/bridge-utils/Makefile
@@ -30,6 +30,8 @@ define Package/bridge/description
  form a larger network.
 endef

+TARGET_CPPFLAGS 
+= -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE

+
 CONFIGURE_ARGS += \
  --with-linux-headers=$(LINUX_DIR) \



___
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] Designated Driver

[Ted Hess]

+1

Sorry I had to spam the whole distlist...

/ted

-Original Message- 
From: Hartmut Knaack 
Sent: Thursday, April 09, 2015 6:21 AM 
To: Ted Hess 
Subject: Re: [OpenWrt-Devel] Designated Driver 


Ted Hess schrieb am 08.04.2015 um 23:43:

+1

/ted



Hi,
it seems this mail just got to me, but not to the mailing list. Thus, nobody
else could see it (and therefor count your vote). Please re-submit and make
sure to include openwrt-devel@lists.openwrt.org as recipient of your message.
Usually the Answer-All (or answer sender and all recipients) function does the
job right. You can confirm that your vote has posted publicly by having a look
at [1].
Thanks

Hartmut

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-April/thread.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Weather station package wview upgraded to wview_5.21.7 - please incorporate

[Ted Hess]

-Original Message- 

Date: Tue, 24 Feb 2015 10:01:25 +0200
From: M?rt Laak mart.l...@active.ee
  ...
So now, I would like to contribute my upgrade to OpenWRT packaging 
system. Please help me - how can I do that?


You can submit this as a Pull Request on:  https://github.com/openwrt/packages

Be sure to read and comply with the guidelines at:
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Maintaining apcupsd-package

[Ted Hess]

Kevin -

In addition to what Alex said, be sure to read and comply with 
CONTRIBUTING.md at:

https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md

Thanks for your interest,
/ted

-Original Message- 
Date: Mon, 23 Feb 2015 08:57:18 +0200

From: Alexandru Ardelean ardeleana...@gmail.com
To: kolbr...@dolphin-it.de
Cc: OpenWrt Development List openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Maintaining apcupsd-package
Message-ID:
CA+U=DsqbRH079SwwD1eez4WJ7k63MbgUb5WnXEG=jcps7hd...@mail.gmail.com
Content-Type: text/plain; charset=utf-8

Hello,

The current packages repo is on Github and the apcupsd package is already
there (since 2 days ago apparently).
The link:
https://github.com/openwrt/packages/tree/master/net/apcupsd

You can do pull requests to the package repo (and review them with the
maintainer) if you want some specifics.

Cheers
Alex


On Mon, Feb 23, 2015 at 3:03 AM, kolbr...@dolphin-it.de wrote:


Good morning to all openwrt-devs,

I would like to update and maintain the apcupsd-package. The current
version is outdated. My company is building device firmwares based on this
and other packages, so we want to join Openwrt and help keeping things
going.

Thanks and with best regards,
Kevin
___
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] ar71xx update to v3.18

[Ted Hess]

A couple of Ubiquiti RouterStation Pros running custom build from r44462. 
One is wifi bridge other is full-router.

So far all is OK (1hr operation).

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

[OpenWrt-Devel] Need to add kmod-usb2-pci to Intel ixp4xx and AMD Geode devices

[Ted Hess]

Recent builds for NSLU2 and my Alix3d2 platforms did not have a USB 
controller recognized! Turns out the latest usb2 driver structure requires 
the addition of kmod-usb2-pci to be added to the target config. See patch 
below...


I believe this issue exists for any platform that has a USB controller 
attached to a PCI bus as was the case of the alix2 target config in 
change-set #37835 (sha1: e7190ac69b9fbe2f7103b8d71ef1c214e065f3b2).


This patch should probably be applied to several other device configs (geos, 
net5501, nas100d, etc.), but I cannot test them.


/ted

Example patch:

diff --git a/target/linux/ixp4xx/generic/profiles/200-NSLU2.mk 
b/target/linux/ixp4xx/generic/profile

index 1f5a4dd..f201535 100644
--- a/target/linux/ixp4xx/generic/profiles/200-NSLU2.mk
+++ b/target/linux/ixp4xx/generic/profiles/200-NSLU2.mk
@@ -8,7 +8,7 @@
define Profile/NSLU2
  NAME:=Linksys NSLU2
  PACKAGES:=-wpad-mini -kmod-ath5k kmod-scsi-core \
-   kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-storage \
+   kmod-usb-core kmod-usb-ohci kmod-usb2-pci kmod-usb2 kmod-usb-storage 
\

   kmod-fs-ext4
endef 
___

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

Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?

[Ted Hess]

Some observations on things that build when you think they shouldn’t... This 
is something I noticed a while ago and can construct an example, but have 
been unable to understand why things work this way – bug or feature?


Let's say you have a package - call it utility xyzzy. In the Makefile, you 
declare 2 additional packages: lib-x and lib-y along with the xyzzy utility. 
lib-x is dependent on libfoo and libbar. lib-y is only dependent on libfoo 
only. The xyzzy utility is dependent on lib-y and NOT lib-x. However, if I 
select xyzzy and hence lib-y is selected by default, when you build, libbar 
will be built (but not installed) even though it not selected in the build 
config as you have observed.


/ted

On Mon, Nov 17, 2014 at 9:16 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:



  i am out of ideas here ... i'm doing a full build for my archer c7
router and, when a package fails to build, i simply deselect that
package via make menuconfig (and, of course, any other packages that
select it) and restart the build.

  at the moment, given that rrdtool failed to build, i deselected
it, but the build again failed trying to build rrdtool. i've verified
through make menuconfig that it is indeed deselected. here are the
lines in .config related to rrdtool:

$ grep rrdtool .config
CONFIG_PACKAGE_lighttpd-mod-rrdtool=m
CONFIG_PACKAGE_collectd-mod-rrdtool=m
# CONFIG_PACKAGE_rrdtool is not set
# CONFIG_PACKAGE_rrdtool1 is not set
$

  i'm baffled ... given that rrdtool is clearly not selected for
building, why does a simple make insist on trying to build it? what
triviality am i overlooking?

rday 

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

Re: [OpenWrt-Devel] libdlna won't build, allegedly due to missing dependencies

[Ted Hess]

On 16.11.2014 09:45, Robert P. J. Day wrote:


  i checked trac and it seems that there is (still?) an ongoing issue
with building libdlna, as i was trying to do for a tp-link archer c7
v2:

cc1: note: someone does not honour COPTS correctly, passed 2 times
src/libdlna.so: undefined reference to `av_find_stream_info'
src/libdlna.so: undefined reference to `av_close_input_file'
collect2: error: ld returned 1 exit status
Makefile:36: recipe for target 'test-libdlna' failed
make[4]: *** [test-libdlna] Error 1

  that seems to match what i see here:

https://dev.openwrt.org/ticket/11666

is there a suggested fix for this? or i can just deselect it for now.

rday



Since both libdlna and ushare are discontinued by the developer and no 
longer maintained, I would suggest you use minidlna instead. If that is not 
satisfactory, then someone needs to volunteer to move these packages to the 
active Github repo, take ownership of the maintenance and bring them 
up-to-date.


I also recommend these packages be moved to the packages-abandoned repo.

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

Re: [OpenWrt-Devel] Problems with ffmpeg and alsa-lib

[Ted Hess]

1 - I will see what I can do to make alsa-lib optional for various configs.

2 - Building alsa-lib has no dependency on the host system's audio setup. 
The problem you are seeing is indeed a problem with your build environment, 
and what tools you have installed. More information is needed about our 
build system and target config before I can help you.


/ted

-Original Message- 
From: Bruno Randolf

Sent: Monday, October 13, 2014 9:23 AM
To: th...@kitschensync.net
Cc: OpenWrt Devel List
Subject: Problems with ffmpeg and alsa-lib

Hello,

I have two problems with libffmpeg and alsa-lib, both in trunk and BB:

1) Is that libffmpeg always selects alsa-lib, even when I only select
libffmpeg-mini. According to the Makefile only libffmpeg-full is
supposed to depend on alsa-lib. If i remove that dependency from
libffmpeg-full in the Makefile I can compile all variants... What's
wrong here? and is the alsa-lib dependency really needed?

2) I can not compile alsa-lib on my platforms (ar71xx and au1000 - both
don't have a sound card), it fails with the following error:

checking for mips-openwrt-linux-gcc... gcc
checking whether the C compiler works... no
configure: error: in
`/home/br1/dev/openwrt/trunk/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/alsa-lib-1.0.28':
configure: error: C compiler cannot create executables

This does not look related to having a sound card or not :(

In the meanwhile I have solved the problems by removing the alsa-lib
dependency... Any ideas for a real fix?

bruno 
___

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

Re: [OpenWrt-Devel] Build ipk and make autostart?

[Ted Hess]

The main source of your problem is the first line of your init script starts 
with: #!/bin/ash instead of #!/bin/sh

The OpenWrt build script that process the start/stop items in /etc/init.d is 
using:
grep '#!/bin/sh /etc/rc.common'

to determine the need to create the initial rc.d links.

HTH,
/ted___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] New package: mailsend. A tool that allows to send emails without the need to install an smtp server. Supports ssl.

[Ted Hess]

[ Original patch attachment removed for brevity ]


Please consider (re-)submitting this as a pull-request to the new packages 
repository (https://github.com/openwrt/packages).


Read over the CONTRIBUTING.md document before submitting.

A couple of things to note about your submission:

1 - Does not have signed-off-by statement
2 - Does not have a PKG_MAINTAINER
3 - Does not have license info
4 - Has references to local file paths !!
5 - Copyright incorrect or out-dated.
6 - OpenSSL should not be required

/ted 
___

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

Re: [OpenWrt-Devel] move socat into package feed

[Ted Hess]

Done ... enjoy!

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

[OpenWrt-Devel] [PATCH] Add abandoned package repo to feeds

[Ted Hess]

 Signed-off-by: Ted Hess th...@kitschensync.net
---
 feeds.conf.default | 1 +
 1 file changed, 1 insertion(+)

diff --git a/feeds.conf.default b/feeds.conf.default
index 4d9f020..e0d6d1d 100644
--- a/feeds.conf.default
+++ b/feeds.conf.default
@@ -4,6 +4,7 @@ src-git routing https://github.com/openwrt-routing/packages.git
 src-git telephony http://git.openwrt.org/feed/telephony.git
 src-git management https://github.com/openwrt-management/packages.git
 #src-git oldpackages http://git.openwrt.org/packages.git
+#src-git abandoned https://github.com/openwrt/packages-abandoned.git
 #src-svn xwrt http://x-wrt.googlecode.com/svn/trunk/package
 #src-svn phone svn://svn.openwrt.org/openwrt/feeds/phone
 #src-svn efl svn://svn.openwrt.org/openwrt/feeds/efl
-- 
1.9.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [hard floating point]

[Ted Hess]

Alberich -

I hope the enclosed info is helpful and not just creating more confusion on 
this subject. I have 
been successfully building the RPi 3.6.11+ Kernel within the OpenWRT buildroot 
using the following 
patches (+/-)... IMMV

I also am using 4.7-linaro (4.7.1) and eglibc 2.15 (20866).

/ted

In target/linux/platform/Makefile, I set:

CFLAGS:=-O2 -pipe -march=armv6 -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard 
-marm

Apply this patch to rules.mk

Index: rules.mk
===
--- rules.mk (revision 35642)
+++ rules.mk (working copy)
@@ -163,7 +163,7 @@
   SOFT_FLOAT_CONFIG_OPTION:=--with-float=soft
   TARGET_CFLAGS+= -msoft-float
 else
-  SOFT_FLOAT_CONFIG_OPTION:=
+  SOFT_FLOAT_CONFIG_OPTION:=--with-float=hard
 endif

 export PATH:=$(TARGET_PATH)

-
Include this patch in the target/linux/platform/kernel-patch directory

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 42d87d7..396f9f3 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -58,7 +58,7 @@ comma = ,
 # macro, but instead defines a whole series of macros which makes
 # testing for a specific architecture or later rather impossible.
 arch-$(CONFIG_CPU_32v7)  :=-D__LINUX_ARM_ARCH__=7 $(call 
cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
-arch-$(CONFIG_CPU_32v6)  :=-D__LINUX_ARM_ARCH__=6 $(call 
cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
+arch-$(CONFIG_CPU_32v6) 
 :=-D__LINUX_ARM_ARCH__=6 -Ofast -mcpu=arm1176jzf-s -mtune=arm1176jzf-s 
-mfloat-abi=hard -mfpu=vfp -fomit-frame-pointer 
 -fexcess-precision=fast
 # Only override the compiler option if ARMv6. The ARMv6K extensions are
 # always available in ARMv7
 ifeq ($(CONFIG_CPU_32v6),y)
@@ -113,8 +113,8 @@ endif
 endif

 # Need -Uarm for gcc  3.x
-KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call 
cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float 
-Uarm
-KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include 
asm/unified.h -msoft-float
+KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call 
cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
+KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include 
asm/unified.h

 CHECKFLAGS += -D__arm__



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