Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
I would really like people to clearly mark when they are using pfifo_fast, codel, and fq_codel. Secondly, I note that for utterly best results it is useful to ALSO have htb on on ingress to a value only slightly lower than the rate under test, and fq_codel attached to the bin(s) (an example of this is in the deBloat repo on github - both ingress.sh and simple_qos.sh) It would be nice if doing ingress was as simple as egress, maybe using some sort of tbf + fq_codel Otherwise for some benchmarks... at 100Mbit, you will see TCP_STREAM behavior holding the line at ~5ms, and TCP_MAERTS being in excess of 30ms, especially when pfifo_fast is on the other side. Or vice versa, depending on where you are running the test. On Tue, May 22, 2012 at 2:22 AM, Rick Jones wrote: > On 05/21/2012 04:30 PM, Rick Jones wrote: >> >> I think my original ones had the unfortunate effect of putting lines on >> top of one another. Your's seem to put them pretty far apart (at least >> sometimes). We aught to be able to find some reasonable medium in there >> somewhere. I'm thinking if latency is the metric of greatest interest, >> we want that to have the full y axis, and then the peak bandwidth of the >> STREAM test be about half-way up? > > > I've tweaked the bloat.sh script in a couple ways. First, I changed how I > compute the scaling factor, to implement what I described above. Second, I > am using a negative value for the demo interval for the TCP_RR test. This > causes netperf to check if it is time to emit a result after each > transaction rather than after what it thought would be the number of > transactions in the interval. In that way the latency line is much more > robust in the face of a sudden bloating of the path. The effect on > transactions per second should be similar to that of enabling histograms. > An example of a test across my 100 Mbit/s link to a laptop is attached. > > happy benchmarking, > > rick jones > > ___ > Codel mailing list > co...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
In looking over your test scripts and results, it seems possible you have gso on. ethtool -K the_device tso off ethtool -K the_device gso off ethtool -K the_device ufo off Secondly, in the 100Mbit and below case, I have found BQL's estimates to be persistently on the high side, and have generally found that a byte queue limit of 3000 or 4500 produces optimal, consistent results. Usually 1500 causes starvation. YMMV. On Mon, May 21, 2012 at 10:49 PM, Tobias Diedrich wrote: > Rick Jones wrote: >> On 05/20/2012 08:48 PM, Dave Taht wrote: >> >Thx for the numbers! >> > >> >Could you do a TCP_RR while under load from UDP_STREAM? >> >> If you want to generate pretty pictures while doing so, you can >> probably tweak >> http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh > > How about this: > http://tdiedrich.de/~ranma/bufferbloat-rt3050/ > > -- > Tobias PGP: http://8ef7ddba.uguu.de -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any known issues with Luci logins (r31835)
On Mon, 21 May 2012 23:23:21 +, Jim Henderson wrote: > Recompiling now and will follow-up and let the list know if that took > care of it. That did, once I remembered that since I enabled shadow passwords, I had to actually reset the password. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any known issues with Luci logins (r31835)
On Tue, 22 May 2012 01:14:07 +0200, Matthias Schiffer wrote: > Looks liks the password isn't actually stored in the shadow file, but > only in passwd, while current libs only check against shadow. You have > to enable shadow support in busybox for the passwd command to store the > password to shadow. Current OpenWRT has this as the default, but I had > the same problem at first when I was updating an old config from > backfire. Thanks, that is probably it - I also am updating an old config from earlier builds, and going through the busybox options (after running the diff script - something I need to remember to do when weirdness happens), I saw that it was disabled. Recompiling now and will follow-up and let the list know if that took care of it. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any known issues with Luci logins (r31835)
Hi,
On 05/22/2012 12:52 AM, Jim Henderson wrote:
> For the past few days, I've been updating to the latest SVN code, and I'm
> seeing that when I try to login to luci, I get a failed username/password.
>
> I can ssh to the router (pubkey authentication), but changing the root
> password doesn't affect my ability to login to the web interface.
>
> I have strace installed on the router and have pulled logs of a version
> earlier this week - here's what strace showed on the relevant thread
> (password obscured):
>
> --- snip ---
>
> 9612 read(0, "username=root&password=MYPASSWORD"..., 33) = 33
> 9612 open("/etc/shadow", O_RDONLY) = 12
> 9612 ioctl(12, TIOCNXCL, 0x7fd02608) = -1 ENOTTY (Inappropriate ioctl
> for device)
> 9612 read(12, "root:x:0:0:9:7:::\ndaemon:*:0"..., 4096) = 116
Looks liks the password isn't actually stored in the shadow file, but
only in passwd, while current libs only check against shadow. You have
to enable shadow support in busybox for the passwd command to store the
password to shadow. Current OpenWRT has this as the default, but I had
the same problem at first when I was updating an old config from backfire.
Maybe the option not to enable shadow support should be removed
altogether, as it is useless when the other software doesn't support it?
Regards,
Matthias
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] swconfig
Wouter van Gulik wrote:
> On 05/20/2012 12:00 PM, openwrt-devel-requ...@lists.openwrt.org wrote:
> >Message: 3
> >Date: Sat, 19 May 2012 22:28:57 +0200
> >From: Tobias Diedrich
> >To: openwrt-devel@lists.openwrt.org
> >Subject: [OpenWrt-Devel] [PATCH] swconfig: List available switches
> >Message-ID:<20120519202857.gj22...@yumi.tdiedrich.de>
> >Content-Type: text/plain; charset=us-ascii
> >
> >List available switches.
> >
> >As part of the usage message or when the switch name was mistyped,
> >show the user a summary of switch devices available in the system.
> >
> >Signed-off-by: Tobias Diedrich
> >
> >
> >Index: package/swconfig/src/cli.c
> >===
> >--- package/swconfig/src/cli.c (revision 31813)
> >+++ package/swconfig/src/cli.c (working copy)
> >@@ -72,9 +72,15 @@
> > }
> >
> > static void
> >+print_dev_summary(struct switch_dev *dev)
> >+{
> >+printf("%s: %s(%s), ports: %d (cpu @ %d), vlans: %d\n", dev->dev_name,
> >dev->alias, dev->name, dev->ports, dev->cpu_port, dev->vlans);
> >+}
> >+
> >+static void
> > list_attributes(struct switch_dev *dev)
> > {
> >-printf("%s: %s(%s), ports: %d (cpu @ %d), vlans: %d\n", dev->dev_name,
> >dev->alias, dev->name, dev->ports, dev->cpu_port, dev->vlans);
> >+print_dev_summary(dev);
> > printf(" --switch\n");
> > print_attrs(dev->ops);
> > printf(" --vlan\n");
> >@@ -84,6 +90,21 @@
> > }
> >
> > static void
> >+list_switches(void)
> >+{
> >+struct switch_dev *dev;
> >+dev = swlib_connect(NULL);
> >+if (!dev)
> >+printf("No switches found\n");
> >+while (dev) {
> >+struct switch_dev *next = dev->next;
> >+print_dev_summary(dev);
> >+swlib_free(dev);
> >+dev = dev->next;
> >+}
> This look like a bad idea, free-ing and then getting next... :)
Yeah, that's a typo and should have been "dev = next;".
It worked fine anyway (since it's not multithreaded and only frees
small bits of memory and immediately uses the pointer when the
memory is not overwritten yet), which is why I didn't catch it.
--
Tobias PGP: http://8ef7ddba.uguu.de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
Rick Jones wrote: > On 05/21/2012 02:49 PM, Tobias Diedrich wrote: > >Rick Jones wrote: > >>On 05/20/2012 08:48 PM, Dave Taht wrote: > >>>Thx for the numbers! > >>> > >>>Could you do a TCP_RR while under load from UDP_STREAM? > >> > >>If you want to generate pretty pictures while doing so, you can > >>probably tweak > >>http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh > > > >How about this: > >http://tdiedrich.de/~ranma/bufferbloat-rt3050/ > > They look pretty I suppose, but it also looks like I've got the > vrules botched somehow. Though I cannot find the bug just yet in > the repository copy. The red vertical line should be at the start > of the UDP_STREAM test's results, and there should be a black one > right after. They shouldn't be at the ends of the _RR test. Did > you tweak that bit when you converted to a UDP_STREAM test? Ah, yes, I botched the vrules. > The other thing is it appears the scaling to make rrdtool look like > it supports dual y-axes could use a bit of tweaking. I was pretty > much guessing there :( Well, I tweaked the scaling myself since I wasn't happy with the original result either. :) I reuploaded new images with correct vrules and your scaling. Anything above 100Mbit can be assumed to be dropped here (although only the bridge seems to drop, the gige mac gets backpressure from the switch I think and just delays transmitting the next packet I suppose). I can do a TCP_STREAM test, but since the SoC lacks sufficient oomph to saturate a 100Mbit link the results are going to be boring I expect. I get about 3MiB/s, regardless of TCP_STREAM or TCP_SENDFILE. Maybe TCP_SENDFILE would be a bit faster if the driver implemented checksum offload. -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Any known issues with Luci logins (r31835)
For the past few days, I've been updating to the latest SVN code, and I'm
seeing that when I try to login to luci, I get a failed username/password.
I can ssh to the router (pubkey authentication), but changing the root
password doesn't affect my ability to login to the web interface.
I have strace installed on the router and have pulled logs of a version
earlier this week - here's what strace showed on the relevant thread
(password obscured):
--- snip ---
9612 read(0, "username=root&password=MYPASSWORD"..., 33) = 33
9612 open("/etc/shadow", O_RDONLY) = 12
9612 ioctl(12, TIOCNXCL, 0x7fd02608) = -1 ENOTTY (Inappropriate ioctl
for device)
9612 read(12, "root:x:0:0:9:7:::\ndaemon:*:0"..., 4096) = 116
9612 close(12) = 0
9612 getuid() = 0
9612 getgid() = 0
9612 open("/usr/lib/lua/luci/view/sysauth.htm", O_RDONLY) = 12
9612 read(12, "<%#\nLuCI - Lua Configuration Int"..., 1024) = 1024
9612 read(12, "na", 2) = 2
9612 read(12, "me=\"username\" value=\"<%=duser%>\""..., 412) = 412
9612 read(12, "\" v", 3) = 3
9612 read(12, "alue=\"<%:", 9) = 9
9612 read(12, "res", 3)= 3
9612 read(12, "et%>\" class=\"cbi-button cbi-bu", 30) = 30
9612 read(12, "tton-reset\" />\n\t\n\n<", 32) = 32
9612 read(12, "%+footer%>\n", 52) = 11
9612 read(12, "", 106) = 0
9612 close(12) = 0
9612 getuid() = 0
9612 getgid() = 0
9612 open("/usr/lib/lua/luci/view/header.htm", O_RDONLY) = 12
9612 read(12, "<%#\nLuCI - Lua Configuration Int"..., 1024) = 581
9612 read(12, "", 445) = 0
9612 close(12) = 0
9612 brk(0xc8e000) = 0xc8e000
9612 sysinfo({uptime=9003, loads=[192, 960, 2976] totalram=63471616,
freeram=24322048, sharedram=0, bufferram=3465216} totalswap=0,
freeswap=0, procs=56}) = 0
9612 uname({sysname="Linux", nodename="fruitbat", release="3.3.6",
version="#1 Sat May 19 13:48:15 MDT 2012", machine="mips"}) = 0
9612 brk(0xc92000) = 0xc92000
9612 stat64(0xc3da18, 0x7fd023f8) = 0
9612 open("/usr/lib/lua/luci/i18n/sysauth.en.lmo", O_RDONLY) = 12
9612 lseek(12, -4, SEEK_END) = 164
9612 read(12, "\0\0\0t", 4)= 4
9612 lseek(12, 116, SEEK_SET) = 116
9612 read(12, "[W\32\346", 4) = 4
9612 read(12, "g\254\22\322", 4) = 4
9612 read(12, "\0\0\0@", 4)= 4
9612 read(12, "\0\0\0003", 4) = 4
9612 read(12, "\212\342\265I", 4) = 4
9612 read(12, "s\1\365\217", 4)= 4
9612 read(12, "\0\0\0\30", 4) = 4
9612 read(12, "\0\0\0(", 4)= 4
9612 read(12, "]0\243\23", 4) = 4
9612 read(12, "=\311T[", 4)= 4
9612 read(12, "\0\0\0\0", 4) = 4
9612 read(12, "\0\0\0\26", 4) = 4
9612 lseek(12, 0, SEEK_SET)= 0
9612 old_mmap(NULL, 116, PROT_READ, MAP_PRIVATE, 12, 0) = 0x77006000
9612 getuid() = 0
9612 getgid() = 0
9612 open("/usr/lib/lua/luci/view/footer.htm", O_RDONLY) = 13
9612 read(13, "<%#\nLuCI - Lua Configuration Int"..., 1024) = 462
9612 read(13, "", 564) = 0
9612 close(13) = 0
9612 getuid() = 0
9612 getgid() = 0
9612 open("/usr/lib/lua/luci/view/themes/openwrt.org/footer.htm",
O_RDONLY) = 13
9612 read(13, "<%#\nLuCI - Lua Configuration Int"..., 1024) = 592
9612 read(13, "", 434) = 0
9612 close(13) = 0
9612 brk(0xc93000) = 0xc93000
9612 write(1, "Status: 200 OK\r\nVary: Accept\r\nCo"..., 2924) = 2924
--- snip ---
PID 9612 is the forked thread that seems to be handling the
authentication. I attached strace to the running uhttpd thread to get
this info.
I can see that it's opening the shadow file, but can't see where it's
actually validating the password.
The PPID has a similar line that includes the user ID (root) and password
string, but it seems that this forked thread pops up almost immediately
afterwards.
opkg shows a number of luci-related updates available along the lines of:
luci - 0.9+svn8682-1 - trunk+svn8682-1
And if I upgrade to trunk+svn8682-1 (which I have to force because luci-
admin-full has some conflicting files), then I can login, but most of the
administration option pages have various and sundry errors on them that
prevent it from being used for administration - I can watch live traffic
and historical data, but I wasn't able to perform administration on
anything that I tried (LAN/WAN interfaces primarily).
Where do I go from here - or is there other info that would be more
useful to track this down?
--
Jim Henderson
Please keep on-topic replies on the list so everyone benefits
_
Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)
Rick Jones wrote: > On 05/20/2012 08:48 PM, Dave Taht wrote: > >Thx for the numbers! > > > >Could you do a TCP_RR while under load from UDP_STREAM? > > If you want to generate pretty pictures while doing so, you can > probably tweak > http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh How about this: http://tdiedrich.de/~ranma/bufferbloat-rt3050/ -- Tobias PGP: http://8ef7ddba.uguu.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- xDSL interface problems
On 21/05/2012 18:16, John Crispin wrote: On 21/05/12 17:48, Spyridon Tompros wrote: Hi all, currently we test our last left-for-testing xDSL interface. The Danube tries to synchronise but without result. Might be a SW problem of the OpenWRT trunk version we use. Our HW is totally identical to that of Lantiq's RDK. We've also used the add-on front-end of Lantiq's RDK in the place of ours with the same results. So you mean that you plug a cable into the AFE and you get no link resulting in no showtime ? Did you try the same image on a easy50712 ? Exactly (periodically reports "leaving showtime"). We've checked it on an easy RDK. It works but marginally. (Takes too much time to get connected) while Danube gets very hot. PS to Crispin: The SD card inteface is integrated (the command interface works, data transfer has some problems), in a few days we will send you an update to upload in the list. awesome ... i had it on my list for later this week, this wil safe me a lot of work :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- xDSL interface problems
On 21/05/2012 18:14, Conor O'Gorman wrote: On Mon, 2012-05-21 at 17:48 +0200, Spyridon Tompros wrote: Hi all, currently we test our last left-for-testing xDSL interface. The Danube tries to synchronise but without result. Might be a SW problem of the OpenWRT trunk version we use. Our HW is totally identical to that of Lantiq's RDK. We've also used the add-on front-end of Lantiq's RDK in the place of ours with the same results. Annex A or B? A ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update tinc init script with new variable names
I applied your patch https://dev.openwrt.org/changeset/31837 Saverio 2012/5/17 Moritz Warning : > On 05/17/2012 09:56 AM, ZioPRoTo (Saverio Proto) wrote: >> Hello, >> >> please can you resend to me the patch as attachment ? my email client >> mangled the patch. >> >> I will review it today. thanks >> >> Saverio >> >> >> 2012/5/17 Moritz Warning : >>> The tinc init script needs to know all valid options used in /etc/conf/tinc. >>> This patch updates that list to tinc 0.18 (current version). >>> >>> Signed-off-by: Moritz Warning >>> >>> --- > [..] > > See attachment. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- xDSL interface problems
On 21/05/12 17:48, Spyridon Tompros wrote: > Hi all, > > currently we test our last left-for-testing xDSL interface. The Danube > tries to synchronise but without result. Might be a SW problem of the > OpenWRT trunk version we use. Our HW is totally identical to that of > Lantiq's RDK. We've also used the add-on front-end of Lantiq's RDK in > the place of ours with the same results. So you mean that you plug a cable into the AFE and you get no link resulting in no showtime ? Did you try the same image on a easy50712 ? > > PS to Crispin: The SD card inteface is integrated (the command interface > works, data transfer has some problems), in a few days we will send you > an update to upload in the list. awesome ... i had it on my list for later this week, this wil safe me a lot of work :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LANTIQ- EASY5072- xDSL interface problems
On Mon, 2012-05-21 at 17:48 +0200, Spyridon Tompros wrote: > Hi all, > > currently we test our last left-for-testing xDSL interface. The Danube > tries to synchronise but without result. Might be a SW problem of the > OpenWRT trunk version we use. Our HW is totally identical to that of > Lantiq's RDK. We've also used the add-on front-end of Lantiq's RDK in > the place of ours with the same results. Annex A or B? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Job opportunity in Italy] Sr/Jr Embedded Linux Engineer Positions Available
Hi, we already posted some job announcements in this mailing list (and in the forum) some time ago and we received some interesting replies. We are further expanding our staff and we have new job opportunities. Following you can find the request (in Italian because the request is related to a job opportunity in Italy). Wi-Next Srl Per il potenziamento dei nostri laboratori di Ricerca e Sviluppo, ricerchiamo le seguenti figure professionali : Profilo Junior Programmatore in ambiente Linux Embedded Competenze: conoscenza approfondita dello stack TCP/IP, 802.11. Conoscenza GNU toolchain. Linguaggi: Linguaggi di scripting linux (bash/sed/awk/), linguaggio C Opzionali: Busybox, Buildroot, OpenWRT, C++, Perl, Python, HTML, Javascript. Fondamenti di Telecomunicazioni (Teoria dei Segnali, Comunicazioni Elettriche, Antenne). Fondamenti di Elettronica. Partecipazione a comunità di sviluppo/progetti Open Source/Free Software. Esperienza: 1-3 anni. Profilo Senior System Analyst in ambiente Linux Embedded nel settore delle telecomunicazioni. Competenze: capacità di analisi, design, e realizzazione di soluzioni firmware/software su TCP/IP e 802.11, capacità di gestire task di sviluppo in autonomia o allinterno di piccoli team. Problem solving. Conoscenza delle tematiche connesse alla Teoria dei Segnali, Comunicazioni Elettriche ed Antenne. Conoscenza di base dellElettronica. Conoscenza delle tematiche connesse allutilizzo di Licenze per il Software Libero. Linguaggi: approfondita conoscenza dei linguaggi di scripting linux (bash/sed/awk/), linguaggio C, OpenWRT, C++, Perl, Python, Javascript. Partecipazione a comunità di sviluppo/progetti Open Source/Free Software. Esperienza: 3+ anni. Per entrambe le posizioni si prevede assunzione con contratto a tempo indeterminato Sede di Lavoro : Rivoli (TO) Per sottoporre la propria candidatura inviare email con curriculum a : info at winext.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LANTIQ- EASY5072- xDSL interface problems
Hi all, currently we test our last left-for-testing xDSL interface. The Danube tries to synchronise but without result. Might be a SW problem of the OpenWRT trunk version we use. Our HW is totally identical to that of Lantiq's RDK. We've also used the add-on front-end of Lantiq's RDK in the place of ours with the same results. PS to Crispin: The SD card inteface is integrated (the command interface works, data transfer has some problems), in a few days we will send you an update to upload in the list. -- Best Regards, Spyridon Tompros Dr. Ing. Spyridon Tompros 36 GE Lebon, 1160 Brussels tel:+322.5133076 www.qualtek.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revisited: [PROPOSAL] growing OpenWrt devel team
On Mon, May 21, 2012 at 9:19 AM, John Crispin wrote: > On 21/05/12 15:16, Outback Dingo wrote: >> On Mon, May 21, 2012 at 8:52 AM, John Crispin wrote: >>> On 21/05/12 14:41, Outback Dingo wrote: On Sat, May 19, 2012 at 4:20 PM, Philip Prindeville wrote: > We talked about how this could be improved... we're more than a year down > the road, and I'm not seeing much difference. > > Maybe we need to talk about this more? > > Or try harder? One thing Ive noticed is its quite difficult to know whos done what as far as patches / ports looking at patchwork seems few of us actually have access to take / mark / close any specific patch, once they hit they list. Even Ive tried to in patchwork but i see no place to assign a ticket to myself or take ownership and close it when completed, or let someone know im working on it. >>> >>> >>> if you create an accoutn in patchwork you will be able to edit your own >>> patches... patchwork matches the email addr for this afaik >>> >>> John >> >> I have a patchwork account, Im loggen in right now and i see no way to >> assign or >> delegate patches to myself that have been submitted to the list. like >> i just completed >> http://patchwork.openwrt.org/patch/2162/ >> but dont see any place in the gui to assign it to me, or close it >> even... maybe permissions?? >> > > as i said, those patches sent to the list by you are editable by you. > > It wont be possible for you to close tickets that enter patchwork that > are not sent by you as you do not have developer access I actually do have commit access to packages in trunk/packages and regular packages hence i have been committing patches/packages submitted to the list by others, yet cannot manage them in patchwork. So i guess Its simply permissions in patchwork > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revisited: [PROPOSAL] growing OpenWrt devel team
On 21/05/12 15:16, Outback Dingo wrote: > On Mon, May 21, 2012 at 8:52 AM, John Crispin wrote: >> On 21/05/12 14:41, Outback Dingo wrote: >>> On Sat, May 19, 2012 at 4:20 PM, Philip Prindeville >>> wrote: We talked about how this could be improved... we're more than a year down the road, and I'm not seeing much difference. Maybe we need to talk about this more? Or try harder? >>> >>> One thing Ive noticed is its quite difficult to know whos done what as >>> far as patches / ports looking at patchwork >>> seems few of us actually have access to take / mark / close any >>> specific patch, once they hit they list. Even Ive tried >>> to in patchwork but i see no place to assign a ticket to myself or >>> take ownership and close it when completed, or let >>> someone know im working on it. >>> >> >> >> if you create an accoutn in patchwork you will be able to edit your own >> patches... patchwork matches the email addr for this afaik >> >> John > > I have a patchwork account, Im loggen in right now and i see no way to assign > or > delegate patches to myself that have been submitted to the list. like > i just completed > http://patchwork.openwrt.org/patch/2162/ > but dont see any place in the gui to assign it to me, or close it > even... maybe permissions?? > as i said, those patches sent to the list by you are editable by you. It wont be possible for you to close tickets that enter patchwork that are not sent by you as you do not have developer access ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revisited: [PROPOSAL] growing OpenWrt devel team
On Mon, May 21, 2012 at 8:52 AM, John Crispin wrote: > On 21/05/12 14:41, Outback Dingo wrote: >> On Sat, May 19, 2012 at 4:20 PM, Philip Prindeville >> wrote: >>> We talked about how this could be improved... we're more than a year down >>> the road, and I'm not seeing much difference. >>> >>> Maybe we need to talk about this more? >>> >>> Or try harder? >> >> One thing Ive noticed is its quite difficult to know whos done what as >> far as patches / ports looking at patchwork >> seems few of us actually have access to take / mark / close any >> specific patch, once they hit they list. Even Ive tried >> to in patchwork but i see no place to assign a ticket to myself or >> take ownership and close it when completed, or let >> someone know im working on it. >> > > > if you create an accoutn in patchwork you will be able to edit your own > patches... patchwork matches the email addr for this afaik > > John I have a patchwork account, Im loggen in right now and i see no way to assign or delegate patches to myself that have been submitted to the list. like i just completed http://patchwork.openwrt.org/patch/2162/ but dont see any place in the gui to assign it to me, or close it even... maybe permissions?? > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revisited: [PROPOSAL] growing OpenWrt devel team
On 21/05/12 14:41, Outback Dingo wrote: > On Sat, May 19, 2012 at 4:20 PM, Philip Prindeville > wrote: >> We talked about how this could be improved... we're more than a year down >> the road, and I'm not seeing much difference. >> >> Maybe we need to talk about this more? >> >> Or try harder? > > One thing Ive noticed is its quite difficult to know whos done what as > far as patches / ports looking at patchwork > seems few of us actually have access to take / mark / close any > specific patch, once they hit they list. Even Ive tried > to in patchwork but i see no place to assign a ticket to myself or > take ownership and close it when completed, or let > someone know im working on it. > if you create an accoutn in patchwork you will be able to edit your own patches... patchwork matches the email addr for this afaik John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revisited: [PROPOSAL] growing OpenWrt devel team
On Sat, May 19, 2012 at 4:20 PM, Philip Prindeville wrote: > We talked about how this could be improved... we're more than a year down the > road, and I'm not seeing much difference. > > Maybe we need to talk about this more? > > Or try harder? One thing Ive noticed is its quite difficult to know whos done what as far as patches / ports looking at patchwork seems few of us actually have access to take / mark / close any specific patch, once they hit they list. Even Ive tried to in patchwork but i see no place to assign a ticket to myself or take ownership and close it when completed, or let someone know im working on it. > > > On 3/24/11 2:17 PM, Luka Perkov wrote: >> Dear OpenWrt developers and other openwrt-devel readers, >> >> first I would like to express my gratitude to the current OpenWrt >> developers for all the work they did to keep up and running this project >> on many embedded devices. You must have spent many long hours >> contributing to this project and not for example spending quality time >> with your girlfriends / boyfriends... :) >> >> But I must notice as occasional project participant that this project >> could benefit a lot more than it does now from people like myself. I say >> this mainly because of the large number of non replied patches posted on >> this list. That's why I have chosen this subject. >> >> Maybe there is a reason I am not aware of why OpenWrt is relatively >> closed community, but I think that involving some fresh blood in this >> project could help. At least with answering to the rejected patches. >> >> Surely, current OpenWrt developers would "lose" some time to help the >> new guys starting up, but in the long run it would be time well spent. >> >> Best of luck to the OpenWrt project, >> Luka Perkov > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] [PATCH] daemonlogger package Makefile (second attempt)
On Sat, May 19, 2012 at 7:46 PM, Robert Vineyard wrote: > On 5/19/2012 7:43 PM, Outback Dingo wrote: >> >> Just reinstalled my development environment, once i get the WRT sources >> pulled down ill get on this and test it, if its good ill commit it for >> you. sometime later this evening most likely. > > > Excellent, most appreciated! > > Thanks, > Robert Vineyard Committed in r31836 /packages/net/daemonlogger/ (. Makefile): [patchteam] - Daemonlogger is a packet logger and soft tap ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
