Re: [OpenWrt-Devel] OpenWrt release name
On Mon, 6 Apr 2015, edgar.sol...@web.de wrote: On 06.04.2015 09:35, John Crispin wrote: i think we have a winner with 96 vs 50 votes. == Dirty Diamond == 2 cl Rum 2 cl Vodka 2 cl Tequila Silver 2 cl Campari 2 cl Curaçao Blue 2 cl Lime syrup 2 1/2 cl Orange juice Coca Cola i also liked == Designated Driver == 1 part cranberry juice cocktail 1 part grapefruit juice 1 part orange juice 1 part pineapple juice , which would also be a nice pun on router functionality. is it really to late to consider this additional entry? hey, that was my idea. :-) and given alphabetics, it's the last chance you'll get to use that particular pun. choose carefully. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt release name
On Sat, 4 Apr 2015, Felix Fietkau wrote: Hey OpenWrt community, We're still working hard on preparing the upcoming Chaos Calmer release, and the work on the first release candidate is almost done. We've decided to include the community in picking the name of the next major release after CC. After some internal discussions, we came up with the following two options: == Dirty Diamond == 2 cl Rum 2 cl Vodka 2 cl Tequila Silver 2 cl Campari 2 cl Curaçao Blue 2 cl Lime syrup 2 1/2 cl Orange juice Coca Cola == Dark Destroyer == 2 oz Malibu coconut rum 2 oz Southern Comfort peach liqueur 3 oz Lemonade You can find the poll here: http://doodle.com/5p6fhn6dtcrbrdxy Please vote and help us make the next release truly amazing! Designated Driver? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] is there something preventing me from watching github openwrt/packages?
just tried to watch github repo openwrt/packages, the Watch selector went to a greyed-out Unwatch for several seconds, then i got the error Something went wrong with that request. Please try again. do i need any special properties on my github account to watch that (or any other openwrt) repo? apologies if this is a silly question. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] UCI usage table missing entries for del_list and reorder
Yes, it's a wiki but I'll let someone higher up the food chain fix this: http://wiki.openwrt.org/doc/uci#usage wherein neither the command usage output nor the table of UCI subcommands mentions either del_list or reorder. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ltq-tapi: configure: error: The lib_ifxos include directory is not valid!
Quoting Hannu Nyman hannu.ny...@iki.fi: Quoting Robert P. J. Day: building for ar71xx: ... make[2]: *** [package/kernel/lantiq/ltq-tapi/compile] Error 2 ... this build worked fine yesterday, pulled to update to current trunk and now the above. You are probably including asterisk in your build, right? The reason is a change in asterisk package in the telephony feed. A lantiq-related change apparently poisons other platforms. That would be what I'm doing, yes. So, for now, out with Asterisk. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QA for upcoming(?) CC?
On Fri, 5 Dec 2014, John Crispin wrote: On 05/12/2014 11:19, Jo-Philipp Wich wrote: Hi. in any event, if the idea of an official release is that it should build out of the box, there are clearly a number of (albeit easily fixable) download and build issues to clean up. is it part of pre-release QA to make sure all of these issues are resolved? Such issues are usually not (completely) resolved before a release. Release builds are generating using make ... IGNORE_ERRORS=m so broken, non-builtin packages are simply skipped. actually i spent 4 week fixing all the issues for BB and we have a fallout of 0 packages on the main targets and a fallout of max 15 unimportant packages on unimportant targets. i intend to do the same for CC cool, i suspected as much, just wanted to check, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LVM2 already moved on to version 2.02.114
current recipe looking for 2.02.113 fails to download as redhat ftp site has already moved on to next version. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] any known issues with wireless luci interface on trunk?
what little info I have until I can check it out myself: colleague just stopped by my desk, claims that on the new tp-link archer c7 v2 router he just bought, when building from trunk, changing wireless settings from the GUI screwed things up, but doing the same thing from the command line with uci worked just fine. i'm going over later to see the symptoms and will post them in more detail, but can anyone else describe seeing anything similar? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] willing to donate a MTK MT7620A/MT7610E-based router to anyone who wants to work on one
On Fri, 21 Nov 2014, John Crispin wrote: Hi, why the mt7610 requirement ? whr works well with a rt5592 as 5ghz and the whr-1166 has mt7612 as 5ghz for which felix pushed the driver last night. mt7610 is only used by the dir810 and there is no free driver for that wifi chip. to repeat earlier question, can one build an openwrt image and flash an out-of-the-box whr-1166d? i'm not even that obsessed with the wireless part, i'm sure that won't be hard, what i most want is a simple solution to basic board-up, just to build, flash and boot. has anyone actually *done* this with the whr-1166d? if so, i'll buy one in a heartbeat. rday p.s. thanks for everyone's inestimable patience as i ask admittedly silly questions on a regular basis. in return, i will be happy to donate whatever helps the project along. if there's a developer that needs a router somewhere, i'll be glad to help. or if there's a way to donate directly, i can do that, too. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] willing to donate a MTK MT7620A/MT7610E-based router to anyone who wants to work on one
[apologies for sending to both lists, i wanted to make sure i caught everyone who might be interested; feel free to delete either recipient when replying.] following up on my earlier pleas for help with getting openwrt onto *any* kind of mediatek-based router or eval board, i'm more than happy to buy anything appropriate and donate it to someone who's in a position to get openwrt onto it. my latest attempt was with a d-link DIR-810L, for which it appeared someone had installed openwrt somehow, but i was unable to do it through the original GUI, and ripping it apart and connecting to the serial port did not give a reliable console port -- partial garbage, even though one could see valid output in the midst of all the garbage. (we tried every combination of baud rate, parity and so on.) so, in short, i have yet to track down either an eval board or commercial router that incorporates the MT7620A SoC and MT7610E 5G radio chip and on which i can install openwrt that i build myself. bonus points if such a thing has a PCIe slot for a broadband modem, that would be delightful. if you can help and want a free modem/eval board out of it, i'm more than happy to supply one in return for instructions on how to do this. rday p.s. if you're an openwrt hacker in the Ottawa area, that would be cool, too, let me know. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] willing to donate a MTK MT7620A/MT7610E-based router to anyone who wants to work on one
Quoting John Crispin blo...@openwrt.org: Hi, why the mt7610 requirement ? whr works well with a rt5592 as 5ghz and the whr-1166 has mt7612 as 5ghz for which felix pushed the driver last night. mt7610 is only used by the dir810 and there is no free driver for that wifi chip. ok, that might solve my problem, i'll check into it, thanks muchly. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] willing to donate a MTK MT7620A/MT7610E-based router to anyone who wants to work on one
Quoting John Crispin blo...@openwrt.org: Hi, why the mt7610 requirement ? whr works well with a rt5592 as 5ghz and the whr-1166 has mt7612 as 5ghz for which felix pushed the driver last night. mt7610 is only used by the dir810 and there is no free driver for that wifi chip. so, to make sure i'm understanding this (and i just glanced at felix's patch for that driver), there is a working build of trunk openwrt for this buffalo airstation whr-1166d router: http://www.amazon.ca/Buffalo-AirStation-WHR-1166D-Wireless-Router/dp/B00JKM0ACW/ref=sr_1_1?ie=UTF8qid=1416584289sr=8-1keywords=whr-1166d with working 2.4G and 5G, and that is flashable onto that router? i can see that a whr-1166d image is part of the default build profile for mt7620, so i just want to make sure what i build can be installed on an out-of-box whr-1166d. do i have that about right? because that would be absolutely delightful. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Any ETA on fixing luci-app-openvpn's dependency issue?
I just tripped over this: https://dev.openwrt.org/ticket/18220 Is there a known workaround for this? And how exactly does one handle this type of generic Provides functionality in .ipk packages? Surely this sort of thing has been done before, no? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ETA on fixing luci-app-openvpn's dependency issue?
Quoting Robert P. J. Day rpj...@crashcourse.ca: I just tripped over this: https://dev.openwrt.org/ticket/18220 Is there a known workaround for this? And how exactly does one handle this type of generic Provides functionality in .ipk packages? Surely this sort of thing has been done before, no? Never mind, I just saw the PROVIDES directive in a couple Makefiles, I'm assuming the proper fix is that all openvpn variants should PROVIDE the functionality of openvpn, yes? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] (again), just a list of packages that failed to build
FWIW (and it's probably not worth much), i documented all the packages that failed to build after i activated the oldpackages feed, then selected to build all packages for my tp-link archer c7 v2. at the time, i figured, eh, how many are not going to build ... and this is what i got: http://www.crashcourse.ca/wiki/index.php/OpenWrt_TP-Link_AC1750#Build_errors i figured i might as well make a list for the benefit of a couple colleagues who are also working with openwrt, so they could be forewarned about packages that might not compile. some of the errors are admittedly trivial; i made no attempt to fix, just copied and pasted, deselected and moved on, so if anyone wants to fix anything, super. it's possible some of that stuff has already been fixed, i just haven't checked. a couple more questions about build errors coming shortly ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] how can i *deselect* building rrdtool?
i am out of ideas here ... i'm doing a full build for my archer c7 router and, when a package fails to build, i simply deselect that package via make menuconfig (and, of course, any other packages that select it) and restart the build. at the moment, given that rrdtool failed to build, i deselected it, but the build again failed trying to build rrdtool. i've verified through make menuconfig that it is indeed deselected. here are the lines in .config related to rrdtool: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Alexandru Ardelean wrote: you can also try a grep through all Makefile(s) to see which package has rrdtool in it's DEPENDS section if some package has it in it's DEPENDS, the build system will pull it; already tried that and saw nothing that would be causing this. one easy way to check that some package depends on rrdtool is to run make defconfig and you'll eventually see that package selected; did you try a clean build ? when I'm puzzled about build errors, I clean the dir, or even git clone a fresh one; you could try to clean everything except the openwrt/dl folder and start fresh that was my last resort, but i wanted to see if there was something else i could try first. i'm willing to believe that there is some leftover remnant from another package that is causing this, but it would be nice to verify that this *shouldn't* be happening. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Hannu Nyman wrote: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? collectd-mod-rrdtool is =m in your .config and gets built. And it needs rrdtool-1.0 as librrd1. You didn't grep .config for plain rrd... https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L315 $(eval $(call BuildPlugin,rrdtool,RRDtool output,rrdtool,+PACKAGE_collectd-mod-rrdtool:librrd1)) https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L225 # exception: mod-rrdtool needs rrdtool-1.0.x ifneq ($(CONFIG_PACKAGE_collectd-mod-rrdtool),) CONFIGURE_ARGS+= --with-librrd=$(STAGING_DIR)/usr/lib/rrdtool-1.0 endif https://github.com/openwrt/packages/blob/master/utils/rrdtool1/Makefile#L47 ah, thank you ... it's going to take me a few minutes to digest that one, i thought just looking at dependencies via make menuconfig was sufficient. apparently, it's much more involved. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Ted Hess wrote: Some observations on things that build when you think they shouldn’t... This is something I noticed a while ago and can construct an example, but have been unable to understand why things work this way – bug or feature? Let's say you have a package - call it utility xyzzy. In the Makefile, you declare 2 additional packages: lib-x and lib-y along with the xyzzy utility. lib-x is dependent on libfoo and libbar. lib-y is only dependent on libfoo only. The xyzzy utility is dependent on lib-y and NOT lib-x. However, if I select xyzzy and hence lib-y is selected by default, when you build, libbar will be built (but not installed) even though it not selected in the build config as you have observed. i'm sure my followup to this is much simpler, but it's sometimes a bit of an ordeal to deselect a single package given the number of Selects throughout the build structure. in my case, i wanted to simply deselect rrdtool, and ended up having to deselect every rrd-related package i could find, having to backtrace through the recipes to see what selected what. i suspect it will get easier as i get more used to the layout of the build structure. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] libdlna won't build, allegedly due to missing dependencies
i checked trac and it seems that there is (still?) an ongoing issue with building libdlna, as i was trying to do for a tp-link archer c7 v2: cc1: note: someone does not honour COPTS correctly, passed 2 times src/libdlna.so: undefined reference to `av_find_stream_info' src/libdlna.so: undefined reference to `av_close_input_file' collect2: error: ld returned 1 exit status Makefile:36: recipe for target 'test-libdlna' failed make[4]: *** [test-libdlna] Error 1 that seems to match what i see here: https://dev.openwrt.org/ticket/11666 is there a suggested fix for this? or i can just deselect it for now. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] packages that won't build when building for tp-link archer c7 v2
for what it's worth, i enabled the oldpackages feed and selected to build all packages and i'm just making a list of all packages that (for one reason or another) don't build for my current platform: http://www.crashcourse.ca/wiki/index.php/OpenWrt_TP-Link_AC1750#Build_errors i make no claims that this is deep or profound information, or that it isn't trivially fixable -- i'm just trying to do a full build of all packages and, for each one that fails to build, i'm just doing a quick copy and paste to keep track, that's it. if anyone wants to do anything about any of them, have at it, i'm just trying to get to the end of my build sometime today. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] is there a preferred repo for luci apps?
just collecting a list of all the available luci apps and while most of them appear to reside (unsurprisingly) at the luci feed: https://github.com/openwrt/luci.git i notice there are a few others scattered around other places. for example, in the standard packages feed, once can find: * net/ * luci-app-bcp38 * luci-app-sqm * mwan3-luci * utils/ * luci-app-lxc i even note that one of the net packages cshark builds the package luci-app-cshark as a subpackage. oh, and i see that, in the routing feed, there is a luci-app-bmx6 while bird-openwrt also builds luci support subpackages. so is there a standard for how and where luci support packages are made available? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] any plans to generate x86 VM images for BB?
minor observation: current wiki page regarding vbox: http://wiki.openwrt.org/doc/howto/virtualbox refers readers to pre-built images but only in AA -- there are no equivalent pre-built images for BB. any plans to add them? not a big deal, i'm building my own, anyway. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] iwinfo_cli.c:(.text.startup+0x120): undefined reference to `iwinfo_backend_by_name'
just updated my git repo, tried to build for TL-MR3220 and got: iwinfo_cli.o: In function `main': iwinfo_cli.c:(.text.startup+0x120): undefined reference to `iwinfo_backend_by_name' collect2: error: ld returned 1 exit status Makefile:40: recipe for target 'compile' failed rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] what are plans for migrating packages from git.openwrt.org/packages to github?
was wondering why i couldn't find some packages documented on the wiki, and finally ran across this discussion of the migration of packages from http://git.openwrt.org/packages.git to https://github.com/openwrt/packages: https://forum.openwrt.org/viewtopic.php?id=51078 the issue i was having is that, because of that migration, some packages clearly documented in the wiki are unavailable now that the old packages feed line is, by default, commented out. examples: * gpsd: documented here: http://wiki.openwrt.org/doc/howto/networked.gps but no longer available. i can see the package ugps as a possible alternative, is that meant to be a replacement? * multiwan: mentioned in a number of places: http://wiki.openwrt.org/?do=searchid=multiwan also no longer available, but mwan3 appears to be the obvious replacement, yes? (interestingly, while multiwan is not available, the luci package luci-multiwan still is.) * wifidog: same with this, even though it's clearly documented here: http://wiki.openwrt.org/doc/howto/wireless.hotspot.wifidog so what is the proper approach to situations like this? if something like wifidog hasn't been migrated, does that mean it's no longer supported or maintained? it's not so much the unavailability of packages that used to be available, so much as wiki pages suggesting pretty clearly they're still there. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] what are plans for migrating packages from git.openwrt.org/packages to github?
On Fri, 24 Oct 2014, Rafał Miłecki wrote: On 24 October 2014 21:36, Robert P. J. Day rpj...@crashcourse.ca wrote: the issue i was having is that, because of that migration, some packages clearly documented in the wiki are unavailable now that the old packages feed line is, by default, commented out. examples: * gpsd: documented here: http://wiki.openwrt.org/doc/howto/networked.gps but no longer available. i can see the package ugps as a possible alternative, is that meant to be a replacement? It's a migration process, no everything was moved at once. There is still oldpackages feed and you can find gpsd there: http://git.openwrt.org/?p=packages.git;a=tree;f=net/gpsd;h=8fcc32fa47f446c16800daaa8e55deb0509380bc;hb=HEAD i know it's in old packages, i mentioned that. i was just pointing out the incongruity that the old packages feed is now, by default, commented out, while openwrt wiki pages still refer to some of the packages there without making that clear. and to clarify my other questions, * is ugps meant to be an upgrade/alternative to gpsd? * is mwan3 meant to be an upgrade/alternative to multiwan? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Tue, 7 Oct 2014, Aaron Z wrote: On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: finally, given that this board looks like *someone's* dev board, would anyone know where it might have come from? there's no manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, i can see a reference to a Ralink MT7620a + MT7610e evaluation board. might that be it? i'd post a pic but i signed an NDA, although since no one has any idea where the board came from, i'm not sure what i'd be disclosing by posting a pic. i'm open to any information i can get, particularly support for that MT7610EN radio chip. thanks muchly. Any chance that it has an FCC ID, chip model numbers or other regulatory body unique number on it that you could share? I realize that you are in Canada and its a off brand board but you never know, the OEM might have used the same FCC number when they cloned the board... ah, just noticed that /proc/cpuinfo identifies this as a HiWiFi JI2 Board, whatever the heck that is. google is not being particularly helpful. rday p.s. just for the heck of it, i started a wiki page and recorded a bunch of board info: http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
at this point, i have to run off for the day where i will be unable to reply to emails, but i'll still be able to read this list. given that i did a build and have, among other things, a squashfs image named: openwrt-ramips-mt7620a-mt7620a_mt7610e-squashfs-sysupgrade.bin i'm tempted to simply reflash this board and take my chances. feel free to give me any other advice. and thanks muchly for the info so far. as a reminder, i documented a bunch of board info here: http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora if there's any other info that would be useful to add to that page, let me know and i can do that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Wed, 8 Oct 2014, Yousong Zhou wrote: On Oct 8, 2014 4:33 PM, Robert P. J. Day i'm looking at this page: http://www.cleanrouter.com/home/product and the processor is shown as an atheros AR7161, though. also, the pandoras hope router apparently has 4 wired ports, and this board has only two. at the risk of abusing this mailing list a bit more, i took a pic of the top of the board and attached it, if that helps maybe you are looking at the router at link [1]. it has 802.11ac capability but i guess padora firmware uses wireless drivers from ralink, not the mac80211 based one. for your information, j2 is for pinyin of 极贰 in Chinese. we already have j1 supported in opnewrt trunk. well, the official name for that board is hiwifi hc6361 [2]. they also have j1s which is mt7620a based without 5ghz capability. [1] http://www.hiwifi.com/j2-specs [2] http://wiki.openwrt.org/toh/hiwifi/hc6361 i can't even get to the page in [1], and the router in [2] is listed as based on AR9331, not MT7620A, so i'm fairly sure that can't be it. i'll keep trying the first link. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] just tripped over defect #14697
tried a make V=s DUMP=1 and encountered precisely this bug: https://dev.openwrt.org/ticket/14697 this is on a fully-updated, fedora rawhide system for which all my non-DUMP openwrt makes have been working pretty well so far. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On Wed, 8 Oct 2014, Felix Fietkau wrote: On 2014-10-08 19:51, Robert P. J. Day wrote: tried a make V=s DUMP=1 and encountered precisely this bug: https://dev.openwrt.org/ticket/14697 this is on a fully-updated, fedora rawhide system for which all my non-DUMP openwrt makes have been working pretty well so far. This is not a bug - overriding a random internal build system variable on the command line isn't exactly a good idea. :) Where did you get the idea of putting DUMP=1 on the command line? it's mentioned in the old kamikaze documentation here: https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 and an admittedly ancient openwrt users mailing list post here: https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On Wed, 8 Oct 2014, Felix Fietkau wrote: On 2014-10-08 20:44, Robert P. J. Day wrote: On Wed, 8 Oct 2014, Felix Fietkau wrote: On 2014-10-08 19:51, Robert P. J. Day wrote: tried a make V=s DUMP=1 and encountered precisely this bug: https://dev.openwrt.org/ticket/14697 this is on a fully-updated, fedora rawhide system for which all my non-DUMP openwrt makes have been working pretty well so far. This is not a bug - overriding a random internal build system variable on the command line isn't exactly a good idea. :) Where did you get the idea of putting DUMP=1 on the command line? it's mentioned in the old kamikaze documentation here: https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 and an admittedly ancient openwrt users mailing list post here: https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html Ah okay, so you just took a small part of that command without checking the context. By the way, if you use the DUMP=1 command as described in that old document, it still works. fair enough ... it's just not clear from that doc what part of the context is actually *required*. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
i apologize for repeating some of what i asked on the users list recently, but i'm rapidly running out of ideas and would be massively grateful for any assistance. just yesterday, i was handed an obvious development board, based on the MT7620A processor, and MT7610EN radio chip, and was asked to look into what it would take to get openwrt running on it. first thing i did was plug it in, connect to the console port and, sure enough, it booted to a version of openwrt -- PandoraBox -- which would appear to be a chinese version of openwrt. i connected the board via ethernet and browsed and, sure enough, i was shown the top-level luci admin page but, again, all the captions were in chinese (that was easy enough to fix). so, that the board can support openwrt seems fairly obvious, but here's where i'm having trouble. there is absolutely no identification on the board as to the manufacturer and, weirdly, no one who supplied the board knows where it came from, so i have no system reference manual. (the board comes with a full-size SD card slot which would be great to boot off of, but i have no idea what format the card requires.) so, first, i can see with openwrt trunk that MT7620A support is pretty solid -- that's the selection i made in menuconfig. but what about support for the MT7610E? i can see that, when i build, one of the squashfs images is for a mt7620a_mt7610e combination, so that makes me optimistic. and i can also see the MT7620a_MT7610e.dts device tree source file, so this makes me conclude i should be safe here. next issue is that the radio chip clearly shows, not MT7610E, but MT7610EN. i can find little online about this variation -- is it compatible with the MT7610E? finally, given that this board looks like *someone's* dev board, would anyone know where it might have come from? there's no manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, i can see a reference to a Ralink MT7620a + MT7610e evaluation board. might that be it? i'd post a pic but i signed an NDA, although since no one has any idea where the board came from, i'm not sure what i'd be disclosing by posting a pic. i'm open to any information i can get, particularly support for that MT7610EN radio chip. thanks muchly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package/kernel: Standardize help info in Config.in files
Use standard format (tab + 2 spaces) for help info, and a couple cheap grammar fixes. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/package/kernel/ar7-atm/Config.in b/package/kernel/ar7-atm/Config.in index 479b7ad..17a2701 100644 --- a/package/kernel/ar7-atm/Config.in +++ b/package/kernel/ar7-atm/Config.in @@ -5,8 +5,8 @@ choice prompt Firmware version default AR7_ATM_FW_VERSION_704 help - This option allows you to switch between firmware/driver versions which - might improve the DSL line speed. + This option allows you to switch between firmware/driver versions which + might improve the DSL line speed. config AR7_ATM_FW_VERSION_705 bool D7.05.01.00 diff --git a/package/kernel/lantiq/ltq-tapi/Config.in b/package/kernel/lantiq/ltq-tapi/Config.in index 84dbef2..44bff26 100644 --- a/package/kernel/lantiq/ltq-tapi/Config.in +++ b/package/kernel/lantiq/ltq-tapi/Config.in @@ -3,86 +3,86 @@ config VOICE_CPE_TAPI_FAX depends on PACKAGE_kmod-ltq-tapi default n help - Option to enable fax/modem support in TAPI. - Note: Newer platforms as AR9 and VR9 support a T.38 fax relay stack - in FW while older platforms like Danube or VINETIC-CPE require a - separate SW stack executed as an application. + Option to enable fax/modem support in TAPI. Note: Newer platforms + such as AR9 and VR9 support a T.38 fax relay stack in FW while + older platforms like Danube or VINETIC-CPE require a separate SW stack + executed as an application. config VOICE_CPE_TAPI_CID bool CID support depends on PACKAGE_kmod-ltq-tapi default y help - Option to enable Caller ID support. + Option to enable Caller ID support. config VOICE_CPE_TAPI_LT_GR909 bool Linetesting GR-909 support depends on PACKAGE_kmod-ltq-tapi default y - help - Option to enable linetesting GR-909. + help + Option to enable linetesting GR-909. config VOICE_CPE_TAPI_DECT bool DECT encoding for COSIC modem depends on PACKAGE_kmod-ltq-tapi default n - help - Option to enable DECT encoding for COSIC modem. + help + Option to enable DECT encoding for COSIC modem. config VOICE_CPE_TAPI_KPI bool KPI (Kernel Packet Interface) depends on PACKAGE_kmod-ltq-tapi default y help - Option to enable the generic kernel level packet interface - which allows accelerated packet transfer for various purposes. - The most important example is the QOS option, which allows - to redirect RTP packets directly into the IP stack. - Other options relying on KPI are DECT and HDLC. + Option to enable the generic kernel level packet interface + which allows accelerated packet transfer for various purposes. + The most important example is the QOS option, which allows + the redirection of RTP packets directly into the IP stack. + Other options relying on KPI are DECT and HDLC. config VOICE_CPE_TAPI_QOS bool QOS for accelerated RTP packet handling depends on PACKAGE_kmod-ltq-tapi default y help - Option to enable an accelerated RTP packet transfer inside - the LINUX kernel space. This option requires the KPI2UDP - packet, which actually provides the OS specific hooks in - the IP stack. + Option to enable an accelerated RTP packet transfer inside + the LINUX kernel space. This option requires the KPI2UDP + packet, which actually provides the OS specific hooks in + the IP stack. config VOICE_CPE_TAPI_STATISTICS bool TAPI statistics via /proc fs depends on PACKAGE_kmod-ltq-tapi default y help - Option to enable /proc fs statistics for packet counts etc. + Option to enable /proc fs statistics for packet counts etc. config VOICE_CPE_TAPI_METERING bool Metering (TTX) support depends on PACKAGE_kmod-ltq-tapi default n help - Option to enable metering (TTX) support. + Option to enable metering (TTX) support. config VOICE_CPE_TAPI_HDLC bool PCM HDLC support, evaluation depends on PACKAGE_kmod-ltq-tapi default n help - Option to enable PCM HDLC framing inside the firmware, e.g. for - ISDN D-Channel access. + Option to enable PCM HDLC framing inside the firmware, e.g. for + ISDN D-Channel access. config VOICE_CPE_TAPI_TRACES bool enable driver traces depends on PACKAGE_kmod-ltq-tapi default y help
[OpenWrt-Devel] [PATCH] udev/Config.in: help format, and fix spelling mistake
Formatting and spelling fixes. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- fixed misspelling of accelerometer in prompt, so figured while i was there, doesn't cost any more to tidy up the help info. i'm pedantic that way. diff --git a/package/system/udev/Config.in b/package/system/udev/Config.in index 56033d8..a9f3e00 100644 --- a/package/system/udev/Config.in +++ b/package/system/udev/Config.in @@ -7,63 +7,62 @@ config UDEV_DISABLE_LOGGING bool Disable udev logging to syslog default n help -Disable logging of udev messages to the syslog. If -unsure, choose the default N. + Disable logging of udev messages to the syslog. If + unsure, choose the default N. config UDEV_ENABLE_DEBUG bool Enable debug build of the udev package default n help -Compile in udev debug messages. If unsure, choose -the default N. + Compile in udev debug messages. If unsure, choose + the default N. config UDEV_EXTRA_accelerometer - bool Install udev acceleroometer callout + bool Install udev accelerometer callout default y help -accelerometer - udev callout to export device orientation -through property + accelerometer - udev callout to export device orientation + through property config UDEV_EXTRA_ata_id bool Install udev ata_id callout default y help -ata_id - udev callout to read product/serial number -from ATA drives + ata_id - udev callout to read product/serial number + from ATA drives config UDEV_EXTRA_cdrom_id bool Install udev cdrom_id callout default y help -cdrom_id - udev callout to determine the capabilities -of optical drives and media + cdrom_id - udev callout to determine the capabilities + of optical drives and media config UDEV_EXTRA_collect bool Install udev collect default n help -Adds ID to the list governed by checkpoint + Adds ID to the list governed by checkpoint config UDEV_EXTRA_edd_id bool Install udev edd_id callout default n help -edd_id - udev callout to identify BIOS disk drives -via EDD + edd_id - udev callout to identify BIOS disk drives + via EDD config UDEV_EXTRA_firmware bool Install firmware support default n help -udev firmware loader -via EDD + udev firmware loader via EDD config UDEV_EXTRA_floppy bool Install create_floppy_devices callout default n help -create_floppy_devices - udev callout to create all -possible floppy device based on the CMOS type + create_floppy_devices - udev callout to create all + possible floppy devices based on the CMOS type config UDEV_EXTRA_input_id bool Install input_id callout @@ -75,22 +74,22 @@ config UDEV_EXTRA_mtd_probe bool Install mtd_probe callout default y help -mtd_probe - udev callout to probe mtd devices + mtd_probe - udev callout to probe mtd devices config UDEV_EXTRA_path_id bool Install udev path_id callout default y help -path_id - udev callout to create a device path based -unique name for a device to implement the Linux -Persistent Device Naming scheme + path_id - udev callout to create a device path based + unique name for a device to implement the Linux + Persistent Device Naming scheme config UDEV_EXTRA_qemu bool Install qemu specific rules default y help -Install rules for autosuspension of QEMU emulated -USB HID devices + Install rules for autosuspension of QEMU emulated + USB HID devices config UDEV_EXTRA_rule_generator bool Install udev rule_generator @@ -101,7 +100,7 @@ config UDEV_EXTRA_scsi_id bool Install udev scsi_id callout default y help -scsi_id - retrieve and generate a unique SCSI identifier + scsi_id - retrieve and generate a unique SCSI identifier config UDEV_EXTRA_usb_id bool Install udev usb_id callout @@ -113,6 +112,6 @@ config UDEV_EXTRA_v4l_id bool Install udev v4l_id callout default y help -v4l_id - udev callout to identify Video4Linux devices + v4l_id - udev callout to identify Video4Linux devices endmenu rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[OpenWrt-Devel] should make distclean remove logs/ directory?
just noticed that it doesn't, is it supposed to? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] why does make clean or make dirclean prep tmp/, only to remove it?
messing around earlier and it seems that running either of make clean or make dirclean first does a prepare-tmpinfo and loads up the tmp/ directory, only to remove it all immediately afterwards. as Exhibit A, i have a totally clean openwrt checkout, in which i did the following: $ make V=s clean Checking 'non-root'... ok. Checking 'working-make'... ok. Checking 'case-sensitive-fs'... ok. Checking 'getopt'... ok. Checking 'fileutils'... ok. Checking 'working-gcc'... ok. Checking 'working-g++'... ok. Checking 'ncurses'... ok. Checking 'zlib'... ok. Checking 'gawk'... ok. Checking 'unzip'... ok. Checking 'bzip2'... ok. Checking 'perl'... ok. Checking '/usr/bin/python2.7'... ok. Checking 'wget'... ok. Checking 'git'... ok. Checking 'gnutar'... ok. Checking 'svn'... ok. Checking 'openssl'... ok. Checking 'gnu-find'... ok. Checking 'getopt-extended'... ok. Checking 'file'... ok. ... etc etc ... i killed that command while it was in the middle of make prepare-tmpinfo. why do those two cleaning targets do all that work, only to remove it right away? this is not the case with make distclean, which seems to be defined differently so it doesn't have this issue. rday p.s. a wild guess, but it seems that there are weird side effects to using FORCE instead of simply declaring targets as .PHONY. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] qemu/malta build error: consider recompiling with interlinking enabled
+with+interlinking+enabled%22ie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-achannel=sbgfe_rd=crei=XWAqVMi9AqWC8QesmoA4#rls=org.mozilla:en-US:officialchannel=sbq=+%22consider+recompiling+with+interlinking+enabled%22+openwrt but i'm unclear on whether any of them represents a solution i can apply. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] why does building an image builder depend on !TARGET_ROOTFS_INITRAMFS?
just noticed target/imagebuilder/Config.in: config IB bool Build the OpenWrt Image Builder depends on !TARGET_ROOTFS_INITRAMFS depends on !PROFILE_KCONFIG depends on !EXTERNAL_TOOLCHAIN why should building an image builder depend on !TARGET_ROOTFS_INITRAMFS? as i read it, under Target Images, i can select a variety of target image types. so why should selecting ramdisk suddenly mean i can't create an image builder? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] docs/ directory should be removed, or README updated
as i recall, the docs/ directory was described as horribly updated, but it is *still* referred to in the top-level README: The OpenWrt system is documented in docs/. You will need a LaTeX distribution and the tex4ht package to build the documentation. Type make -C docs/ to build it. either the docs/ directory should be removed or, at the very least, the README file should be updated to warn readers about its obsolescence. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] target/toolchain/Config.in: Clarify packaging of toolchain.
Change the help info to emphasize that this option refers specifically to packaging the toolchain that would be built anyway. --- hoping i'm not misreading this, but it seems clear that as the toolchain must be constructed anyway, this option refers only to packaging it as a tarball. diff --git a/target/toolchain/Config.in b/target/toolchain/Config.in index eda2300..5a6ecef 100644 --- a/target/toolchain/Config.in +++ b/target/toolchain/Config.in @@ -1,6 +1,8 @@ config MAKE_TOOLCHAIN - bool Build the OpenWrt based Toolchain + bool Package the OpenWrt-based Toolchain depends on !EXTERNAL_TOOLCHAIN help - This is essentially the toolchain created by OpenWrt. - + Package the created toolchain as a tarball under the bin/ directory as + OpenWrt-Toolchain-$(BOARD)-for-$(ARCH)$(ARCH_SUFFIX)-gcc-$(GCCV)$(DIR_SUFFIX). + For example, a toolchain for the MIPS architecture might be named + OpenWrt-Toolchain-malta-for-mipsel_mips32-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] target/toolchain/Config.in: Clarify packaging of toolchain.
Change the help info to emphasize that this option refers specifically to packaging the toolchain that would be built anyway. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- whoops, forgot to sign the last post. diff --git a/target/toolchain/Config.in b/target/toolchain/Config.in index eda2300..5a6ecef 100644 --- a/target/toolchain/Config.in +++ b/target/toolchain/Config.in @@ -1,6 +1,8 @@ config MAKE_TOOLCHAIN - bool Build the OpenWrt based Toolchain + bool Package the OpenWrt-based Toolchain depends on !EXTERNAL_TOOLCHAIN help - This is essentially the toolchain created by OpenWrt. - + Package the created toolchain as a tarball under the bin/ directory as + OpenWrt-Toolchain-$(BOARD)-for-$(ARCH)$(ARCH_SUFFIX)-gcc-$(GCCV)$(DIR_SUFFIX). + For example, a toolchain for the MIPS architecture might be named + OpenWrt-Toolchain-malta-for-mipsel_mips32-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] is there an actual ralink MT7620A evaluation board?
i've seen references to such a board in the openwrt code base ... does such a thing exist? google is not showing me anything that looks like a board. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] some questions/observations about building qemu/malta image
a few questions about things i ran into today trying to build a qemu malta image using the latest git checkout of openwrt -- some are admittedly trivial, i just want to make sure i'm understanding everything related to them. i started with the config.malta_le config file downloaded from openwrt.org. first, i'm aware that trying to run the pre-built qemu image from downloads.openwrt.org will fail with a kernel panic, as explained here: http://wiki.openwrt.org/doc/howto/qemu#openwrt.in.qemu.mips so during configuration, i deselected MIPS16 support. i'm not really familiar with the MIPS architecture but, as i read it, that support is really just an optimization so i can do away with it, yes? next, haven't done this yet but to save piles of time, i'm going to deselect all config settings of the form: CONFIG_PACKAGE_...=m as i understand it, those selections represent packages that will be compiled and packaged, but not built into the final rootfs. and, just to be clear, while such a final image might be deficient in all sorts of features, it should still *theoretically* boot, which is all i care about right now. next issue i ran into was this (which looks like a real bug): make[4]: Entering directory '/home/rpjday/openwrt/qemu_malta/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22' mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mno-branch-likely -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -mips16 -minterlink-mips16 -c dump1090.c In file included from dump1090.c:31:0: dump1090.h:60:25: fatal error: rtl-sdr.h: No such file or directory #include rtl-sdr.h ^ compilation terminated. Makefile:21: recipe for target 'dump1090.o' failed make[4]: *** [dump1090.o] Error 1 not sure what to make of that ... i checked under the build dir and there is such a header file at this location: $ find build_dir/ -name rtl-sdr.h build_dir/target-mipsel_mips32_uClibc-0.9.33.2/dump1090-2014-08-22/rtlsdr/rtl-sdr.h $ is this a known issue? for now, i'll get around it by just deselecting the dump1090 package but that shouldn't be necessary. should i file a bug report on this? another issue was one i ran into before and that i reported here: https://github.com/openwrt/packages/issues/296 a bit later this evening, i'll try applying the patch mentioned there. does anyone have any further info on this bug? finally (and this one is a bit weird), i was trying all of the above at a site where the corp firewall did not allow numerous fetching protocols, including git, ftp and wget, but i had most of the tarballs i needed already so i figured i was in good shape. not so, it turns out. partway through the build, building gcc just hung, and i tracked it down to this: $ vi build_dir/mipsel_mips32_uClibc-0.9.33.2/gcc-4.8.3/contrib/download_prerequisites MPFR=mpfr-2.4.2 GMP=gmp-4.3.2 MPC=mpc-0.8.1 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1 tar xjf $MPFR.tar.bz2 || exit 1 ln -sf $MPFR mpfr || exit 1 ... snip ... argh. so, as i read it, there is no way to preload tarballs to get around the above, is there? configuring gcc above *requires* net access, is that correct? anyway, feel free to comment on any of the above. thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] some questions/observations about building qemu/malta image
On Mon, 29 Sep 2014, Florian Fainelli wrote: Hello, (short emails for separate issues do help BTW) On 09/29/2014 03:32 PM, Robert P. J. Day wrote: a few questions about things i ran into today trying to build a qemu malta image using the latest git checkout of openwrt -- some are admittedly trivial, i just want to make sure i'm understanding everything related to them. i started with the config.malta_le config file downloaded from openwrt.org. first, i'm aware that trying to run the pre-built qemu image from downloads.openwrt.org will fail with a kernel panic, as explained here: http://wiki.openwrt.org/doc/howto/qemu#openwrt.in.qemu.mips And as explained in the ticket, get an updated qemu binary to fix that problem. since i'm working on fedora rawhide and do regular updates, i keep thinking that a fixed qemu can't be far away. then again, i might just be optimistic. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] missing debootstrap-udeb_1.0.61_all.udeb
On Sun, 28 Sep 2014, Yousong Zhou wrote: hi On 27 September 2014 05:44, Robert P. J. Day rpj...@crashcourse.ca wrote: Download failed. --2014-09-26 17:31:12-- http://downloads.openwrt.org/sources/debootstrap-udeb_1.0.61_all.udeb should this exist somewhere? It should try first the URL as specified in the package Makefile. But that retrieval failed and downloads.openwrt.org is more like a last resort backup. yes, i realize that. In the case of debootstrap-udeb, looks like the corresponding Makefile needs update. i realized that immediately, and i would have happily submitted such a patch, but wasn't sure where to do that. it seemed like too minor an issue over which to issue a bug report, so where does one send patches to update packages? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] want to clarify why a local mirror doesn't work for mtd-utils
i asked about this once upon a time, and i did some extra research recently, so i just want to clarify how i *think* some downloads are being done -- specifically, mtd-utils. i set up a local mirror, and it has a mtd-utils-1.4.5.tar.gz tarball in it, but if i'm setting up a new openwrt build directory, that tarball simply won't be used and, based on what i've read, here's why. here's an early snippet from tools/mtd-utils/Makefile: PKG_NAME:=mtd-utils PKG_VERSION:=1.4.5 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=git://git.infradead.org/mtd-utils.git PKG_SOURCE_PROTO:=git PKG_SOURCE_VERSION:=5319b84974fcb71504aed2d1b8285e9c0a4a4bb8 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) PKG_CAT:=zcat so, *if* i understand this correctly, the source for mtd-utils is obtained by checking out a specific commit ID from the mtd-utils git repo -- that would be the commit ID (apparently) corresponding to version 1.4.5. and upon such a checkout, that build's dl/ downloads directory will now have the tarball mtd-utils-1.4.5.tar.gz. so far, so good. however, if i copy that tarball to my local mirror directory to be used for any subsequent builds, it will never be used since there is no md5sum setting in the Makefile, so that source will always be downloaded anew in each new build directory, is that correct? also, there is no point adding a PKG_SOURCE_MD5SUM= setting to that Makefile since (as i see it), every time you check out the same version of mtd-utils from its git repo, the subsequent tarball will have a different md5sum value, simply due to the internal timestamp corresponding to the creation time of the tarball. am i understanding all this correctly? or have i just misread something? it sure seems that that's what's happening, unless i've completely messed up my testing. and, surely, that can't be the only package that will act that way -- i just used mtd-utils since that's the only example i've stumbled over so far. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] missing debootstrap-udeb_1.0.61_all.udeb
Download failed. --2014-09-26 17:31:12-- http://downloads.openwrt.org/sources/debootstrap-udeb_1.0.61_all.udeb should this exist somewhere? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Makefile: Remove unnecessary FORCE targets
Given that both clean and world are declared as .PHONY targets at the bottom of the Makefile, the FORCE is unnecessary. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/Makefile b/Makefile index 91b6946..0043347 100644 --- a/Makefile +++ b/Makefile @@ -49,7 +49,7 @@ printdb: prepare: $(target/stamp-compile) -clean: FORCE +clean: rm -rf $(BUILD_DIR) $(BIN_DIR) $(BUILD_LOG_DIR) dirclean: clean @@ -83,7 +83,7 @@ prereq: $(target/stamp-prereq) tmp/.prereq_packages fi prepare: .config $(tools/stamp-install) $(toolchain/stamp-install) -world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp-install) $(target/stamp-install) FORCE +world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp-install) $(target/stamp-install) $(_SINGLE)$(SUBMAKE) -r package/index # update all feeds, re-create index files, install symlinks -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] is there some reason to be using FORCE prereqs in Makefiles?
still wandering around the openwrt code base and, every so often, i come across the explicit use of FORCE prerequisites, like this in target/sdk/files/Makefile: clean: FORCE rm -rf $(BUILD_DIR) $(BIN_DIR) dirclean: clean rm -rf $(TMP_DIR) # check prerequisites before starting to build prereq: $(package/stamp-prereq) ; world: prepare $(package/stamp-compile) FORCE @$(MAKE) package/index .PHONY: clean dirclean prereq prepare world which seems a bit weird, given that targets clean and world are listed as .PHONY. is there something subtle about including FORCE there, or is that just a remnant of earlier design that i can submit a patch to remove? just being pedantic again. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] what's the rationale for mixed quotes in Config.in help?
if i wanted to add some help info to some Config.in entries, what's the deal with the strange mixture of back quotes and single quotes around some names? for example, in toolchain/eglibc/config/Config.in: ... snip ... select EGLIBC_OPTION_EGLIBC_INET help This option group includes the `libanl' library which provides support for asynchronous name lookup. config EGLIBC_OPTION_EGLIBC_LIBM bool libm (math library) default y help This option group includes the 'libm' library, containing ^^ ... snip ... it seems like there's quite a bit of a leading *back* quote, then then name, then a closing regular single quote, but even *that* is not consistent, as you can see above. is there a standard? and why the bck quotes, anyway? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] any reason why Makefile for mtd-utils doesn't set PKG_MIRROR_MD5SUM?
i was tracing down why running: $ make V=s tools/download insisted on doing a git checkout for the mtd-utils source, and refused to ever check either my local mirror or mirror2.openwrt.org, and i think i figured out that it's because the Makefile doesn't set the variable PKG_MIRROR_MD5SUM, is that correct? i compared that to the Makefile for yaffs2, which behaves the way i would have expected. so is there any reason why one doesn't add the appropriate md5sum line to the mtd-utils Makefile to fix this? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] what's the rationale for mixed quotes in Config.in help?
On Sun, 14 Sep 2014, Stefan Monnier wrote: This option group includes the `libanl' library which Back before XFree86 consolidated misc-fixed and other such fonts to cover (a small subset of) Unicode, these two chars where typically rendered under X11 as symmetric quotes (the ' quote was tilted a bit like the accent of é). So the above convention became ugly right around that point, but being very widespread before, it still lives on in various places. Emacs still uses it extensively, for example. ah, thank you, i never knew that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Config.in: why the occasional use of select instead of depends?
more of my annoying pedantry surfacing, but i'm puzzled as to the occasional use of select in some Config.in files. case in point -- this in toolchain/eglibc/config/Config.in: ... snip ... config EGLIBC_OPTION_EGLIBC_CRYPT bool Encryption library default y help This option group includes the `libcrypt' library which provides functions for one-way encryption. Supported encryption algorithms include MD5, SHA-256, SHA-512 and DES. config EGLIBC_OPTION_EGLIBC_CRYPT_UFC bool Ultra fast `crypt' implementation default y select EGLIBC_OPTION_EGLIBC_CRYPT ... snip ... assuming there are no other references to those two Config.in variables, the above strikes me as just awkward and unnecessarily obtuse. rather than the second one selecting the first one, why doesn't it just depend on the first one? first, would that not be entirely equivalent? more importantly, using select produces a potentially confusing menuconfig session, where both options are visible, but selecting/deselecting the second one magically changes the visual appearance of the first. once upon a time, there was a discussion on LKML regarding how many people really, really despised the arbitrary use of select in config files, because it produced magical side effects that reached across the kernel source and screwed around with other submenus. so, serious question, why select above and not depends? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][Makefile] Remove redundant FORCE dependencies from .PHONY targets
Since clean and world are declared as .PHONY, remove dependencies on FORCE. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- as long as i'm reading this correctly, since both clean and world are declared as .PHONY, there is no need for the older-style FORCE dependency, is there? diff --git a/Makefile b/Makefile index 91b6946..0043347 100644 --- a/Makefile +++ b/Makefile @@ -49,7 +49,7 @@ printdb: prepare: $(target/stamp-compile) -clean: FORCE +clean: rm -rf $(BUILD_DIR) $(BIN_DIR) $(BUILD_LOG_DIR) dirclean: clean @@ -83,7 +83,7 @@ prereq: $(target/stamp-prereq) tmp/.prereq_packages fi prepare: .config $(tools/stamp-install) $(toolchain/stamp-install) -world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp-install) $(target/stamp-install) FORCE +world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp-install) $(target/stamp-install) $(_SINGLE)$(SUBMAKE) -r package/index # update all feeds, re-create index files, install symlinks -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] picky questions about openwrt build structure
just issues of curiosity as i continue to dig through the openwrt build structure ... i notice numerous makefiles that define targets using a FORCE target, which i'm assuming guarantees that that target will always be processed. if that's the case, is there some reason those targets simply aren't declared as PHONY targets? just historical precedent? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] couple questions about downloading for a new build
first, i created a local mirror with all the tarballs i downloaded during an earlier build, and configured a new build to use that, and i noticed that the download operation *copied* over the tarballs into the dl/ directory. is there any reason that symlinks aren't used, rather than doing actual copies? wouldn't symlinks work just as well? also, i wondered if building the host tools would take advantage of already-installed host tools that match the exact version that openwrt needs. in my new build, the version of patch required is ostensibly 2.7.1, which is precisely the version already installed on my host, but it appears the patch-2.7.1.tar.xz tarball was still copied (from the local mirror, admittedly) into the dl/ directory. i haven't followed the Makefile structures far enough yet to see what should happen, but a comment in tools/Makefile reads: # in case there is no patch tool on the host we need to make patch tool a # dependency for tools which have patches directory which *seems* to suggest that the build will look for patch already installed on the host and take advantage of it if it's there. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] couple questions about downloading for a new build
On Thu, 11 Sep 2014, Yousong Zhou wrote: On 11 September 2014 20:30, Robert P. J. Day rpj...@crashcourse.ca wrote: first, i created a local mirror with all the tarballs i downloaded during an earlier build, and configured a new build to use that, and i noticed that the download operation *copied* over the tarballs into the dl/ directory. is there any reason that symlinks aren't used, rather than doing actual copies? wouldn't symlinks work just as well? I take mirrors as places where the build system will try to fetch those tarballs, into CONFIG_DOWNLOAD_FOLDER which defaults to $(TOPDIR)/dl/ which in my local tree is a symbolic link to the actually directory holding those tarballs. It works quite well. i realize that's *one* way to do it, and it's how i did it originally, but i chose instead to set up a single local mirror directory that each build can fetch from into their personal dl/ directory, whereupon i noticed that fetching from that local mirror really is doing a full copy, whereas it *seems* that just doing a symlink would work just as well and not use up all that disk space. i'm just wondering why symlinks aren't used. also, i wondered if building the host tools would take advantage of already-installed host tools that match the exact version that openwrt needs. in my new build, the version of patch required is ostensibly 2.7.1, which is precisely the version already installed on my host, but it appears the patch-2.7.1.tar.xz tarball was still copied (from the local mirror, admittedly) into the dl/ directory. IMHO, for a build system complex like OpenWrt, it's better to be self-contained and do things in a more predictable/controlled way. i agree, it was just the way i was reading the comment below that i think confused me. i haven't followed the Makefile structures far enough yet to see what should happen, but a comment in tools/Makefile reads: # in case there is no patch tool on the host we need to make patch # tool a dependency for tools which have patches directory which *seems* to suggest that the build will look for patch already installed on the host and take advantage of it if it's there. No, it tries to handle the case that some host tools needs to be patched (having patches/ directory) before getting compiled in which case those tools/XXX/compile needs to have a dependence on tools/patch/install. ok, i think i see what that comment means ... if any tool needs patching, then patch is registered as a necessary host tool and it *will* be downloaded and built, even if it already exists on the host, correct? however, assuming i understand that, there are now two new things that puzzle me. first, i selected CONFIG_CCACHE and, as i read it, that would normally mean i would need the ccache utility to be downloaded and built as a host tool (even if it's already installed, yes?). but it's not. even though: CONFIG_CCACHE=y i see no ccache tarball in my dl/ direectory. ccache is, in fact, installed on my build host, but i thought we just agreed that that shouldn't make a difference. so what would force ccache to be downloaded and built? finally, mtd-utils -- the recipe specifies both a version number and git info in the Makefile: PKG_NAME:=mtd-utils PKG_VERSION:=1.4.5 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=git://git.infradead.org/mtd-utils.git PKG_SOURCE_PROTO:=git PKG_SOURCE_VERSION:=5319b84974fcb71504aed2d1b8285e9c0a4a4bb8 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) PKG_CAT:=zcat now, the first time i downloaded all the tools, git cloned the mtd-utils repository, and created the tarball mtd-utils-1.4.5.tar.gz. however, even though i added that to my local mirror directory, the download uses a git clone every time. should it not look in my local mirror, and notice that the tarball is there? or does that not apply to source that is cloned from a git repo? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] still remnants left around from deletion of LLVM back in 2013
long story short: poking around llvm content in openwrt, which looked really weird and eventually led me to this: commit 9241c57193bb8af2c1f4944ee21249b927cfecff Author: kaloz kaloz@3c298f89-4303-0410-b956-a3cf2f4a3e73 Date: Mon Apr 1 15:08:38 2013 + [toolchain/gcc]: llvm is marked broken for two and a half year now, nuke it git-svn-id: svn://svn.openwrt.org/openwrt/trunk@36145 3c298f89-4303-0410-b956-a3cf2f4a3e73 diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in index f83f83c..6cfde54 100644 --- a/toolchain/gcc/Config.in +++ b/toolchain/gcc/Config.in @@ -26,16 +26,11 @@ choice config GCC_VERSION_4_7_LINARO bool gcc 4.7.x with Linaro enhancements - config GCC_VERSION_LLVM - bool llvm-gcc 4.2 - depends BROKEN - ... snip ... but there are still some references to llvm in the source tree: $ grep -r LLVM * package/utils/busybox/Makefile:ifdef CONFIG_GCC_VERSION_LLVM toolchain/gcc/common.mk:$(if $(shell gcc --version 21 | grep LLVM), \ toolchain/Makefile:ifdef CONFIG_GCC_VERSION_LLVM tools/Makefile:ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN)$(CONFIG_GCC_LLVM),) $ should those final remnants be removed? and what's with CONFIG_GCC_LLVM, anyway? is that a typo? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] where do i submit a target-related bug report?
i erroneously submitted a target-related bug report to the packages bug tracker. where is the proper place to submit such an issue? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where do i submit a target-related bug report?
On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 08:36, Robert P. J. Day rpj...@crashcourse.ca wrote: i erroneously submitted a target-related bug report to the packages bug tracker. where is the proper place to submit such an issue? thanks. Have you heard about http://google.com/ ? Try openwrt bug reports. why, yes, i *have* heard of google ... and in fact i did that recently, whereupon the very first match took me here: http://wiki.openwrt.org/doc/devel/bugs which, as it turns out, gave me completely outdated and incorrect instructions on how to open a ticket. so if you could ditch the attitude and be helpful, that would be great. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where do i submit a target-related bug report?
On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 09:24, Robert P. J. Day rpj...@crashcourse.ca wrote: On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 08:36, Robert P. J. Day rpj...@crashcourse.ca wrote: i erroneously submitted a target-related bug report to the packages bug tracker. where is the proper place to submit such an issue? thanks. Have you heard about http://google.com/ ? Try openwrt bug reports. why, yes, i *have* heard of google ... and in fact i did that recently, whereupon the very first match took me here: http://wiki.openwrt.org/doc/devel/bugs which, as it turns out, gave me completely outdated and incorrect instructions on how to open a ticket. so if you could ditch the attitude and be helpful, that would be great. The two very first results I got: http://wiki.openwrt.org/doc/devel/bugs https://dev.openwrt.org/report and i now see where i was getting confused. when i had an earlier problem with a *package*, i was told to file a report at github, but i had read the above pages and incorrectly filed a report in trac, whereupon i was chastised for filing in the wrong place. having thought i now knew the *correct* place to file bug reports, i filed a target-specific issue in trac, whereupon it was closed since it was not related to a *package*. so, to clarify. * package-related issues go to github? * target-related issues go to trac? which appears to be what it says here: http://wiki.openwrt.org/doc/devel/bugs but only if you read the entire page, and not stop at the first line which says, To report a bug, go here:. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where do i submit a target-related bug report?
On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 09:24, Robert P. J. Day rpj...@crashcourse.ca wrote: http://wiki.openwrt.org/doc/devel/bugs which, as it turns out, gave me completely outdated and incorrect instructions on how to open a ticket What's so completely outdated there? i just replied to that -- not outdated, just misleading for a first-time reader. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where do i submit a target-related bug report?
On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 09:38, Robert P. J. Day rpj...@crashcourse.ca wrote: so, to clarify. * package-related issues go to github? * target-related issues go to trac? That's mostly correct. There are still some special packages (like uci, fstools, iptables, etc.) that are part of OpenWrt repository and problems with them should be reported on trac. For all fancy software however you should use github. i added a couple early lines to the wiki page here: http://wiki.openwrt.org/doc/devel/bugs to make it a bit clearer where bugs should be reported. anyone else is welcome to tweak it further. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where do i submit a target-related bug report?
On Wed, 10 Sep 2014, Rafał Miłecki wrote: On 10 September 2014 09:38, Robert P. J. Day rpj...@crashcourse.ca wrote: so, to clarify. * package-related issues go to github? * target-related issues go to trac? That's mostly correct. There are still some special packages (like uci, fstools, iptables, etc.) that are part of OpenWrt repository and problems with them should be reported on trac. For all fancy software however you should use github. thanks, that clears things up immensely. once i think i understand this completely, i'll adjust the appropriate wiki pages to explain this for the next poor newbie who tries to file an issue. :-) whoops, hang on, i just noticed that my github report which was closed as inappropriate was just reopened as it apparently relates to the devel/gcc package after all: https://github.com/openwrt/packages/issues/296 i'll figure all this out eventually, thanks for your patience. and i apologize for my earlier snippiness -- tired, cranky and just wanting to get a build out of this. :-( rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][toolchain] Aesthetic/formatting fixes to toolchain/Config.in.
Non-functional edits to toolchain/Config.in: * fix spelling mistake (us - is) * Overly long help lines shortened to avoid line wrap * Standardize help info to use tab(s), then two spaces Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- i hope no one objects to my patches which are simply aesthetic cleaning of files i'm currently examining. if there's a better way to submit these, let me know. diff --git a/toolchain/Config.in b/toolchain/Config.in index 7257f1d..aad7095 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -43,7 +43,8 @@ menuconfig EXTERNAL_TOOLCHAIN bool prompt Use external toolchain if DEVEL help - If enabled, OpenWrt will compile using an existing toolchain instead of compiling one + If enabled, OpenWrt will compile using an existing toolchain instead of + compiling one. config NATIVE_TOOLCHAIN bool @@ -51,7 +52,8 @@ menuconfig EXTERNAL_TOOLCHAIN depends on EXTERNAL_TOOLCHAIN select NO_STRIP help - If enabled, OpenWrt will compile using the native toolchain for your host instead of compiling one + If enabled, OpenWrt will compile using the native toolchain for your + host instead of compiling one. config TARGET_NAME string @@ -95,10 +97,10 @@ menuconfig EXTERNAL_TOOLCHAIN depends on EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN default uclibc help - Specify the libc type used by the external toolchain. The given value us passed as -m - flag to all gcc and g++ invocations. This is mainly intended for multilib toolchains - which support glibc and uclibc at the same time. If no value is specified, no -m flag - is passed. + Specify the libc type used by the external toolchain. The given value + is passed as -m flag to all gcc and g++ invocations. This is mainly + intended for multilib toolchains which support glibc and uclibc at + the same time. If no value is specified, no -m flag is passed. config TOOLCHAIN_BIN_PATH string @@ -106,8 +108,8 @@ menuconfig EXTERNAL_TOOLCHAIN depends on EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN default ./usr/bin ./bin help - Specify additional directories searched for toolchain binaries (override PATH) - Use ./DIR for directories relative to the root above + Specify additional directories searched for toolchain binaries + (override PATH). Use ./DIR for directories relative to the root above. config TOOLCHAIN_INC_PATH string @@ -115,8 +117,8 @@ menuconfig EXTERNAL_TOOLCHAIN depends on EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN default ./usr/include ./include help - Specify additional directories searched for header files (override CPPFLAGS) - Use ./DIR for directories relative to the root above + Specify additional directories searched for header files (override + CPPFLAGS). Use ./DIR for directories relative to the root above. config TOOLCHAIN_LIB_PATH string @@ -124,8 +126,8 @@ menuconfig EXTERNAL_TOOLCHAIN depends on EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN default ./usr/lib ./lib help - Specify additional directories searched for libraries (override LDFLAGS) - Use ./DIR for directories relative to the root above + Specify additional directories searched for libraries (override LDFLAGS). + Use ./DIR for directories relative to the root above. config NEED_TOOLCHAIN bool @@ -237,7 +239,7 @@ config GDB prompt Build gdb if TOOLCHAINOPTS default y if !EXTERNAL_TOOLCHAIN help - Enable if you want to build the gdb + Enable if you want to build the gdb. config INSIGHT bool @@ -245,7 +247,7 @@ config INSIGHT select GDB default n help - Enable if you want to build insight-gdb + Enable if you want to build insight-gdb. config USE_EGLIBC bool -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
[OpenWrt-Devel] [PATCH] [config] Various typo/grammar/line-length fixes in Config*.in files
Non-functional changes to config/Config-*.in files, including: * spelling mistakes * inconsistent terminology * grammar * overly long lines in help components Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- while digging through the four existing Config*.in files to understand the build structure, i started tweaking a number of entries, for the most part to fix help information regarding things like grammar, punctuation, using consistent terminology and, in many cases, overly long lines, given that the standard is typically that displayed config help should not exceed 80 characters to avoid wrapping in a terminal window. these changes appear to make no difference in a build test i just ran, and you're welcome to ignore them as unnecessary -- i figured that, while i was there, i'd do some proofreading and editing. diff --git a/config/Config-build.in b/config/Config-build.in index 02fe136..89cf964 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -20,23 +20,25 @@ menu Global build settings default y bool Compile with support for patented functionality help - When this option is disabled, software which provides patented functionality will not be built. - In case software provides optional support for patented functionality, - this optional support will get disabled for this package. + When this option is disabled, software which provides patented functionality + will not be built. In case software provides optional support for patented + functionality, this optional support will get disabled for this package. config BUILD_NLS default n bool Compile with full language support help - When this option is enabled, packages are built with the full versions of iconv and GNU gettext - instead of the default OpenWrt stubs. If uClibc is used, it is also built with locale support. + When this option is enabled, packages are built with the full versions of + iconv and GNU gettext instead of the default OpenWrt stubs. If uClibc is + used, it is also built with locale support. config BUILD_STATIC_TOOLS default n bool Attempt to link host utilities statically help - Linking host utilities like sed or firmware-utils statically increases the portability of the - generated ImageBuilder and SDK tarballs, however it may fail on some Linux distributions. + Linking host utilities like sed or firmware-utils statically increases the + portability of the generated ImageBuilder and SDK tarballs; however, it may + fail on some Linux distributions. config SHADOW_PASSWORDS bool @@ -50,7 +52,8 @@ menu Global build settings prompt Remove ipkg/opkg status data files in final images default n help - This removes all ipkg/opkg status data files from the target directory before building the root fs + This removes all ipkg/opkg status data files from the target directory + before building the root filesystem. config COLLECT_KERNEL_DEBUG bool @@ -59,7 +62,8 @@ menu Global build settings default n help This collects debugging symbols from the kernel and all compiled modules. - Useful for release builds, so that kernel issues can be debugged offline later. + Useful for release builds, so that kernel issues can be debugged offline + later. comment Kernel build options @@ -72,24 +76,24 @@ menu Global build settings prompt Compile packages with debugging info default n help - Adds -g3 to the CFLAGS + Adds -g3 to the CFLAGS. config IPV6 bool prompt Enable IPv6 support in packages default y help - Enable IPV6 support in packages (passes --enable-ipv6 to configure scripts). + Enable IPv6 support in packages (passes --enable-ipv6 to configure scripts). config PKG_BUILD_PARALLEL bool prompt Compile certain packages parallelized default y help - This adds a -jX option to certain packages that are known to - behave well for parallel build. By default the package make processes - use the main jobserver, in which case this option only takes effect - when you add -jX to the make command. + This adds a -jX
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Etienne Champetier wrote: Hi Le 7 sept. 2014 23:40, Robert P. J. Day rpj...@crashcourse.ca a écrit : still reviewing so i don't think i have the background to debug this one: $ make V=s ... big snip ... Package emailrelay-nossl is missing dependencies for the following libraries: libcrypto.so.1.0.0 libssl.so.1.0.0 Makefile:118: recipe for target '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' failed make[3]: *** [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] Error 1 i'm using the default config.ramips_mt7620a config file. thoughts? rday Please open an issue on github github? the FAQ instructs one to report bugs here: http://dev.openwrt.org/report can you clarify? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Etienne Champetier wrote: Hi Le 7 sept. 2014 23:40, Robert P. J. Day rpj...@crashcourse.ca a écrit : still reviewing so i don't think i have the background to debug this one: $ make V=s ... big snip ... Package emailrelay-nossl is missing dependencies for the following libraries: libcrypto.so.1.0.0 libssl.so.1.0.0 Makefile:118: recipe for target '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' failed make[3]: *** [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] Error 1 i'm using the default config.ramips_mt7620a config file. thoughts? rday Please open an issue on github submitted through trac: https://dev.openwrt.org/ticket/17794 rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Jonas Gorski wrote: On Mon, Sep 8, 2014 at 2:14 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Mon, 8 Sep 2014, Etienne Champetier wrote: Hi Le 7 sept. 2014 23:40, Robert P. J. Day rpj...@crashcourse.ca a écrit : still reviewing so i don't think i have the background to debug this one: $ make V=s ... big snip ... Package emailrelay-nossl is missing dependencies for the following libraries: libcrypto.so.1.0.0 libssl.so.1.0.0 Makefile:118: recipe for target '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' failed make[3]: *** [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] Error 1 i'm using the default config.ramips_mt7620a config file. thoughts? rday Please open an issue on github submitted through trac: https://dev.openwrt.org/ticket/17794 Trac is not github. The (new) packages feed is at https://www.github.com/openwrt/packages and any issues for the packages therein should be raised there. i realize that, except that if one goes to the development page here: https://dev.openwrt.org/ one of the first links is entitled Add a new ticket, and it takes you to trac. pretty sure it's not my fault if i followed precisely the directions at the openwrt development page. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Jonas Gorski wrote: I do acknowledge that the trac intro page doesn't have instructions for bugs in feeds, but you didn't follow the directions completely. You were told to report to github, and then actively decided to disregard that. i (incorrectly) assumed you made a slip of the tongue since the wiki page pointed me at trac -- my apologies. i just noticed that, further down that same page is the link to github error reporting specifically for packages: https://github.com/openwrt/packages/issues so i'll reproduce the issue there. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
ok, new issue at github: https://github.com/openwrt/packages/issues/291 is this the proper format? is there any information i failed to include? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
still reviewing so i don't think i have the background to debug this one: $ make V=s ... big snip ... Package emailrelay-nossl is missing dependencies for the following libraries: libcrypto.so.1.0.0 libssl.so.1.0.0 Makefile:118: recipe for target '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' failed make[3]: *** [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] Error 1 i'm using the default config.ramips_mt7620a config file. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [scripts] Fix typo, replace quotes in comments
No functional changes. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- first, admittedly trivial patch just to verify i'm doing this correctly. it's only because i fixed the typo that i bothered to get rid of those backquotes -- to me, backquotes mean something quite special so i prefer to avoid using them unless it's in the specific context of shell command substitution. if this patch is of the correct format, further patches will eventually be more substantive. diff --git a/scripts/update-package-md5sum b/scripts/update-package-md5sum index 1cf1716..3b4e047 100755 --- a/scripts/update-package-md5sum +++ b/scripts/update-package-md5sum @@ -2,12 +2,12 @@ # # update-package-md5sum - Updates md5sum of OpenWrt packages # -# update-package-md5sum will update the md5sum for all recusivly found OpenWrt packages -# in a given directory. +# update-package-md5sum will update the md5sum for all recursively-found +# OpenWrt packages in a given directory. # # Usage: scripts/update-package-md5sum package directory # -# Example: `scripts/update-package-md5sum feeds/packages/python` +# Example: $ scripts/update-package-md5sum feeds/packages/python DL_FOLDER=`grep -Eo '^CONFIG_DOWNLOAD_FOLDER=.*$' .config | \ sed 's,^CONFIG_DOWNLOAD_FOLDER=\(.*\)$,\1,'` -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Documentation link on main page goes to kamikaze
feel free to suggest where i can make observations as i peruse the openwrt web and wiki pages, since i don't want to waste the list's time with minor pedantry. on the main openwrt page (https://openwrt.org/), over on the right under Latest release: 12.09, while the Download link takes you to the right place, the Documentation link still points at what i'm guessing is older kamikaze docs. is that link still valid for the newer release? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [scripts] Fix typo, replace quotes in comments
On Thu, 4 Sep 2014, Bastian Bittorf wrote: * Robert P. J. Day rpj...@crashcourse.ca [04.09.2014 10:54]: -# Example: `scripts/update-package-md5sum feeds/packages/python` +# Example: $ scripts/update-package-md5sum feeds/packages/python if you use '$' instead of '`', you must use e.g. $(...) so `shell_command` or $(shell_command) the $ i used above is meant to represent just the command-line prompt, it's not being used for a variable or command line substitution. i took out the backquotes specifically *because* i didn't think just showing a command example needed to incorporate command substitution. perhaps i should have just left the $ out entirely. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] seems like outdated link on devel page
wandering thru the openwrt pages, getting back up to speed, and on the development page: https://dev.openwrt.org/ the link labelled Developer and User Documentation takes one to a kamikaze-related page, which seems kind of old. and, yes, i know it's a wiki but i don't have the street cred to start messing around in some places. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Resume work on Asus WL500g2 (LP-PHY)
On Wed, 28 Jan 2009, Michael Buesch wrote: On Tuesday 27 January 2009 12:42:20 Robert P. J. Day wrote: On Mon, 26 Jan 2009, Michael Buesch wrote: I just want to note that I resumed work on the WL500gV2, which has a b43 based LP-PHY wireless device. I cannot make any guarantees or timelines, just that it's done when it's done. I'll first look into making the serial port work. i'm particularly interested in this project, since i love my V1 but it's getting harder to find them, while the V2s are far more common. let me know if i can do anything to help. i can start by going out and getting one. :-) Yes, you can help me a lot. I just bricked it. Can you be so kind to give me images of your CFE and NVRAM partitions of a working v2 device? You can read them with the mtd utility in linux. you'll have to wait until later today as i was just going out to get one later this morning. unless someone else can help you out more quickly. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] repeated kernel config questions
Quoting Brian J. Murrell [EMAIL PROTECTED]: On Mon, 2008-11-10 at 14:03 +0100, Gregers Petersen wrote: Did you try 'make clean' and then a new 'menuconfig' ? I did make clean before I did make oldconfig. Why should I need to make menuconfig? I don't want to use the stupid menu interface. make oldconfig should achieve the same thing, no? make oldconfig did ask me questions about new openwrt options, but it did not prompt me about any of those kernel options. I suspect there is a disconnect between those new kernel options and the supporting options in openwrt's configuration for them or some such. I'm not entirely clear of the relationship between those configs. typically, you will be perpetually asked about NEW kernel options if the default config file has no mention of them. for every valid kernel option, the default config file should either select that option, or have a line commented out saying that that option is not set. one or the other. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] repeated kernel config questions
Quoting Stanislav Sinyagin [EMAIL PROTECTED]: The makefiles override the kernel config each time you do make menuconfig. It's not a bug, it's so by design :) really? i don't have the build structure in front of me, but the standard kernel config recipe is that, if you have no .config file, the build will grab the default (and, hence, you might have to answer questions about NEW options.) however, as long as you have an existing .config, the build process will use it. are you saying that any existing .config file will *always* be ignored in favour of the default? that would be unusual, and definitely non-standard behaviour. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] repeated kernel config questions
Quoting bifferos [EMAIL PROTECTED]: I think he means ones like this: https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/config-2.6.27 I'd really love this to be fixed, because it makes building custom kernels a nuisance. Presumably it's done this way because it makes things simpler in terms of supporting newly released kernels for all the various target profiles? I get around this by piping a file full of carriage returns into the build process - not exactly elegant. actually, the normal way to handle that is: $ yes '' | make oldconfig the yes command simply churns out its argument as long as it's read. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] what's the news on 8.08?
if openwrt 8.08 is going to be any further delayed, it would be nice to have a top-level post on the openwrt.org page explaining this and keeping people up-to-date. there are few things more frustrating than simply having no idea what's going on. rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [gcc4.3] Adding initial support for m68k/coldfire
whoa, please don't do that again. with something that large, just post it somewhere and let others download it if they're interested. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Infrastructure question
On Sun, 27 Apr 2008, Sergey Lapin wrote: Hi, all! Is there make targets to accomplish the following things: * build just one package w/o other stuff, just to check it builds and packages well; * build kernel, for the same reasons? Thanks a lot, i've occasionally wondered whether there was a make target to do precisely one task as well. it would be handy if the openwrt makefile supported a make help like the linux kernel does, in that it would simply print all of the possible targets. one could either rewrite the current make help target, or create a new one like, say, make list_targets. but a comprehensive list of openwrt targets would be *immensely* helpful. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] why does my initial /etc/ipkg.conf file refer to snapshots?
perhaps i just missed the doc on how to update this, but the freshly-created /etc/ipkg.conf for my brcm47xx build creates a new /etc/ipkg.conf file that contains the following: src snapshots http://downloads.openwrt.org/snapshots/brcm47xx/packages dest root / dest ram /tmp however, there is no such directory at downloads. am i simply expected to adjust the contents of this file, or should the build create a correct file? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] why does my initial /etc/ipkg.conf file refer to snapshots?
On Sat, 26 Apr 2008, Oliver Ertl wrote: I always compile trunk by myself and put the package repository on a web or FTP server. so you simply do an all-package build and create your own repo, is that what you're saying? that's the direction i'm going in as well. Yes. But I only compile the packages I need. Nothing more. sure, but nothing stops you from just building them all just to play it safe. In the build-system I change either package/base-files/files/etc/ipkg.conf to have a new standard ipkg.conf for all targets. what do you mean you change either? i'm assuming that what you're referring to is that, before an image build, you modify the contents of the generic /etc/ipkg.conf file to refer to your repository, correct? and that modified version will be used for any new image you build. Absolutly right :) i did a quick find for all ipkg.conf files in a clean tree, and what i got was: $ find . -name ipkg.conf ./package/base-files/files/etc/ipkg.conf ./target/linux/etrax/base-files/etc/ipkg.conf ./target/linux/at91/base-files/etc/ipkg.conf $ so i'm assuming that all image builds will use whatever is in that first one, but etrax and at91 are the sole exceptions to that rule. i'd never noticed that before. For target specific ipkg.conf files change or add the file target/linux/arch/base-files/etc/ipkg.conf. and i haven't looked closely enough yet -- if you have both a generic and an arch-specific ipkg.conf file, what happens? are the combined in your final image? a pointer to the part of the build infrastructure that deals with that would be great so i can RTFS for myself. thanks muchly. A arch specific ipkg.conf will simply overwrite the generic one. right, as i noted above. You can check the contents of your final /etc/ipkg.conf file which goes into the image at build_dir/arch/root-board/etc/ipkg.conf I hope this helps. Sorry, my native language is German. no problem, thanks for clearing that up. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] update README to mention need for perl?
if someone wants to tweak this, shouldn't the top-level README file mention a need for perl on the build system? rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] some questions about the tools building infrastructure
i'm following through the setup for building the various host tools, and i have a few questions. as i read it, the basic makefile on top of which the tools building is based is include/host-build.mk, which defines a number of default actions such as Build/Prepare/Default, Build/Configure/Default, Build/Compile/Default and so on. for each tool, if that action is appropriate, that tool's Makefile doesn't need to define that action. on the other hand, if that particular action needs to be different, then that tool's Makefile has to redefine that action. as an example, host-build.mk includes the snippet: define Build/Compile/Default $(MAKE) -C $(PKG_BUILD_DIR) $(1) endef but the Makefile for automake apparently needs a slightly different compile step, so it has to redefine with: define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) endef as an override. is that correct? next, i notice that host-build.mk doesn't define a default clean rule, so i'm assuming that cleaning just isn't standard enough to define such a thing, which means that each tools Makefile has to do that explicitly. however, *if* that's the case, what does this mean in the automake Makefile: define Build/Clean $(MAKE) -C $(PKG_BUILD_DIR) uninstall $(MAKE) -C $(PKG_BUILD_DIR) clean $(call Build/Clean/Default) -- ??? endef as far as i can tell, there is no Build/Clean/Default defined anywhere, is there? so what is the purpose of that line? moving on, i can see that some Makefiles have to define the PKG_CAT to represent the cat variation with which to unpack the package source. if the source is a bz2 tarball, it's not necessary. however, i noticed that if the tarball is simply .gz, then you normally see PKG_CAT:=zcat but is that really necessary? it seems like the makefile include/unpack.mk would auto-detect the tarball type and force the use of zcat automatically, no? or am i misreading something? continuing, i see that host-build.mk defines the default package build directory as: PKG_BUILD_DIR ?= $(BUILD_DIR_HOST)/$(PKG_NAME)$(if $(PKG_VERSION),-$(PKG_VERSION)) but if you look at the Makefile for dtc, you read: PKG_NAME:=dtc PKG_VERSION:=1.1.0 ... PKG_BUILD_DIR=$(BUILD_DIR_HOST)/$(PKG_NAME) -- is this necessary? but wouldn't that last line be redundant? isn't that what PKG_BUILD_DIR would be set to anyway? as another example of what looks like a redundancy, there's the lzma Makefile: PKG_BUILD_DIR:=$(BUILD_DIR_HOST)/$(PKG_NAME)-$(PKG_VERSION)/lzma PKG_UNPACK:=bzcat $(DL_DIR)/$(PKG_SOURCE) | $(TAR) -C $(PKG_BUILD_DIR)/ $(TAR_OPTIONS) i can see why you need to override the standard PKG_BUILD_DIR but, once that's done, wouldn't the default PKG_UNPACK command work just fine? after all, it should just untar the source tarball into the PKG_BUILD_DIR, no? anyway, that should do for now and will give me a good idea if i've totally misunderstood some important ideas. thanks. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] cbtt compilation broken
i'm currently doing another run-through trying to build every possible package for my ASUS WL-500GP and the latest breakage is with the cbtt package: atom.cpp: In copy constructor 'CAtomList::CAtomList(const CAtomList)': atom.cpp:221: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:222: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:223: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:224: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:225: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:226: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:227: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:228: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:229: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:230: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp: In copy constructor 'CAtomDicti::CAtomDicti(const CAtomDicti)': atom.cpp:333: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:334: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:335: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:336: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:337: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:338: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:339: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:340: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:341: error: 'dynamic_cast' not permitted with -fno-rtti atom.cpp:342: error: 'dynamic_cast' not permitted with -fno-rtti make[4]: *** [atom.o] Error 1 ... should i file a ticket related to this? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] error building libshout
... ogg.c:33:24: error: tremor/ogg.h: No such file or directory In file included from ogg.c:37: shout_ogg.h:34: error: expected specifier-qualifier-list before 'ogg_stream_state' shout_ogg.h:47: error: expected declaration specifiers or '...' before 'ogg_page' shout_ogg.h:52: error: expected declaration specifiers or '...' before 'ogg_page' ogg.c:41: error: expected specifier-qualifier-list before 'ogg_sync_state' ogg.c:49: error: expected declaration specifiers or '...' before 'ogg_page' ogg.c:52: error: expected declaration specifiers or '...' before 'ogg_page' ogg.c:54: error: expected declaration specifiers or '...' before 'ogg_page' ... etc etc ... rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] lirc build still broken, erroneously refers to mipsel kernel dir
the build of lirc-0.8.3pre1 for the (MIPS-based) ASUS WL500-GP is broken thusly: ... make[9]: Entering directory `/home/rpjday/openwrt/wl-500gp/build/git-trunk/build_dir/linux-brcm47xx/linux-2.6.23.16' Makefile:492: /home/rpjday/openwrt/wl-500gp/build/git-trunk/build_dir/linux-brcm47xx/linux-2.6.23.16/arch/mipsel/Makefile: No such file or directory make[9]: *** No rule to make target `/home/rpjday/openwrt/wl-500gp/build/git-trunk/build_dir/linux-brcm47xx/linux-2.6.23.16/arch/mipsel/Makefile'. Stop. ... that's because there *is* no kernel arch directory named mipsel, only mips. so how does one correct that kind of issue? obviously, any package being built for mipsel should still realize that the directory name is simply mips. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mjpg-streamer-r56.tar.bz2 not found in sources/
the mjpg-streamer package doesn't build as the download can't find the respective tarball. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] anyone have any ideas on why asterisk-addons still can't build
essentially, it's still this problem: https://dev.openwrt.org/ticket/2858 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] upgrade: libsamplerate from 0.1.2 to 0.1.3
if you upgrade that package thusly, the build error goes away and you don't need the libtool patch anymore. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] any problems with bumping up the toolchain versions?
On Thu, 27 Mar 2008, Imre Kaloz wrote: On 2008.03.27. 23:03:59 Robert P. J. Day [EMAIL PROTECTED] wrote: is there any inherent difficulty in bumping up the software versions of the toolchain components? say, binutils to 2.18 and gcc to 4.2.3? i realize you can always do that *manually* but if those values are the *defaults*, it's more likely that people will use them and will identify build problems if they exist. i think it's more valuable to push the toolchain along, just so if there are issues hiding in the newer versions, they're identified as quickly as possible. The reason why we stick to 4.1.2 is simply the fact that it compiles good code. 4.2 is broken on ARM, misscompiles some stuff on x86, not to mention that probably noone tested all platforms out there. We slowly bumb toolchain versions when the toolchain is known to work nicely for some time for a developer. ok, i didn't realize the situation WRT to gcc. but is there anything stopping upgrading the default of binutils to 2.18? does that not work well with any of the architectures? as i mentioned before, unless there's an actual issue, i'm a big fan of pushing version upgrades so that any problems can be identified sooner rather than later. if a newer version of some toolchain component works on all but one architecture, i think it's more useful to bump the default version, except in the case of that one architecture (which is what the binutils Config.in would be doing anyway WRT to avr32, which doesn't have patches for binutils-2.18). anyway, just my $0.02. rday p.s. and what about gdb? currently, it's sitting at 6.3 while 6.7.1 is out. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Libsamplerate not building - autoconfig version mismatch
On Fri, 28 Mar 2008, Michael wrote: I am getting an automake version mismatch when compiling libsamplerate. This worked for me: define Build/Compile pushd $(PKG_BUILD_DIR) aclocal automake popd . I can make that an official patch if you would like. there's been a ticket on this for a while: https://dev.openwrt.org/ticket/2851 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] any problems with bumping up the toolchain versions?
On Thu, 27 Mar 2008, Imre Kaloz wrote: On 2008.03.27. 23:37:47 Luigi 'Comio' Mantellini [EMAIL PROTECTED] wrote: snip Ok. Anyway the compiler gcc4.3 supports a lot new cpus (like the coldfire) :) opening new development horizons. Sure, as AVR32 uses gcc 4.2.3.. Some targets work better with newer compilers, others do not. Spice this is up with uClibc, and you have fun everytime you play with toolchain combinations ;) rday already sent a preliminary 4.3 patch top the list, if you volunteer to fix it up, we are happy to add it :) Same goes for your platform :) that was a first attempt, i was making no guarantees. :-) will post more on this later. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] upgrade fuse-2.7.1 to fuse-2.7.3 to fix breakage.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
i'm not sure why this patch wouldn't apply cleanly. it applies
perfectly cleanly against the latest git tree with patchlevel 1 on my
system. can anyone else verify this? thanks.
package/fuse/Makefile|4
package/fuse/patches/100-cross_compile.patch |7
package/fuse/patches/102-no_depmod.patch |7
package/fuse/patches/112-no_break_on_mknod.patch |8
package/fuse/patches/200-disable_compat.patch| 692 ++---
package/fuse/patches/300-2.6.24_fixes.patch | 246
6 files changed, 359 insertions(+), 605 deletions(-)
diff --git a/package/fuse/Makefile b/package/fuse/Makefile
index 8d280e1..2376eaa 100644
--- a/package/fuse/Makefile
+++ b/package/fuse/Makefile
@@ -10,12 +10,12 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=fuse
-PKG_VERSION:=2.7.1
+PKG_VERSION:=2.7.3
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:[EMAIL PROTECTED]/$(PKG_NAME)
-PKG_MD5SUM:=f95b4a238a3df5a92e9013ecb55c2c17
+PKG_MD5SUM:=98563fc7b265b7479a3178181cbcf59a
include $(INCLUDE_DIR)/package.mk
diff --git a/package/fuse/patches/100-cross_compile.patch
b/package/fuse/patches/100-cross_compile.patch
index 2ce83c4..54a4d59 100644
--- a/package/fuse/patches/100-cross_compile.patch
+++ b/package/fuse/patches/100-cross_compile.patch
@@ -1,7 +1,6 @@
-Index: fuse-2.6.5/kernel/configure
-===
fuse-2.6.5.orig/kernel/configure 2007-06-23 13:03:50.0 +0200
-+++ fuse-2.6.5/kernel/configure2007-06-23 13:03:50.0 +0200
+diff -Nru fuse-2.7.3.orig/kernel/configure fuse-2.7.3/kernel/configure
+--- fuse-2.7.3.orig/kernel/configure 2008-02-19 15:00:19.0 -0500
fuse-2.7.3/kernel/configure2008-03-17 14:10:14.0 -0400
@@ -1851,7 +1851,9 @@
{ echo $as_me:$LINENO: checking kernel source version 5
diff --git a/package/fuse/patches/102-no_depmod.patch
b/package/fuse/patches/102-no_depmod.patch
index 899d307..ee86942 100644
--- a/package/fuse/patches/102-no_depmod.patch
+++ b/package/fuse/patches/102-no_depmod.patch
@@ -1,7 +1,6 @@
-Index: fuse-2.6.5/kernel/Makefile.in
-===
fuse-2.6.5.orig/kernel/Makefile.in 2007-06-23 13:03:50.0 +0200
-+++ fuse-2.6.5/kernel/Makefile.in 2007-06-23 13:03:50.0 +0200
+diff -Nru fuse-2.7.3.orig/kernel/Makefile.in fuse-2.7.3/kernel/Makefile.in
+--- fuse-2.7.3.orig/kernel/Makefile.in 2006-12-09 13:51:13.0 -0500
fuse-2.7.3/kernel/Makefile.in 2008-03-17 14:12:32.0 -0400
@@ -25,11 +25,9 @@
install-y: all
$(mkdir_p) $(DESTDIR)$(fusemoduledir)
diff --git a/package/fuse/patches/112-no_break_on_mknod.patch
b/package/fuse/patches/112-no_break_on_mknod.patch
index 93e3242..911d25c 100644
--- a/package/fuse/patches/112-no_break_on_mknod.patch
+++ b/package/fuse/patches/112-no_break_on_mknod.patch
@@ -1,8 +1,6 @@
-Index: fuse-2.6.5/util/Makefile.in
-===
fuse-2.6.5.orig/util/Makefile.in 2007-06-23 13:03:50.0 +0200
-+++ fuse-2.6.5/util/Makefile.in2007-06-23 13:03:50.0 +0200
-@@ -489,7 +489,7 @@
+--- fuse-2.7.3.orig/util/Makefile.in 2008-02-19 15:00:55.0 -0500
fuse-2.7.3/util/Makefile.in2008-03-17 14:14:10.0 -0400
+@@ -528,7 +528,7 @@
install-exec-hook:
-chown root $(DESTDIR)$(bindir)/fusermount
-chmod u+s $(DESTDIR)$(bindir)/fusermount
diff --git a/package/fuse/patches/200-disable_compat.patch
b/package/fuse/patches/200-disable_compat.patch
index d4bb978..12203d3 100644
--- a/package/fuse/patches/200-disable_compat.patch
+++ b/package/fuse/patches/200-disable_compat.patch
@@ -1,25 +1,22 @@
-Index: fuse-2.7.1/include/fuse_common_compat.h
-===
fuse-2.7.1.orig/include/fuse_common_compat.h 2007-10-20
17:13:51.409738304 +0200
-+++ fuse-2.7.1/include/fuse_common_compat.h2007-10-20 17:14:26.323727941
+0200
+diff -Nru fuse-2.7.3.orig/include/fuse_common_compat.h
fuse-2.7.3/include/fuse_common_compat.h
+--- fuse-2.7.3.orig/include/fuse_common_compat.h 2008-02-19
14:51:23.0 -0500
fuse-2.7.3/include/fuse_common_compat.h2008-03-17 14:55:01.0
-0400
@@ -17,6 +17,7 @@
- unsigned int keep_cache : 1;
+ unsigned int keep_cache : 1;
};
+#ifndef DISABLE_COMPAT
int fuse_mount_compat25(const char *mountpoint, struct fuse_args *args);
int fuse_mount_compat22(const char *mountpoint, const char *opts);
-@@ -24,4 +25,4 @@
+@@ -24,3 +25,4 @@
int fuse_mount_compat1(const char *mountpoint, const char *args[]);
void fuse_unmount_compat22(const char *mountpoint);
--
+#endif
-Index: fuse-2.7.1/lib/fuse.c
[OpenWrt-Devel] any progress on using installed host tools?
a while back, i proposed having the build check if any of the already-installed host tools were suitable so that you didn't have to download and build them -- sed being the perfect example since almost everyone has a relatively recent sed on their system. has anyone done anything along those lines yet? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] any problems with bumping up the toolchain versions?
is there any inherent difficulty in bumping up the software versions of the toolchain components? say, binutils to 2.18 and gcc to 4.2.3? i realize you can always do that *manually* but if those values are the *defaults*, it's more likely that people will use them and will identify build problems if they exist. i think it's more valuable to push the toolchain along, just so if there are issues hiding in the newer versions, they're identified as quickly as possible. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
