Re: [LEDE-DEV] On the proposed Mantis and maximizing bug usefulness

Fundamentally I disagree with you unspoken premise that 'there is no such thing as a useless bug report'. I agree with the *reason* the developers proposed the bug reporting mechanism they dig, just not with mechanism itself, which is that there *are* bug reports that are not worth the time and

Re: [LEDE-DEV] On the proposed Mantis and maximizing bug usefulness

On 16-05-08 09:24 PM, Ben Greear wrote: > >> 1) I like the suggestion of one the of list members made of having >> something on the device that you clicked on and it prefilled as much as >> possible of the relevant information (like arch, model, etc) into the >> bug report (for example a luci

[LEDE-DEV] I really like the new output (bin) layout!

Hi, I just want to say kudos for the new output (bin) dir layout. Separating things that are target-specific from things can be shared among targets of the same arch is *awesome*! Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org

Re: [LEDE-DEV] On the proposed Mantis and maximizing bug usefulness

One more note: if using prefilled forms (e.g. from openwrt_release) and the triagers notice that the report is from a third party source (e.g. a manufacturer who hasn't bothered to modified the URLs, etc), I'd suggest a boilerplate response that indicates what LEDE is and the fact it has no

Re: [LEDE-DEV] Doodle poll alternative

On Mon, 9 May 2016 01:00:55 +0100 dvn wrote: > source: https://github.com/kellerben/dudle > > homepage/demo: https://dudle.inf.tu-dresden.de/ hi dvn, thanks for the hint. I'll suggest we move to it on the next meeting. Best, lynxis -- Alexander Couzens mail: lyn...@fe80.eu

[LEDE-DEV] Doodle poll alternative

Thought the group might be interested in hosting an instance of this open-source doodle alternative: source: https://github.com/kellerben/dudle homepage/demo: https://dudle.inf.tu-dresden.de/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org

Re: [LEDE-DEV] Status of OpenWrt feeds in LEDE

Mike - The packages in the LEDE source repo are just the base-system packages as they were in the OpenWRT repo. The Github packages (openwrt/packages) will continue as they are and will be used by both distros. Hopefully, the packages will continue to be build in both environments. /ted

Re: [LEDE-DEV] Lantiq NAND

Hi Hauke, On Sun, May 08, 2016 at 11:22:13PM +0200, Hauke Mehrtens wrote: > Hi John, > > How does the Lantiq NAND sysupgrade stuff work? I don't have much insight on Lantiq specifically, but I can tell you a bit about how John and I have integrated UBI support starting from OpenWrt SVN

[LEDE-DEV] Lantiq NAND

Hi John, How does the Lantiq NAND sysupgrade stuff work? I see there are sysupgrade packages with a squasfs and a ubifs root file system. Are both file systems still supported and needed? I see that other targets only have a squasfs support. Do the devices with NAND flash all use UBI by default

Re: [LEDE-DEV] Status of OpenWrt feeds in LEDE

Hi Michael On 05/08/2016 10:59 PM, W. Michael Petullo wrote: > I am the maintainer of a number of OpenWrt packages, and I am watching > with interest the emargence of the LEDE project. Some time ago, OpenWrt > migrated to GitHub for some of its feeds, including the packages feed. At > that time,

[LEDE-DEV] Status of OpenWrt feeds in LEDE

I am the maintainer of a number of OpenWrt packages, and I am watching with interest the emargence of the LEDE project. Some time ago, OpenWrt migrated to GitHub for some of its feeds, including the packages feed. At that time, many of the packages were deprecated until the maintainter manually

Re: [LEDE-DEV] LEDE mirror from RCS Romania

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Git mirror also at https://gitlab.com/lede -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJRBAEBCgA7BQJXL4aCNBxLdXNoYWwgSGFkYSAoZGV2ZWxvcGVyKSA8a3VzaGFs ZGV2ZWxvcGVyQGdtYWlsLmNvbT4ACgkQJsInd2b1xmNfKg/+LlyVX5D1Xo38/Xbt

[LEDE-DEV] BUG: gcc build failure of lede-project HEAD for ath25

Building lede-project HEAD, i.e.: $ git describe reboot-98-g5b64e35 The interesting bits of diffconfig is: CONFIG_TARGET_ath25=y CONFIG_TARGET_ath25_Default=y CONFIG_TARGET_BOARD="ath25" CONFIG_DEVEL=y CONFIG_BUSYBOX_CUSTOM=y CONFIG_BUILD_LOG=y I get a build failure

Re: [LEDE-DEV] [PATCH] iftop: Update to latest version, and drop patch

On 05/07/2016 08:11 PM, Russell Senior wrote: > In this particular case, as the author of the patch involved, I would > suggest "if it isn't broken, don't fix it". That is, iftop doesn't > really need ncursesw, the patch lets it use plain ncurses even if > ncursesw is available. I don't see the