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

[Daniel Dickinson]

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 effort to process them.

Maybe in an ideal world where there was legion of willing volunteer
triagers who could turn even the most useless bug report (or notice a
pattern from a large number of same) into something meaningful, this
isn't an ideal world, and there are bug reports that drain resources
more than any minute value they might provide warrants.

Actually in ideal world we would a) have bugs b) in a slightly less
ideal world we'd at least always get greatly helpful bug reports.  But I
digress.

I'm interested in a solution that works, both for dealing with the valid
developer points, without what I feel is the 'more harm than good' than
I feel the originally proposed solution would do.

It looks to me like there is some movement to something inbetween, which
I think is good.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Daniel Dickinson]

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 screen that hooked into Mantis API (I
>> assume they have one)) and required such fields are guaranteed to be
>> required, and before submitting to the bug tracker, force the user to at
>> least claim that the information genuinely met the guidelines.  I'd be
>> happy to whip up something like this, that fit what you wanted.
> 
> Don't make it required, it is possible a user cannot actually provide
> the information for whatever reason and otherwise has a perfectly fine
> bug report.

That's what the 'force the use the user to claim' bit is about -
basically the only things that should be in the required things that are
*guaranteed* to be available / applicable (like what device is this
occurring on), and everything should be optional but users should be
required to actually think about whether their bug report is actually
useful to volunteer developers, or is just going to waste time and
resources).

> Make it suggested, and make it easy to provide, and users will likely
> do the right thing most of the time.

I think if you ensure users actually read WHY they're being asked for
what they are, and are reminded of the fact that a useless bug report
hurts rather than helps, then I'd agree they will, but in my experience
without that kind of reminder, there is a significantly detrimental
tendency to be lazy and not do the right thing.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Daniel Dickinson]

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
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Daniel Dickinson]

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 relationship with the third party, so "please contact your vendor".

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Doodle poll alternative

[Alexander Couzens]

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
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpIsdPZEavz0.pgp
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Doodle poll alternative

[dvn]

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
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Ted Hess]

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

-Original Message- 
From: W. Michael Petullo

Sent: Sunday, May 08, 2016 4:59 PM
To: lede-dev@lists.infradead.org
Subject: [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 migrated them to GitHub (e.g., gstreamer1). I just finished an
initial review of the LEDE Git repositories, and it seems a number of
packages are missing. Will we go through a period of manual migration
again? What is in store for all of these packages with respect to LEDE?

Thank you,

--
Mike

:wq

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Lantiq NAND

[Daniel Golle]

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 r41121...

> 
> 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.

Both, ubifs (rw) and squashfs (ro+overlay) should work and are
supported and selection of the root filesystem works automagically:

 - auto-attach UBI MTD device on boot:
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch;h=8494064eb1e9ca0d47bc1a90d76a030f36cc7c7f;hb=HEADhttps://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch;h=8494064eb1e9ca0d47bc1a90d76a030f36cc7c7f;hb=HEAD

 - create ubiblock for squashfs and set ROOT_DEV:
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch;h=da3111266a60e80cc01c0099a597e7299ba216fe;hb=HEAD
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch;h=f55e8e3a4d12f3883de8f6805051ba7a97f688d6;hb=HEAD

 - try mounting ubifs rootfs on boot:
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch;h=d21e6d21cefa11a966f8a249283162529d4cd7c9;hb=HEAD

Well, NAND support on oxnas works pretty much the same as on lantiq.
Unfortunately, the image generation code has still not been
completely migrated to the new framework, especially on targets
which were somehow using UBI in some way before we added sysupgrade
support. So currently, there is a misconception that UBI and UBIFS are
the same thing and some code existed before introducing
https://git.lede-project.org/?p=source.git;a=blob;f=scripts/ubinize-image.sh;h=b87cbb48dc8cc004d754e3b9c8001beb5f111393;hb=HEAD
and using it here
https://git.lede-project.org/?p=source.git;a=blob;f=include/image.mk;h=9e342e0a42a793d73264d6a7e4fe464fdbe591ce;hb=HEAD#l194

However, somehow generating ubifs images still depends on the old-style
using a static ubinize.cfg instead of ubinize-image.sh, so changing
that is all needed to also get ubifs-rootfs images to be built for
those targets which never used a static ubinize.cfg.

> Do the devices with NAND flash all use UBI by default in the vendor
> firmware or how is that initialized?

No. Some use jffs2-nand, some use yaffs, some use UBI in some way
or another. Some store the kernel (which may or may not include the
read-only rootfs) directly on NAND, supposedly due to the lack of UBI
support in their bootloader. Others even use a jffs2-nand filesystem
to store their kernel and initramfs. Again others are using a
seperate ubi partition with only a single ubifs filesystem which
is used like the /boot partition on desktop systems...
As NAND devices usually offer more space than needed, a whole jungle
of built-in rescue-systems, dual-boot solutions and such has grown
which makes things yet a bit harder to deal with.

In the worst-cases, the only way is to first flash an image with
initegrated initramfs in the vendors format and then use that to
flash the final system using ubiformat and in some cases also make
changes to the bootloader environment. As there usually is enough
space, I like keeping that 'rescue' kernel+initramfs system on
the flash and change the bootloader so it would fall-back on that
in case *loading* the kernel from UBI fails, see:
https://git.lede-project.org/?p=source.git;a=blob;f=package/boot/uboot-oxnas/files/include/configs/ox820.h;h=85ee3b4cd511d74bc50bb4abf22412a8f06b1a6b;hb=HEAD#l228

Some people reported successfully flashing an ubinized image via
nandwrite, I'm not sure whether this is as reliable as using
ubiformat.

> 
> Is it needed to run padjffs2 on the squasfs root file system of the NAND

No.


Cheers


Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Lantiq NAND

[Hauke Mehrtens]

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 in the vendor
firmware or how is that initialized?

Is it needed to run padjffs2 on the squasfs root file system of the NAND
sysupgrade image?

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nemesis]

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, many of the packages were deprecated until the maintainter
> manually migrated them to GitHub (e.g., gstreamer1). I just finished an
> initial review of the LEDE Git repositories, and it seems a number of
> packages are missing. Will we go through a period of manual migration
> again? What is in store for all of these packages with respect to LEDE?
> 
> Thank you,

As far as I understood, we are going to continue using the current
package repo on the openwrt github org [1].

Nemesis

[1]: https://github.com/openwrt/packages


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Status of OpenWrt feeds in LEDE

[W. Michael Petullo]

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 migrated them to GitHub (e.g., gstreamer1). I just finished an
initial review of the LEDE Git repositories, and it seems a number of
packages are missing. Will we go through a period of manual migration
again? What is in store for all of these packages with respect to LEDE?

Thank you,

-- 
Mike

:wq

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Kus]

-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
KPN9bPsKY7cF3Ts9e4s9Q+F50UUHVGfZFXHLUSMQnnrVLMkgm2SoE7abH04urIXZ
g02frcmY1hJgOvmYebltYmQgJN4S4vqa+S/+FHQc6zt2wYbQpbXbQEwIQ5H8hzfj
SPirCELtK9/NSoClVyG2Z29UMy/EwoQIvi4A7wOgEwglwBVTjGV9IfrXUJXUE7tA
fUqA02gJI0A+aSNpEPMKDcIJlcit7TyEqMMb3W/1lbSccg8UPOzihrCpXKF98mi6
IFDacAv7QJrYtjitXeOn6b2zqu2x57DZ0lme4zrLORTJi2dITVFb0hBDHrWhX4/V
wAVfnA7at+ZIFznfEZodcupFTibYAh6JEVleOrbn3AcUmF7Lx5nSo4GZJoDl7dhz
75xIQrj8GITRz4he8hrL6q/4sJVv4vlzWOOUSGVnxkiw15sW70CadB1FiyeD2AdO
uh04VnCIRzGPjhlI6Pskh5HVRT7C1gX5lWZG8yrdBvRXdKqHNz6hRFrm1m9e1fqt
MIg8qPnkiPutTAZZy7F5y9XeONM056MoJ0Cz+0kNZYRbZuESXpmPm0YG2LvcXWo1
rf5k1WIXf9NJVSqx90q8jgdQvfVLU9kwHFpIjevpR2ipdDXvD0Cs7gy8ue7am4Ll
YvZp3C6a4PbCpA0XBmYyBpBAcWo=
=SRoh
-END PGP SIGNATURE-


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Russell Senior]

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 in gcc.  The command line looks like this:

  make -j1 BUILD_LOG=1 IGNORE_ERRORS=m V=s

The tail of logs/toolchain/gcc/final/compile.txt looks like this:

g++ -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   
-DHAVE_CONFIG_H -I. -Icp 
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc
 
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp
 
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/../include
 
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/../libcpp/include
 -I/home/openwrt/src/lede/staging_dir/host/include 
-I/home/openwrt/src/lede/staging_dir/host/include 
-I/home/openwrt/src/lede/staging_dir/host/include  
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/../libdecnumber
 -I/home/op
 
enwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/../libdecnumber/dpd
 -I../libdecnumber 
-I/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/../libbacktrace
   -o cp/except.o -MT cp/except.o -MMD -MP -MF cp/.deps/except.TPo 
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp/except.c
In file included from ./tm.h:26:0,
 from 
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp/except.c:27:
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/config/elfos.h:102:21:
 warning: invalid suffix on literal; C++11 requires a space between literal and 
string macro [-Wliteral-suffix]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
 ^
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/config/elfos.h:170:24:
 warning: invalid suffix on literal; C++11 requires a space between literal and 
string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from ./tm.h:32:0,
 from 
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp/except.c:27:
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/config/mips/mips.h:2913:20:
 warning: invalid suffix on literal; C++11 requires a space between literal and 
string macro [-Wliteral-suffix]
   fprintf (STREAM, "\t.space\t"HOST_WIDE_INT_PRINT_UNSIGNED"\n", (SIZE))
^
In file included from ./tm.h:47:0,
 from 
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp/except.c:27:
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/defaults.h:126:24:
 warning: invalid suffix on literal; C++11 requires a space between literal and 
string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from 
/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0/gcc/cp/except.c:1023:0:
cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)':
cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' 
redeclared inline with 'gnu_inline' attribute
cfns.gperf:26:14: note: 'const char* libc_name_p(const char*, unsigned int)' 
previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function 'const char* libc_name_p(const 
char*, unsigned int)' used but never defined
Makefile:1065: recipe for target 'cp/except.o' failed
make[6]: *** [cp/except.o] Error 1
make[6]: Leaving directory 
'/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0-final/gcc'
Makefile:4118: recipe for target 'all-gcc' failed
make[5]: *** [all-gcc] Error 2
make[5]: Leaving directory 
'/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0-final'
Makefile:873: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[4]: Leaving directory 
'/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0-final'
Makefile:77: recipe for target 
'/home/openwrt/src/lede/build_dir/toolchain-mips_mips32_gcc-5.3.0_musl-1.1.14/gcc-5.3.0-final/.built'
 failed
make[3]: 

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

[Bert Vermeulen]

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 problem leaving things like
> that.  It means carrying a small patch.  Seems like not that big a
> problem.

Carrying patches is of course a problem: as I showed with numbers, a
problem that won't solve itself and will get worse over time.

Upstreaming your patch must clearly be the first choice. Did you even
try to upstream an ncurses preference in iftop? It's been in the OpenWrt
repo for 3.5 YEARS!


-- 
Bert Vermeulen
b...@biot.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev