**** BEGIN LOGGING AT Tue Jan 07 02:59:58 2014
Jan 07 05:10:28 <builder> build #450 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/450
Jan 07 05:13:27 <builder> build #450 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/450
Jan 07 05:57:50 <builder> build #487 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/487
Jan 07 06:03:52 <builder> build #485 of atheros is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/485
Jan 07 08:06:17 <builder> build #420 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/420
Jan 07 09:01:26 <Devastator> good evening, is BB scheduled to be released anytime soon? I wonder if the release window is still open for fixes
Jan 07 09:01:42 <Devastator> s/evening/morning
Jan 07 09:09:12 <plntyk> afaik it is planned soonish because we are still sitting at 3.10.24 Kernel for (most?) platforms and there will be no kernel update in trunk until BB is forked off
Jan 07 09:13:55 <Devastator> the webflash image of one of my device's doesn't have the deadc0de marker, I've reported to the mailing list a few months ago, I don't know if I should ping the dev about it or leave it for the next release or so
Jan 07 09:16:25 <plntyk> maybe ping the dev about it ? maybe it is not there because of missing feedback or "non-trivial" changes ? dunno ... even small patches that fix compile issues can take a "random" time to get accepted
Jan 07 09:18:39 <Devastator> in this case I didn't send a patch, I just reported the problem itself as I don't have skill to fix it
Jan 07 09:18:43 <plntyk> there is other major reworking done - maybe there was no time to review/test - see the talk of nbd @ 30C3 - he mentions luci2 and something about DD-WRT changing/improving its buildroot
Jan 07 09:19:59 <Devastator> exactly, that is why I'm asking, to see if this is something that should be fixed before the release, because I don't want to bother a dev for nothing
Jan 07 09:22:14 <zajec> Devastator: just repost this issue description
Jan 07 09:22:17 <zajec> Devastator: could be missed
Jan 07 09:22:36 <plntyk> Devastator: well if there is an open ticket too it "might" be on the radar but there is no rule like "fix all bugs before release" because there will always be more incoming - maybe try to throw the bug at some ppl active in the forums where u can have other ppl. that might have your / the problematic hardware
Jan 07 09:23:24 <Devastator> I guess I'm going to bump the mailing list thread and ask if there is some news about it
Jan 07 09:23:51 <Devastator> and in fact I didn't open a ticket at the time, to be honest
Jan 07 09:25:23 <plntyk> I am still trying to get the buildroot to work on several different distros and there are some minor differences everywhere that are really strange
Jan 07 09:26:08 <Devastator> I don't know which distro the devs use, but I had much success with debian
Jan 07 09:26:38 <Devastator> zajec congrats for your CFE magic patches that were pushed in linux-mtd, great work
Jan 07 09:32:16 <russell--> hmm. problem with netifd sequence, runs dhcp query before all the interfaces on the bridge are up
Jan 07 09:36:29 <zajec> Devastator: oh, you tested it!
Jan 07 09:36:30 <zajec> thanks!
Jan 07 09:36:53 <zajec> Devastator: u mean https://dev.openwrt.org/ticket/13733 right?
Jan 07 09:36:53 <Devastator> zajec I didn't, but I liked the work heh
Jan 07 09:37:21 <zajec> ahh ;)
Jan 07 09:37:28 <Devastator> zajec "find root partition by CFE magic"
Jan 07 09:37:37 <zajec> ok
Jan 07 09:38:33 <russell--> hmm. waiting another minute, dhcp retries and i get a lease
Jan 07 09:52:49 <builder> build #477 of lantiq is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/477
Jan 07 10:16:19 <builder> build #430 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/430
Jan 07 10:21:31 <OpenWrt-Commits> kaloz r39206 trunk/ target/linux/x86/image/Config.in target/linux/x86/image/Makefile config/Config-images.in * move most of the x86 image generation options to the main file
Jan 07 10:24:06 <OpenWrt-Commits> kaloz r39207 trunk/config/Config-images.in * virtualbox emulates the e1000 for a long time now
Jan 07 11:03:20 <builder> build #50 of mxs is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/50
Jan 07 11:06:48 <karlp> I'm trying to replace some old gpioctl usages with sysfs for gpio, but I just get "device or resource busy" when I try something like "echo 5 > /sys/class/gpio/export"
Jan 07 11:07:12 <karlp> if I cat /sys/kernel/debug/gpio, it shows that all the gpios are already assigned,
Jan 07 11:07:43 <zajec> karlp: well, there is sth grabbing them
Jan 07 11:07:44 <karlp> if the kernel has grabbed them, as "leds" according to the ar2315.c file, is there anyway to use them from userspace?
Jan 07 11:07:48 <zajec> karlp: maybe arch code for LEDs
Jan 07 11:08:06 <zajec> karlp: since GPIOs are grabbed for LEDs, use LEDs insterface
Jan 07 11:08:11 <zajec> see /sys/class/leds/
Jan 07 11:12:26 <karlp> zajec: thanks, not sure why I hadn't followed that thread all the way
Jan 07 11:12:32 <karlp> feel a bit silly now :)
Jan 07 11:15:21 <zajec> np :)
Jan 07 11:15:24 <karlp> heh, great, the active low on this led wasn't set up properly
Jan 07 11:15:34 <karlp> echo 255 > brightness to turn it off
Jan 07 11:15:41 <zajec> oh
Jan 07 11:15:45 <zajec> report it  :)
Jan 07 11:16:16 <karlp> no point, this is the atheros platform, which needs to be split into multiple platforms for this sort of reason already, but no-one's going to bother.
Jan 07 11:16:25 <zajec> ah
Jan 07 11:17:04 <KanjiMonster> send a patch ;p
Jan 07 11:17:06 <karlp> sucks I know, but it's more work than I've got time for.
Jan 07 11:17:10 <karlp> yeah, thought abotu it :)
Jan 07 11:17:47 <karlp> but the atheros platform has lots of olders tyle stuff, building up a new set of separate platforms for and old target, when I onlt hve the one version of atheros hardware isn't going to help anyone much
Jan 07 12:26:11 <OpenWrt-Commits> kaloz r39208 trunk/ (24 files in 12 dirs) * add x86_64 target support
Jan 07 12:26:29 <stintel> sweet
Jan 07 12:26:41 * stintel starts compiling
Jan 07 12:27:23 <Kaloz> ;)
Jan 07 12:28:01 <Kaloz> mind you this is using ahci, and I'll likely drop even more legacy stuff later
Jan 07 12:28:42 <stintel> running on KVM though
Jan 07 12:28:45 <stintel> so virtio_blk
Jan 07 12:29:04 <stintel> which I probably want to switch to virtio_scsi
Jan 07 12:29:36 <Kaloz> well, for now it's ahci+e1000
Jan 07 12:29:40 <Kaloz> I add virtio stuff, too
Jan 07 12:29:57 <stintel> ic, maybe I should migrate the x86_kvm subtarget to x86_64
Jan 07 12:30:10 <Kaloz> nah, I dropped it for a reason
Jan 07 12:30:23 <stintel> ah, it's gone, ok - haven't checked the commits yet
Jan 07 12:30:31 <Kaloz> having virtio drivers in the normal target should be fine
Jan 07 12:33:53 <stintel> ok, CONFIG_HYPERVISOR_GUEST=y would be nice though when running on KVM
Jan 07 12:33:59 <stintel> anyway, afk - meeting
Jan 07 12:38:40 <roh> Kaloz: for x86 stuff?
Jan 07 12:38:42 <builder> build #462 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/462
Jan 07 12:39:01 <Kaloz> roh: x86_64
Jan 07 12:39:34 <roh> ah.. well.. that eats disk and ram anyhow.. whats the virtio_ kernel modules? 100-200k total?
Jan 07 13:09:01 <builder> build #451 of x86 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/451
Jan 07 13:35:42 <stintel> hmmm, must check if >=3.10 kernel has this upstream: https://dev.openwrt.org/changeset/33072
Jan 07 13:36:15 <stintel> because if it isn't, the bug will be back when switching x86 from 3.3 to 3.10
Jan 07 13:41:18 <stintel> ah, I knew I had been looking into that before: http://stewie.be.tintel.eu/openwrt/x86/0004-x86-add-fix-for-11882-on-3.7.patch
Jan 07 13:46:37 <stintel> heh that patch still applies on 3.12
Jan 07 13:49:49 <stintel> too bad I don't have any via rhine to test
Jan 07 14:35:53 <builder> build #443 of ar7 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/443
Jan 07 15:03:08 <OpenWrt-Commits> kaloz r39209 trunk/toolchain/gcc/common.mk * [toolchain/gcc]: upgrade Linaro GCC 4.8 to 4.8-2013.12
Jan 07 15:06:30 <OpenWrt-Commits> kaloz r39210 trunk/ (9 files in 3 dirs) * [toolchain/binutils]: upgrade the Linaro binutils to 2.24-2013.12
Jan 07 16:41:04 <lynxis> wigyori: sunxi is still broken for my cubieboard2 with openwrt's own u-boot and linux kernel (build with gcc/linaro 4.6). any thoughts what's missing?
Jan 07 18:26:35 <wigyori> lynxis: for the cb2 a good couple things are missing - i'll try to get on top of it today/tomorow
Jan 07 19:31:35 <russell--> stintel: alix2's have rhine interfaces
Jan 07 19:32:06 <stintel> yeah but I don't have any alix2's ;)
Jan 07 19:32:17 * russell-- happens to
Jan 07 19:32:41 <russell--> what are you wanting tested?
Jan 07 19:32:46 <stintel> oh, so did you ever experience the bug in https://dev.openwrt.org/ticket/11882
Jan 07 19:33:50 * russell-- looks
Jan 07 19:37:08 * russell-- wants to visit the scotland network ;-)
Jan 07 19:38:32 * russell-- has not seen that bug, but probably never had enough traffic to tickle it
Jan 07 19:41:56 <russell--> this https://dev.openwrt.org/changeset/33072 claims that it is fixed, is there reason to believe it isn't fixed?
Jan 07 19:42:11 <stintel> russell--: that's only for 3.3 kernel
Jan 07 19:42:39 <stintel> so if x86 is switched to 3.10, the bug might be back
Jan 07 19:42:59 <russell--> have you looked upstream?
Jan 07 19:43:18 <stintel> well yes
Jan 07 19:43:44 <stintel> see http://stewie.be.tintel.eu/openwrt/x86/0004-x86-add-fix-for-11882-on-3.7.patch
Jan 07 19:44:12 <stintel> short explanation starting at "+This patch"
Jan 07 19:44:49 <stintel> not sure if it addresses the same problem and all, but that's what I could find
Jan 07 19:47:27 * russell-- looked at linux kernel git tree and at least the first part of the patch is upstream, i haven't read the whole thing
Jan 07 19:48:32 <stintel> ok, so just forget about it
Jan 07 19:53:26 <russell--> stintel: linux.git's 05d334eca9994680a6cb8fba3f19955356ccf72a from March 2012 is part of it, anyway
Jan 07 19:54:09 <stintel> might be enough, no idea
Jan 07 19:57:26 <stintel> but that's what I wanted to test, if 3.10 works as good as 3.3 + patch in openwrt
Jan 07 19:59:20 <russell--> you could probably just ask the william waites dude
Jan 07 20:01:12 <stintel> but I did, in march 2013 ;)
Jan 07 20:01:38 <stintel> but didn't get any feedback
Jan 07 20:01:52 <stintel> he didn't have a spare device to test at that time
Jan 07 20:02:05 <stintel> iirc
Jan 07 20:03:58 <russell--> hmm, i could probably set up a similar test rig
Jan 07 20:05:45 <russell--> or, you could just assume it is fixed until someone reports the problem again
Jan 07 20:08:37 <stintel> that's an option yes. I just remember how annoyed ww was on IRC :)
Jan 07 20:08:55 <stintel> comparing against bsd where it worked just fine
Jan 07 20:09:10 <stintel> 17|13:00:55< ww> stintel: bsd manages to have no problem
Jan 07 20:09:10 <stintel> 17|13:01:14< ww> typically poor linux code quality
Jan 07 20:10:02 <russell--> well, there is no accounting for taste ;-)
Jan 07 20:10:05 <stintel> heh, 547MB irc logs, most of them xz compress
Jan 07 20:11:26 <stintel> well I just wanted to avoid if I send patches to switch all x86 targets to 3.10 that the bug is back and someone can blame me ;p
Jan 07 22:03:28 <russell--> hmm. trouble with nocatauth coming up.  /me gets an error during boot that /etc/resolv.conf doesn't exist and it dies, this is newish
Jan 07 22:24:51 <builder> build #323 of octeon is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/323
Jan 07 22:36:14 <russell--> hmm, better now, boggle
Jan 07 22:43:51 <builder> build #504 of at91 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/504
Jan 07 22:57:08 <builder> build #397 of au1000 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/397
Jan 07 23:01:18 <builder> build #451 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/451
Jan 07 23:04:11 <builder> build #451 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/451
Jan 07 23:22:08 <heilterminalcons> procd is crashing with segfault on boot. has anybody heard about something similar?
Jan 07 23:30:25 <russell--> hmm, worse again. nocat looks for /etc/resolv.conf during startup, doesn't like it if it isn't found
Jan 07 23:31:02 <russell--> heilterminalcons: what rev?
Jan 07 23:32:12 <heilterminalcons> procd?
Jan 07 23:32:18 <russell--> openwrt
Jan 07 23:32:30 <heilterminalcons> its a derived trunk version
Jan 07 23:32:53 <heilterminalcons> base-files procd ubus ubox are trunk latest
Jan 07 23:32:53 <russell--> how recent?
Jan 07 23:33:03 <russell--> ok
Jan 07 23:33:32 <russell--> any output when it segfaults?
Jan 07 23:33:42 <heilterminalcons> after init its says 3.946028] procd[1]: segfault at 408f37
Jan 07 23:34:02 <heilterminalcons> the problem doest not occour in failsave mode
Jan 07 23:34:31 <russell--> what happens if you try a vanilla openwrt instead of your derived one?
Jan 07 23:34:49 <heilterminalcons> good point
Jan 07 23:35:09 <russell--> (and then, like, bisect your differences until you find the problem)
Jan 07 23:35:14 <heilterminalcons> this derived one was really huge work
Jan 07 23:35:40 <heilterminalcons> its a native 64bit kvm version
Jan 07 23:35:52 <russell--> cool
Jan 07 23:36:00 <heilterminalcons> i saw today kaloz startet the first 64bit commit
Jan 07 23:43:40 <danitool> I hate procd :P
Jan 07 23:46:08 <heilterminalcons> procd is hard
Jan 07 23:46:22 <heilterminalcons> its never easy to write a init
Jan 07 23:57:48 <heilterminalcons> the problem occurs after commit 582c88fdb55e01f3814e9c09a860651ed51a659d
**** ENDING LOGGING AT Wed Jan 08 02:59:59 2014