**** BEGIN LOGGING AT Sun Apr 03 02:59:58 2011 Apr 03 03:01:39 nbd: you still around? Apr 03 03:11:03 yes Apr 03 03:11:15 got_milk: not for much longer though ;) Apr 03 03:11:24 haha Apr 03 03:11:29 just a quick question Apr 03 03:11:39 I'm setting up a new environment for a new PC I built Apr 03 03:11:57 should I continue to enable mac80211 debugging, and if so, what's the name of it? Apr 03 03:12:43 i don't think you need to keep it enabled Apr 03 03:12:53 since we already identified where the latency spikes are coming from Apr 03 03:13:07 ok Apr 03 03:13:16 I'll put this Core i7 to the test then ;) Apr 03 03:13:20 :) Apr 03 03:13:35 must be far faster than the old core 2 duo I was using Apr 03 03:14:49 Hello, is everything okay with tools/squashfs4 in the latest trunk? Apr 03 03:15:00 suddenly, erros Apr 03 03:15:02 errors Apr 03 03:15:12 I just happened to do a svn up and now it is borked somewhere in there Apr 03 03:15:16 kaomie: details? Apr 03 03:15:30 dunno it seems confused when linking to lzma Apr 03 03:15:39 kaomie: ok. make tools/xz/clean, then make Apr 03 03:15:41 should fix it Apr 03 03:15:47 hmm Apr 03 03:15:49 I have it too Apr 03 03:15:55 hmmm did that but let me try again just to confirm Apr 03 03:16:54 I may just have wiped lzma only Apr 03 03:17:17 fixed it for me Apr 03 03:17:23 weird Apr 03 03:17:34 liblzma was installed both by the lzma package and the xz package Apr 03 03:17:43 the one from xz is the correct one Apr 03 03:17:50 convenient timing though, as soon as you asked my build failed Apr 03 03:17:51 so i changed lzma to no longer export it Apr 03 03:18:00 yeah I was checking your updates with the change to 4.2 and XZ Apr 03 03:18:38 okay it's good now thanks Apr 03 03:18:48 wowowowowow this Core i7 is *fast* Apr 03 03:18:55 same I was messing with something completely different and then BAM Apr 03 03:19:02 was like huho what'd I do Apr 03 03:19:07 ha Apr 03 03:19:09 same here Apr 03 03:20:04 okay, this is crazy. a build that would take me 2.5 hours to do is halfway done in about 4 minutes. Apr 03 03:21:05 another build error -_- Apr 03 03:22:41 ls: cannot access ./patches: No such file or directory Apr 03 03:23:03 util-linux/mount.c:72:22: fatal error: rpc/rpc.h: No such file or directory Apr 03 03:31:52 make oldconfig Apr 03 03:32:00 it's always a good idea to run that after svn up Apr 03 03:35:05 always do and did this time Apr 03 03:36:40 cleaning, running oldconfig again and trying once more Apr 03 03:40:20 same thing Apr 03 03:44:45 nbd * r26434 /trunk/include/debug.mk: build: undefine debug helper templates used by subdir.mk if the DEBUG variable is empty, speeds up "make prereq" by 25% when lots of packages are installed Apr 03 03:44:48 nbd * r26435 /trunk/include/subdir.mk: build: use a conditional @ sign before silenced targets instead of .SILENT - makes prereq checks more than twice as fast Apr 03 03:44:51 nbd * r26436 /trunk/include/subdir.mk: build: reduce the amount of generated make code for the initial prereq scan - makes it about 20% faster Apr 03 03:45:02 got_milk: is CONFIG_BUSYBOX_USE_LIBRPC set? Apr 03 03:45:09 oh, wait Apr 03 03:45:14 what package does this error happen in? Apr 03 03:45:15 busybox? Apr 03 03:45:18 yeah Apr 03 03:45:39 ok, then i need to know if CONFIG_BUSYBOX_USE_LIBRPC is set Apr 03 03:46:02 one second Apr 03 03:46:21 ah Apr 03 03:46:22 never mind Apr 03 03:46:24 i found the bug Apr 03 03:46:58 nbd * r26437 /trunk/package/busybox/Config.in: busybox: add missing kconfig symbol type for BUSYBOX_USE_LIBRPC Apr 03 03:47:00 ^^ Apr 03 03:47:05 haha Apr 03 03:47:05 make oldconfig and make should work now Apr 03 03:47:06 thanks Apr 03 03:47:07 no clean necessary Apr 03 03:47:45 damn, almost 6am again Apr 03 03:47:55 i should get some sleep ;) Apr 03 03:48:05 haha I'll let you :P Apr 03 07:18:18 <_trine> cshore, ping Apr 03 09:34:14 <_trine> trunk doe snot compile http://dpaste.com/528286/ Apr 03 11:36:40 _trine: same as the others earlier: make tools/xz/clean Apr 03 11:37:06 <_trine> nbd, I have download svn again Apr 03 11:37:18 <_trine> it seems to be compiling now Apr 03 11:37:30 <_trine> thanks Apr 03 11:53:29 cshore: ping Apr 03 12:56:31 <_trine> cshore, any ideas?? http://dpaste.com/528324/ Apr 03 13:08:29 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Apr 03 13:24:02 hauke * r26438 /trunk/tools/xz/ (Makefile patches/): xz: update to version 5.0.2 Apr 03 13:24:38 hauke * r26439 /trunk/tools/m4/Makefile: m4: update to version 1.4.16 Apr 03 13:25:25 hauke * r26440 /trunk/target/linux/generic/patches-2.6.38/160-l2tp_fix_oops_backport.patch: kernel: l2tp: fix possible oops on l2tp_eth module unload Apr 03 14:03:52 hauke * r26441 /trunk/target/linux/ (25 files in 22 dirs): Apr 03 14:03:52 kernel: Update to version 2.6.37.6 Apr 03 14:03:52 Thank you Peter Wagner for the patch Apr 03 14:59:22 hauke * r26442 /trunk/include/kernel-version.mk: Apr 03 14:59:22 kernel: add md5sum of kernel Apr 03 14:59:22 This was missing in r26441 Apr 03 15:11:52 got_milk: did your build work? Apr 03 15:31:11 nbd: yeah it did build, thanks Apr 03 16:00:37 <[florian]> KanjiMonster: ping? Apr 03 16:00:54 [florian]: pong Apr 03 16:10:00 got_milk: any test results from the intel stuff yet? Apr 03 16:10:14 i'm hoping to be able to finally close that bug soon Apr 03 16:11:08 yeah, it's a bit better, latency spikes are still occurring but they're not as bad Apr 03 16:11:26 from ~200ms to anywhere between 80-100ms Apr 03 16:13:41 nbd: easy to fix bug in mac80211 - rtl819x seems to depend on kmod-usb-core (or rather usb support enabled in the kernel), else compilation breaks (see #openwrt ;) Apr 03 16:15:52 got_milk: still with severe effects on throughput or faster recovery now? Apr 03 16:18:14 nbd: throughput is still affected but not as badly, and recovery is faster Apr 03 16:19:18 do the latency issues show up a few times every 5 seconds or so? Apr 03 16:19:25 or one spike for a while and then that's it? Apr 03 16:21:35 it's not every 5 seconds, more like every minute or so Apr 03 16:22:00 ok, because what happens is this: Apr 03 16:22:14 the latency spike occurs when the intel client tells the AP to stop the aggregation session Apr 03 16:22:26 without my patch it would then try to establish a new one right away Apr 03 16:22:37 and with my patch it waits for at least 5 seconds Apr 03 16:23:57 ah i see Apr 03 16:43:53 got_milk: so is this issue still problematic or do you think it doesn't matter that much anymore? Apr 03 16:44:13 because I think this might just be a nasty bug in the intel drivers and I'm not sure what to do about it at this point Apr 03 16:49:50 <_trine> cshore, have you woke up yet? Apr 03 17:02:13 _trine: cshore said he's out of town today Apr 03 17:06:15 <_trine> ah ok thanks KanjiMonster I was hoping he could fix freeswitch and yate Apr 03 17:07:15 <_trine> I'll catch when hes about next week Apr 03 17:39:37 nbd * r26443 /trunk/package/mac80211/Makefile: mac80211: rtl818x depends on kmod-usb-core Apr 03 17:39:43 nbd * r26444 /trunk/package/mac80211/patches/542-mac80211_minstrel_ht_aggr_delay.patch: mac80211: increase delay between aggregation session negotiation attempts - improves interop with intel clients Apr 03 17:41:32 nbd * r26445 /branches/backfire/package/mac80211/patches/542-mac80211_minstrel_ht_aggr_delay.patch: mac80211: increase delay between aggregation session negotiation attempts - improves interop with intel clients (backport of r26444) Apr 03 17:47:41 evening Apr 03 18:13:43 nbd: it's not really problematic for me anymore, as the client's been replaced anyway and it's hardly used anymore Apr 03 18:13:52 ok Apr 03 18:15:24 luka * r26446 /packages/net/ethtool/ (Makefile patches/01-ixp4xx_ethtool_autotools.patch): upgrade ethtool Apr 03 18:17:10 luka * r26447 /packages/libs/file/Makefile: upgrade file Apr 03 18:21:39 luka * r26448 /packages/net/ethtool/patches/ (01-ixp4xx_ethtool_autotools.patch 110-ixp4xx.patch): add ethtool patch for ixp4xx Apr 03 18:34:29 florian * r26449 /packages/multimedia/ffmpeg/ (Config.in Makefile): (log message trimmed) Apr 03 18:34:29 [package] ffmpeg: expose additionnal configuration options (#7837, #8831) Apr 03 18:34:29 This series, along with previous applied patches, should close tickets #7837 and #8831. Apr 03 18:34:30 This patch exposes additional decoders and demuxers for FFmpeg in menuconfig, along with other minor changes. Apr 03 18:34:30 Additional decoders: Apr 03 18:34:31 flac (Free Lossless Audio Codec) Apr 03 18:34:31 Additional demuxers: Apr 03 18:34:32 florian * r26450 /packages/multimedia/ (ffmpeg/Config.in minidlna/Makefile): (log message trimmed) Apr 03 18:34:32 [package] minidlna/ffmpeg: add minidlna profile to ffmpeg Apr 03 18:34:33 This adds a profile to ffmpeg to support minidlna, similar to the Apr 03 18:34:33 libdlna/ushare profile. When minidlna encounters media, it uses ffmpeg to Apr 03 18:34:34 figure out what it is. If ffmpeg fails to open it, then minidlna will try Apr 03 18:34:34 and fail to read the file on its own. The profile may need to be extended; Apr 03 18:35:04 I attempted to cover all popular formats for dlna streaming. Apr 03 18:35:26 florian * r26451 /trunk/ (include/netfilter.mk package/kernel/modules/netfilter.mk): Apr 03 18:35:26 [package] add kmod-ipt-led Apr 03 18:35:26 Netfilter LED target triggers blinkenlichten when a network packet hits Apr 03 18:35:26 a rule. Apr 03 18:35:26 LED target requires iptables 1.4.9 or higher Apr 03 18:35:27 Signed-off-by: Ɓukasz Stelmach Apr 03 18:35:31 florian * r26452 /trunk/package/kernel/modules/netdevices.mk: Apr 03 18:35:31 [package] add kmod-hfcpci Apr 03 18:35:31 Changed: Apr 03 18:35:31 - Support added for mISDN card driver for Cologne AG's HFC pci cards (single port) Apr 03 18:35:31 - Title texts and help texts for some other isdn drivers adjusted for clarification Apr 03 18:35:31 Signed-off by: Arnold Schulz Apr 03 18:35:37 florian * r26453 /trunk/target/linux/realview/Makefile: [realview] create an initramfs image by default Apr 03 18:35:41 florian * r26454 /trunk/.gitignore: gitignore: add *.rej and *.orig to .gitignore Apr 03 18:35:49 florian * r26455 /trunk/package/busybox/ (26 files in 19 dirs): [package] update busybox to 1.18.4, patch from Peter Wagner Apr 03 18:44:54 As announced on the -devel mailinglist - there will shortly be a meeting about the current patch process Apr 03 18:47:57 i might be a few minutes late, going to hunt down some food Apr 03 18:52:58 nbd: no prop Apr 03 18:53:06 I am here as well Apr 03 18:54:49 'k Apr 03 18:56:04 a couple of others have written/posted comments to the agenda Apr 03 18:57:58 I'm here to observe that meeting, too. Apr 03 18:58:11 welcome Apr 03 18:58:51 the meeting is scheduled to begin @ 19:00 UTC (which should be in a few minuts) Apr 03 19:03:48 the first topic on the agenda is: The current patch process, and the problems which have been voiced Apr 03 19:04:32 I'll try to keep track of things and afterwards post a summary on -devel Apr 03 19:06:17 hi, so on the list was discussed how patches on the mailing list are not processed Apr 03 19:07:22 depending on the patch it can take a long time from patch submission untill patch goes into the upstream svn Apr 03 19:07:29 yes. I believe that the discussion began with the voicing of frustration about missing feedback Apr 03 19:07:35 yes Apr 03 19:08:08 so, i was thinking to get new developers do the "easy" stuff Apr 03 19:08:24 like package upgrade Apr 03 19:08:52 I has been started in the past that it is fully acceptable to 'repost' or 'remind' that patches are waiting Apr 03 19:08:53 which would leave current deelopers more time for more complex stuff Apr 03 19:09:16 that sometimes does not help also Apr 03 19:09:29 yes. Apr 03 19:10:05 sorry for missing part of the convo, but from the mailing list thread, it seemed that the proposal is essentially to decentralize the maintenance, correct? Apr 03 19:10:29 i think so yes... Apr 03 19:10:33 thepeople: you have been doing a lot for getting new package maintainers - and creating the patch-team Apr 03 19:10:54 thepeople has given me svn access last week Apr 03 19:11:36 what I would like to see is for all the packages to have their own maintainer which would do a lot for the patch jam that we have now Apr 03 19:11:53 that would be great... Apr 03 19:12:19 yeah, well defined ownership would stop us noobs from bugging the wrong people when our patches aren't looked at. Apr 03 19:12:41 did enough apply to cover all the packages? Apr 03 19:12:51 :) Apr 03 19:12:51 not even close Apr 03 19:13:08 I put out a new call from time to time and I always get a couple more Apr 03 19:13:29 this issue is nothing special, it is quite common across projects Apr 03 19:13:37 i think that extensive documentation about making package Makefile would help Apr 03 19:14:13 this is something i would like to do after upgrading all the packages i have applied to maintain Apr 03 19:14:28 that could be one addition - the more general aspect of documentation Apr 03 19:14:42 luka12345|wiik: seems you have just made a promise Apr 03 19:14:48 then somebody of the older devs could look into that docoment make corrections -- so that could be the cookbook for new packages Apr 03 19:14:58 yes Apr 03 19:15:01 that would be great Apr 03 19:15:02 glp: np :) Apr 03 19:15:29 just to keep the documentation topic Apr 03 19:15:29 documentation is something we are particularly bad at doing IMO Apr 03 19:15:45 if you need any help with figuring out aspects of the build system for writing documentation, feel free to bug me directly about specifics Apr 03 19:16:03 so i was thinking when documentation is done maybe somebody could put call for new devels on the openwrt homepage ? Apr 03 19:16:27 nbd: thank you, so far did not have many issues Apr 03 19:16:35 it was mentioned that the patch submission documentation could need to be better Apr 03 19:16:59 i have upgraded several packages, and each time i learn something new :) Apr 03 19:17:41 glp: i dont understand... you mean when sending to -devel list? Apr 03 19:17:50 also the situation that patches can be submitted in both Trac and on mailinglist Apr 03 19:18:19 I mean the general model for how patches are submitted Apr 03 19:18:34 thepeople * r26456 /branches/backfire/package/ (base-files/files/etc/banner opkg/files/opkg.conf): prepare for RC5 Apr 03 19:18:38 i think we should strongly discourage patch submissions to trac Apr 03 19:18:47 the official process is that a patch is submitted on -devel Apr 03 19:18:50 i prefer mailing list also Apr 03 19:18:59 but some patches end up in trac Apr 03 19:19:07 how about creating mailing list only for patches? Apr 03 19:19:14 do we need that? Apr 03 19:19:29 <_trine> one idea might be to find easy packages to maintain and delegate some of those to people with only enough knowledge to keep them updated to the current version Apr 03 19:19:32 sometimes patch submission and general discussions overlap Apr 03 19:19:37 more mailing are not necesarily an answer Apr 03 19:20:19 trac patches are much easier to locate and test than mailing list ones Apr 03 19:20:20 just a suggestion, i thought that then patches would not be forgotten Apr 03 19:20:43 several have mentioned using patchwork Apr 03 19:20:55 anyone know if there is a way that trac will only accept tickets with a valid email? Apr 03 19:20:57 I think it's more a process issue. and time. :-) Apr 03 19:21:13 process and time - yes Apr 03 19:21:35 luka12345|wiik: i fear breaking -devel into -devel and -patch would mean patches would be less likely to be reviewed. Apr 03 19:22:06 It'd mean that patches get scattered into one additional location, most probably. Apr 03 19:22:22 probably Apr 03 19:23:07 ok, but i think that each submitted patch should get a reply Apr 03 19:23:40 what is wrong with submitting patches to trac? It keeps discussions about a patch together and until the ticket is closed one knows it is being submitted/reviewed/forgotten. Seems good enough to me Apr 03 19:23:59 veger: drive-by issues/patches Apr 03 19:24:09 as an ideal. sometimes the reply happens on irc Apr 03 19:24:19 Another issue is that for some patches, there might only be one dev that can give an intelligent reply. Apr 03 19:24:47 veger: applying patches from trac is annoying Apr 03 19:24:47 how about having several well defined "components", and each package or subtree would belong to one or more components, and each component would have one or more "veteran" owners, plus the possibility of a "mentee in training"? Apr 03 19:25:01 trac is slow and it requires lots of clicks to even get the patch in a format that can be applied Apr 03 19:25:08 veger: patchwork can also tell you if a patch is being reviewed and/or forgotten... Apr 03 19:25:31 glp: then the person wh submitted patch on list and got help on irc should post the short summary on the list... dont you think? Apr 03 19:25:35 nbd: patches in trac are anoting because you have to download them to actually view them? Apr 03 19:25:36 i think the main issue with patches getting dropped is not about how many developers we have or what the submission process is Apr 03 19:25:58 using patchwork results in yet another place devs needs to look at Apr 03 19:26:10 veger: wrong, patchwork automatically collects from the list Apr 03 19:26:17 philipp64|laptop: ideally this could be part of the patch team Apr 03 19:26:19 you don't have to use it Apr 03 19:26:40 i think the main issue is that we don't have a properly maintained list of *pending* patches Apr 03 19:26:50 many patches that get submitted are low hanging fruit Apr 03 19:26:50 but to view outstanding patches you need to open patchwork, next to trac and mailinglist Apr 03 19:26:54 easy to review and verify Apr 03 19:27:04 why must pending patches be a list? Apr 03 19:27:48 sn9: what else? Apr 03 19:28:04 i think in order to fix the handling of patches, it needs to be organized well enough that a bored developer can take care of some patches in 5 minutes or so Apr 03 19:28:26 so that we can make it a habit to take care of a bunch of simple stuff every day Apr 03 19:28:37 for that it needs to be easy to find some pending work Apr 03 19:28:48 well, that's the entire purpose of bug tracking Apr 03 19:29:04 nbd: what about using the paths of the files to trigger "auto-assignment" to the correct component-owner? Apr 03 19:29:30 that way, it either gets handled or reassigned quickly. Apr 03 19:29:40 philipp64|laptop: then the component owner is the bottleneck Apr 03 19:29:50 i think collective code ownership is a good thing Apr 03 19:29:52 and how is that different from today? Apr 03 19:29:56 :-) Apr 03 19:30:19 philipp64|laptop: patchwork lists lots of stuff that has been taken care of already Apr 03 19:30:23 it needs to be made official Apr 03 19:30:27 the idea being that you can triage a bug in 30 seconds or less when looking at it. Apr 03 19:30:32 and all devs should start using it for taking care of patches Apr 03 19:31:09 i already watch the trac timeline for stuff that i can take care of in 30 seconds or less Apr 03 19:31:45 how many new developers are there now? why we (new devs) should take that job - apply easy patches and delegate complicated ones to right devel Apr 03 19:31:50 since PW already watches the mailing list, and the committer sends a message saying "applied in XXXX", why not write a trigger script in PW to notice those messages and mark the patches as APPLIED (or CLOSED or RESOLVED or whatever)? Apr 03 19:31:56 that way new devels would learn a lot Apr 03 19:32:17 the issue with adding new devs is an issue of trust Apr 03 19:32:26 not as in can we trust this guy to not do anything bad Apr 03 19:32:28 why? Apr 03 19:32:39 but instead, can we trust this guy to have good enough judgement to filter out bad code Apr 03 19:33:04 but how you can have that judgement for example for me Apr 03 19:33:08 luka12345: it's not always a question of easy vs. hard... sometimes there's hardware or a particular topology, etc. that a noob has access to that no one else does. Apr 03 19:33:21 so use new devs for non critical packages, so they are 'allowed' to make bad choices and learn Apr 03 19:33:35 he might be the only one situated to fix a rare or hard-to-reproduce bug. Apr 03 19:34:05 luka12345|wiik: if i read enough patches from somebody, i can usually tell Apr 03 19:34:14 i have submited new target several times without reply Apr 03 19:34:23 that's because i didn't have time to look at stuff Apr 03 19:34:27 i'm hoping to change that Apr 03 19:34:38 veger: yes, good point Apr 03 19:34:39 veger: not that simple... even a non-critical package can be badly mangled and "break the build" for everyone else, causing lost time. Apr 03 19:34:42 i guess nobody has the device... Apr 03 19:34:43 but for that we need to change the structure a bit Apr 03 19:34:57 we need to differentiate between maintained packages and unmaintained packages Apr 03 19:35:10 for unmaintained packages the threshold for adding new devs can be much lower Apr 03 19:35:38 philipp64|laptop: if you want new devs you need to give them time to learn, risking lost time indeed... Apr 03 19:35:39 nbd: yes... good. Apr 03 19:35:48 luka12345|wiik: what target by the way? Apr 03 19:36:07 nbd: dlink dns323 storage Apr 03 19:36:20 I still like the idea of having each noob have a "buddy". Apr 03 19:36:36 philipp64|laptop: you meen like mentor Apr 03 19:36:39 philipp64|laptop: mentor system? Apr 03 19:37:07 yes... and if a noob ends up taking too much time and attention... he gets "thrown back" (like a fish) and told to come back later. Apr 03 19:37:07 i think also that mentor system is great Apr 03 19:37:30 human resources is a problem Apr 03 19:37:42 well, but it's an investment, right? Apr 03 19:37:45 <_trine> another idea might be to have a personal director of patches, so that one person could direct a few helper patcher persons who could do the donkey work and waiting for things to compile under the direction of a more experienced person. This would make more computing power available and cut down the waiting time Apr 03 19:37:59 yes Apr 03 19:38:20 say you invest 10% of your time to a mentor, but at the end of 4 months, that noob ends up being 40% as effective as you are on an ongoing basis... it's paid off. Apr 03 19:38:24 in some ways this is the current patch-team Apr 03 19:38:42 well, it's paid off collectively. maybe not for the mentor who had to put off certain goals on his "todo" list. Apr 03 19:39:10 yeah, i think much of this was probably covered in the initial discussion behind starting the patch team already Apr 03 19:39:33 how about this: if the trust issue is about the filtering of bad code, why not have a set of trusted devs do all the filtering? Apr 03 19:39:41 _trine: more build servers building more packages (and more targets!) would also help spot commit-damage sooner, so that we'd have a smoking gun. Apr 03 19:40:06 sn9: because the trusted devs are usually busy Apr 03 19:40:42 filtering is quite a bit of work as well Apr 03 19:40:53 sn9: or have a "sandbox" branch that untrusted commits go into, and then merge that up regularly? Apr 03 19:41:04 philipp64|laptop: that's even more work Apr 03 19:41:21 ok, scratch that then. Apr 03 19:41:29 philipp64|laptop: we need more buildslaves! Apr 03 19:41:39 aye, master! Apr 03 19:42:04 there are a lot of sub targets that don't get built now Apr 03 19:42:14 thepeople: how many machines does the project have access to atm? Apr 03 19:42:18 yeah, and that's a problem. Apr 03 19:42:19 issue is that the things that the trusted devs are busy with can often be handled by others Apr 03 19:43:00 jmccrohan: I can currently do 13 concurrent builds Apr 03 19:43:11 sn9: at least with me that's not the case Apr 03 19:43:17 on 5 boxed Apr 03 19:43:18 true Apr 03 19:43:20 thepeople: on what sort of machine? Apr 03 19:43:21 i wish i had some people that i could delegate parts of my todo list to Apr 03 19:43:23 boes* Apr 03 19:43:32 boxes* Apr 03 19:43:34 sn9: which to a certain degree requires that someone would sit and delegate work to others, but openwrt doesn't really have someone who delegates Apr 03 19:44:25 nbd: but you're mostly the only one for whom delegating would not be possible Apr 03 19:44:27 nbd: would it be possible to publish a to-do list, maybe it would get a couple of volenteers Apr 03 19:45:03 thepeople: for what kind of to-do items? Apr 03 19:45:35 thepeople: isn't a patchwork list a todo list? Apr 03 19:45:39 nbd: generally things that you don't currently have time for but should be done Apr 03 19:45:55 glp: in a way, but what if there is no patch? Apr 03 19:46:02 nbd: what tasks are mechanical yet time-consuming? that would be the most bang-for-the-buck. Apr 03 19:46:15 thepeople: ah. yes Apr 03 19:46:46 philipp64|laptop: different boxes with different capabilities, 2 boxes do 4 builds each, 2 boxes do two builds each, and one box does one build Apr 03 19:47:19 I think it'd be good to have a running talley of unmaintained packages, and # of needed build servers, too. Maybe on the front page of dev.openwrt.org Apr 03 19:47:20 philipp64|laptop: not sure Apr 03 19:47:39 I have another server here but nowhere to host it currently that could run 3-4 builds Apr 03 19:48:27 oneru: there are currently 40 arches, there are many more sub targets that it would be nice to see built Apr 03 19:49:05 If you keep that need in front of people, they might be more willing to help out. Apr 03 19:49:28 swalker: ping Apr 03 19:50:03 oneru: https://home.comcast.net/~sdwalker/uscan/index.html Apr 03 19:50:30 oneru: just a guess would put packages with no defined maintainer at ~900 Apr 03 19:50:53 thepeople: we probably need at least 2 targets per processor family built just to get reasonable coverage, right? Apr 03 19:50:55 how come isnt any official site for that list? Apr 03 19:51:06 could that be hosted on the official site? its very handy. Apr 03 19:51:13 i postulate that neither trac nor patchwork will solve the patch problem Apr 03 19:51:27 about package maintainers: i'd prefer it if people wouldn't just pick up random packages, but instead maintain packages that they actually use and care about Apr 03 19:51:34 a bit offtopic - is anybody using theese subtargets that don't get compiled? do you have any usage feedback? i mean would there be any benefits of fixing those subtargets? Apr 03 19:51:43 so that stuff gets tested properly and fixes get integrated quickly Apr 03 19:52:08 luka12345: I use net5501 and geos, but I don't think any x86 targets are currently built. Apr 03 19:52:35 i also observe that even with trusted devs filtering, bad code sometimes still gets in Apr 03 19:52:54 no one is perfect Apr 03 19:53:25 nbd: i agree - how about to organize voting to see on which packages/targets openwrt should focus to? Apr 03 19:53:31 philipp64|laptop: that is likely a good estamate Apr 03 19:53:48 btw are there any statisics of package usage from official site? Apr 03 19:53:56 RooTer: nope Apr 03 19:54:28 luka12345|wiik: why? Apr 03 19:54:51 what about having the build process optionally report back what target was built with which packages? Apr 03 19:54:58 why to boder fixing some target nobody uses? Apr 03 19:55:16 then we could instrument which packages and targets are used, and how often builds happen. Apr 03 19:55:22 luka12345|wiik: difficult to know if someone is using a specific target Apr 03 19:55:27 glp: exactly why lack of perfection is not a valid justification for rejecting good proposals Apr 03 19:55:33 luka12345|wiik: I think there is at least some use of all the arches currently in openwrt Apr 03 19:56:11 luka12345|wiik: people should work on parts that they like to work on Apr 03 19:56:17 luka12345|wiik: not on stuff that somebody else votes they should do Apr 03 19:56:20 sn9: I'm not rejection anything, just commenting Apr 03 19:57:35 philipp64|laptop: depends on if there are more people that compile or if they just download images from the website Apr 03 19:57:43 philipp64|laptop: actually you can get some statistics from downloads from openwrt.org of precompiled packages Apr 03 19:58:01 philipp64|laptop: and I would be opposed to adding that to the buildroot anyhow Apr 03 19:58:06 so if no one is going to do anything what they don't like/want than we get the situation we have now... Apr 03 19:58:08 the best possible repository for proposed and pending patches is merged code Apr 03 19:58:46 i didn't mean something like that the voting should be used as rule more as some sort of guidance Apr 03 19:59:14 downloads don't offer as much insight into the ratio of package significance vs. developer/owner availability. Apr 03 20:00:12 luka12345|wiik: we should influence the process, not the specific details of what components people work on Apr 03 20:00:32 luka12345: "if you don't eat your meat, you can't have any pudding..." Apr 03 20:00:45 philipp64|laptop: that is why I said "some" statistics Apr 03 20:01:12 thepeople: the statistics in buildroot could be made anonymous. Apr 03 20:03:04 as an alternative to tracking patches in patchwork or trac, i'd like to propose simply having multiple trunks Apr 03 20:03:34 sn9: in what way? Apr 03 20:03:40 debian has stable, testing, and unstable Apr 03 20:03:56 strong NACK to that one Apr 03 20:04:05 openwrt could have separate trunks that serve the same purpose Apr 03 20:04:14 we've had lots of experience with branches that diverge from each other Apr 03 20:04:17 it happens too easily Apr 03 20:04:17 sn9: we need a much larger dev community to support something like that Apr 03 20:04:18 stable and unstable are already there Apr 03 20:04:24 and the merge effort simply makes it not worth it Apr 03 20:04:36 sn9: debian has a lot more manpower. Apr 03 20:04:37 maybe something like arch linux AUR? Apr 03 20:04:57 like what? Apr 03 20:05:06 sn9: splitting trunk does not solve the fundamental problem of not having enough patch review Apr 03 20:05:28 place for community to submit their packages Apr 03 20:05:34 and at the same time it creates more tree maintenance overhead Apr 03 20:05:36 + voting system Apr 03 20:05:42 voting doesn't work Apr 03 20:05:46 <_trine> the problem is clear,, there are not enough people with the relevant knowledge and experience to be full blown maintainers so what needs to be done is to find ways people with perhaps only minimal knowledge and experience can help Apr 03 20:05:48 not for this Apr 03 20:06:11 high vote ratio is only for gaining attention, noting more Apr 03 20:06:16 *nothing more Apr 03 20:06:27 yes, but high or low voting ratio is completely meaningless input for us Apr 03 20:06:44 RooTer: nbd is right about that Apr 03 20:06:45 why? it means package works and it is used Apr 03 20:06:56 yes. why vote - it will just create another kind of frustration Apr 03 20:06:56 no, it means somebody wants to push it Apr 03 20:07:05 so it can be prioritezed to be reviewed Apr 03 20:07:43 the only thing that means a package works and is used is feedback saying so Apr 03 20:07:56 indeed Apr 03 20:07:59 if someone does pull down a patch from patchwork, build it, and test it... verification *is* useful information to track. Apr 03 20:08:47 so maybe not "votes" but being able to annotate a patch as "confirmed". Apr 03 20:08:59 philipp64|laptop: patchwork does not provide a bug tracking framework for doing so, and trac does Apr 03 20:09:01 I hope it was noted down that because patchwork and list of unmaintaned packages SHOULD be officially hosted Apr 03 20:09:24 I hope it was noted down that because patchwork and list of unmaintaned packages are that important they SHOULD be officially hosted Apr 03 20:09:57 sn9: not so. if you reply to a [PATCH] posting with the same subject line, it gets sucked down by PW into the patch-thread. Apr 03 20:10:26 philipp64|laptop: i am well aware of that, but that provides no issue-tracking metadata Apr 03 20:10:41 we don't need issue tracking metadata Apr 03 20:11:03 and the thing with trac is it pisses me off whenever i use it for applying patches Apr 03 20:11:21 well that's a showstopper. :-) Apr 03 20:11:22 with well-formatted mailing list patches, i use my email program, hit view source and copy&paste to git-am Apr 03 20:11:26 need it or not, it exists, whether online, or in our minds Apr 03 20:11:49 i believe mixing bug tracking and patch tracking is a bad idea Apr 03 20:11:55 i think trac is useful for bug tracking Apr 03 20:12:01 but i don't like it for patch tracking at all Apr 03 20:12:20 nbd: that's how bugzilla, cyrus, fedora, etc. all do it. Apr 03 20:12:29 it _is_ a bad idea, but no worse than mixing it with a discussion list Apr 03 20:12:31 don't remind me about bugzilla Apr 03 20:12:34 i hate that thing with passion Apr 03 20:13:02 ok, well, openssl, CPAN, proftpd, APR/Apache... Apr 03 20:13:31 i actually like patchwork very much, but i just don't think it addresses the underlying issues here Apr 03 20:13:41 trac actually is far more accessible than openwrt-devel for most "fresh" users (IMHO) Apr 03 20:13:45 sn9: what do you see as the underlying issue? Apr 03 20:14:05 RooTer: yes, that's good for bug reports Apr 03 20:14:12 the underlying issue is the "attention bottleneck" Apr 03 20:14:15 but for patches, having a higher threshold is actually a good thing Apr 03 20:14:28 sn9: we've done patch tracking in trac Apr 03 20:14:37 sn9: and IMHO it was even worse than with patchwork Apr 03 20:14:51 "attention bottleneck" - I mentioned the 'ombudsmand' topic in the agenda Apr 03 20:14:57 it's just as easy for stuff to get lost in trac as it is with patchwork Apr 03 20:15:05 nbd: no when patches are getting "trap" (lost) on the -devel Apr 03 20:15:15 the means by which patches are reviewed may change, but the review process remains the same Apr 03 20:16:24 nbd: and "higher threshold" isnt a reason for doing sth in other way.. the fact that it is a bother to apply patches from it is, as you mentioned previously Apr 03 20:16:27 so how can be make languishing patches get more attention? Apr 03 20:16:45 nbd: so I wonder is anything that could be done to make that easier Apr 03 20:17:03 to make what easier? Apr 03 20:17:51 nbd: you said applying patches from trac was a hassle Apr 03 20:18:12 yeah Apr 03 20:18:13 as i see it, the only way to make things easier is for the community to shrink until there are few enough patches to manage, but that's absurd Apr 03 20:18:36 RooTer: that might be solvable with some good scripting to eliminate all the click-throughs. Apr 03 20:19:05 ergo, things will continue to be difficult no matter what Apr 03 20:19:06 sn9: the opposite is true as well, the dev community needs to grow to cope with the level of patches Apr 03 20:19:20 sn9: actually, maybe that's not a bad idea... don't introduce new packages without a committed owner. Apr 03 20:19:26 sn9: which more package maintainers would solve Apr 03 20:19:31 philipp64|laptop: how would that help? Apr 03 20:19:57 well, you can't submit patches for a package that doesn't exist... Apr 03 20:19:57 thepeople: that was luka12345|wiik's initial observation, but as we all know, the way to make a late software project later is to add more people Apr 03 20:20:03 lol @ killing community idea, that is the spirit for opensource project Apr 03 20:20:12 RooTer: i believe bug triaging and patch review are completely different things and it's ok to have them in completely different interfaces Apr 03 20:20:26 and when i look for patches to apply, i don't want to step through a mess of bug reports Apr 03 20:20:36 and when i look for bugs to fix, i prefer to focus on that Apr 03 20:20:51 i think having separate interfaces/queues for both is a good thing Apr 03 20:20:52 nbd: but don't you want to see if the patch has been tested and validated independently Apr 03 20:21:01 sn9: proper use of more people helps tho, and this is not a *late* software project, just one that lacks manpower Apr 03 20:21:19 thepeople: same metaphor applies Apr 03 20:21:20 philipp64|laptop: only if it's by somebody i trust Apr 03 20:21:27 otherwise, i don't care Apr 03 20:21:29 nbd: that is ok with me as there is some communication between both.. and both are accessible Apr 03 20:21:54 RooTer: you can link to trac items in patches and you can link to mailing list posts from trac Apr 03 20:21:58 I know people who are terrible (or non-existent) coders but good testers. Apr 03 20:21:58 nbd: it cannot be denied that bugs are typically fixed by patches Apr 03 20:22:00 i think that's all the communication that it needs Apr 03 20:22:42 sn9: sure, but so what? Apr 03 20:22:46 what's your point? Apr 03 20:22:47 philipp64|laptop: the bar for testing trunk code has been lowered with the daily snapshots being made Apr 03 20:23:10 so keeping patches out of trac by force is a losing proposition Apr 03 20:23:18 ok, stepping back a minute (because we seem to be going around)... Apr 03 20:23:54 sn9: i wouldn't want to keep them out by force anyway Apr 03 20:23:55 what can be made to help the more vital people (who are typically the bottlenecks) delegate more? Apr 03 20:24:02 just strongly discourage posting them there Apr 03 20:24:11 close enough Apr 03 20:24:22 what we have until this point is 1. a promise to write some documentation Apr 03 20:24:58 2. the suggestion to make patchwork official Apr 03 20:25:20 i have an idea how the review load could be shared some more Apr 03 20:25:24 documentation needs manpower too, and it's much more difficult to find than devs are Apr 03 20:25:32 3. make it clear that patches should be posted on -devel Apr 03 20:26:05 how about this: experienced devs take a quick look at patches to filter good vs bad, then other devs take care of the testing and committing Apr 03 20:26:23 usually it does not take me very long to spot whether a patch looks good or bad Apr 03 20:26:26 sn9: both devs and documenters have been hard to find in any kind of numbers Apr 03 20:26:32 but testing it and integrating it, making sure that it actually works is more work Apr 03 20:26:33 1. i will do package documentation when i get some experiance with package maintance; somebody will have to review it though Apr 03 20:26:33 nbd: i thought that was already the case Apr 03 20:26:40 sn9: there's no process for that yet Apr 03 20:26:41 nbd: sounds good for me... Apr 03 20:26:54 shouldnt that be the other way around? the newbies should look at vast of patches, then this filter out patches would go through guru Apr 03 20:27:25 one observation about the build docs... it's good for doing a "one-shot" build from scratch, but it isn't so good at documenting the iterative process that dev's go through. Apr 03 20:27:30 thepeople: in the case of devs, it's more a matter of procedure, as luka12345|wiik pointed out Apr 03 20:27:58 I've been bitten more than once by bit-rot in my .config file because I didn't blow away enough stuff before doing a "make defconfig", for instance. Apr 03 20:28:20 RooTer: no, because good vs. bad is a matter of policy Apr 03 20:28:50 glp: 4 swalker's package list should be officially hosted Apr 03 20:29:07 RooTer: it does not make sense for somebody to spend minutes or more testing a patch, when i can tell in seconds that it's crap Apr 03 20:29:16 RooTer: there are interdependencies in packages that might not always be apparent to noobs. Apr 03 20:29:49 thepeople: you mean this https://home.comcast.net/~sdwalker/uscan/index.html Apr 03 20:29:51 thepeople: yes Apr 03 20:30:03 luka12345|wiik: yes Apr 03 20:30:13 but is it updated automaticaly? Apr 03 20:30:39 luka12345|wiik: swalker updates it manually currently I think, but I would think it could be automated Apr 03 20:31:29 i think it does not update automatically... look at for example ethtool Apr 03 20:31:31 thepeople: have we added more devs ? Apr 03 20:32:10 you can count that as people that you accept patches from, or you can count that as additional people with commit rights. Apr 03 20:33:45 OutBackDingo: yep Apr 03 20:33:57 are there more comments to the current topic? Apr 03 20:34:08 philipp64|laptop: additional people with commit rights Apr 03 20:34:09 <_trine> I am prepared to help but I have little knowledge but have quite a bit of spare time,, people like me willing to help would not want commit ability,, so someone needs to decide on how to use such a facility Apr 03 20:34:11 thepeople: all ports ? or extended commit rights Apr 03 20:34:31 _trine: i can help you Apr 03 20:34:32 actually, we may not even need more people with commit access Apr 03 20:34:34 nbd: sounds good Apr 03 20:34:47 nbd: I think with need more package maintainers with commit access Apr 03 20:34:52 how about this: Apr 03 20:34:57 nbd: well, there have been things i could have commited if i had access to those areas Apr 03 20:35:02 OutBackDingo: new package maintainers Apr 03 20:35:18 - incoming patches get noticed by patchwork Apr 03 20:35:24 - experienced devs mark patches which look good Apr 03 20:35:49 mark how? Apr 03 20:35:51 - patch team people (not necessarily all of which need commit access) pick up patches and maintain a git-am compatible patch series Apr 03 20:36:16 OutBackDingo: for the time being you can ping me for trunk/ patches if they are good Apr 03 20:36:16 - that git-am patch series occasionally gets looked over and thrown into the tree Apr 03 20:36:25 sn9: we need a flag in patchwork for that Apr 03 20:36:30 maybe a status type Apr 03 20:36:36 can be something fairly simple Apr 03 20:36:50 nbd: open, accepted, assigned, commited Apr 03 20:37:03 yes Apr 03 20:37:28 i think that is ok Apr 03 20:37:32 with that process we only need a few people to actually commit the changes Apr 03 20:37:36 open - reviewed, accept by senior dev, aiigned to patch team, work occurs, commited Apr 03 20:37:39 the other ones can work together to throw stuff into a staging git tree Apr 03 20:37:43 doesn't accepted come after assigned? Apr 03 20:37:44 philipp64|laptop: (iterative building) yeah, its an yet unwritten chapter of the buildroot manual, you could start some rough sketches in the wiki we can expand later Apr 03 20:37:47 (which should be constantly rebased for clarity) Apr 03 20:37:50 and we can centralize tests Apr 03 20:38:09 philipp64|laptop: accepted would be the initial review by an experienced dev Apr 03 20:38:20 which comes before some patch team member grabbing it for testing (assigned) Apr 03 20:38:33 ok. Apr 03 20:38:59 nbd: yeah, patch team reviews whats accepted, and they assign to their accounts what they cantake/handle Apr 03 20:39:12 i think such a process makes things easier because we don't have to give out more commit access and the task of reviewing patches is simple enough Apr 03 20:39:14 there should also be a "rejected" Apr 03 20:39:17 xMff: sounds like I need to register for Wiki access. :-) Apr 03 20:39:20 i'll volunteer for spending a few minutes on review every day Apr 03 20:39:32 i'll just make it a habit once this process is accepted and implemented Apr 03 20:39:38 KanjiMonster: yes Apr 03 20:39:41 KanjiMonster: very important Apr 03 20:40:16 but not rejected without at least one complete sentence saying why it was rejected. Apr 03 20:40:29 philipp64|laptop: good point Apr 03 20:40:34 otherwise people get frustrated because they aren't learning the "rules". Apr 03 20:40:38 yes, somebody who marks patches as rejected needs to reply to the mail Apr 03 20:40:43 nbd: instead of a single flag in patchwork, how about having each trusted dev have an ack list and a nak list of what they see in patchwork? Apr 03 20:40:45 so that the patch submitter gets feedback Apr 03 20:41:01 sn9: yeah, i don't care as long as it's something that gets done Apr 03 20:41:13 i don't know patchwork enough to be able to tell how much work this is Apr 03 20:41:21 we have a bottleneck on the admin side as well Apr 03 20:41:28 so i don't want to push much work there Apr 03 20:41:29 or, well instead of rejected, maybe reviewed, meaning it needs to go back to the author for improvements :) so they dont think we dont want their work :P Apr 03 20:41:43 patchwork has no infrastructure for any of this Apr 03 20:41:55 sn9: then the flag would be easier Apr 03 20:42:16 "changes requested" Apr 03 20:42:29 doesnt patchwork have a queue system Apr 03 20:42:57 OutBackDingo: yes, and that would be more of a liability than an asset Apr 03 20:44:06 sn9: wel couldnt initial patches be submitted to a review que, then when accepted palced in a work queue Apr 03 20:45:11 the queuing itself is bad, IMO Apr 03 20:45:38 ahhhh Apr 03 20:46:16 a trunk que and a stable que might be helpful Apr 03 20:46:32 i don't think we need a separate queue Apr 03 20:46:40 for stable Apr 03 20:46:47 patches need to go to trunk first Apr 03 20:46:57 <_trine> there seems to be 2 themes to this discussion one theme seems to be how can the current team work harder and more deficiently and the other theme seems to be how do we get more people to share the work which seems to me to be the correct way to go Apr 03 20:46:58 and backports are something that need to be handled and reviewed separately anyway Apr 03 20:47:37 ack Apr 03 20:47:40 the only other set I could see as being useful is a trunk/ que and a packages/ que so the core devs have a short list of what needs to be looked at and the patch team/package maintainers should take care of packages/ Apr 03 20:47:45 _trine: more sharing makes the work harder Apr 03 20:48:05 thepeople: personally I mentally filter away packages patches anyway Apr 03 20:48:31 thepeople: don't think it must be split, would only encourage devs to not even look into the non core queue Apr 03 20:48:58 yeah Apr 03 20:49:19 <_trine> to delegate in a business has always been the way to move ahead Apr 03 20:49:38 unless its delegated back to you in the end :) Apr 03 20:49:45 _trine: this is not really a business :-) Apr 03 20:49:56 _trine: or it all filters down to a single delagate Apr 03 20:49:59 <_trine> glp it is really Apr 03 20:50:24 it's an attention economy ;) Apr 03 20:50:31 <_trine> the only other idea I have is to make nbd do it all Apr 03 20:50:57 _trine: we could try that version :D Apr 03 20:50:59 that's going backwards Apr 03 20:51:02 if we can get the split review/testing process in place, then i'm not too worried about the scalability of the review process anymore Apr 03 20:51:20 well, id hate to see core devs also get bogged down with this stuff as they have alot of stuff to do already Apr 03 20:51:39 OutBackDingo: taking a quick look at a chunk of the incoming stuff is not a big deal for me Apr 03 20:51:46 though not that the patches can be overwheming Apr 03 20:51:50 OutBackDingo: it takes much less time than testing and committing the patches Apr 03 20:52:02 nbd: i agree, process defined here looks promising to me... Apr 03 20:52:06 <_trine> my experience with doing things on a computer is that its 2% thinking time and 92% waiting time Apr 03 20:52:38 <_trine> so by asking helper people to do things would spread the waiting time Apr 03 20:52:44 with the stuff that i've been working on recently it was 80% thinking and 20% doing Apr 03 20:52:56 but i did the thinking while not sitting at my computer ;) Apr 03 20:53:00 _trine: ok great ill be sure to delaget all the stuff i take to you Apr 03 20:53:13 :P Apr 03 20:53:31 <_trine> well I am willing to donate some of my time and others would do also Apr 03 20:53:35 though patches dont take alot of thought Apr 03 20:53:45 in most cases Apr 03 20:53:55 there is an agreement that we should try to above sketched model? Apr 03 20:53:57 they do require time Apr 03 20:54:15 so the new bottleneck could be the lack of interest of new devs, but we will see how it goes... Apr 03 20:54:34 there is an agreement that we should try to _use_ above sketched model? Apr 03 20:54:36 well we've been down that road before Apr 03 20:54:44 luka12345|wiik: if the new bottleneck is lack of interest from external devs, then i don't see much problem with that Apr 03 20:54:51 glp: yes Apr 03 20:54:56 luka12345|wiik: then at least nobody can rightfully complain that we're not letting new people in ;) Apr 03 20:55:08 nbd: yes :) Apr 03 20:55:08 glp: if it's not a business then it must be a cult. Apr 03 20:55:37 <_trine> the other thing people with little knowledge also have is spare computing power which could be utilised Apr 03 20:56:19 * OutBackDingo looks at his 96 core monster Apr 03 20:56:20 by the way, the model that i'm proposing does not even depend on adding flags to patchwork Apr 03 20:56:27 there's a very simple alternative Apr 03 20:56:32 devs drop email subject lines into a wiki page Apr 03 20:56:39 philipp64|laptop: I think nbd had a very valid point Apr 03 20:56:41 potentially with some comments about specific stuff that should be tested Apr 03 20:56:43 OutBackDingo: looks like a good buildslave, care to donate :-P Apr 03 20:56:57 that may even be better than patchwork Apr 03 20:57:04 nbd: that could be automated, too Apr 03 20:57:17 sn9: not sure that it needs to Apr 03 20:57:21 thepeople: how many cores? Apr 03 20:57:28 from my perspective it would work like this Apr 03 20:57:45 i go throuh my email list, pick a patch, review it, remember some things to watch out for Apr 03 20:57:57 OutBackDingo: half :-) Apr 03 20:58:13 then both copy&paste the subject line and also metion things like 'test the dependency of this package', or 'try building it on this OS' Apr 03 20:58:27 thepeople: LOL... how bout i get with Intel or SGI and inquire about a donation Apr 03 20:58:43 copy&paste? seriously? Apr 03 20:59:00 sn9: what's wrong with that? Apr 03 20:59:09 i care about results not perfection of the tools Apr 03 20:59:22 i use copy&paste to apply patches as well Apr 03 20:59:32 because it's faster than saving a file and looking it up Apr 03 21:01:09 my focus for designing the build system, tools and workflows has always been just one simple thing: spend as little time as possible on mechanical tasks Apr 03 21:02:03 hacking a hack of a hack is something i'd also do, but gotta consider what happens when things go awry Apr 03 21:02:25 where do you see potential for things to go awry? Apr 03 21:03:52 things already go awry with faulty formatting in patchwork Apr 03 21:04:00 <_trine> going to bed goodnight Apr 03 21:04:06 i think we have covered this topic very well... any other that needs to be discussed? Apr 03 21:04:20 sn9: so? we don't depend on any formatting in patchwork Apr 03 21:04:22 editing text in it willy nilly can only compound that Apr 03 21:04:32 i wasn't suggesting editing text in patchwork Apr 03 21:04:38 i was suggesting editing text in a wiki page Apr 03 21:04:49 ok Apr 03 21:04:57 As noted, I'll put a summary together of the discussion and post it on -devel Apr 03 21:05:42 glp: great Apr 03 21:05:53 but it doesn't even need wiki markup, just checkboxes Apr 03 21:05:56 hey all, I'm back. Is the discussion of patches new devs still on? Apr 03 21:06:03 cshore: yes Apr 03 21:06:23 sn9: yeah, but i don't want special tools for this unless absolutely necessary Apr 03 21:06:37 i prefer something that can be done without any changes to the existing infrastructure Apr 03 21:06:58 patchwork can do that, in a way Apr 03 21:07:23 if patchwork does exactly what we need, then we can use it for that Apr 03 21:07:26 subscribe e-mail autoresponders to the list that patchwork monitors Apr 03 21:07:53 but if the annotations cannot be done well in patchwork, then a wiki page is better Apr 03 21:07:55 then all a dev needs to do is hit a button; no new tools needed Apr 03 21:08:08 and a wiki page can also notify the whole patchteam about incoming stuff Apr 03 21:08:09 ;) Apr 03 21:08:51 is it possible to enter a comment for a patch (only directed at testers) in patchwork? Apr 03 21:09:02 i'd recommend a patch-only list for patchwork, with reply-to set to -devel Apr 03 21:09:50 there is no reason to distinguish between comments to testers and comments to the submitter Apr 03 21:10:01 i think there is Apr 03 21:10:26 comments to testers would be something like 'please test this, but verify dependencies with packages foo and bar, test platform qux' Apr 03 21:10:31 stuff like that is meaningless for submitters Apr 03 21:10:37 they don't need to be spammed with it Apr 03 21:10:46 and those comments are not useful in an archive either Apr 03 21:11:01 they're only temporarily useful to whoever picks up the patch and tests it Apr 03 21:12:06 no, I don't think patchwork can handle that Apr 03 21:12:11 then wiki it is Apr 03 21:13:06 well, without that, patchwork is superfluous Apr 03 21:13:34 no, patchwork is still useful for marking stuff at done Apr 03 21:13:39 s/at/as/ Apr 03 21:14:02 so, the proposed workflow is the following? Apr 03 21:14:27 -devel -> patchwork -> wiki -> patchwork Apr 03 21:14:36 yes Apr 03 21:15:02 where -devel -> patchwork is automatic, right? Apr 03 21:15:05 yes Apr 03 21:15:37 that is very similar to a bug tracking system Apr 03 21:15:47 yes Apr 03 21:16:27 what about patches that patchwork doesn't recognize as patches...there seem to be some that happens for according to an email on -devel? Apr 03 21:16:43 the way i see it, the mailing list integration is the primary thing this provides that trac doesn't Apr 03 21:17:49 i do see the problem of having bug reports mixed in, but that has nothing to do with which tools are used Apr 03 21:18:51 just because two trackers are better than one doesn't mean the same tools cannot be used for both Apr 03 21:19:28 i think you're missing the point Apr 03 21:19:33 it doesn't matter what tools we use Apr 03 21:19:43 important is that we get this implemented the fastest way possible Apr 03 21:19:52 without blocking it by having to wait for site admins to take care of it Apr 03 21:20:17 that part i already agreed with Apr 03 21:20:21 ok Apr 03 21:20:26 step 2 is how Apr 03 21:20:30 I think it does matter... if the submitter is populated the required information in tool X, and the committer is looking in Y, then they will never be on the same page... literally. Apr 03 21:20:41 *populating Apr 03 21:21:33 philipp64: but that happens regardless of which two tracking systems you use....i.e. it's a problem for two Tracs as well. Apr 03 21:21:41 philipp64|laptop: the proposal was for having a single place for testing/commit requests Apr 03 21:22:13 and if a patch is in trac, then people can throw a link to the trac ticket into the wiki Apr 03 21:22:50 sn9: first we need to have a good writeup of the proposal, then we figure out who does what Apr 03 21:22:54 sn9: then we create the wiki page Apr 03 21:23:07 and ensure that people have access to patchwork to mark stuff as done Apr 03 21:23:20 wiki page is not even needed with a second tracker Apr 03 21:23:42 sn9: but it requires admins to set it up Apr 03 21:23:47 and maintain it Apr 03 21:23:56 sn9: the wiki patchworks stuff doesn't require the admins to do anything Apr 03 21:24:00 in the wiki, admin access is more widely distributed Apr 03 21:24:02 sn9: so we can do it now Apr 03 21:24:07 which means that adding access is much faster Apr 03 21:25:22 cshore: without integration between the wiki page and patchwork, more must be done at every dev step Apr 03 21:25:25 sn9: the problem with you proposal is it requires a whole bunch more work for the already busy site admins. Apr 03 21:25:52 sn9: copying a subject line takes 1-2 seconds if i'm slow Apr 03 21:25:58 that hardly counts as significant overheard Apr 03 21:26:01 overhead Apr 03 21:26:14 wikis require more maintenance than that Apr 03 21:26:26 we already have a wiki Apr 03 21:26:36 sn9: ^^^^ Apr 03 21:26:50 s/wikis/wiki pages/ Apr 03 21:27:02 how does a wiki page require more maintenance? Apr 03 21:27:30 all it takes is making a page and giving a group of people access to it Apr 03 21:27:46 and a whole bunch of openwrt devs including myself have admin access to the wiki Apr 03 21:28:13 sn9: IIUC, the dev copies and pasts to the wiki pages....testers do stuff...eventually the dev commits and removes the entry. Hardly difficult Apr 03 21:28:39 and keeping that straight on a constant basis is less work than one-time setup? if so, then ok Apr 03 21:29:14 the admins don't have much time Apr 03 21:29:24 and typically many 'one time setups' take months to be implemented Apr 03 21:29:31 sn9: I don't see that Trac will do what we want as far as tester only email anyway Apr 03 21:29:54 sn9: remember the wiki changeover? Apr 03 21:30:07 ugh Apr 03 21:31:24 sn9: I take it that's a yes ? ;-) Apr 03 21:31:53 ok, if the wiki gets a patchstatus-only section that doesn't hog the wiki resources, yes Apr 03 21:31:57 on a sidenote... do we need a process to keep all of the targets (platforms) within reasonable sync for linux kernel version updates? Apr 03 21:32:13 sn9: 'hog the wiki resources'? Apr 03 21:32:17 what do you mean? Apr 03 21:32:23 well... its php Apr 03 21:32:32 so that we're not finding patch damage on processor X weeks or months after processor Y gets bumped? Apr 03 21:32:37 if there is a separate wiki page for every patch... Apr 03 21:32:47 we don't need a separate page for every patch Apr 03 21:32:51 one page is enough Apr 03 21:33:00 someone already managed to create a page big enough to make the server time out when trying to serve it Apr 03 21:33:02 philipp64|laptop: various core devs take care of their branches Apr 03 21:33:14 i don't expect the page to get very long Apr 03 21:33:14 philipp64|laptop: sometimes outside people help Apr 03 21:33:16 yes, but not all equally. :-) Apr 03 21:33:22 thepeople: do we have an x86 dev? Apr 03 21:33:24 we won't post the full patches there anyway Apr 03 21:33:33 just links/subject lines Apr 03 21:33:34 cshore: Kaloz? Apr 03 21:33:35 and some notes Apr 03 21:33:55 cshore: Kaloz has taken care of it Apr 03 21:34:09 but then so had {Nico} in the past Apr 03 21:34:36 I'd like to see x86, for example, be bumped to 2.6.37.4 at a minimum. Apr 03 21:34:44 and if it gets to big we can discuss how to split it Apr 03 21:34:49 or .6 as of today... Apr 03 21:34:57 philipp64: what's needed for the .4 bump? Apr 03 21:35:13 nothing that I can tell... it should be good to go. Apr 03 21:35:23 I just don't think a build has been done and signed off. Apr 03 21:36:17 philipp64|laptop: so do one :) Apr 03 21:37:15 OutBackDingo: not sure the builds I do are good enough to be official builds... I tend to throw in what others might call "cruft" (excess). Apr 03 21:37:17 like Vim... Apr 03 21:37:29 ahhh Apr 03 21:37:40 philipp64: can you do a plain build just for testing? Apr 03 21:37:58 i can tackle a plain x86 target to test Apr 03 21:38:42 patchwork creates patch numbers, fwiw Apr 03 21:38:45 philipp64|laptop: what platform you loading on ? Apr 03 21:39:09 geos or net5501 Apr 03 21:39:24 btw: someone said a while back that we need more subtargets, not fewer. I tend to agree. Apr 03 21:39:36 "generic" should be optimal for a salvaged PC. Apr 03 21:39:41 +1 Apr 03 21:40:00 anything else (alix, net4801, net5501, geos, wrap, etc) should be tailored. Apr 03 21:40:35 can we get some consensus on that? Apr 03 21:40:52 I think there already is one Apr 03 21:40:58 I agree Apr 03 21:41:01 its just a matter of implementing the changes Apr 03 21:41:06 right Apr 03 21:41:06 if so, I'll start looking at adding new platform definitions... though the net4[58]01 have been EOL'd now 3 years, so testing might be tricky. Apr 03 21:41:23 philipp64|laptop: and thats exactly the problem :) Apr 03 21:41:40 ok... didn't want to do the effort and then find out there was no consensus. Apr 03 21:41:51 maybe I'll spend $200 on eBay... Apr 03 21:42:47 phillipp64: one problem with more subtargets is making sure that they don't create more need for synching Apr 03 21:42:57 btw, did i see correctly on the mailing list that eabi can be done on armv4l? Apr 03 21:45:05 just to back up, building a "fatter" x86-platform target (like net5501 + vim) is still good proof of a kernel bump, though, right? as long as it works? Apr 03 21:47:29 xMff: alternatively.... if no one is using (say) net4501 we could retire it. Apr 03 21:47:43 at what point does a subtree on the SCM get pruned? Apr 03 21:51:06 philipp64|laptop: I think there are no common precedents Apr 03 21:51:16 i don't think pruning is a good idea, regardless Apr 03 21:51:59 well, if it's there, but it's not being built periodically, then what good is it anyway? Apr 03 21:52:08 even otherwise abandoned code is always patchable Apr 03 21:52:42 well, the threat of deletion is one way to get someone to step up and own something... :-) Apr 03 21:53:04 lol Apr 03 21:53:10 damn... 110-allow_static_liblzma.patch fails to patch on 2.6.38.2 Apr 03 21:53:35 it does, but it doesn't exactly foster good judgment Apr 03 21:54:56 oh, nevermind... bitrot. was previously 100-... Apr 03 21:59:08 * philipp64|laptop tries to stop thinking about canoes and grass skirts. Apr 03 22:04:19 philipp64|laptop: are you in my backyard ? Apr 03 22:07:21 philipp64|laptop: actually we did prune two targets Apr 03 22:07:25 one is brcm-2.4 Apr 03 22:07:46 and the other was for enterprise APs from aruba Apr 03 22:08:07 nice island Apr 03 22:08:14 not the island Apr 03 22:08:17 a company called like that Apr 03 22:08:18 :p Apr 03 22:08:20 ;) Apr 03 22:09:04 and now to forget about pruning entirely, here's some pictures of kitteeeh! http://narf-archive.com/pix/5f5399bf90a483b5f46698618322f17dc2dcc84b.jpg Apr 03 22:09:08 ;) Apr 03 22:10:14 that's one small cat. Apr 03 22:10:28 cool, it worked ;) Apr 03 22:10:48 at least it wasn't goatse Apr 03 22:13:36 it's like you guys speak another language sometimes... Apr 03 22:14:02 yes, english is another language Apr 03 22:14:47 can you really have been so sheltered so as to not know what goatse is? Apr 03 22:15:22 is it a small cat you wear as a chin-wig? Apr 03 22:15:36 no. Apr 03 22:15:43 :D Apr 03 22:15:56 * EqUaTe is trying to work out if philipp64|laptop is serious or having us on Apr 03 22:15:59 i think i'll stay out of this discussion Apr 03 22:16:07 oh, nevermind... just wikipedia's it. Apr 03 22:16:17 that works Apr 03 22:16:17 thank god for slow image downloads. Apr 03 22:16:32 heh Apr 03 22:16:37 why would someone post a picture of a goat? Apr 03 22:16:43 ... Apr 03 22:16:48 nice kitty Apr 03 22:17:00 cshore: Wikipedia Is Your Friend Apr 03 22:17:22 my friends don't show me things like that. Apr 03 22:17:46 at least never when I've been sober enough to remember it later. Apr 03 22:18:04 I see...I really didn't want to know that Apr 03 22:18:11 brain-scars Apr 03 22:18:17 how can you be so sheltered??! Apr 03 22:18:35 next you'll tell me you've never heard of tubgirl, lemonparty or two girls one cup Apr 03 22:18:51 STOP, the nightmares are coming back Apr 03 22:18:56 lol Apr 03 22:19:00 sn9: see what you did there? ;) Apr 03 22:19:02 what has been seen cannot be unseen Apr 03 22:19:24 nbd: it's called a facepalm Apr 03 22:19:40 facewalls and facedesks are more appropriate with things like this imo Apr 03 22:19:55 freedom to see has pluses and minuses Apr 03 22:20:02 indeed. Apr 03 22:20:17 see plus plus Apr 03 22:20:20 a regular facepalm won't do... http://flipvine.com/blog/wp-content/uploads/2009/12/4139.jpg Apr 03 22:20:21 I'm going to have nightmares tonight. Apr 03 22:20:33 * russell-- not looking Apr 03 22:20:35 * EqUaTe thinks philipp64|laptop's done a google image search Apr 03 22:20:38 eQUatTe: I am obvously sheltered Apr 03 22:20:57 nbd: indeed. Apr 03 22:21:07 who is sicker? the girl in the tub, or the one holding the camera? Apr 03 22:21:16 cshore: and lacking a tab key? Apr 03 22:21:23 yup, he image searched. Apr 03 22:21:45 I'll skip the other references. Apr 03 22:21:54 EqUATe: my client doesn't do the TAB completion thing Apr 03 22:21:54 hm.. there was 1guy1jar too Apr 03 22:21:56 yeah, probably a good idea. Apr 03 22:22:20 I'm already going to have a longer than average conversation with St. Peter. Apr 03 22:22:21 cshore: that makes me curious as to what client. i haven't come across any that didn't in a long time.. Apr 03 22:22:32 Pidgin Apr 03 22:22:35 who's St. Peter? Apr 03 22:22:48 nbd: rumoured to be the entry clerk at the pearly gates Apr 03 22:22:55 he decides whether to let you into heaven or not based on your life... Apr 03 22:22:57 if you believe certain sources. Apr 03 22:22:57 cshore: I use pidgin too and it does tab complete Apr 03 22:22:57 nbd: christian dealer Apr 03 22:23:07 *drug dealer Apr 03 22:23:10 lol Apr 03 22:23:20 xMff: really? hmm...what am I doing wrong then, I wonder? Apr 03 22:23:37 you never tried to press tab after typing the first two chars of the nick? Apr 03 22:23:44 * russell-- has been wondering about openembedded, do openwrt developers have knowledge/opinions about it? Apr 03 22:23:51 xMff: nope, and I see that it works Apr 03 22:23:53 philipp64|laptop: so he's a bouncer Apr 03 22:24:03 yeah, kind of. Apr 03 22:24:25 cshore: it ignores case too so quite convenient Apr 03 22:24:50 xMff: sweet....why didn't I try that before?!?!! Apr 03 22:24:54 russell--: tried it, didn't like it Apr 03 22:24:58 openwrt > openembedded Apr 03 22:25:04 i think it has a tendency to make projects really unproductive ;) Apr 03 22:25:13 lol Apr 03 22:25:23 i've seen what it did to openmoko ;) Apr 03 22:25:24 * russell-- lives near giant intel campuses Apr 03 22:25:38 there is something called yocto now Apr 03 22:25:42 russell--: which ones? Apr 03 22:25:58 the ones in hillsboro oregon Apr 03 22:26:22 I was in HF2 until about 10 days ago. Apr 03 22:26:38 the intel dudes seem excited about it Apr 03 22:27:25 i don't know anything about it, except it uses some weird bitbake thing Apr 03 22:27:30 stuff like yocto and openembedded really is for a different kind of embedded Apr 03 22:27:54 nbd: what do you mean by that? Apr 03 22:27:58 phones? Apr 03 22:28:09 stb's Apr 03 22:28:34 RooTer: the kind where you take in all the desktop world bloat and try to make it just small enough to be able to work on a fast mobile cpu Apr 03 22:28:36 that's not *so* different... Apr 03 22:29:15 * russell-- has taken a couple runs at understanding the openwrt buildroot makefile hackery, but my head explodes after 15 or 20 minutes ... Apr 03 22:29:17 oh... dont packages in openwrt try to do the same? Apr 03 22:29:34 philipp64: I think that's why nbd doesn't do much with packages feed IIRC Apr 03 22:29:35 ssh, small httpd server, QoS, firewall... Apr 03 22:29:48 it's not just what the packages do Apr 03 22:29:51 or is the base system more fine tunned? Apr 03 22:29:55 it's what the base system is designed for Apr 03 22:30:19 openwrt is about starting with something small, then only adding what's necessary Apr 03 22:30:33 at least from my point of view Apr 03 22:31:16 and you say that openembedded is taking desktop software and making it small to fit on embedded in contrast to openwrt? Apr 03 22:31:27 that's what it looks like to me Apr 03 22:31:35 at least in the projects where it gets used Apr 03 22:31:40 ok, thanks Apr 03 22:32:06 philipp64: That's why I want to get away from extroot as the solution to exernal packages. IMO you system should be able to run off flash, and only need a little from USB or whatever, and then only for things like VoIP which are bigger than a typical 4MB flash, but still useful for small embedded devices. Apr 03 22:32:10 so right now i'm working on redesigning quite a bit of stuff in the core packages in openwrt Apr 03 22:32:34 to make stuff integrate better Apr 03 22:32:53 what is the new design strategy? Apr 03 22:33:00 extroot is very nice for testing, and "trying out" openwrt Apr 03 22:33:37 RooTer: that is true...you can install all kinds of stuff and see what you want...that kind of thing? Apr 03 22:33:37 russell--: more ipc, rpc and C :) Apr 03 22:33:45 yep Apr 03 22:34:04 the x86 builds tend to be more feature-rich by their nature, so probably more stateful at the same time. Apr 03 22:34:05 cshore: yea, no worries about cleaning up every time you want to checkout sth new Apr 03 22:34:07 C is good, the others, not so much Apr 03 22:34:27 sn9: why not? Apr 03 22:34:29 I tried using sysupgrade, but it clobbered everything, including the files called out in sysupgrade.conf ... Apr 03 22:34:41 not sure what I did wrong. Apr 03 22:34:44 philipp64|laptop: yeah I need to so some work on that Apr 03 22:35:03 philipp64|laptop: I mean sysupgrade with extroot...different topic...sorry Apr 03 22:35:53 is there a wiki page on setting up a box with persistent state across upgrades? Apr 03 22:36:21 hm, I was gone for like a hour, or two, so the metting is over already yes? Apr 03 22:36:29 appears to be Apr 03 22:36:34 yes Apr 03 22:36:58 because there was talk about goatse, so I hope it wasnt on the agenda of openwrt devs;) Apr 03 22:37:05 sn9: the new RPC stuff in openwrt will be based on ubus Apr 03 22:37:09 should i bring up iftop again? ;-) Apr 03 22:37:17 RooTer: didn't you know, it's the new initiation rite? Apr 03 22:37:20 me-bus? Apr 03 22:37:52 ubus is a lightweight message bus that c daemons can use to expose an RPC API Apr 03 22:38:17 RooTer: not that I actually have seen the photo, only the desciption on wikipedia....I didn't do an image search, and don't plan to either. Apr 03 22:38:37 cshore: oh, sth in style of nbd's "higher threshold Apr 03 22:38:39 [Sun 2011-04-03 03:25:35 PM PDT] openwrt is about starting with something small, then only adding what's necessary Apr 03 22:38:54 or killing community;) Apr 03 22:39:10 ubus is very small Apr 03 22:39:48 any daemon that adds an API via ubus automatically becomes scriptable as well Apr 03 22:39:55 and it is necessary Apr 03 22:40:12 as the shell/hotplug mixture is about to fall apart Apr 03 22:40:33 reminds me eerily of OSA Scripting Apr 03 22:41:10 it doesn't carry its own scripting language Apr 03 22:41:56 minor point Apr 03 22:41:57 an application that registers with ubus can expose objects and methods that can be called from outside stuff Apr 03 22:42:16 these methods take in structured messages and can send back structured messages as well Apr 03 22:42:39 the format is a binary type-length-name-value format with a simple C parser/generator library Apr 03 22:42:46 and supports automatic conversion to and from JSON Apr 03 22:42:57 niiiiiice Apr 03 22:43:10 anything written in C will not need to use JSON Apr 03 22:43:20 but the CLI uses it Apr 03 22:43:32 and i wrote a small shell tool/library to read and write json from shell scripts Apr 03 22:44:10 when i think json lib, i think mono, so this is neato Apr 03 22:44:32 the C api is designed to be easy to use and easy to integrate with any existing codebase Apr 03 22:45:49 I think it will be helpful for redoing init as well Apr 03 22:46:06 and it also allows the programmer to not have to think about memory management or input validation too much Apr 03 22:46:13 without sacrificing efficiency Apr 03 22:47:58 ATM, I'm seeing issues due to USB stuff needing to be loaded for extroot in preinit, but not doing cold plug in the 'regular init', (so not hotplug events for partitions on devices present at boot when extroot is present). Apr 03 22:48:12 cshore: yes this is a bug Apr 03 22:48:24 cshore: it uses to work at some point Apr 03 22:48:28 *used Apr 03 22:48:53 hm maybe nvm Apr 03 22:49:00 i think ubus will have at least as much of an impact on openwrt as uci had Apr 03 22:49:07 but it's better designed than uci ;) Apr 03 22:49:24 uci can be frustrating Apr 03 22:49:45 uci was written 3 years ago Apr 03 22:49:50 i've learned quite a bit since then ;) Apr 03 22:50:39 not that uci is going away Apr 03 22:50:47 but at least we'll stop abusing it for storing status information Apr 03 22:52:44 it's too bad initramfs doesn't give you and fs you can use after boot Apr 03 22:53:15 ? Apr 03 22:53:48 I think using initramfs would solve some of the issues around preinit/init, especially with an event-based init Apr 03 22:54:10 i don't see how initramfs is necessary for this Apr 03 22:54:11 the problem at moment for extroot is that we need hotplug and modules loaded before init Apr 03 22:54:39 Or else be able to coldplug in init Apr 03 22:54:48 yeah Apr 03 22:54:51 we just need to rewrite init Apr 03 22:54:54 blogic will be working on that Apr 03 23:03:00 sn9: at least uci is reasonably easy to debug and trace... Apr 03 23:06:24 crumb. it appears there are issues with overlayfs and also with miniupnpd Apr 03 23:06:47 nbd: quick makefile question for you... Apr 03 23:06:47 and I don't have serial on my main router atm Apr 03 23:07:46 oh, so much for my plans for what I was going to work on.... Apr 03 23:08:33 even with the commit #26397 in place, "make defconfig" still gets the wrong defaults... CONFIG_DEFAULT_kmod-gpio-cs5535 gets set, even for LINUX_VERSION=2.6.38.2 Apr 03 23:09:05 is that a bug in "make defconfig"? Apr 03 23:09:59 no Apr 03 23:10:15 ah, CompareKernelPatchVer is disabled for DUMP=1 Apr 03 23:10:21 so how about this Apr 03 23:10:27 instead of checking for >= 2.6.38 Apr 03 23:10:41 check for !2.6.32 Apr 03 23:10:58 that can be done without CompareKernelPatchVer Apr 03 23:13:36 got an example somewhere I could look at? Apr 03 23:14:31 $(if $(findstring 2.6.32,$(LINUX_VERSION)),,) Apr 03 23:14:35 something like tht Apr 03 23:14:50 ok. Apr 03 23:16:45 hmmm...it seem libiptc is missing ... odd. Apr 03 23:16:58 libiptc shouldn't be used anymore Apr 03 23:17:16 there's libip4tc and libip6tc Apr 03 23:17:26 nbd: hmmm...miniupnp seem to depend on libiptc Apr 03 23:17:29 i mean libiptc is still there, but it's only a wrapper that links against the other two Apr 03 23:17:47 nbd: ah. well it's got libip45c and libipt6c Apr 03 23:17:56 but ldd shows missing libiptc Apr 03 23:18:42 yeah, it doesn't explicitly specify dependency on libiptc Apr 03 23:18:55 while you're at it, you can remove the dep on the libiptc.so Apr 03 23:19:07 and make the dependency on libip4tc and libip6tc explicit Apr 03 23:19:12 ok Apr 03 23:19:16 i'll make sure the package split gets backported Apr 03 23:19:31 nbd: tried it, fail... Apr 03 23:21:24 oh, nevermind... had bitrot... needed to remove tmp/ first. Apr 03 23:21:30 nbd: is there any reason one would be unable to rename the $(TOPDIR) (i.e. if I rename my openwrt buidroot dir's parent dir, will things break unless I do a dirclean)? Apr 03 23:22:02 various packages use absolute pathnames internally Apr 03 23:22:20 ick, ok Apr 03 23:25:35 nbd * r26457 /branches/backfire/package/iptables/Makefile: iptables: backport the libiptc split from r26292 Apr 03 23:25:39 I generally used dated buildroot parent, so that I can keep previous builds around in case the current one is bad (so I can compile new/different packages for a known good build). Apr 03 23:31:40 philipp64|laptop: is it tested this time? Apr 03 23:31:44 ;) Apr 03 23:33:23 well, it's hard to know how much testing is necessary without a deep understanding of the Makefile machinery, alas. Apr 03 23:34:07 last time I thought it had worked, but that was partially due to stale state left over in tmp/ Apr 03 23:34:22 yeah, i need to fix the timestamp checks for targets Apr 03 23:34:49 either way, i tested it by changing the kernel version from .32 to .38 and back Apr 03 23:34:54 and the default selection changed Apr 03 23:35:04 so... Apr 03 23:35:14 nbd * r26458 /trunk/target/linux/x86/geos/target.mk: Apr 03 23:35:14 x86/geos: redux of cs5535 version Apr 03 23:35:14 The previous technique didn't work with "make defconfig" correctly. Apr 03 23:35:14 Signed-off-by: Philip Prindeville Apr 03 23:35:16 there Apr 03 23:35:17 ;) Apr 03 23:35:18 thanks. **** BEGIN LOGGING AT Sun Apr 03 23:55:22 2011 **** BEGIN LOGGING AT Mon Apr 04 15:14:14 2011 Apr 04 17:45:26 how do I find the offset to: mtd -o offset fixtrx? Apr 04 19:42:34 thepeople * r26473 /packages/utils/firmwarehotplug/Makefile: newer versions of sdcc dropped support for xa51, compiles fine without so change the ckeck for sdcc Apr 04 19:42:52 cshore * r26474 /packages/libs/newt/patches/110-disable-snackmodule-python.patch: [libs] newt: Fixed cross-compilation error due to attempt to use host Python by disabling build of snackmodule (a python module) which we weren't shipping anyway. Apr 04 19:50:35 build #0 of sibyte is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/0 Apr 04 19:50:38 build #0 of uml is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/0 Apr 04 19:51:32 build #0 of x86 is complete: Failure [failed compile_1] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/0 Apr 04 19:52:17 build #0 of ar7 is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/0 Apr 04 20:01:32 build #0 of xburst is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/0 Apr 04 20:17:57 build #0 of ixp4xx is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/0 Apr 04 20:17:58 build #0 of kirkwood is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/0 Apr 04 20:37:57 nbd: http://www.personaltelco.net/~russell/strace-iftop.log ... it looks like the parent process 1189 sets up the SIGRT_0 handler with sigaction, clones 1192, then sends a SIGRT_0 to 1192, but 1192 says "unknown signal". documentation (http://linux.die.net/man/2/clone) suggests clone() should have 1192 inheriting the signal handlers Apr 04 20:46:31 thepeople * r26475 /packages/utils/firmwarehotplug/Makefile: account for more sdcc variants Apr 04 21:33:08 build #0 of au1000 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/0 Apr 04 22:09:07 build #0 of etrax is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/0 Apr 04 23:00:38 glp_: could the summary of irc metting be posted on -devel, as not all interested were able to attend? Apr 04 23:19:09 russell--: what if we're viewing this the wrong way Apr 04 23:19:20 e.g. if the signal hander is still there Apr 04 23:19:32 but something in the call chain of the signal handler calls abort() Apr 04 23:19:46 based on my reading of the strace, i think that's more likely Apr 04 23:21:33 russell--: should be possible to track this down using gdbserver/remote-gdb by setting a breakpoint Apr 04 23:48:17 where should the breakpoint go, do you think? Apr 04 23:49:09 oh, in the signal handler Apr 04 23:49:15 hmm Apr 04 23:49:46 should be easy to check, anyway Apr 04 23:52:12 btw, libthread_db.so ought to get added to the gdbserver (or ?) package Apr 04 23:55:06 you could also put the breakpoint into abort() Apr 04 23:55:11 and do a backtrace Apr 05 00:01:13 oh, so the signal handler just sets a variable Apr 05 00:01:31 yes Apr 05 00:01:41 the abort might show up later in some thread handling code Apr 05 00:01:50 there are some instances of abort() being called after cancellation Apr 05 00:02:00 okay, i'll try the breakpoint in abort() Apr 05 00:02:00 if it can't find the right context for the thread Apr 05 00:03:34 hmm. Apr 05 00:03:39 (gdb) break abort Apr 05 00:03:40 Breakpoint 1 at 0x401f40 Apr 05 00:03:40 (gdb) continue Apr 05 00:03:40 Continuing. Apr 05 00:03:40 Program exited normally. Apr 05 00:03:57 doesn't stop for me Apr 05 00:04:08 maybe /me doing something dumb Apr 05 00:04:28 i don't use gdb very often Apr 05 00:05:01 the exit normally happens after i give iftop a 'q' to quit Apr 05 00:05:12 i think you need to set the breakpoint before you start it Apr 05 00:05:22 not sure though Apr 05 00:06:03 i don't thing there's a chance to. you start gdbserver and it waits until gdb connects Apr 05 00:06:28 the break abort is the first thing i type to gdb Apr 05 00:06:52 ah ok Apr 05 00:07:53 also, break finish ; continue ; (press q to iftop) exits too, as if it is never called Apr 05 00:08:06 where finish() is the signal handler Apr 05 00:08:40 make me think the signal handlers aren't being cloned Apr 05 00:08:43 ok, maybe some printf debugging in uclibc is necessary then Apr 05 00:08:53 well, signal handler cloning is the kernel's job Apr 05 00:09:05 i don't see any code in clone.S, neither in uclibc nor in glibc Apr 05 00:09:25 hmm Apr 05 00:09:30 and the correct parameters for that are being passed to the clone syscall Apr 05 00:10:35 one nice thing is that when wrapped by gdbserver the terminal gets straightened out on exit Apr 05 00:10:48 so i don't have to kill/restart the session Apr 05 00:10:59 do you even see the 'aborted' message? Apr 05 00:11:06 using gdbserver Apr 05 00:11:16 no Apr 05 00:11:29 ok, then maybe gdbserver is hiding the problem Apr 05 00:11:33 and that's why the breakpoint doesn't work Apr 05 00:11:47 maybe it's a race condition Apr 05 00:11:49 also, *sometimes* the first time i try iftop it doesn't 'abort' Apr 05 00:11:57 but when i try it again it does Apr 05 00:12:04 ok Apr 05 00:12:13 i still think the code is hitting an actual abort() call Apr 05 00:12:21 and there aren't that many likely candidates for that Apr 05 00:12:54 btw. you can unpack uclibc using quilt as well and selectively build it like with normal packages Apr 05 00:13:02 in case you want to put some debug statements in there Apr 05 00:13:18 * russell-- has forgotten how to do the quilt thing Apr 05 00:13:19 just need to use {clean,compile} on base-files as well after a uclibc compile Apr 05 00:13:30 make toolchain/uClibc/{clean,compile} V=99 QUILT=1 Apr 05 00:13:35 you don't need to actually use quilt Apr 05 00:13:51 just use the flag which forces the build system to let you change stuff without throwing the build dir away Apr 05 00:13:59 okay Apr 05 01:24:02 latest trunk on ar71xx/wndr3700 is broken Apr 05 01:24:09 it compiles fine but the device doesn't boot Apr 05 01:42:18 got_milk: i'll look into it Apr 05 01:44:49 thanks nbd Apr 05 01:46:23 got_milk: nbd: worked for me earlier today on a wrt160nl Apr 05 01:48:41 nbd: I figured out the (part of) the overlayfs problem Apr 05 01:48:55 nbd: it seems that it happens when you are not running as root Apr 05 01:49:21 nbd: the symlink is 'seen' by ls, but then you don't have permissions to access the overlay-whiteout Apr 05 01:53:11 got_milk: worked in my test too Apr 05 01:53:39 got_milk: did you check the output of ./scripts/diffconfig.sh? anything suspicious in there? Apr 05 02:09:04 nbd: nothing that jumped out at me Apr 05 02:09:10 like I said, it built just fine Apr 05 02:09:42 ran make clean, svn up, updated feeds then ran oldconfig and built Apr 05 02:16:54 show me your .config please Apr 05 02:17:04 menuconfig is doing some really crazy stuff in my tests Apr 05 02:17:11 and i want to see if it might have messed up your config Apr 05 02:18:36 sure, give me a few minutes, i'm not at my build machine right now Apr 05 02:31:01 nbd: http://www.pastebin.com/9zHYaUJT Apr 05 02:50:27 looks normal to me Apr 05 02:54:16 to me as well Apr 05 02:56:18 ah, i know why your image doesn't work Apr 05 02:56:23 the block-mount package is broken Apr 05 02:56:28 cshore: ping Apr 05 02:56:40 nbd: pong Apr 05 02:56:55 if i select block-mount in latest trunk, the image dies in preinit Apr 05 02:56:59 jffs2 not ready yet; using ramdisk Apr 05 02:56:59 Kernel panic - not syncing: Attempted to kill init! Apr 05 02:57:34 what arch? Apr 05 02:57:35 ahhhh Apr 05 02:57:38 ar71xx Apr 05 02:58:08 for reference, here's diffconfig.sh: http://pastebin.com/jm19dMz4 Apr 05 02:58:13 not sure what the 4 warnings are Apr 05 02:58:35 but they don't appear to be relevant Apr 05 02:59:31 hmmm...it works on brcm63xx, so I'm not sure what's up....oh wait....damn nit I think I made a change that should have been innocent, but didn't test. I added /lib/functions/fsck Apr 05 02:59:43 if you delete it, what happens? **** ENDING LOGGING AT Tue Apr 05 02:59:58 2011