ScrewDriver1337 has quit [Ping timeout: 480 seconds]
ScrewDriver1337 has joined #openwrt-devel
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
ScrewDriver1337 has joined #openwrt-devel
ScrewDriver1337 has quit [Remote host closed the connection]
rua has quit [Quit: Leaving.]
noltari has quit [Quit: Bye ~ Happy Hacking!]
nixuser has quit [Read error: Connection reset by peer]
nixuser has joined #openwrt-devel
noltari has joined #openwrt-devel
Tapper has joined #openwrt-devel
n3ph has joined #openwrt-devel
<dhewg>
blogic: figured out why there were no 'dhcpsnoop' ubus calls. there's a package with the same name in the package feeds which got used instead... and it also registers an ubus object of the same name. the cherry on top is the same author though ;)
<dhewg>
and I just noticed this: "//usr/lib/opkg/info/udhcpsnoop.postinst: /etc/uci-defaults/50-dhcpsnoop: line 13: lan1: not found" looks like there's a "lan=" missing in front of the cat in line 13
<hurricos>
Where in the googly does one *get* the OpenWrt one? I realize BPi manufactures them, but I'm unsure what lead time looks like ATM and have need for, say, QTY6.
<Tapper>
hurricos I don't know if any of the openwrt devs cair about the openwrt one. They did not even make a post on the email list letting people who have bin waiting for it for a long time now. No posts on the forums or website.
<blogic>
the inbox page should be delted
<blogic>
Tapper: there were only 150 test run units on sale, they are all sold
<hauke>
blogic: one.openwrt.org forwards to the inbox
<blogic>
Tapper: well will announce it properly once the mass production starts
<Tapper>
blogic a tech blog posted about them before any one from the openwrt project!
<blogic>
Tapper: I know, intentional... only 150 units were avail, if we did a big annoucne the community would need to wait
<Tapper>
People who were waiting for one should of bin given a heads up.
<Tapper>
That makes me feel grate!
<blogic>
so we will announce it publicly once the the the first mass production run happens
<Tapper>
How did a tech blog know about it before us openwrt fokes?
<blogic>
there was a forum post
<schmars[m]>
if anyone of you knows a friend or studio with CAD / industrial design experience, we're looking to (mass)produce a proper outdoor case for the One. there's some $$ for the design work
<schmars[m]>
my personal preference would be something similar to Zyxel NWA55AXE or Cudy AP3000 Outdoor
<schmars[m]>
(i should post on the forum)
<schmars[m]>
contact me or blogic if you have someone
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
sestowner has joined #openwrt-devel
n3ph_ has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
sestowner has quit [Ping timeout: 480 seconds]
peter has joined #openwrt-devel
peter is now known as Guest5432
<Guest5432>
G'day! I'd like to know how you do kernel developement with a quick write-compile-error loop. Like, running `make target/linux/compile` unpacks, patches and re-compiles the whole kernel even if just one file under target/*/files-6.6 changed. That's just so inefficient compared to normal kernel development.
Guest5432 is now known as MaZderMind
<MaZderMind>
sorry
n3ph_ has quit [Quit: WeeChat 4.4.2]
n3ph has joined #openwrt-devel
n3ph has quit [Quit: WeeChat 4.4.2]
n3ph has joined #openwrt-devel
n3ph has quit [Quit: WeeChat 4.4.2]
n3ph has joined #openwrt-devel
<damo22>
if the config changes then ofc you need to recompile the kernel right? mine doesnt recompile the whole kernel if i change just one of the makefiles for example
<dwfreed>
you don't need to recompile the whole kernel if you change just one part of the config
Tapper has quit [Read error: Connection reset by peer]
<damo22>
there you go
Tapper has joined #openwrt-devel
<dwfreed>
the thing is that the openwrt build system explicitly runs clean on the kernel "package" and it is entirely disjoint from the actual kernel build system
n3ph has quit [Quit: WeeChat 4.4.2]
n3ph has joined #openwrt-devel
<damo22>
that doesnt clean the entire kernel tree though rihgt
<damo22>
just the binaries that come out the other end?
goliath has quit [Quit: SIGSEGV]
<dwfreed>
I think it cleans the whole build dir, yes
<dwfreed>
for the kernel
<damo22>
no way, im sure its quicker to do a second build in a row
<MaZderMind>
it's not recompiling the whole toolchain and most packages stay the same, but the kernel for sure is unpacked, patched and recompiled entirely
<MaZderMind>
i tried building only the kernel and then kexec'ing into it but my target does not seem to have enough ram to do this (keec oom's out)
<MaZderMind>
so i probably have to create a whole new sysupgrade image and flash over test kernel changes anyway
<damo22>
MaZderMind: you could try ccache
<MaZderMind>
sounds like a plan, '
<MaZderMind>
I'd have to hack ccache into the toolchain gcc then, I guess
<damo22>
there must be a environment variable you can set to prefix the toolchain but im not familiar with it
<MaZderMind>
I see a couple of forum posts
<MaZderMind>
will give it a spin tomorrow
<damo22>
CONFIG_CCACHE
<Habbie>
i love ccache
<MaZderMind>
yea just found it in menuconfig
<damo22>
yeah it saves a lot of time
* MaZderMind
creates a ramdrive for ccache
<damo22>
/home = ram ?
<damo22>
lol
<MaZderMind>
mkdir /dev/shmem/ccache and just use it
<MaZderMind>
(i kind-of wanted to do this for the source as well but I think I might regret it when the whole build dir is lost in a couple of days when I forgot it only existed in ram)