Re: [OpenWrt-Devel] Git mirror with branches, tags and full history
Hello, Same here - this is really appreciated. BR, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition / paid patch-checking
Hello, On Tue, Oct 13, 2015 at 1:04 PM, Nemesis <neme...@ninux.org> wrote: > > As far as I remember, there's no initiative going on, but the issue was > brought up at the summit by different speakers. > > There was also a quick poll: > > 1. Kathy Giori asked the attendees to raise their hand if they backed the > idea of an OpenWRT foundation > I would say half of the presents raised their hands (I did not because I'm > not involved so much in OpenWRT and I don't feel entitled to take sides) > > 2. Kathy asked the attendees to raise their hand if they opposed the idea of > an OpenWRT foundation > I think there were almost no raised hands or not at all Wouldn't it be easier if the project is adopted by an umbrella organization? There should be one that could be interested in managing the pitfalls and dirty bits of the organization, allowing the developers to spend their time on the project itself - and not on the maintenance of a foundation. > Federico > BR, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
Hello John, On Sun, Oct 11, 2015 at 2:48 PM, John Crispin <blo...@openwrt.org> wrote: > > On 11/10/2015 14:09, Jan Čermák wrote: > > Hello, > > > > thanks for pointing that out, Steven. Yes, this is basically the main > > reason why > > Bedrich opened this topic. If you need to maintain sustainable OpenWrt fork > > (no > > flame please, there are some situations - like running "heavyweight" OpenWrt > > fork on a device like our Turris - when it's reasonable to fork), pure Git > > is > > the way to go. > > although i see the point, out of tree fork have never been relevant to > any core decision makings Well, if all your users are using git, it can become at least a bit relevant :) > > When you have a fork based on some trunk version, it's not *that hard* to > > merge > > upstream changes from time to time, but if you want to base your system on > > some > > stable branch and then upgrade to a newer one, getting back the history of > > changes between versions gets pretty awkward. > > indeed > > > IMHO the main argument against Git over SVN here is that users would lose > > the > > information that'll help them to compare which version is newer. But as > > Atilla > > and Bruno said - git describe works maybe even better than just an > > incrementing > > revision number. Maybe it'd be needed to change a some of the workflow, but > > the > > pros of git (for us mainly: keeping the track of history and merging > > upstream > > changes) outweigh the cons. > > essentially the same point as above > > > Last but not least - Git has become a de-facto standard for larger projects > > with > > more contributors and the it helps to open the project to community - > > sending a > > patch to the mailing list (a patch that sometimes just lies there without > > any > > positive nor negative response for weeks) might discourage smaller > > contributors. > > Just look at the situation of openwrt-packages - the people became much more > > active since moving the repo to GitHub. > > patches will linger in mailing list until someone has time to look at > them. the version control system used is completely irrelevant I'm not sure about that. Git offer the possibility to have non-committer maintainers that can take control of a large part of the tree (for example, a few specific mips architectures). This will limit the burden on the committers which would then take pull requests from sub-maintainers. As a consequence, proposed patches may arrive in the main tree faster than today (where some patches lies on one ML for days or month when noone has the time to review and commit them). I might be wrong, but it seems to me that the OpenWRT community is bigger than ever. I've been following the project from some time now, and I feel there is some traction here. Changing the SCM now might help in the near future - where the number of potential contributors will outnumber the number of commiters by a far margin. Changing to git now will prevent svn to get in the way in the future. > to sum up, people want to have the history inside the branches ? Yes, for sure. The also want to create their own branch from an existing branch and merge some important changes that happened on the master branch - for example to use a newer version of some particular package, or to apply a kernel patch they need. They want to know what was applied on a particular branch (because following the ML is not something everybody has the time to do, unfortunately). OpenWRT is no longer a small thing that people use on their own personnal router. Its also a distribution that companies uses to build firmwares for their consumer products (we do that at SFR on the 9box). Following and integrating OpenWRT changes is part of my day to day job, and I must admit that a correct git repository - with the corresponding tagged releases and branches are present - would be immensly helpful. BR, -- Emmanuel Deloget (P.S. this mail represent my personnal views, not the view of my employer). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Dualradio 2.4/5GHz ath9k-Hardware which is deliverable?
You should try Aliexpress - it seems they still have some 4900 (be aware that prices might be a bit weird). I also found one company in France that can sell it (integration-reseaux.com ). BR, -- Emmanuel Deloget On Wed, Jul 1, 2015 at 9:00 PM, Bastian Bittorf bitt...@bluebottle.com wrote: * Jonathan Bennett jbscienc...@gmail.com [01.07.2015 20:33]: I have had great success with the tp-link Archer c7. It fits the bid nicely, if it is available. no, it does not fit. it has only an ath10k-radio for 5ghz. 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
[OpenWrt-Devel] [RFC] [PATCH] build: honor command line CONFIG_ variables on kernel_*config targets
The CONFIG_* variables are correctly handled when building nearly all targets (at least packages and full build) yet they are not honored on kernel_menuconfig and similar targets. Some use case : make CONFIG_DOWNLOAD_FOLDER=../dl/ kernel_menuconfig make CONFIG_BUILD_SUFFIX=test kernel_oldconfig and so on... When used, they generate build errors because the kernel_*config targets are not able to find the correct directories. Signed-off-by: Emmanuel Deloget emman...@deloget.com --- include/toplevel.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/toplevel.mk b/include/toplevel.mk index d8651d9..02e337a 100644 --- a/include/toplevel.mk +++ b/include/toplevel.mk @@ -128,13 +128,13 @@ else endif kernel_oldconfig: prepare_kernel_conf - $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux oldconfig + $(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C target/linux oldconfig kernel_menuconfig: prepare_kernel_conf - $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux menuconfig + $(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C target/linux menuconfig kernel_nconfig: prepare_kernel_conf - $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux nconfig + $(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C target/linux nconfig staging_dir/host/.prereq-build: include/prereq-build.mk mkdir -p tmp -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] make kernel_menuconfig does not honor command line CONFIG_ variables
Hello,
As of today, there are a few CONFIG_ variables that are used to change
the input or the result of the build process - i.e. the places where files
are stored or from where they are fetched. I haven't checked everything
but I will mention some of them:
CONFIG_DOWNLOAD_FOLDER : the place where downloaded files are stored
(and, consequently, the place from where they are retrieved during
the prepare steps).
CONFIG_BINARY_FOLDER : the bin directory where the build result is
stored
CONFIG_BUILD_SUFFIX : the suffix to add to a number of build
directories.
There might be others.
It was my impression that these variables where fully handled when they
were passed as command line arguments to the make command. For example,
if I do
make CONFIG_BUILD_SUFFIX=_my_router CONFIG_DOWNLOAD_FOLDER=/ramdisk/dl
Then it will just work.
Of course, this is correct most of the time. The few kernel_*config rules
are not honoring the command lines - meaning that if I fully built the
image with these command line vars then I cannot (for example) do a
make CONFIG_BUILD_SUFFIX=_my_router CONFIG_DOWNLOAD_FOLDER=/ramdisk/dl
kernel_menuconfig
It breaks. Here is a part of the --trace output I got for a similar command
line:
me@home:~/openwrt$ make --trace CONFIG_DOWNLOAD_FOLDER=/home/me/dl
CONFIG_BINARY_FOLDER=/home/me/bin/bpipro CONFIG_BUILD_SUFFIX=bpipro
kernel_menuconfig
/home/me/openwrt/include/toplevel.mk:69: update target 'prepare-tmpinfo'
due to: FORCE
make -r -s staging_dir/host/.prereq-build OPENWRT_BUILD= QUIET=0
mkdir -p tmp/info
export MAKEFLAGS= ;make V=s -j1 -r -s -f include/scan.mk
SCAN_TARGET=packageinfo SCAN_DIR=package SCAN_NAME=package
SCAN_DEPS=/home/me/openwrt/include/package*.mk
/home/me/openwrt/overlay/*/*.mk SCAN_DEPTH=5 SCAN_EXTRA=
export MAKEFLAGS= ;make V=s -j1 -r -s -f include/scan.mk
SCAN_TARGET=targetinfo SCAN_DIR=target/linux SCAN_NAME=target
SCAN_DEPS=profiles/*.mk /home/me/openwrt/include/kernel*.mk
/home/me/openwrt/include/target.mk SCAN_DEPTH=2 SCAN_EXTRA=
SCAN_MAKEOPTS=TARGET_BUILD=1
for type in package target; do \
f=tmp/.${type}info; t=tmp/.config-${type}.in; \
[ $t -nt $f ] || ./scripts/metadata.pl ${type}_config $f $t || {
rm -f $t; echo Failed to build $t; false; break; }; \
done
[ tmp/.config-feeds.in -nt tmp/.packagefeeds ] || ./scripts/feeds
feed_config tmp/.config-feeds.in
./scripts/metadata.pl package_mk tmp/.packageinfo tmp/.packagedeps || {
rm -f tmp/.packagedeps; false; }
./scripts/metadata.pl package_feeds tmp/.packageinfo tmp/.packagefeeds ||
{ rm -f tmp/.packagefeeds; false; }
touch /home/me/openwrt/tmp/.build
/home/me/openwrt/include/toplevel.mk:83: update target '.config' due to:
prepare-tmpinfo
if [ \! -e .config ] || ! grep CONFIG_HAVE_DOT_CONFIG .config /dev/null;
then \
[ -e /home/me/.openwrt/defconfig ] cp /home/me/.openwrt/defconfig
.config; \
export MAKEFLAGS= ;make V=s menuconfig OPENWRT_BUILD= QUIET=0; \
fi
/home/me/openwrt/include/toplevel.mk:134: update target 'kernel_menuconfig'
due to: prepare_kernel_conf
export MAKEFLAGS= ;make V=s -C target/linux menuconfig
make[1]: Entering directory '/home/me/openwrt/target/linux'
make[2]: Entering directory '/home/me/openwrt/target/linux/mvebu'
mkdir -p /home/me/openwrt/dl
/home/me/openwrt/scripts/download.pl /home/me/openwrt/dl
linux-3.18.11.tar.xz 2def91951c9cedf7896efb864e0c090c
@KERNEL/linux/kernel/v3.x
converted '
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz'
(ANSI_X3.4-1968) - '
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz' (UTF-8)
--2015-04-23 19:38:01--
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz
As you can see from these lines, the CONFIG_DOWNLOAD_FOLDER is ignored
(too bad because I don't have any internet access on this build
machine ; everything is already stored into a pre-built download
directory).
I identified the culprit: the kernel_menuconfig (and the other related
rules) are calling $(_SINGLE)$(NO_TRACE_MAKE) ... - and $(_SINGLE) empties
MAKEFLAGS (export MAKEFLAGS= ;).
My problem is that I don't know how to fix this, as there might be a good
reason to do that - one I don't understand yet. My little, dirty solution
for now is to rewrtite the kernel_menuconfig rule as:
kernel_menuconfig: prepare_kernel_conf
$(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C
target/linux menuconfig
Which works, but is probably not very clever.
So, a few questions:
* does someone has any information on why these kernel_*config rules
have this $(_SINGLE) here?
* is there a way to have these CONFIG_* command line variables
correctly honored in this specific case?
* is this even legal (from an OpenWRT point of view)?
Best regards,
-- Emmanuel Deloget
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] PATCH [openvpn] --enable-small as option
Hello, On 12/02/2014 19:30, Christoph Kottke wrote: hi, this add the configure switch --enable-small as an option in menuconfig. christoph There is a problem in the last hunk - $(if $(CONFIG_OPENVPN_$(BUILD_VARIANT)_SMALL),--enable-small) should be $(if $(CONFIG_OPENVPN_$(BUILD_VARIANT)_ENABLE_SMALL),--enable-small) Best regards, -- Emmanuel Deloget attachment: emmanuel_deloget.vcf___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Devel, PATCH:, kernel, CONFIG:, kernel] OpenWRT for Raspberry PI - second version
Hello, On 17/01/2014 19:27, Oskari Rauta wrote: Hi. I previously provided a patch for OpenWrt that enabled use of kernel 3.12.2y which is a raspberry pi specific kernel. Patch was a huge blob, 8 megabytes and was not integrated to mainstream. What that patch did, was that it converted vanilla kernel from kernel.org of version 3.12.2 to 3.12.2y. Now I have made a new patch with high hopes of it being integrated into OpenWrt. It isn't as big anymore and it enables kernel version 3.12.7y for brcm2708 target. This time, I made it to download already patched version of 3.12.7y directly from official raspberry pi kernel repository. Maybe I'm missing the point, but 3.12.2y is still a 3.12.2 kernel with some added patches. There is no reason to handle this version like another kernel version, force all bcm2708 devices to use this kernel (Raspi may be the biggest provider for bcm2708 powerd board, it doesn't mean they are the only one) and so on. The fact that the current trunk build binaries for the raspi doesn't mean it targets only the raspi. There might be some better thing to do - as of today, it's possisble to have patches for a specific architecture - maybe you can take advantage of this, or maybe the OpenWRT makefiles should allow the possibility to propose patches for a specific arch profile. Best regards, -- Emmanuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Embedded Database
Le 04/04/2013 08:52, Pietro Paolini a écrit : Hello all, I am looking for a open source database designed for embedded devices, I google the problem and I found different solutions : 1 - Embedded InnoDB 2 - Empress Embedded Database 3 - Firebird embedded They are the more interesting, I found them from [http://en.wikipedia.org/wiki/Embedded_database], someone have some experience on that and has in mind a way or the right DB (which preferably supports triggers) ? I've used SQLite for years. It's small (written in C, not C++, so you don't even depend on a libstdc++ - even a tiny one), fast, exists as a library, is ACID-compliant, supports triggers and so on. It's C interface is both simple and powerfull. Thanks in advance, Pietro. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compiling custom kernel for latest trunk
Le 12/01/2013 16:08, darius a écrit : Hello, Simple question for those who know. I do 'make kernel_menuconfig' then select some needed features in kernel and then do 'make -j3' in topdir. After image is done, I install it on the router, but my kernel features are still not available. So I suppose I've done something wrong with kernel compilation. Could someone guide my about compiling custom kernel ? -- Darius Hello, Features selected with '*' in make kernel_menuconfig are statically linked to the kernel, so they should be available in your image. Features selected with 'M' in make kernel_menuconfig are compiled as modules, and those modules are NOT copied into the modules package unless the same module is selected in make menuconfig. If you miss a specific module, you can change one of the file in openwrt/package/kernel/modules/ to include the missing module (using the other lines as samples) and propose the patch to the mailing list. This is just a matter of adding: === define KernelPackage/the-module-I-want-to-add SUBMENU:=$(A_MENU_VARIABLE) TITLE:=The module description KCONFIG:=CONFIG_MODULE_SELECTION_SYMBOL FILES:=$(LINUX_DIR)/path.to/module.ko AUTOLOAD:=$(call AutoLoad,the_module_order,module) endef define KernelPackage/the-module-I-want-to-add/description Description endef $(eval $(call KernelPackage,the-module-I-want-to-add)) === Available menu variables are defined in the various *.mk files in the openwrt/package/kernel/modules/ directory. The module order is an integer (from 00 to 99) which will be used to create the script that will be used to load the module. Since OpenWRT does not use any module dependency management tool, you have to handle this by yourself, meaning that you must make sure that you module * is insmoded after the module it depends on. * is insmoded before the modules that depends on it. Once you added the correct lines, you can do another make menuconfig - and your module will show up. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] [RFC] Add Kernel 3.4 to AR71xx platform.
Hello, Le 28/09/2012 21:07, Dave Taht a écrit : On Fri, Sep 28, 2012 at 02:29:56PM +0200, Oliver wrote: On Friday 28 September 2012 14:30:45 Felix Fietkau wrote: 3.6 is going to be released soon, I think we should go for that once we've taken care of branching for release. - Felix +1 to that. +1 to that too. It seems possible this will be a long-term stable release, which 3.3 is not. Unless I failed to understant the -longterm selection process, it will not (unless someone other than GKH decide to make it a longterm). GKH took 3.4 to make it a -longterm, and he only peek one version per year. I guess the next -longterm (the one that will replace v3.0) will be v3.8, not v3.6. 3.0: -longterm support by GKH; released 07/22/2011 3.2: -longterm support by BH; released 01/05/2012 3.4: -longterm support by GHK; released 05/22/2012 3.6: no -longterm support; released 10/01/2012 3.8: probable -longterm support by GKH, will be released on 08/??/2013 (roughly ; there is a delay of 4-5 month between two subsequent kernel versions). Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?
Hello, I understand that a lot of effort has been pushed in making Linux 3.3 the trunk kernel, and I understand that I probably missed long (IRC?) discussions on this very subject, but since 3.3.8 is going to be the last supported kernel in the 3.3.x branch it might be a good idea to move on to another, more recent kernel version - and to do it slightly better. Not that anything is really bad, but there were obviously better choices that 3.3 at the time it came up. First and foremost, 3.3 has never been a -longterm. In fact, 3.(2n+1) are doomed to be supported only for a short period of time, given that: * they are not supported by any -rt patch * and thus, will probably not promoted to -longterm. The only existing, official -longterm at this point is 3.0, as stated on GKH blog [1]. The very first argument against 3.3 would have been that given that 3.0 was already known to be a -longterm at this point, it should have been selected. 3.0-rt are also going to be maintained as -longterm by Steven Rostedt. Ben Hutchings proposed to maintain a -longterm of Linux 3.2 when GKH dropped its support ; Steven immediately stated that 3.2-rt are going to stay for a long time as well. 3.2 is going to be used by Debian and Ubuntu for (quite possibly) a long time, so we can be sure that this version is indeed a longterm although it's a kind-of community-maintained one. I know that these lines do not add much to the debate. I get that. The thing is, OpenWRT is supposed to be used in, well, wireless routers - possibly commercial ones. Commercial consumer products need to have at least two things : * they need to be able to pick a recent kernel when they start the development of their product. There is no real point today to select a 4 years old kernel because it's known to work. Given the development model of Linux, kernel breakage are less and less frequent (they still happen, but then the regressions are spotted quite fast). * the need to pick a kernel that they know will be supported for some time. This decrease the workload on the kernel crew in this company, and increase their productivity. A third point should not be left aside: * sometimes, having a realtime kernel is necessary. Some VoIP apps mandate this (there is a reason why RTP is called RTP). These should be the points to consider when its time to select a new kernel version to work on. It may mean that the OpenWRT tree needs to store two different kernel (a known longterm - maybe - the current kernel version). There are also important things to factor in. * the -rt maintainers pledged to maintaina -rt patch for every 3.(2n) releases (and possibly for every 4.(2n) releases after that). That means that 3.(2n+1) have virtually no chance to become a -longterm since distributions are more and more interested in proposing both the -rt and the !-rt kernel to their users (see Debian, for example). * One -longterm will be selected every year and will be maintained by GKH. Given the development pace, it will probably happen around 3.6 since 3.0 has been elected last year. The selection of 3.2 by Ben Hutchings is not related to the selection of another longterm by GKH. Anyway, whatever your (OWRT maintainers) choices are, we're going to accept and support them. But it might be good to at least publish some kind of rationale document when a new kernel is pushed in the tree. Hoping I have not been too disruptive, best regard, -- Emmanuel Deloget [1] http://www.kroah.com/log/linux/stable-status-01-2012.html [2] http://thread.gmane.org/gmane.linux.kernel/1284809/focus%3D1285786 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1, V1] Bump klish version to 1.6.0
Le 07/07/2012 09:13, Luka Perkov a écrit : On Fri, Jun 29, 2012 at 06:06:17PM +0200, Emmanuel Deloget wrote: Bump klish version to 1.6.0. You should use buildvariants for this. Take a look at freecwmp: packages/utils/freecwmp/Makefile I will give a look to this in the next hours/days and I will propose another patch. Luka Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1, V1] Bump klish version to 1.6.0
Bump klish version to 1.6.0. This version removes its dependency on the C++ library tinyxml as it now implements a new XML backend that support some common C-based XML libraries: libxml2, expat and libroxml. A config option is defined to let the user select the XML backend he wants to use. Since libroxml is not yet in the OpenWRT package tree, it's not yet possible to select this XML backend. Signed-off-by: Emmanuel Deloget log...@free.fr Index: packages/utils/klish/Config.in === --- packages/utils/klish/Config.in (révision 0) +++ packages/utils/klish/Config.in (révision 0) @@ -0,0 +1,16 @@ +choice +prompt XML Backend +depends on PACKAGE_klish +default KLISH_XML_BACKEND_EXPAT +help + Select the Klish XML backend. Only two backends are currently + supported by both OpenWRT and klish: the expat XML parser and + the well known Gnome libxml2. It's safe to chose either of them. + +config KLISH_XML_BACKEND_LIBEXPAT + bool Expat XML parser + +config KLISH_XML_BACKEND_LIBXML2 + bool Gnome libxml2 + +endchoice Index: packages/utils/klish/Makefile === --- packages/utils/klish/Makefile (révision 32525) +++ packages/utils/klish/Makefile (copie de travail) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=klish -PKG_VERSION:=1.5.4 +PKG_VERSION:=1.6.0 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://klish.googlecode.com/files -PKG_MD5SUM:=c98a1c65f7538c3f4687c6f8039295df +PKG_MD5SUM:=dad910b6b7d160177317bfe8f145ffd1 PKG_INSTALL:=1 @@ -28,7 +28,9 @@ define Package/klish $(call Package/klish/default,main tool) - DEPENDS:=+libstdcpp + DEPENDS:= \ + +KLISH_XML_BACKEND_LIBEXPAT:libexpat \ + +KLISH_XML_BACKEND_LIBXML2:libxml2 endef define Package/konf @@ -56,6 +58,17 @@ More information about these tools is to be found on the klish web site. endef +define Package/klish/config + source $(SOURCE)/Config.in +endef + +ifeq ($(strip $(CONFIG_KLISH_XML_BACKEND_LIBEXPAT)),y) + CONFIGURE_ARGS += --with-libexpat +endif +ifeq ($(strip $(CONFIG_KLISH_XML_BACKEND_LIBXML2)),y) + CONFIGURE_ARGS += --with-libxml2 +endif + define Package/klish/install $(INSTALL_DIR) $(1)/usr/bin $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/clish $(1)/usr/bin/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1, v1] Make Pandaboard an OMAP4 subtarget
This preliminary patch makes room in the target/linux/omap4 target to allow support of different OMAP4-based targets. It does so by moving the Pandaboard to a subtarget (as well as providing two profiles for this board: Original Pandaboard and Pandaboard ES). Further similar platforms (OMAP4430-SDP, OMAP4-Blaze, ...) may later be added if needed. Signed-off-by: Emmanuel Deloget log...@free.fr Index: target/linux/omap4/pandaboard/config-default === --- target/linux/omap4/pandaboard/config-default(révision 0) +++ target/linux/omap4/pandaboard/config-default(révision 0) @@ -0,0 +1,378 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_APM_EMULATION is not set +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_HAS_BARRIERS=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y +CONFIG_ARCH_HAS_OPP=y +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_OMAP=y +# CONFIG_ARCH_OMAP1 is not set +# CONFIG_ARCH_OMAP2 is not set +CONFIG_ARCH_OMAP2PLUS=y +CONFIG_ARCH_OMAP2PLUS_TYPICAL=y +# CONFIG_ARCH_OMAP3 is not set +CONFIG_ARCH_OMAP4=y +# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set +CONFIG_ARCH_REQUIRE_GPIOLIB=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +# CONFIG_ARCH_SUPPORTS_MSI is not set +CONFIG_ARCH_SUSPEND_POSSIBLE=y +# CONFIG_ARCH_USES_GETTIMEOFFSET is not set +CONFIG_ARM=y +CONFIG_ARM_CPU_SUSPEND=y +# CONFIG_ARM_ERRATA_430973 is not set +# CONFIG_ARM_ERRATA_458693 is not set +# CONFIG_ARM_ERRATA_460075 is not set +CONFIG_ARM_ERRATA_720789=y +# CONFIG_ARM_ERRATA_742230 is not set +# CONFIG_ARM_ERRATA_742231 is not set +# CONFIG_ARM_ERRATA_743622 is not set +# CONFIG_ARM_ERRATA_751472 is not set +# CONFIG_ARM_ERRATA_754322 is not set +# CONFIG_ARM_ERRATA_754327 is not set +# CONFIG_ARM_ERRATA_764369 is not set +CONFIG_ARM_GIC=y +CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_ARM_L1_CACHE_SHIFT_6=y +# CONFIG_ARM_LPAE is not set +CONFIG_ARM_NR_BANKS=8 +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_THUMB=y +# CONFIG_ARM_THUMBEE is not set +# CONFIG_ATH_COMMON is not set +# CONFIG_ATMEL_PWM is not set +CONFIG_AVERAGE=y +CONFIG_BCMA_POSSIBLE=y +CONFIG_BOUNCE=y +CONFIG_CACHE_L2X0=y +CONFIG_CACHE_PL310=y +CONFIG_CFG80211=m +# CONFIG_CFG80211_DEBUGFS is not set +CONFIG_CFG80211_DEFAULT_PS=y +# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set +# CONFIG_CFG80211_INTERNAL_REGDB is not set +# CONFIG_CFG80211_REG_DEBUG is not set +CONFIG_CFG80211_WEXT=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_MMIO=y +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_CPU_32v6K=y +CONFIG_CPU_32v7=y +CONFIG_CPU_ABRT_EV7=y +# CONFIG_CPU_BPREDICT_DISABLE is not set +CONFIG_CPU_CACHE_V7=y +CONFIG_CPU_CACHE_VIPT=y +CONFIG_CPU_COPY_V6=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y +CONFIG_CPU_HAS_ASID=y +CONFIG_CPU_HAS_PMU=y +# CONFIG_CPU_ICACHE_DISABLE is not set +CONFIG_CPU_PABRT_V7=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_TLB_V7=y +CONFIG_CPU_V7=y +CONFIG_CRC16=y +CONFIG_CRYPTO_AES=m +CONFIG_CRYPTO_ALGAPI=m +CONFIG_CRYPTO_ALGAPI2=m +CONFIG_CRYPTO_ARC4=m +# CONFIG_DEBUG_HIGHMEM is not set +# CONFIG_DEBUG_USER is not set +CONFIG_DECOMPRESS_LZMA=y +CONFIG_DUMMY_CONSOLE=y +# CONFIG_DW_WATCHDOG is not set +CONFIG_EXT4_FS=y +CONFIG_FB=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_IMAGEBLIT=y +CONFIG_FB_MODE_HELPERS=y +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +CONFIG_FB_OMAP2_NUM_FBS=3 +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +# CONFIG_FB_SM7XX is not set +CONFIG_FB_TILEBLITTING=y +# CONFIG_FB_WMT_GE_ROPS is not set +CONFIG_FIRMWARE_EDID=y +# CONFIG_FONTS is not set +CONFIG_FONT_8x16=y +CONFIG_FONT_8x8=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +CONFIG_FRAME_POINTER=y +CONFIG_FS_MBCACHE=y +CONFIG_GENERIC_BUG=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_GENERIC_CPU_DEVICES is not set +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_TWL4030=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +CONFIG_HAVE_AOUT=y +CONFIG_HAVE_ARCH_KGDB=y +CONFIG_HAVE_ARCH_PFN_VALID=y +CONFIG_HAVE_ARM_SCU=y +CONFIG_HAVE_ARM_TWD=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_GENERIC_HARDIRQS=y +CONFIG_HAVE_IRQ_WORK=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_HAVE_KERNEL_XZ=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_HAVE_PROC_CPU=y +CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y +CONFIG_HAVE_SCHED_CLOCK=y +CONFIG_HAVE_SMP=y +CONFIG_HAVE_SPARSE_IRQ=y +CONFIG_HIGHMEM=y
[OpenWrt-Devel] uClibc++ fails to compile on trunk?
Hello,
I don't know if this is dependant on my setup or not, but I'm failing
to compile uClibc++.
~$ svn info
Path: .
URL: svn://svn.openwrt.org/openwrt/trunk
Repository Root: svn://svn.openwrt.org/openwrt
Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73
Revision: 31481
Node Kind: directory
Schedule: normal
Last Changed Author: hauke
Last Changed Rev: 31481
Last Changed Date: 2012-04-25 22:32:17 +0200 (Wed, 25 Apr 2012)
I attached the output of
~$ cat .config | grep -Ev ^#|^$ ../config-panda-3.3
as my setup includes both the packages and the feeds feeds (and thus
is quite long, with many unselected options). Please disregard the fact
that I'm using a 3.3 kernel - the same errors also happen on the 3.2
kernel as it's independant of the kernel version.
A few hand-picked options:
CONFIG_TARGET_omap4=y
CONFIG_TARGET_BOARD=omap4
CONFIG_SOFT_FLOAT=y
CONFIG_NEED_TOOLCHAIN=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_BINUTILS_VERSION_2_22=y
CONFIG_GCC_VERSION_4_7_LINARO=y
CONFIG_EXTRA_GCC_CONFIG_OPTIONS=
CONFIG_INSTALL_LIBSTDCPP=y
CONFIG_USE_UCLIBC=y
CONFIG_UCLIBC_VERSION_0_9_33=y
CONFIG_GCC_VERSION=4.7-linaro
CONFIG_GCC_VERSION_4_7=y
CONFIG_UCLIBC_VERSION=0.9.33
CONFIG_LIBC=uClibc
CONFIG_LIBC_VERSION=0.9.33
The compilation error is in attached file uclibc++.errors
~$ make V=1 package/feeds/libs/uclibc++/{clean,compile} \
../uclibc++.errors 21
The error might be related to the gcc version (4.7-linaro). As
I write this, I'm trying another toolchaine (4.6-linaro). If that
fails too, I'll try some other toolchains as well, but I'll be less
optimistic on the results.
Has anyone else met this issue? The uClibc++ git does not show
anything that looks like gcc 4.7 bug correction, not patch has
been published to address this specific problem, and it seems
weird to me that g++ 4.7 refuses to compile a code that is
seemingly fine (although the specific error makes sense for the
C++ folks ; stuff about dependant type lookup is always very
dependant on the compiler and ameliorations in compilers may
very often break code in these areas).
Best regards,
-- Emmanuel Deloget
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_TARGET_omap4=y
CONFIG_TARGET_omap4_Default=y
CONFIG_TARGET_BOARD=omap4
CONFIG_TARGET_ARCH_PACKAGES=omap4
CONFIG_DEFAULT_TARGET_OPTIMIZATION=-Os -pipe -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=softfp
CONFIG_LINUX_3_3=y
CONFIG_DEFAULT_base-files=y
CONFIG_DEFAULT_busybox=y
CONFIG_DEFAULT_dropbear=y
CONFIG_DEFAULT_hotplug2=y
CONFIG_DEFAULT_libc=y
CONFIG_DEFAULT_libgcc=y
CONFIG_DEFAULT_mtd=y
CONFIG_DEFAULT_opkg=y
CONFIG_DEFAULT_uci=y
CONFIG_AUDIO_SUPPORT=y
CONFIG_GPIO_SUPPORT=y
CONFIG_USB_SUPPORT=y
CONFIG_USES_TARGZ=y
CONFIG_arm=y
CONFIG_ARCH=arm
CONFIG_EXTERNAL_CPIO=
CONFIG_TARGET_ROOTFS_TARGZ=y
CONFIG_TARGET_ROOTFS_EXT4FS=y
CONFIG_TARGET_ROOTFS_SQUASHFS=y
CONFIG_TARGET_IMAGES_GZIP=y
CONFIG_TARGET_ROOTFS_PARTSIZE=48
CONFIG_TARGET_ROOTFS_MAXINODE=6000
CONFIG_DISPLAY_SUPPORT=y
CONFIG_BUILD_PATENTED=y
CONFIG_SHADOW_PASSWORDS=y
CONFIG_KERNEL_DEBUG_FS=y
CONFIG_KERNEL_MAGIC_SYSRQ=y
CONFIG_KERNEL_ELF_CORE=y
CONFIG_KERNEL_PRINTK_TIME=y
CONFIG_IPV6=y
CONFIG_USE_STRIP=y
CONFIG_STRIP_ARGS=--strip-all
CONFIG_DEVEL=y
CONFIG_DOWNLOAD_FOLDER=
CONFIG_LOCALMIRROR=
CONFIG_AUTOREBUILD=y
CONFIG_BUILD_SUFFIX=
CONFIG_TARGET_ROOTFS_DIR=
CONFIG_EXTERNAL_KERNEL_TREE=
CONFIG_KERNEL_GIT_CLONE_URI=
CONFIG_KERNEL_GIT_LOCAL_REPOSITORY=
CONFIG_TARGET_OPTIMIZATION=-Os -pipe -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=softfp
CONFIG_SOFT_FLOAT=y
CONFIG_NEED_TOOLCHAIN=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_BINUTILS_VERSION_2_22=y
CONFIG_EXTRA_BINUTILS_CONFIG_OPTIONS=
CONFIG_BINUTILS_VERSION=2.22
CONFIG_GCC_VERSION_4_7_LINARO=y
CONFIG_EXTRA_GCC_CONFIG_OPTIONS=
CONFIG_INSTALL_LIBSTDCPP=y
CONFIG_USE_UCLIBC=y
CONFIG_UCLIBC_VERSION_0_9_33=y
CONFIG_GDB=y
CONFIG_GCC_DEFAULT_VERSION_4_6_LINARO=y
CONFIG_GCC_VERSION=4.7-linaro
CONFIG_GCC_VERSION_4_7=y
CONFIG_UCLIBC_VERSION=0.9.33
CONFIG_LIBC=uClibc
CONFIG_LIBC_VERSION=0.9.33
CONFIG_TARGET_SUFFIX=uclibcgnueabi
CONFIG_TARGET_PREINIT_SUPPRESS_STDERR=y
CONFIG_TARGET_PREINIT_TIMEOUT=2
CONFIG_TARGET_PREINIT_IFNAME=
CONFIG_TARGET_PREINIT_IP=192.168.1.1
CONFIG_TARGET_PREINIT_NETMASK=255.255.255.0
CONFIG_TARGET_PREINIT_BROADCAST=192.168.1.255
CONFIG_TARGET_INIT_PATH=/bin:/sbin:/usr/bin:/usr/sbin
CONFIG_TARGET_INIT_ENV=
CONFIG_TARGET_INIT_CMD=/sbin/init
CONFIG_TARGET_INIT_SUPPRESS_STDERR=y
CONFIG_FEATURE_drawing-backend_DirectFB=y
CONFIG_PACKAGE_base-files=y
CONFIG_PACKAGE_base-files-network=y
CONFIG_EXTROOT_SETTLETIME=20
CONFIG_PACKAGE_busybox=y
CONFIG_BUSYBOX_CONFIG_HAVE_DOT_CONFIG=y
CONFIG_BUSYBOX_CONFIG_INCLUDE_SUSv2=y
CONFIG_BUSYBOX_CONFIG_PLATFORM_LINUX=y
CONFIG_BUSYBOX_CONFIG_FEATURE_BUFFERS_GO_ON_STACK=y
CONFIG_BUSYBOX_CONFIG_SHOW_USAGE=y
CONFIG_BUSYBOX_CONFIG_FEATURE_VERBOSE_USAGE=y
CONFIG_BUSYBOX_CONFIG_FEATURE_COMPRESS_USAGE=y
CONFIG_BUSYBOX_CONFIG_LONG_OPTS=y
CONFIG_BUSYBOX_CONFIG_FEATURE_DEVPTS=y
CONFIG_BUSYBOX_CONFIG_FEATURE_PIDFILE=y
CONFIG_BUSYBOX_CONFIG_FEATURE_SUID=y
Re: [OpenWrt-Devel] uClibc++ fails to compile on trunk?
Le 27/04/2012 15:01, Jo-Philipp Wich a écrit : Yes, its a known issue. See https://dev.openwrt.org/ticket/11341 and http://freetz.org/browser/trunk/make/libs/uclibcxx/patches/050-gcc47x-proper-two-phase-lookup.uclibcxx.patch ~ Jow Doh!... I forgot to get a look at the trac. My bad. Sorry for the noise then... -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
of my machine at home (or unless I give you that information myself, for example by visiting a web site with a particular device) it will be very difficult for you to know how much and waht kind of devices I own - limiting your attacks to guesses in the first place. Give me IPv6 public addresses and all you have to do is not nmap my address space. There's a reason for the existence of an IPv6 NAT implementation in Linux [2][3]. Sorry for the derailing. That were my 2 cents, you are free to discard those arguments (or to mock them, if you feel you must do that :)). Best regards, -- Emmanuel Deloget [1] https://www.google.fr/search?q=zigbee+soc [2] http://lwn.net/Articles/452293/ [3] http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/39974 (*) there are other cases of security by obscurity that works well. One of them involves asymetric cryptography and keep your private key private. So, please, don't tell me it's a bad thing :) ___ 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
Hello, snip things about PKG_VERSION and so on Le 19/04/2012 18:40, Emmanuel Deloget a écrit : I have no idea on how we can fix this, other than setting the correct version numbers in the CONFIG_EGLIBC_VERSION. I can provide a patch to fix the current state, but that would not make much sense if 2.12 is to be removed from the tree. Of course, such a patch shall also cure the problem when the user handpick a revision in the eglibc trunk (but again, this might be removed as well). No answer on that, so I submit and you decide. I think the best course of action is to re-fetch the source in those cases: * if the package is not prepared yet (i.e. if the user cleans the package or before the package is built for the first time). * if the package fails to compile But we should avoid re-fetching the source once the package has been successfully built. For packages, these conditions can be factorized into the following one: $(PKG_BUILD_DIR)/.built exists. No patch for this, as I didn't come with any working and elegant solution. 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. Fine with me. That was just yet another idea :) Do you want me to resubmit a patch without OPENWRT_BLEEDING_EDGE? No response on this subject, so I'll submit, and you'll decice :) I'm going to post 3 patches. The first one correct the current compilation issues. It's indepependant of the other patches (but rely on the SVN revision to be correctly defined, otherwise it won't work ; so applying either patch 2 or 3 is still a good idea otherwise the user might break things by selecting bad eglibc revisions). The second one disable the possibility to select a specific revision for known versions of eglibc. The third one provide the same functionnality, and removes the possibility to select the trunk version. Of course, this patch is not compatible with the previous one, so you either apply 1 and 2 or you apply 1 and 3 - but not 1, 2 and 3. All patches will be posted in the next 10/15 minutes. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3 V1] correct eglibc version numbers
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 Index: toolchain/eglibc/Config.version === --- toolchain/eglibc/Config.version (révision 31444) +++ toolchain/eglibc/Config.version (copie de travail) @@ -1,7 +1,7 @@ config EGLIBC_VERSION string depends on USE_EGLIBC - default 2.12 if EGLIBC_VERSION_2_12 + default 2.12.2 if EGLIBC_VERSION_2_12 default 2.13 if EGLIBC_VERSION_2_13 - default 2.14 if EGLIBC_VERSION_2_14 + default 2.14.1 if EGLIBC_VERSION_2_14 default trunk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3 V1] disable SVN revision selection for non-trunk eglibc
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 while it still provide the functionnality if the selected version is the eglibc trunk. Some labels are modified in the process to clarify the system. Signed-off-by: Emmanuel Deloget log...@free.fr Index: toolchain/eglibc/Config.in === --- toolchain/eglibc/Config.in (révision 31444) +++ toolchain/eglibc/Config.in (copie de travail) @@ -18,18 +18,23 @@ depends !GCC_VERSION_LLVM config EGLIBC_VERSION_TRUNK - bool eglibc trunk + bool eglibc SVN trunk endchoice +config EGLIBC_TRUNK_REVISION + string + prompt eglibc SVN trunk 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 EGLIBC_TRUNK_REVISION if EGLIBC_VERSION_TRUNK default menu eglibc configuration ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3 V1] remove the possibility to select eglibc trunk and disable eglibc SVN revision selection
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 Index: toolchain/eglibc/Config.version === --- toolchain/eglibc/Config.version (révision 31444) +++ toolchain/eglibc/Config.version (copie de travail) @@ -4,4 +4,4 @@ default 2.12.2 if EGLIBC_VERSION_2_12 default 2.13 if EGLIBC_VERSION_2_13 default 2.14.1 if EGLIBC_VERSION_2_14 - default trunk + default 2.13 Index: toolchain/eglibc/Config.in === --- toolchain/eglibc/Config.in (révision 31444) +++ toolchain/eglibc/Config.in (copie de travail) @@ -17,19 +17,14 @@ bool eglibc 2.14 depends !GCC_VERSION_LLVM - config EGLIBC_VERSION_TRUNK - bool eglibc trunk - endchoice 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 menu eglibc configuration Index: toolchain/eglibc/Makefile === --- toolchain/eglibc/Makefile (révision 31444) +++ toolchain/eglibc/Makefile (copie de travail) @@ -24,9 +24,6 @@ ifneq ($(CONFIG_EGLIBC_VERSION_2_14),) PKG_SOURCE_URL:=svn://svn.eglibc.org/branches/eglibc-2_14 endif -ifneq ($(CONFIG_EGLIBC_VERSION_TRUNK),) - PKG_SOURCE_URL:=svn://svn.eglibc.org/trunk -endif PATCH_DIR:=./patches/$(PKG_VERSION) ___ 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
Le 18/04/2012 23:17, Peter Naulls a écrit : On 04/17/2012 11:15 AM, Mirko Vogt wrote: Hey Emmanuel, I levelled up all versions of eglibc to i'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. 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. Checked with 2.13, and it indeed works. 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. 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: -8--- 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 ___ 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
Le 19/04/2012 15:02, Mirko Vogt a écrit :
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 Delogetlog...@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/.
Good catch. In fact, HEAD is likely to never be the right choice, even
in other packages. So maybe we can forbid it?
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
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?
I believe that having a way to fetch a development version of eglibc
makes sense in the OpenWRT trunk (but makes far less sense in the
backfire branch). In the proposal below, I added a config option to
reflect that (obviously, this config option shall be n on stable
branches).
Changing the prompts in the Config.in file helps to make this clearer
---8-
Force the use of known revision for specific eglibc versions.
Eglibc revision can only be changed if the user wants it (this patch
makes this choice much clear).
Since this is probably not a good thing to allow that on stable
branches, we add a new config symbol whose value is supposed to
be y on bleeding edge OpenWRT, and n on stable branches).
Signed-off-by: Emmanuel Deloget log...@free.fr
Index: Config.in
===
--- Config.in (révision 31345)
+++ Config.in (copie de travail)
@@ -10,6 +10,10 @@
bool
default y
+config OPENWRT_BLEEDING_EDGE
+ bool
+ default y
+
source target/Config.in
menu Target Images
Index: toolchain/eglibc/Config.in
===
--- toolchain/eglibc/Config.in (révision 31345)
+++ toolchain/eglibc/Config.in (copie de travail)
@@ -18,19 +18,32 @@
depends !GCC_VERSION_LLVM
config EGLIBC_VERSION_TRUNK
- bool eglibc trunk
+ bool specific SVN revision on trunk
+ depends OPENWRT_BLEEDING_EDGE
endchoice
+config EGLIBC_TRUNK_REVISION
+ string
+ prompt eglibc SVN revision
+ depends on TOOLCHAINOPTS USE_EGLIBC EGLIBC_VERSION_TRUNK
+ default HEAD
+ help
Re: [OpenWrt-Devel] eglibc 2.12 fails to build
Le 19/04/2012 16:40, Mirko Vogt a écrit : 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. My fingers are sometimes too fast for my brain. The resulting code often contain bugs - and the resulting email often contain junk. Brain says ok, I've read that but the fingers have already types some kind of nonsensical answer. I apologize. I also just found another issue with HEAD (in this specific case): we are not able to correctly specify LIBC_SO_VERSION, meaning that building base-files fails (as we cannot copy the libc shared library). $ grep EGLIBC_ .config | grep -v OPTION # CONFIG_EGLIBC_VERSION_2_12 is not set # CONFIG_EGLIBC_VERSION_2_13 is not set # CONFIG_EGLIBC_VERSION_2_14 is not set CONFIG_EGLIBC_VERSION_TRUNK=y CONFIG_EGLIBC_TRUNK_REVISION=HEAD CONFIG_EGLIBC_REVISION=HEAD CONFIG_EGLIBC_VERSION=trunk $ 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-trunk.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 Culprit is toolchain/eglibc/Makefile line 79: define Host/SetToolchainInfo $(SED) 's,^\(LIBC_TYPE\)=.*,\1=$(PKG_NAME),' $(TOOLCHAIN_DIR)/info.mk $(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.eglibc.org/,' $(TOOLCHAIN_DIR)/info.mk $(SED) 's,^\(LIBC_VERSION\)=.*,\1=$(PKG_VERSION),' $(TOOLCHAIN_DIR)/info.mk $(SED) 's,^\(LIBC_SO_VERSION\)=.*,\1=$(PKG_VERSION),' $(TOOLCHAIN_DIR)/info.mk endef Since PKG_VERSION is set to CONFIG_EGLIBC_VERSION, it cannot work. In fact, it works only in very specific cases - i.e. where the version is not a maintenance release. Maintenance releases have a version number of the form x.y.z and CONFIG_EGLIBC_VERSION is x.y only - it's missing a micro version part. As a consequence, both LIBC_VERSION and LIBC_SO_VERSION will be wrong if the selected revision refer to a maintenance release (this is the case for at least 2.12, which is really 2.12.2). I have no idea on how we can fix this, other than setting the correct version numbers in the CONFIG_EGLIBC_VERSION. I can provide a patch to fix the current state, but that would not make much sense if 2.12 is to be removed from the tree. Of course, such a patch shall also cure the problem when the user handpick a revision in the eglibc trunk (but again, this might be removed as well). 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. Unfortunately, it's not enough to get the work done, as the build system really wants the archive to be present - if I don't save the file, I get the following error: Aeglibc-trunk-rHEAD/localedef/config.sub Aeglibc-trunk-rHEAD/localedef/vasprintf.c Aeglibc-trunk-rHEAD/localedef/install-sh Exported revision 18123. bzcat: Can't open input file /home/me/openwrt/trunk/dl/eglibc-trunk-rHEAD.tar.bz2: No such file or directory. /bin/tar: This does not look like a tar archive /bin/tar: Exiting with failure status due to previous errors I think the best course of action is to re-fetch the source in those cases: * if the package is not prepared yet (i.e. if the user cleans the package or before the package is built for the first time). * if the package fails to compile But we should avoid re-fetching the source once the package has been successfully built. For packages, these conditions can be factorized into the following one: $(PKG_BUILD_DIR)/.built exists. We have a similar file in I just tested the following: Index: include/download.mk === --- include/download.mk (révision 31345) +++ include/download.mk (copie de travail) @@ -176,8 +176,13 @@ ) download: $(DL_DIR)/$(FILE) + ifeq ($(strip $(VERSION)),HEAD) + .PHONY: $(DL_DIR)/$(FILE) + endif + $(DL_DIR)/$(FILE): mkdir -p $(DL_DIR) + [ ! -f $(DL_DIR)/$(FILE) ] || rm -f $(DL_DIR)/$(FILE
Re: [OpenWrt-Devel] RE : Re: eglibc 2.12 fails to build
Le 17/04/2012 23:07, Luka Perkov a écrit :
On Tue, Apr 17, 2012 at 10:51:47PM +0200, Emmanuel Deloget wrote:
htmlhead
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
meta name=Generator content=Microsoft Exchange Server
!-- converted from text --
style!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #80 2px solid;
} --/style/head
body
bodyNo specific reason. That's just the default eglibc setting and some ticket seems to show that there are other issues with 2.13 (but then I did not read them very
carefully).brbrbrspan style=font-size:87%Envoy? depuis un mobile Samsung/span brbrbr Original message brSubject:
Re: [OpenWrt-Devel] eglibc 2.12 fails to buildbrFrom: Mirko Vogtlt;li...@nanl.degt;brTo: Emmanuel Delogetlt;emmanuel.delo...@efixo.comgt;,OpenWrt Development
Listlt;openwrt-devel@lists.openwrt.orggt;brCC:brbrbr/body
font size=2div class=PlainTextHey Emmanuel,br
br
I levelled up all versions of eglibc to it's latest revisions of itsbr
respective branches (a
href=https://dev.openwrt.org/changeset/31300;https://dev.openwrt.org/changeset/31300/a
) andbr
therewith I guess broke eglibc version 2.12 which I'd like to purge outbr
anyway. Is there any reason for you to stay on 2.12 instead of 2.13?br
If it idquot;because it doesn't/didn't workquot; please give it another try
andbr
let me know.br
br
Thanks,br
br
nbsp; mirkobr
br
On 04/17/2012 07:01 PM, Emmanuel Deloget wrote:br
gt; Hello,br
gt;br
gt; (working on trunk...)br
gt;br
gt; It seems (to me; I can be wrong) that patchbr
gt; 100-do-not-use-implicit-rules.patchbr
gt; for eglibc-2.12 is not needed, as this version already contains it.br
gt;br
gt; Can someone confirm this before I send a patch / open a ticket?br
gt;br
gt; Best regards,br
gt;br
gt; -- Emmanuel Delogetbr
gt; ___br
gt; openwrt-devel mailing listbr
gt; openwrt-devel@lists.openwrt.orgbr
gt;a
href=https://lists.openwrt.org/mailman/listinfo/openwrt-devel;https://lists.openwrt.org/mailman/listinfo/openwrt-devel/abr
br
/div/font
/body
/html
Please post using plain text only.
Luka
Ouch. I had no idea my smartphone was that dumb.
Sorry for that.
-- Emmanuel Deloget
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] eglibc 2.12 fails to build
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] RE : Re: eglibc 2.12 fails to build
No specific reason. That's just the default eglibc setting and some ticket seems to show that there are other issues with 2.13 (but then I did not read them very carefully).Envoyé depuis un mobile Samsung Original message Subject: Re: [OpenWrt-Devel] eglibc 2.12 fails to build From: Mirko Vogt li...@nanl.de To: Emmanuel Deloget emmanuel.delo...@efixo.com,OpenWrt Development List openwrt-devel@lists.openwrt.org CC: 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
[OpenWrt-Devel] [PATCH 1/1, V2] add klish package
Le 11/04/2012 08:52, serj.kalic...@gmail.com a écrit : Hello The recent version of klish is 1.5.4. It was released yesterday. The main aim of release is portability. But there are some another changes: bugfix, removing unnecessary library dependencies, code clean, autotools files fixes, changes in locking mechanism. So i recommend to use 1.5.4. I'm changing that. + klish is able to run using clish XML configuration files, and its + behavior differ in only one thing: clish allow a user to kill the current + running tack using Ctrl+C, while klish does not allow this by default + (meaning that individual tasks are atomic unless specified otherwise). The command interruption was an example only. I mean that XMLs are compatible but there are some diffirencies in behaviour. Not the interruption only. Another example is differencies in look and feel. Help ? andtab behaviour. So it's easy to adopt old clish XML configs for klish but the user must be ready for a little behaviour differencies. Thanks for the clarification - text updated (see below). Thanks. Best regards, -- Emmanuel Deloget ---8- The klish is a framework for implementing a CISCO-like CLI on a UNIX systems. It is configurable by XML files. The KLISH stands for Kommand Line Interface Shell. klish is an active fork of the clish program created by Graeme McKerrell. Signed-off by: Emmanuel Deloget log...@free.fr Index: packages/utils/klish/Makefile === --- packages/utils/klish/Makefile (révision 0) +++ packages/utils/klish/Makefile (révision 0) @@ -0,0 +1,96 @@ +# +# 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:=klish +PKG_VERSION:=1.5.4 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 +PKG_SOURCE_URL:=http://klish.googlecode.com/files +PKG_MD5SUM:=c98a1c65f7538c3f4687c6f8039295df + +PKG_INSTALL:=1 + +include $(INCLUDE_DIR)/package.mk + +define Package/klish/default + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Kommand Line Interface SHell ($(1)) + URL:=http://code.google.com/p/klish/ +endef + +define Package/klish +$(call Package/klish/default,main tool) + DEPENDS:=+libstdcpp +endef + +define Package/konf +$(call Package/klish/default,konf tool) + DEPENDS:=klish +endef + +define Package/klish/description + The klish is a framework for implementing a CISCO-like CLI on a UNIX + systems. It is configurable by XML files. The KLISH stands for Kommand + Line Interface Shell. + The klish is a fork of clish 0.7.3 developed by Graeme McKerrell. + It defines new features but it's compatible (as much as possible) with + clish's XML configuration files. + klish is able to run using clish XML configuration files although + current clish users may expect some changes in behavior. +endef + +define Package/konf/description + The klish is a framework for implementing a CISCO-like CLI on a UNIX + systems. It is configurable by XML files. The KLISH stands for Kommand + Line Interface Shell. + Konf and konfd are klish utilities that are used to store configuration + informations in a way which is similar to what's found on CISCO devices. + More information about these tools is to be found on the klish web site. +endef + +define Package/klish/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/clish $(1)/usr/bin/ + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/ +endef + +define Package/konf/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/konf $(1)/usr/bin/ + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/konfd $(1)/usr/bin/ + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libkonf.so* $(1)/usr/lib/ + $(CP) $(PKG_INSTALL_DIR)/usr/lib/liblub.so* $(1)/usr/lib/ +endef + +$(eval $(call BuildPackage,klish)) +$(eval $(call BuildPackage,konf)) + +define Package/klish-xml-files + SECTION:=utils + CATEGORY:=Utilities + DEPENDS:=klish + TITLE:=klish sample XML files + URL:=http://code.google.com/p/klish/ +endef + +define Package/klish-xml-files/description + This is a set of sample XML files for klish. This specific sample set + is compatible with the original clish. +endef + +define Package/klish-xml-files/install + $(INSTALL_DIR) $(1)/etc/clish + $(CP) $(PKG_BUILD_DIR)/xml-examples/clish $(1)/etc/clish/ +endef + +$(eval $(call BuildPackage,klish-xml-files)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] remove clish, support klish ?
(CC'ed to Vitkar and to the klish maintainer) clish (Command Line Interface SHell) support has been added a few weeks ago by Viktar [1] and commited a few days later in the packages repository. I use clish, so this is not a real issue for me. But clish is a seemingly dead project, with no update in the last two years (approx.). It has been forked at least onceand the fork seems to be a very active project [2] (I found it because I was about to create a similar fork on google code as well). Thus the questions: * does it make sense to keep clish in the packages repository? * should we replace it with klish? Best regards, -- Emmanuel Deloget [1] https://lists.openwrt.org/pipermail/openwrt-devel/2012-February/014277.html [2] http://code.google.com/p/klish/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] remove clish, support klish ?
Le 10/04/2012 13:27, serj.kalic...@gmail.com a écrit : Hello The XMLs are compatible. But there are some differencies in behaviour. For example the commands in klish are non-interruptible by Ctrl^C by default to make command execution atomic. The clish users can suppose the commands are interruptible. And so on. I think if someone really use clish it's not good to remove it Serj Kalichev On 10.04.2012 12:28, Viktar Palstsiuk wrote: Hello Emmanuel I'm not sure that clish and klish have 100% compatible XML configs. So I think that klish can simply be added in the packages repository without pushing out clish. I'm fine with this. I'll let other (Viktar or anyone else) decide what to do with clish. Next message will contain a patch with a request to add klish to the packages repository (this next message will not be CC'ed). On Tue, Apr 10, 2012 at 10:47 AM, Emmanuel Deloget emmanuel.delo...@efixo.com wrote: (CC'ed to Vitkar and to the klish maintainer) clish (Command Line Interface SHell) support has been added a few weeks ago by Viktar [1] and commited a few days later in the packages repository. I use clish, so this is not a real issue for me. But clish is a seemingly dead project, with no update in the last two years (approx.). It has been forked at least onceand the fork seems to be a very active project [2] (I found it because I was about to create a similar fork on google code as well). Thus the questions: * does it make sense to keep clish in the packages repository? * should we replace it with klish? Best regards, -- Emmanuel Deloget [1] https://lists.openwrt.org/pipermail/openwrt-devel/2012-February/014277.html [2] http://code.google.com/p/klish/ Thanks everyone ! -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1, V1] add klish package
The klish is a framework for implementing a CISCO-like CLI on a UNIX systems. It is configurable by XML files. The KLISH stands for Kommand Line Interface Shell. klish is an active fork of the clish program created by Graeme McKerrell. Signed-off by: Emmanuel Deloget log...@free.fr Index: packages/utils/klish/Makefile === --- packages/utils/klish/Makefile (révision 0) +++ packages/utils/klish/Makefile (révision 0) @@ -0,0 +1,99 @@ +# +# 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:=klish +PKG_VERSION:=1.5.3 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 +PKG_SOURCE_URL:=http://klish.googlecode.com/files +PKG_MD5SUM:=12109cac0e7429157987160d1b8732b6 + +PKG_INSTALL:=1 + +include $(INCLUDE_DIR)/package.mk + +define Package/klish/default + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Kommand Line Interface SHell ($(1)) + URL:=http://code.google.com/p/klish/ +endef + +define Package/klish +$(call Package/klish/default,main tool) + DEPENDS:=+libstdcpp +endef + +define Package/konf +$(call Package/klish/default,konf tool) + DEPENDS:=klish +endef + +define Package/klish/description + The klish is a framework for implementing a CISCO-like CLI on a UNIX + systems. It is configurable by XML files. The KLISH stands for Kommand + Line Interface Shell. + The klish is a fork of clish 0.7.3 developed by Graeme McKerrell. + It defines new features but it's compatible (as much as possible) with + clish's XML configuration files. + klish is able to run using clish XML configuration files, and its + behavior differ in only one thing: clish allow a user to kill the current + running tack using Ctrl+C, while klish does not allow this by default + (meaning that individual tasks are atomic unless specified otherwise). +endef + +define Package/konf/description + The klish is a framework for implementing a CISCO-like CLI on a UNIX + systems. It is configurable by XML files. The KLISH stands for Kommand + Line Interface Shell. + Konf and konfd are klish utilities that are used to store configuration + informations in a way which is similar to what's found on CISCO devices. + More information about these tools is to be found on the klish web site. +endef + +define Package/klish/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/clish $(1)/usr/bin/ + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/ +endef + +define Package/konf/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/konf $(1)/usr/bin/ + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/konfd $(1)/usr/bin/ + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libkonf.so* $(1)/usr/lib/ + $(CP) $(PKG_INSTALL_DIR)/usr/lib/liblub.so* $(1)/usr/lib/ +endef + +$(eval $(call BuildPackage,klish)) +$(eval $(call BuildPackage,konf)) + +define Package/klish-xml-files + SECTION:=utils + CATEGORY:=Utilities + DEPENDS:=klish + TITLE:=klish sample XML files + URL:=http://code.google.com/p/klish/ +endef + +define Package/klish-xml-files/description + This is a set of sample XML files for klish. This specific sample set + is compatible with the original clish. +endef + +define Package/klish-xml-files/install + $(INSTALL_DIR) $(1)/etc/clish + $(CP) $(PKG_BUILD_DIR)/xml-examples/clish $(1)/etc/clish/ +endef + +$(eval $(call BuildPackage,klish-xml-files)) + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] puzzling over hostapd behavior
Le 03/04/2012 13:21, Brian J. Murrell a écrit : On 12-04-03 04:52 AM, Dave Taht wrote: I was wondering why hostapd (on cerowrt 3.3) ate so much cpu, even when idle, nothing connected, no crypto enabled... I'm curious as to if this is correct behavior, and what's the point of writing 000s to /dev/random, Is it supposed to be feeding the entropy pool (i.e. perhaps from RF noise for example) for the kernel's random number generator? I'm really not sure if writing into /dev/random does feed the entropy pool or not, but just guessing here. Cheers, b. That's strange. Normally, if someone is to do that, then it shall be done in the kernel. Application tends to have a reproducible behavior that makes this entropy far more predictable than, say, the timing of generated wifi interrupts (if there are any). The fact is: writing bytes in /dev/random does NOT change the advertised entropy - it merely changes the bytes that are to be read. So this operation is likely a non-interesting one, as the bytes to read will be just as hard to predict with and without this op. See linux/driver/char/random.c for further reference [1]. Moreover, in this very, very specific case (where the application writes a predicatble number of 0s), an additional cryptoanalysis is very likely to be necessary: the pattern, when mixed in the random buffer, might in fact lower the real entropy delivered by the char device. IMHO, I would consider this as a possibly dangerous behavior, and I would probably remedy to this situation using a simple yet effective solution: removing the offending code, as it doesn't change anything in terms of security and functionnality. -- Emmanuel Deloget [1] the write_pool() function ends up calling mix_pool_bytes_extract(), which has the following comment: /* * This function adds bytes into the entropy pool. It does not * update the entropy estimate. The caller should call * credit_entropy_bits if this is appropriate. * * The pool is stirred with a primitive polynomial of the appropriate * degree, and then twisted. We twist by three bits at a time because * it's cheap to do so and helps slightly in the expected case where * the entropy is concentrated in the low-order bits. */ See http://lxr.linux.no/linux+v3.3.1/drivers/char/random.c#L456 for further information. Needless to say, write_pool() do not call credit_entropy_bits(), and therefore does not change the advertised entropy. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lighttpd-nossl (+PATCH, RFC)
Hello, My own two cents. I tried to implement it the VARIANT way, and I ended with (basically) repeating everything twice in the Makefile. See attached for details. If someone knows a better way, or if I messed up this patch, I'm ready to listen to criticism. Another way I tried (and I already posted the patches on this list [1]) is to use a CONFIG symbol that lets you choose wether you want to use openssl or not. The changes in the lighttpd Makefile are less invasive and the end result is quite similar (modulo the fact that you cannot build the two versions at the same time). Best regards, -- Emmanuel Deloget [1] http://patchwork.openwrt.org/patch/1924/ Le 19/03/2012 15:05, Peter Wagner a écrit : both packaes are build in a sepreate folders so yes - you can select both packages. But you can also building both and testing it ;) /Peter On Monday 19 March 2012 13:24:24 edgar.sol...@web.de wrote: had a look at irssi. does this actually work when both packages are selected? don't you end up with two packages both containing whatever was build first? ..ede On 19.03.2012 13:18, Peter Wagner wrote: Hi, look at the ctorrent or irssi Makefile. There you can see how to implement the nossl stuff in one Makefile. Regards, Peter On Monday 19 March 2012 12:05:31 Christiane Ruetten wrote: Hi Edgar, just to be explicit: the idea is to have lighttpd-nossl in the official repo so I can get away with distributing a single platform-independent opkg. So I was hoping that the current maintainer could simply add a -nossl build instead of me having to reproduce the complete build effort. What I could do, though, is provide for a package/lighttpd-nossl/ Makefile and company and someone else adds it to the official build system, but chances are that testing my changes, and generally making sure I didn't screw up might surpass the effort that a knowledgable maintainer requires for a copy/modify operation on the current package repo. I might be wrong there, and am grateful for any advice on how to proceed. Cheers, Christiane Am 19.03.12 11:30, schrieb edgar.sol...@web.de: On 19.03.2012 10:52, Christiane Ruetten wrote: Hi, would you be able to easily add a variant of the lighttpd package without the massive libopenssl dependency? It is almost completely filling up the flash in 4 MByte routers, leaving almost no headroom for further functionality, and https is not always required. I am currently in the process of rewriting the PirateBox wifi deaddrop service in an OpenWRT-friendly way. The current target router chosen by the PirateBox community is the TL-MR3020 which unfortunately only has 4 MByte flash. Installing just lighttpd with rewrite and cgi and minimal modules for USB storage takes the system from 1.4M to under 100K of free flash. hi christiane, take a look at the lighttpd makefile https://dev.openwrt.org/browser/packages/net/lighttpd/Makefile how webdav is build in as selectable package. you could do something similar to the currently hard coded openssl support. ..ede Index: packages/net/lighttpd/Makefile === --- packages/net/lighttpd/Makefile (révision 31021) +++ packages/net/lighttpd/Makefile (copie de travail) @@ -9,7 +9,7 @@ PKG_NAME:=lighttpd PKG_VERSION:=1.4.30 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=http://download.lighttpd.net/lighttpd/releases-1.4.x @@ -18,6 +18,8 @@ PKG_FIXUP:=libtool PKG_INSTALL:=1 +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) + include $(INCLUDE_DIR)/package.mk define Package/lighttpd/Default @@ -25,186 +27,340 @@ SECTION:=net CATEGORY:=Network URL:=http://www.lighttpd.net/ + TITLE:=A flexible and lightweight web server + MENU:=1 + DEPENDS:=+libpcre +libpthread endef define Package/lighttpd $(call Package/lighttpd/Default) - MENU:=1 - DEPENDS:=+libopenssl +libpcre +libpthread - TITLE:=A flexible and lightweight web server + DEPENDS+=+libopenssl + VARIANT:=ssl endef +define Package/lighttpd-nossl + $(call Package/lighttpd/Default) + TITLE+=(without SSL) + VARIANT:=nossl +endef + +define Package/lighttpd-module/Default + SUBMENU:=Web Servers/Proxies + SECTION:=net + CATEGORY:=Network + URL:=http://www.lighttpd.net/ + DEPENDS:=$(1) +endef + define Package/lighttpd-mod-access - $(call Package/lighttpd/Default) - DEPENDS:=lighttpd + $(call Package/lighttpd-module/Default,lighttpd) TITLE:=Access restrictions module endef define Package/lighttpd-mod-accesslog - $(call Package/lighttpd/Default) - DEPENDS:=lighttpd + $(call Package/lighttpd-module/Default,lighttpd) TITLE:=Access logging module endef define Package/lighttpd-mod-alias - $(call Package/lighttpd/Default) - DEPENDS:=lighttpd + $(call Package/lighttpd-module/Default,lighttpd) TITLE:=Directory alias module endef define Package/lighttpd-mod-auth - $(call Package
Re: [OpenWrt-Devel] [PATCH 1/1] v1: configure lighttpd with OpenSSL support only if the user asks for it
Hello, Le 28/02/2012 13:05, Emmanuel Deloget a écrit : SSL support adds a quite large dependency to lighttpd when compiled in. On a 32 bit platform, libcrypto is roughly 1MB, to which one must add the size of libssl (roughly 250KB). This is 2 to 5 times the size of a typical lighttpd embedded installation. SSL support is only needed if one enables the SSL engine in the lighttpd.conf configuration file. This patch introduces a configuration option that allows the user to choose whether or not he wants to compile SSL support in. It defaults to 'y' only if libopenssl is already selected (either by active selection or because libopenssl is a dependency of another package). Signed-off-by: Emmanuel Delogetlog...@free.fr Any news on that one ? Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] v1: configure lighttpd with OpenSSL support only if the user asks for it
SSL support adds a quite large dependency to lighttpd when compiled in. On a 32 bit platform, libcrypto is roughly 1MB, to which one must add the size of libssl (roughly 250KB). This is 2 to 5 times the size of a typical lighttpd embedded installation. SSL support is only needed if one enables the SSL engine in the lighttpd.conf configuration file. This patch introduces a configuration option that allows the user to choose whether or not he wants to compile SSL support in. It defaults to 'y' only if libopenssl is already selected (either by active selection or because libopenssl is a dependency of another package). Signed-off-by: Emmanuel Deloget log...@free.fr Index: packages/net/lighttpd/Makefile === --- packages/net/lighttpd/Makefile (révision 30750) +++ packages/net/lighttpd/Makefile (copie de travail) @@ -9,7 +9,7 @@ PKG_NAME:=lighttpd PKG_VERSION:=1.4.30 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=http://download.lighttpd.net/lighttpd/releases-1.4.x @@ -30,10 +30,21 @@ define Package/lighttpd $(call Package/lighttpd/Default) MENU:=1 - DEPENDS:=+libopenssl +libpcre +libpthread + DEPENDS:=+LIGHTTPD_SSL:libopenssl +libpcre +libpthread TITLE:=A flexible and lightweight web server endef +define Package/lighttpd/config +config LIGHTTPD_SSL + bool SSL support + depends on PACKAGE_lighttpd + default y if PACKAGE_libopenssl + help + Implements SSL support in lighttpd (using libopenssl). This + option is required if you enable the SSL engine in your + lighttpd confguration file. +endef + define Package/lighttpd-mod-access $(call Package/lighttpd/Default) DEPENDS:=lighttpd @@ -222,7 +233,6 @@ --without-lua \ --without-memcache \ --without-mysql \ - --with-openssl=$(STAGING_DIR)/usr \ --with-pcre \ --without-valgrind \ $(call autoconf_bool,CONFIG_IPV6,ipv6) @@ -230,6 +240,14 @@ CONFIGURE_VARS+= \ PCRE_LIB=-lpcre \ +ifneq ($(strip $(CONFIG_LIGHTTPD_SSL)),) + CONFIGURE_ARGS+= \ + --with-openssl=$(STAGING_DIR)/usr +else + CONFIGURE_ARGS+= \ + --without-openssl +endif + ifneq ($(SDK)$(CONFIG_PACKAGE_lighttpd-mod-webdav),) CONFIGURE_ARGS+= \ --with-webdav-locks \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] RE : Re: cc1: all warnings being treated as errors
Hello,On this particular case, a gcc bug report exists because this specific warning should not show when no other diagnostics are issued. I can't link to the exact report right now but a simple google search should show it. IIRC gcc-4.7 may behave more correctly.So the correct treatment is either to solve the bug or to use the specialized option to hide it (again, no link : phones are not that goog at multitasking).Best regards,-- EmmanuelEnvoyé depuis un mobile Samsung a écrit : Hello,Le lundi 13 février 2012 21:04:53, Nerijus Baliunas a écrit : Hello, I've updated from svn trunk and udpxy package no longer compiles: mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -fhonour-copts -msoft-float -I/a/openwrt/kamikaze/staging_dir/target-mipsel_r2_uClibc-0.9.33/usr/inclu de -I/a/openwrt/kamikaze/staging_dir/target-mipsel_r2_uClibc-0.9.33/include -I/a/openwrt/kamikaze/staging_dir/toolchain-mipsel_r2_gcc-4.6-linaro_uClib c-0.9.33/usr/include -I/a/openwrt/kamikaze/staging_dir/toolchain-mipsel_r2_gcc-4.6-linaro_uClib c-0.9.33/include -W -Wall -Werror --pedantic -W -Wall -Werror --pedantic -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE -c udpxy.c -o udpxy.o udpxy.c: In function 'accept_requests': udpxy.c:914:25: error: variable 'rc' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors Was this change (all warnings being treated as errors) intentional? Yes, updating the toolchain to gcc-4.6 implies that more warnings are turned on by default by the compiler. Do we expect all packages to have no warnings?Yes, or either selectively build with Wno-error to disable warnings as errors. Usually these warnings are caused by genuine bugs or unused variables/functions, so fixing them are beneficial in any case.--Florian___openwrt-devel mailing listopenwrt-devel@lists.openwrt.orghttps://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] Let's fix the OpenWrt patch acceptance problem!
Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit : On 24/01/12 08:22, Dave Taht wrote: My principal critique of this workflow is that I tend to view svn as part of the problem to a large extent. If I do a patch in my own (git) tree to test with, I invariably have to rebase that tree when it comes down from svn. as I am frequently offline, not being able to do a 'svn log' is the second deal-killer for me, for svn usage. I also see svn as part of the problem. I think a move towards the linux-kernel development model would be a great benefit. Using git would allow users to make many small fixes in their own tree and send single a pull request for fixes to x,y and z to a member of the patch review team for ACK or NAK who can then commit to master. Hopefully this will result in fewer stray patches. The original user will then show up in git blame and will make tracing errors far easier. Currently, unless you have commit rights, everything comes from one of the few core developers and you have to manually look up the changeset to figure out who is responsible for it. I would also give my vote to git, as this solution proved to be far more scalable than svn. Since importing an svn tree to git is quite easy, and since trac proposed a git connector, such a move should be nearly painless (unless you have the full openwrt svn as an svn:external in your own tree). Jon ___ 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] [RFC] + [PATCH, V1] Reorder package dependencies
Le 12/15/2011 07:15 PM, Nico a écrit :
Hi,
On Thu, Dec 15, 2011 at 5:51 PM, Emmanuel Deloget
emmanuel.delo...@efixo.com wrote:
Hi everybody,
I recently faced an issue related to package dependencies that drove me
nuts. Consider the following case :
* I manage different platforms (let's say platform1 and platform2)
* On platform1, packageX depends on pkgdep, which should be autoselected
when I select packageX.
* On platform2, packageX also depends on pkgdep, which should be
autoselected when I select packageX.
* On all other platforms, packageX shall not depends on anything.
The current solution is to handle that using the package dependencies
define Package/packageX
TITLE:=PackageX
MAINTAINER:=me
SECTIONS:=utils
CATEGORY:=Utils
URL:=http://somewhere/
DEPENDS:=+TARGET_platform1:pkgdep +TARGET_platform2:pkgdep
endef
Have you tried the following?
DEPENDS:=+(TARGET_platform1||TARGET_platform2):pkgdep
I forgot to mention that.
Yes, I tried, but then metadata.pl tries to create the following condition:
$(if $(CONFIG_(TARGET_platform1||TARGET_platform2)),$(curdir).../pkgdep)
metadata.pl takes the full condition to create the CONFIG_ symbol.
--
-{Nico}
Best regards,
-- Emmanuel Deloget
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH,V1] correct tar link
When we create the /bin/tar in $(IPKG_INSTROOT) link we want it to point to
/usr/bin/tar, and not to $(IPKG_INSTROOT)/usr/bin/tar as $(IPKG_INSTROOT)
is certainly not a valid path on the built rootfs.
Signed-off-by: Emmanuel Deloget log...@free.fr
Index: packages/utils/tar/Makefile
===
--- packages/utils/tar/Makefile (revision 29557)
+++ packages/utils/tar/Makefile (working copy)
@@ -37,7 +37,7 @@
if [ -e $${IPKG_INSTROOT}/bin/tar ]; then
rm -r $${IPKG_INSTROOT}/bin/tar;
fi
-ln -sf $${IPKG_INSTROOT}/usr/bin/tar $${IPKG_INSTROOT}/bin/tar
+ln -sf /usr/bin/tar $${IPKG_INSTROOT}/bin/tar
endef
define Package/tar/postrm
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] + [PATCH, V1] Reorder package dependencies
Hi everybody,
I recently faced an issue related to package dependencies that drove me
nuts. Consider the following case :
* I manage different platforms (let's say platform1 and platform2)
* On platform1, packageX depends on pkgdep, which should be autoselected
when I select packageX.
* On platform2, packageX also depends on pkgdep, which should be
autoselected when I select packageX.
* On all other platforms, packageX shall not depends on anything.
The current solution is to handle that using the package dependencies
define Package/packageX
TITLE:=PackageX
MAINTAINER:=me
SECTIONS:=utils
CATEGORY:=Utils
URL:=http://somewhere/
DEPENDS:=+TARGET_platform1:pkgdep +TARGET_platform2:pkgdep
endef
I have a more concrete case, where one of my package depends on libatomics
on the architecture where the GCC atomic primitives are not supported (this
is a very real case).
Unfortunately, and despite this is apparently the solution to my
particular problem, this doesn't work at all - because pkgdep is only
considered once when we build the dependencies of packageX/compile.
In the example case, tmp/.packagedeps have the following line:
$(curdir)/feeds/myfeeds/packageX/compile: \
$(if $(CONFIG_TARGET_platform1),$(curdir)/feeds/myfeeds/pkgdep/compile)
(split in two lines for the sake of readability).
There is no mention of platform2, meaning that if I try to build packageX
for this target, the build is very likely to fail.
The problem lies in scripts/metadata.pl ; when the script builds the
tmp/.packagedeps file, it consider $(DEPENDS) then $(PKG_BUILD_DEPENDS).
In order to avoid multiple check of the same package, a package in included
in the dependency list only if it has not been specified yet, regardless of
the condition that may trigger its build.
I fully understand that: in order to build a correct dependency list in this
case, one would have to build the full condition tree. Failure to do that means
that a condition might be set to y because another condition in the list is
valid (in practice, this can happen for big targets). An exemple will help you
to get the point here:
CONFIG_symbol1=y
CONFIG_symbol2=y only if CONFIG_symbol1=y
DEPENDS:= +symbol1:pkg +symbol2:pkg
Will check twice if pkg has been build. This may or may not be acceptable.
The generation of tmp/.config-package.in is not affected by this issue: all
conditions are considered.
I have a workaround for this, which leverage the patch that I propose below
that reorders DEPENDS and PKG_BUILD_DEPENDS. On standard packages, this
workaround changes nothing (dependencies are still built in roughly the
same order). On convoluted packages like the one I mentionned earlier,
putting PKG_BUILD_DEPENDS first allows me to use another conditional notation
that takes advantage of the fact that package selection works as intended.
Let's take an example (I think it will be easier, because I feel that I'm
not as clear as I should be). I rewrite my example above:
PKG_BUILD_DEPENDS = PACKAGE_pkgdep:pkgdep
define Package/packageX
TITLE:=PackageX
MAINTAINER:=me
SECTIONS:=utils
CATEGORY:=Utils
URL:=http://somewhere/
DEPENDS:=+TARGET_platform1:pkgdep +TARGET_platform2:pkgdep
endef
Remember that metadata.pl only consider the first occurence of the package
name it finds in the list built with DEPENDS+PKG_BUILD_DEPENDS. Without
the reorder of these two variables, the first occurence has the condition
TARGET_platform1 - thus we'll only build the dependency on platform1 and
it will not be built on platform2.
If we exchange the position of DEPENDS and PKG_BUILD_DEPENDS, the first
occurence has the condition PACKAGE_pkgdep - thus, the depencendy will be
built if the package is selected. Since the DEPENDS line forces the
selection of the package on all platforms where it is needed, we always
build the dependency when it is needed.
Again, this shall not change anything on the existing packages, as most
of them do not use conditions on dependencies. A very small number define
a PKG_BUILD_DEPENDS rule - and those which do
There are cases where the dependency can be selected and we're not on
the platform. This is not a problem - it might be built a bit earlier but
it's still built only once.
Cldt,
-- Emmanuel Deloget
--
Change the order in which package dependencies are considered while
building the packages dependency rules.
Signed-off-by: Emmanuel Deloget log...@free.fr
--
Index: scripts/metadata.pl
===
--- scripts/metadata.pl (revision 29541)
+++ scripts/metadata.pl (working copy)
@@ -670,7 +670,7 @@
}
foreach my $spkg (@{$srcpackage{$pkg-{src}}}) {
- foreach my $dep (@{$spkg-{depends}}, @{$spkg-{builddepends}}) {
+ foreach my $dep (@{$spkg-{builddepends}}, @{$spkg-{depends}}) {
$dep =~ /@/ or do {
$dep =~ s
[OpenWrt-Devel] [PATCH 1/1, V1] define a symbol before use in scripts/config/symbol.c
This patch reorders the functions sym_set_changed() and sym_set_all_changed()
to place them before sym_calc_value() where the later is used in order to avoid
a symbol redefinition warning.
Signed-off-by: Emmanuel Deloget log...@free.fr
Index: scripts/config/symbol.c
===
--- scripts/config/symbol.c (révision 28798)
+++ scripts/config/symbol.c (copie de travail)
@@ -266,6 +266,26 @@
return NULL;
}
+void sym_set_changed(struct symbol *sym)
+{
+ struct property *prop;
+
+ sym-flags |= SYMBOL_CHANGED;
+ for (prop = sym-prop; prop; prop = prop-next) {
+ if (prop-menu)
+ prop-menu-flags |= MENU_CHANGED;
+ }
+}
+
+void sym_set_all_changed(void)
+{
+ struct symbol *sym;
+ int i;
+
+ for_all_symbols(i, sym)
+ sym_set_changed(sym);
+}
+
void sym_calc_value(struct symbol *sym)
{
struct symbol_value newval, oldval;
@@ -396,26 +416,6 @@
sym_calc_value(modules_sym);
}
-void sym_set_changed(struct symbol *sym)
-{
- struct property *prop;
-
- sym-flags |= SYMBOL_CHANGED;
- for (prop = sym-prop; prop; prop = prop-next) {
- if (prop-menu)
- prop-menu-flags |= MENU_CHANGED;
- }
-}
-
-void sym_set_all_changed(void)
-{
- struct symbol *sym;
- int i;
-
- for_all_symbols(i, sym)
- sym_set_changed(sym);
-}
-
bool sym_tristate_within_range(struct symbol *sym, tristate val)
{
int type = sym_get_type(sym);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/3, V4] Support for make xconfig
Forewords = This is a new version of the make xconfig patchset. Because I'm almost as good as a snail when it comes to sending patches, the previous versions were not usable. Hopefully, this version will be. It has been tested against trunk/r28798. Description === This patchset brings back the support for the xconfig top-level target. Since this target 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 xconfig/. Otherwise, a message will be printed when the user will try to execute this target. xconfig has nice properties that menuconfig does not have: * all-in-one screen: a menu tree, a list of CONFIG symbol to play with and the help of these symbols. * an improved search function that leads the user directly to the symbol he's searching for. The patches applies on svn://svn.openwrt.org/openwrt/trunk r28798 with patch -p0. ChangeLog = Changes since version 3 * in patch 1/3; the prototype of expr_print() changed in r28658. qconf.cc has been adapted to reflect the change. Changes since version 2 * patch 4/4 has been removed, and the series is now made of 3 patches 1/3, 2/3 and 3/3. * patch 2/3 has been corrected (added a missing rule) Changes since version 1: * in Patch 4/4: the missing changes from several important makefiles have been added back. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3, V4] qconf target in config/Makefile
This patch modifies the scripts/config/Makefile file to build the qconf utility. qconf is not added to the target list unless the development files of qt3 has been detected (we simply check for the presence of the /usr/include/qt3 directory). Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com Index: scripts/config/Makefile === --- scripts/config/Makefile (révision 28798) +++ 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,23 @@ 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 +endif + +lkc_defs.h: lkc_proto.h sed $ $@ 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' zconf.tab.c: zconf.y @@ -52,3 +66,6 @@ %.hash.c: %.gperf cp $@_shipped $@ || gperf $ $@ + +%.moc: %.h + cp $@_shipped $@ || moc -i $ -o $@ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3, V4] Toplevel xconfig target
This patch adds support for the xconfig top-level target. If qt3 is detected on the system (by checking for the presence of the directory /usr/include/qt3), the top-level target expands to the invocation of scripts/configs/qconf. Otherwise, the target prints a message and errors out. Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com Index: include/toplevel.mk === --- include/toplevel.mk (révision 28798) +++ include/toplevel.mk (copie de travail) @@ -43,6 +43,8 @@ SUBMAKE:=umask 022; $(SUBMAKE) +have-qt3-dev:=$(shell [ -d /usr/include/qt3 ] echo y) + prepare-mk: FORCE ; prepare-tmpinfo: FORCE @@ -67,6 +69,13 @@ $(eval $(call rdep,scripts/config,scripts/config/mconf)) +ifneq ($(have-qt3-dev),) +scripts/config/qconf: + @$(_SINGLE)$(SUBMAKE) -s -C scripts/config qconf + +$(eval $(call rdep,scripts/config,scripts/config/qconf)) +endif + scripts/config/conf: @$(_SINGLE)$(SUBMAKE) -s -C scripts/config conf @@ -89,6 +98,19 @@ fi $ Config.in +ifneq ($(have-qt3-dev),) +xconfig: scripts/config/qconf prepare-tmpinfo FORCE + if [ \! -e .config -a -e $(HOME)/.openwrt/defconfig ]; then \ + cp $(HOME)/.openwrt/defconfig .config; \ + fi + $ Config.in +else +xconfig: + @echo Target xconfig adds qt3-dev to the dependencies of OpenWRT, and this dependency is missing on your system + @echo You shall install qt3-dev to be able to run make xconfig. + @false +endif + prepare_kernel_conf: .config FORCE ifeq ($(wildcard staging_dir/host/bin/sed),) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ПОКАНА Re: [PATCH] WR740N V3 support
Le 20/10/2011 11:28, NetworkPro a écrit : Здравей, моля присъедини се към нашите усилия да популяризираме тестваме и развиваме *WRT http://www.mikrotik-bg.net/topic/2622-tl-wr741nd-%D1%81-openwrt/page__pid__31768__st__50#entry31768 Поздрави. Ouch. Is this the signal for the return of WhiteRussian? Joke aside, Google translate says this is a bulgarian post, and translate it to: --8 Hello, please join our efforts to promote test and develop * WRT http://www.mikrotik-bg.net/topic/2622-tl-wr741nd-%D1%81-openwrt/page__pid__31768__st__50#entry31768 Greetings. --8 Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/3] support for make xconfig
This patchset brings back the support for the xconfig top-level target. Since this target 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 xconfig/. Otherwise, a message will be printed when the user will try to execute this target. xconfig has nice properties that menuconfig does not have: * all-in-one screen: a menu tree, a list of CONFIG symbol to play with and the help of these symbols. * an improved search function that leads the user directly to the symbol he's searching for. The patches applies on svn://svn.openwrt.org/openwrt/trunk r28372. It has been generated using /svn diff/. This is version 3 of the patchset. --- Changes since version 2 * patch 4/4 has been removed, and the series is now made of 3 patches 1/3, 2/3 and 3/3. * patch 2/3 has been corrected (added a missing rule) --- Changes since version 1: * in Patch 4/4: the missing changes from several important makefiles have been added back. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3, V3] qconf target in scripts/config/Makefile (RESEND, no lone wrap)
This patch modifies the scripts/config/Makefile file to build the qconf utility. qconf is not added to the target list unless the development files of qt3 has been detected (we simply check for the presence of the /usr/include/qt3 directory). Changes since version 2: missing rule to create the missing .moc file Changes since Version 1: none Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com -- 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,23 @@ 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 +endif + +lkc_defs.h: lkc_proto.h sed $ $@ 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' zconf.tab.c: zconf.y @@ -52,3 +66,6 @@ %.hash.c: %.gperf cp $@_shipped $@ || gperf $ $@ + +%.moc: %.h +cp $@_shipped $@ || moc -i $ -o $@ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3, V3] top-level xconfig target (RESEND, no line wrap)
This patch adds support for the xconfig top-level target. If qt3 is detected on the system (by checking for the presence of the directory /usr/include/qt3), the top-level target expands to the invocation of scripts/configs/qconf. Otherwise, the target prints a message and errors out. Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com -- Index: include/toplevel.mk === --- include/toplevel.mk(révision 28361) +++ include/toplevel.mk(copie de travail) @@ -43,6 +43,8 @@ SUBMAKE:=umask 022; $(SUBMAKE) +have-qt3-dev:=$(shell [ -d /usr/include/qt3 ] echo y) + prepare-mk: FORCE ; prepare-tmpinfo: FORCE @@ -67,6 +69,13 @@ $(eval $(call rdep,scripts/config,scripts/config/mconf)) +ifneq ($(have-qt3-dev),) +scripts/config/qconf: +@$(_SINGLE)$(SUBMAKE) -s -C scripts/config qconf + +$(eval $(call rdep,scripts/config,scripts/config/qconf)) +endif + scripts/config/conf: @$(_SINGLE)$(SUBMAKE) -s -C scripts/config conf @@ -89,6 +98,19 @@ fi $ Config.in +ifneq ($(have-qt3-dev),) +xconfig: scripts/config/qconf prepare-tmpinfo FORCE +if [ \! -e .config -a -e $(HOME)/.openwrt/defconfig ]; then \ +cp $(HOME)/.openwrt/defconfig .config; \ +fi +$ Config.in +else +xconfig: +@echo Target xconfig adds qt3-dev to the dependencies of OpenWRT, and this dependency is missing on your system +@echo You shall install qt3-dev to be able to run make xconfig. +@false +endif + prepare_kernel_conf: .config FORCE ifeq ($(wildcard staging_dir/host/bin/sed),) ___ 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
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
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
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] rsync: cosmetic changes after package split
Le 30/09/2011 14:59, Florian Fainelli a écrit : On Friday 30 September 2011 14:37:05 Eugene San wrote: Ok. I just tried to unify style of this file, and wasn't planning tabs-spaces holy-war :-) Although, both approaches can be found all over the code and there is no specific guidelines on subject. Agreed, in general I try to keep this style of 2 spaces for declarations inside define/endef blocks, but having tabs is also valid. Note sure about other editors, but vim for instance does a better highlighting job when using 2 spaces (it's Friday after all). Same for geany and gedit, as far as I can tell. With tabs, variable definitions are not highlighted correctly (they are when 2 spaces are used). -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] cs5535-gpio: name changed in linux-3.1
Le 29/08/2011 06:55, Philip Prindeville a écrit : The name gpio-cs5535 used to refer to the drivers/char/ module, but in 3.1 it refers to what had been drivers/gpio/cs5535-gpio in more recent kernels. Have you checked on Linux 3.0 ? It seems to me that many drivers have been moved (serial went to drivers/serial/tty or something like that) and so on. Also, I would have checked the linux kernel version out of the package definitions and set a GPIODIR variable to either /gpio or /char, depending on the kernel version. Something like this would be useful anyway when dealing with drivers that move from staging to non-staging. Best regards, -- Emmanuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RESEND] Platform patches not applied on make toolchain/kernel-headers/prepare
Apologies if you receive this twice. It was supposed to be sent on last friday, but it seems it wasn't - or at least, I didn't got it back - which is weird since I didn't lost any other message. ---8- Hello, I'm not sure whether this is by design or if this is a mistake, but when one does a make toolchain/kernel-headers/prepare the build process applies the generic patches (in $(GENERIC_PLATFORM_DIR)/paches-$(KERNEL_VERSION)) but not the ones that are located in the specific platform subtree. This has an undesireable consequence: when one wants to modify a linux header that can be used by some userspace program, he must add its platform-specific patch in the generic subtree - otherwise the changes to the header file are not visible. The same remark applies for the platfom files/ directory, which contains potentially important header files as well. In my opinion, the kernel-headers toolchain package shall have no patches/ and no files/ - that doesn't make much sense. I cannot see any reason were one would want to have user-space kernel header files that are not tied to the kernel-space ones. Since the patches are applied on the linux tree, they should be added into to linux generic patch dir (same remark for the files), so maybe one can just set PATCH_DIR to $(PLATFORM_DIR)/patches-$(KERNEL_VERSION) (or something like that) in kernel-headers/Makefile - or change the Kernel/Patch/Default rule so that it always apply the platform patches - and not the patches in PATCH_DIR (since this variable depends on the package). So, honnest mistake or design choice? (i.e. what should I do with this report?) Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Platform patches not applied on make toolchain/kernel-headers/prepare
Hello, I'm not sure whether this is by design or if this is a mistake, but when one does a make toolchain/kernel-headers/prepare for the first time, the build process applies the generic patches (in $(GENERIC_PLATFORM_DIR)/paches-$(KERNEL_VERSION)) but not the ones that are located in the specific platform subtree. This has an undesireable consequence: when one wants to modify a linux header that can be used by some userspace program, he must add its patch in the generic subtree - otherwise the changes to the header file are not visible. The same remark applies for the platfom files/ directory, which contains potentially important header files as well. The kernel-headers toolchain package shall have no patches/ and no files/ - that doesn't make sense. Since the patches are applied on the linux tree, they should be added into to linux generic patch dir (same remark for the files), so maybe one can just set PATCH_DIR to $(PLATFORM_DIR)/patches-$(KERNEL_VERSION) (or something like that) in kernel-headers/Makefile - or change the Kernel/Patch/Default rule so that it always apply the platform patches - and not the patches in PATCH_DIR (since this variable depends on the package). So, honnest mistake or design choice? (i.e. what should I do with this report?) Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel Modules not copying over.
On 08/17/2011 12:21 AM, Hartmut Knaack wrote:
Hi Hauke,
sorry for snatching in.
If you need some kernel module do make menuconfig and select it if it
is there or add a module to packages/kernel/modules/.
Hauke
So what would be the most convenient way to submit changes (i.e.
patches) in packages/kernel/modules/ ? This mailing list, or opening a
ticket, or anything else? It happened that I created a patch in i2c.mk
about 2 months ago and submitted it on june 22nd in this mailing list. I
also opened a ticket with the patch attached, about a week later. So far
both without any progress. I don't want to be annoying, I know
developers are quite busy. Just thought, since you mentioned this topic,
I might get a hint how to get such patches applied.
Take care
Hartmut
Another solution would be to create a modules.mk file in your
target/linux/${BOARD}/ directory, on the model of the
package/kernel/module/*.mk files. This file is included when the module
kernels are to be built.
(and a better solution would be to generate the list of modules from the
TRISTATE symbols in the kernel config files, but that's a lot harder ;
the module list changes from one release of Linux to another, and the
current solution does not work very well ; the problem is then that this
list can only be built once the kernel has been downloaded and extracted).
Best regards,
-- Emmanuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/4, V2] support for make xconfig
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. --- Changes since version 1: * in Patch 4/4: the missing changes from several important makefiles have been added back. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4, V2] qconf target in the makefile
This patch modifies the scripts/config/Makefile file to build the qconf utility. qconf is not added to the target list unless the development files of qt3 has been detected (we simply check for the presence of the /usr/include/qt3 directory). Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com --- Changes since version 1: * none --- Index: scripts/config/Makefile === --- scripts/config/Makefile (revision 27257) +++ scripts/config/Makefile (working copy) @@ -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,23 @@ 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 +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] [PATCH 3/4, V2] xconfig top-level target
This patch adds support for the xconfig top-level target. If qt3 is detected on the system (by checking for the presence of the directory /usr/include/qt3), the top-level target expands to the invocation of scripts/configs/qconf. Otherwise, the target prints a message and errors. Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com --- Changes since version 1: * none --- Index: include/toplevel.mk === --- include/toplevel.mk (revision 27257) +++ include/toplevel.mk (working copy) @@ -43,6 +43,8 @@ SUBMAKE:=umask 022; $(SUBMAKE) +have-qt3-dev:=$(shell [ -d /usr/include/qt3 ] echo y) + prepare-mk: FORCE ; prepare-tmpinfo: FORCE @@ -67,6 +69,13 @@ $(eval $(call rdep,scripts/config,scripts/config/mconf)) +ifneq ($(have-qt3-dev),) +scripts/config/qconf: + @$(_SINGLE)$(SUBMAKE) -s -C scripts/config qconf + +$(eval $(call rdep,scripts/config,scripts/config/qconf)) +endif + scripts/config/conf: @$(_SINGLE)$(SUBMAKE) -s -C scripts/config conf @@ -89,6 +98,19 @@ fi $ Config.in +ifneq ($(have-qt3-dev),) +xconfig: scripts/config/qconf prepare-tmpinfo FORCE + if [ \! -e .config -a -e $(HOME)/.openwrt/defconfig ]; then \ + cp $(HOME)/.openwrt/defconfig .config; \ + fi + $ Config.in +else +xconfig: + @echo Target xconfig adds qt3-dev to the dependencies of OpenWRT, and this dependency is missing on your system + @echo You shall install qt3-dev to be able to run make xconfig. + @false +endif + prepare_kernel_conf: .config FORCE ifeq ($(wildcard staging_dir/host/bin/sed),) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4, V2]
This patch adds support for the kernel_xconfig top-level target. If qt3 is detected on the system (by checking for the presence of the directory /usr/include/qt3), the top-level target expands to the invocation of the kernel xconfig target. Otherwise, the target prints a message and errors. Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com (Warning) Please note that this patch does not apply cleanly, although it applies. I get the following warning (after I applied patches 1/4 to 3/4): patching file include/toplevel.mk Hunk #1 succeeded at 129 (offset 22 lines). patching file include/kernel-build.mk patching file target/linux/Makefile --- Changes since version 1: * the missing changes from several important makefiles have been added back. --- Index: include/toplevel.mk === --- include/toplevel.mk (revision 27257) +++ include/toplevel.mk (working copy) @@ -107,6 +129,16 @@ kernel_nconfig: prepare_kernel_conf $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux nconfig +ifneq ($(have-qt3-dev),) +kernel_xconfig: prepare_kernel_conf + $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux xconfig +else +kernel_xconfig: + @echo Target kernel_xconfig adds qt3-dev to the dependencies of OpenWRT, and this dependency is missing on your system + @echo You shall install qt3-dev to be able to run make xconfig. + @false +endif + tmp/.prereq-build: include/prereq-build.mk mkdir -p tmp rm -f tmp/.host.mk Index: include/kernel-build.mk === --- include/kernel-build.mk (revision 27257) +++ include/kernel-build.mk (working copy) @@ -113,7 +113,7 @@ compile: $(LINUX_DIR)/.modules $(MAKE) -C image compile TARGET_BUILD= - oldconfig menuconfig nconfig: $(STAMP_PREPARED) $(STAMP_CHECKED) FORCE + oldconfig menuconfig nconfig xconfig: $(STAMP_PREPARED) $(STAMP_CHECKED) FORCE rm -f $(STAMP_CONFIGURED) $(LINUX_RECONF_CMD) $(LINUX_DIR)/.config $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) $$@ Index: target/linux/Makefile === --- target/linux/Makefile (revision 27257) +++ target/linux/Makefile (working copy) @@ -9,5 +9,5 @@ export TARGET_BUILD=1 -prereq clean download prepare compile install menuconfig nconfig oldconfig update refresh: FORCE +prereq clean download prepare compile install menuconfig nconfig xconfig oldconfig update refresh: FORCE @+$(NO_TRACE_MAKE) -C $(BOARD) $@ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/4] support for make xconfig
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. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] support for make kernel_xconfig
This patch adds support for the kernel_xconfig top-level target. If qt3 is detected on the system (by checking for the presence of the directory /usr/include/qt3), the top-level target expands to the invocation of the kernel xconfig target. Otherwise, the target prints a message and errors. Signed-off-by: Emmanuel Deloget emmanuel.delo...@efixo.com (Warning) Please note that this patch does not apply cleanly, although it applies. I get the following warning (after I applied patches 1/4 to 3/4): patching file include/toplevel.mk Hunk #1 succeeded at 129 (offset 22 lines). The resulting file is still valid. -- Index: include/toplevel.mk === --- include/toplevel.mk (revision 27257) +++ include/toplevel.mk (working copy) @@ -107,6 +107,16 @@ kernel_nconfig: prepare_kernel_conf $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux nconfig +ifneq ($(have-qt3-dev),) +kernel_xconfig: prepare_kernel_conf + $(_SINGLE)$(NO_TRACE_MAKE) -C target/linux xconfig +else +kernel_xconfig: + @echo Target kernel_xconfig adds qt3-dev to the dependencies of OpenWRT, and this dependency is missing on your system + @echo You shall install qt3-dev to be able to run make xconfig. + @false +endif + tmp/.prereq-build: include/prereq-build.mk mkdir -p tmp rm -f tmp/.host.mk ___ 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
On 06/17/2011 04:39 PM, 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. snip udevtrigger.c:(.text+0x538): undefined reference to `strlcpy' udevtrigger.c:(.text+0x548): undefined reference to `strlcat' Problem has been identified (seehttps://dev.openwrt.org/ticket/9012) and Mika Laitio provided a patch on this list. See : https://lists.openwrt.org/pipermail/openwrt-devel/2011-June/011138.html See also https://lists.openwrt.org/pipermail/openwrt-devel/2011-June/011137.html for other problems that are related to glibc/eglibc. Best regards, -- Emmanuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Of stripping executable/relocatable
Hello, I'm facing an interesting porting challenge : one of the program which is to be installed on our target is compressed using upx. As you may know, upx-compressed programs are not to be stripped (strip removes everything but the stub, resulting in a 300 bytes program that does nothing but crashing ; that's not very usefull). The problem is here : OpenWRT's package-ipkg.mk automatically strip any executables it finds right after Package/X/install. The relevant code snippet is (from trunk/include/package-ipkg.mk [1], line 90 to 95): $$(IPKG_$(1)): $(STAMP_BUILT) @rm -rf $(PACKAGE_DIR)/$(1)_* $$(IDIR_$(1)) mkdir -p $(PACKAGE_DIR) $$(IDIR_$(1))/CONTROL $(call Package/$(1)/install,$$(IDIR_$(1))) -find $$(IDIR_$(1)) -name 'CVS' -o -name '.svn' -o -name '.#*' | $(XARGS) rm -rf $(RSTRIP) $$(IDIR_$(1)) To avoid this, I do something that I find quite bad (and I'm sure you'll agree with me): I added a PKG_NO_STRIP variable in my package Makefile, and I modified package-ipkg.mk : Index: openwrt/include/package-ipkg.mk === --- openwrt/include/package-ipkg.mk(revision 3671) +++ openwrt/include/package-ipkg.mk(working copy) @@ -117,7 +117,7 @@ $(call Package/$(1)/install,$$(IDIR_$(1))) mkdir -p $(PACKAGE_DIR) -find $$(IDIR_$(1)) -name 'CVS' -o -name '.svn' -o -name '.#*' | $(XARGS) rm -rf -$(RSTRIP) $$(IDIR_$(1)) +[ ! -n $$(PKG_NO_STRIP) ] $(RSTRIP) $$(IDIR_$(1)) ifneq ($$(KEEP_$(1)),) @( \ (this is not the version present in the openwrt trunk, but you get the trick). I think this solution is sub-optimal - but then, I believe the whole install process is suboptimal (from a versatility point of view). You can change the behavior of all major build step - but you can only select the files that are to be installed (using Package/X/install). It would be nice to be able to allow a user to specify a different stripping behavior (or no behavior at all). There are many cases where such a possibility would be useful: * if you don't want (some or all) your binaries to be stripped at all * if you want to use different stripping parameters (for example strip --only-keep-debug + objcopy --add-gnu-debuglink) * if you want to use another software to strip the binaries (for instance, upx). It's now the time to write down a few questions : + Do you think that a configurable strip target (for example Package/X/strip, which defaults to Package/strip/Default) makes sense ? + Do you have any other idea ? Best regards, -- Emmanuel Deloget [1] https://dev.openwrt.org/browser/trunk/include/package-ipkg.mk#L75 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Of stripping executable/relocatable
On 05/10/2011 03:30 PM, Jo-Philipp Wich wrote: Hi, a less invasive method is setting RSTRIP:=true in your package Makefile. (Not: true in this context means /bin/true) Agreed, it's less invasive than the change I made. My question is more should OpenWRT provide more stripping options to package maintainers? ~ Jow Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trivial questions about packages
On 04/28/2011 12:49 PM, John Zavgren wrote: Emmanuel: Thanks for getting back to me on this issue. I haven't tried your suggestions yet, however, I wonder why similar packages that don't have the modifications you recommend seem to work they way I expect them to. For example, the package that installs the bridge utiliites: package/bridge-utils/, has a Makefile that looks like this: snip I will be honest: I have some issue to find my way in the include/*.mk files. I even might have been wrong (although adding this simple line helped me to correct similar situations). What I can read from the openwrt makefiles (and I may misintrepret them ; they are not that easy to follow): * PKG_INSTALL controls the execution of make -C yourbuilddir install during the package compilation (ie it executes make -C builddir make -C builddir install if PKG_INSTALL is defined). So effectively, it is not related to your issue. * BuildTarget/ipkg (in include/package-ipkg.mk) adds the compile rule, which depends on whether Package/xxx/install is defined or not: ifdef Package/$(1)/install ifneq ($(CONFIG_PACKAGE_$(1))$(SDK)$(DEVELOPER),) compile: $$(IPKG_$(1)) $(STAGING_DIR_ROOT)/stamp/.$(1)_installed ifeq ($(CONFIG_PACKAGE_$(1)),y) install: $$(INFO_$(1)) endif else compile: $(1)-disabled $(1)-disabled: @echo WARNING: skipping $(1) -- package not selected endif endif The dependant rules are: $(STAGING_DIR_ROOT)/stamp/.$(1)_installed: $(STAMP_BUILT) rm -rf $(STAGING_DIR_ROOT)/tmp-$(1) mkdir -p $(STAGING_DIR_ROOT)/stamp $(STAGING_DIR_ROOT)/tmp-$(1) $(call Package/$(1)/install,$(STAGING_DIR_ROOT)/tmp-$(1)) $(call Package/$(1)/install_lib,$(STAGING_DIR_ROOT)/tmp-$(1)) $(CP) $(STAGING_DIR_ROOT)/tmp-$(1)/. $(STAGING_DIR_ROOT)/ rm -rf $(STAGING_DIR_ROOT)/tmp-$(1) touch $$@ $$(IPKG_$(1)): $(STAMP_BUILT) (do a bunch of stuff to generate the final package) Thus, the conditions to have the Package/XXX/install rule executed is to have: * CONFIG_PACKAGE_XXX set to y (*) * An existing Package/XXX/install (obvious) And the condition to have your own install rule executed dring compilation is: * define PKG_INSTALL in the package Makefile Build/InstallDev is called from the moment it is defined (right after compilation). Best regards, -- Emmanuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
