<owrt-snap-builds>
build #684 of octeon/generic is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/684 blamelist: David Bauer <mail@david-bauer.net>, Tom St?veken <tom@naaa.de>, Jason A. Donenfeld <Jason@zx2c4.com>, Lech Perczak <lech.perczak@gmail.com>, Jeff Collins
<owrt-snap-builds>
<jeffcollins9292@gmail.com>, Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>
<lipnitsk>
yeah I think I fixed it, but maybe there is still something lurking
lucenera has joined #openwrt-devel
<lipnitsk>
now just need somebody to push that fix :)
<lipnitsk>
zx2c4: I think it's still better not to break the build as much as possible, but it is hard to test every target locally. I wonder if there is a simple ./checkbuild.sh script or something you can just run overnight
<owrt-snap-builds>
build #790 of lantiq/ase is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/790 blamelist: David Bauer <mail@david-bauer.net>, Tom St?veken <tom@naaa.de>, Jason A. Donenfeld <Jason@zx2c4.com>, Lech Perczak <lech.perczak@gmail.com>, Jeff Collins <jeffcollins9292@gmail.com>,
<owrt-snap-builds>
Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>
<zx2c4>
Bah. I hope someone merges that patch ..
mgiganto has quit [Ping timeout: 240 seconds]
Tapper has quit [Ping timeout: 276 seconds]
hbug__ has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 265 seconds]
hbug_ has quit [Ping timeout: 268 seconds]
<mangix>
lipnitsk: the best solution is to completely remove gettext-full. unfortunately it's needed in some cases...
<lipnitsk>
mangix: then we are left with doing nothing or speeding it up, right?
<lipnitsk>
mangix: or do you foresee it being removed
<lipnitsk>
zx2c4: if you are still awake.. Looks like we got more
<lipnitsk>
modules/crypto.mk:587: recipe for target '/builder/shared-workdir/build/bin/targets/octeon/generic/packages/kmod-crypto-lib-poly1305_5.4.100-1_mips64_octeonplus.ipk' failed
<rr123>
somehow I feel the lua-based luci is easier to use and it's faster enough for the 'mainstream' 16M/64~128MB routers, hope someone will keep lua-compat up-to-date in the future
<lipnitsk>
not sure why that fail didn't get reported in the channel
<rr123>
luci is 'resource intensive' probably for low-end routers, but routers are getting a little more resource-rich these years
<mangix>
lipnitsk: I do not. If you can speed it up, go ahead.
<zx2c4>
Im basically asleep right now but
<zx2c4>
lipnitsk:
<zx2c4>
select CRYPTO_POLY1305_MIPS if CPU_MIPS32 || (CPU_MIPS64 && 64BIT)
<zx2c4>
How is it possible that the octeonplus doesnt hit that?
<mangix>
why is sane-backends compiling for three hours?
<mangix>
patch sent
<mangix>
let's see what happens
mangix has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
victhor has quit [Ping timeout: 256 seconds]
snh has quit [Read error: Connection reset by peer]
<owrt-snap-builds>
build #626 of bcm47xx/generic is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fgeneric/builds/626 blamelist: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, David Bauer <mail@david-bauer.net>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>, Jason A. Donenfeld <Jason@zx2c4.com>
koniu has quit [Remote host closed the connection]
snh has joined #openwrt-devel
koniu has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
<pkgadd_>
rr123: luci is being refactored to javascript in place, so the lua dependency will disappear altogether (although that might take time), large parts of luci don't even use it at all anymore (and lua-compat merely serves as bridge between old- and new). keep in mind that this refactoring /also/ side-steps updating luci to lua >=5.3, which is rather non-trivial as well
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
<owrt-snap-builds>
build #575 of bcm63xx/smp is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/575 blamelist: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, David Bauer <mail@david-bauer.net>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>, Jason A. Donenfeld <Jason@zx2c4.com>
<Borromini>
Grommish: so 5.10 is breaking your shield right?
<Borromini>
will give it a shot on my erlite.
<Grommish>
Borromini: yes, I'm going to try another version for testing
<Borromini>
different from adrian's PR?
<adrianschmutzler>
note that there might be essentially three causes: 1. 5.4 refresh, 2. the erpro symbol added back, 3. the 5.10 bump
<Borromini>
:P
<Borromini>
adrianschmutzler: and these are all three bundled in your pr?
<Borromini>
i saw a separate pr for that erpro symbol, so probably no
<adrianschmutzler>
I made the 5.10 first, and then got confronted with the erpro situation again
<Borromini>
ok
<adrianschmutzler>
but since I looked closer now, I came to a different conclusion when I realized that this was removed in 4.19 bump due to a mistake
<adrianschmutzler>
so, I created the erpro commit and then came to the conclusion that the diff for 5.10 might be much simpler when we put the 5.4 refresh in front of it
<adrianschmutzler>
and the erpro fix has higher priority for me anyway, since I want to fix support for that also in 21.02
<Grommish>
I need to go thru the 5.10 kernel and see what is missing
<adrianschmutzler>
Grommish: I just read ehci everywhere
<Grommish>
Yeah
<Grommish>
I was testing if it was missing, but I was in a bad place recovery wise on it
<Borromini>
guys can somebody tell me what secsize represents in uboot-envtools?
<Borromini>
i'm looking at the gs108t v3 and it has slightly different namings for its u-boot/system settings partitions, but i'm only getting the u-boot one to work with fw_printenv, fw_printsys doesn't work for the system settings one
dxld has quit [Quit: Bye]
jschwart has joined #openwrt-devel
muhaha has joined #openwrt-devel
<plntyk>
Borromini, tech spec - see sector size mt25q_qlkt_u_512_abb_0.pdf (google that filename /datasheet)
<plntyk>
in u-boot it might be possible to just dd if=/dev/mtd<part> | strings
<grift>
confusing ... i guess eventhough nodefaultroute6 should be the default, it seems to not be others why set it explicitly in the sample config, and then makes me wonder whether openwrt should add this explicitly to its ppp config file
yoook has joined #openwrt-devel
Tapper has joined #openwrt-devel
Borromini has quit [Ping timeout: 264 seconds]
Night-Shade has joined #openwrt-devel
Night-Shade has quit [Read error: Connection reset by peer]
Night-Shade has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 260 seconds]
yoook has quit [Quit: Connection closed]
black_ant has quit [Ping timeout: 264 seconds]
ericzolf has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
PaulFertser has joined #openwrt-devel
erg has joined #openwrt-devel
erg has quit [Quit: Connection closed]
valku has joined #openwrt-devel
ericzolf has quit [Remote host closed the connection]
Tost has joined #openwrt-devel
Tapper has quit [Ping timeout: 276 seconds]
rotanid_ is now known as rotanid
<zx2c4>
blocktrron: it works
<zx2c4>
(tested)
<lipnitsk>
zx2c4: are there any loongson64 targets in openwrt?
<SwedeMike>
for IPv6, it'd be better to follow the guidance in the pppd commit. The default should not be to blindingly install an ipv6 default route to the ipv6 interface. It's fine to keep the option in case the user needs it, but it shouldn't be the default.
<SwedeMike>
to the ppp interface, I mean
<SwedeMike>
the standard according to RFC7084 is for the ISP upstream to send an RA
<grift>
SwedeMike, yes its probably not related to the change in behavior ive been seeing either
<grift>
not sure what changed in the latest pppd release and if that is an issue
<grift>
but yes thing i noticed after updating pppd is that it started to write the routing table
<Tapper>
Hi does it matter that the /etc/rc.common has an out of date Copyright line?
<Tapper>
For OpenWrt not my router.
<pkgadd_>
Tapper: no, it should reflect when it was last (significantly) changed, you don't just bump it because
<Tapper>
OK
<Tapper>
It was just somthing I spotted and wanted to ask about.
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
Borromini has joined #openwrt-devel
<russell-->
guidosarducci: why include/iproute2/ instead of just include/ ?
<guidosarducci>
russell--: because that's the standard include path used in the upstream software, and also in packaging that I've seen e.g. Ubuntu 20 LTS.
<guidosarducci>
russell--: so I imagine users normally include "iproute2" from CLI includes.
<Borromini>
plntyk: ok, thanks
<guidosarducci>
russell--: I just saw Hauke was asking too..
<russell-->
yeah, i'm following up on Hauke's question
<russell-->
the iproute2 makefile uses that path in HDRDIR
<russell-->
HDRDIR?=$(PREFIX)/include/iproute2
dirkSt has joined #openwrt-devel
DirkS has quit [Ping timeout: 240 seconds]
dirkSt has quit [Client Quit]
DirkS has joined #openwrt-devel
<guidosarducci>
russell--: right, I saw that too. And since it's in some distro packaging as well (Ubuntu/Alpine/Arch), it should be OK for users to expect it there, no?
<russell-->
guidosarducci: what else uses that header?
<guidosarducci>
russell--: what do you mean? it's only for BPF programs loaded with iproute2 (and so compiled with clang).
<russell-->
i mean, what other packages rely on it?
<guidosarducci>
russell--: no current packages use it, otherwise they'd have been broken before. But any new packages that compiled BPF programs could use it.
<guidosarducci>
russell--: since we don't include clang as a prerequisite, those would probably just be local packages.
<russell-->
* Below ELF section names and bpf_elf_map structure definition
<russell-->
* are not (!) kernel ABI. It's rather a "contract" between the
<russell-->
* application and the BPF loader in tc. For compatibility, the
<russell-->
explaining all that to the commenters on the pull request will probably expedite merging
<guidosarducci>
russell--: well, I'll try... not sure in the current TL;DR society however.. :) Let me re-check the PR to see what happened.
<guidosarducci>
russell--: was your concern it may be unneeded, or could be in the wrong place?
<russell-->
when people ask questions, they want reassuring, reliable answers where they don't need to exhaustively re-solve the problem
<russell-->
the patch made it look like you were moving the include directory, that was my reading (after Hauke asked)
<russell-->
i can't speak for him, but i wondered "what else is using whatever headers were installed before and did moving it break them?"
<guidosarducci>
russell--: oh, you're talking about the change to $(INSTALL_DIR)? That doesn't move anything, just creates the extra subdir, so I didn't follow you.
<guidosarducci>
russell--: I'll clarify that too for clarity, thanks.