pine127 has quit [Remote host closed the connection]
kontaxis has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
pine127 has joined #openwrt-devel
black_ant has quit [Ping timeout: 260 seconds]
koniu has joined #openwrt-devel
koniu has quit [Ping timeout: 268 seconds]
koniu has joined #openwrt-devel
jlsalvador has quit [Quit: jlsalvador]
<owrt-snap-builds>
build #815 of tegra/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/815 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Shiji Yang <yangshiji66@qq.com>, Paul Spooren <mail@aparcar.org>, Adrian Schmutzler <freifunk@adrianschmutzler.de>
nast has quit [Ping timeout: 240 seconds]
heffer has quit [Ping timeout: 240 seconds]
heffer has joined #openwrt-devel
nast has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
victhor has quit [Quit: Leaving]
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
goliath has quit [Quit: SIGSEGV]
<owrt-2102-builds>
build #9 of mxs/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mxs%2Fgeneric/builds/9 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Shiji Yang <yangshiji66@qq.com>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>
dangole has quit [Remote host closed the connection]
<lipnitsk>
but take a look at the detection and see if you want to test another case
<lipnitsk>
once it's good I can dump the temp commit
<aparcar[m]>
I'm working rn on the docker CI fixup but will check it afterwards
<aparcar[m]>
thank you very much for the work!
<lipnitsk>
okay let me know or leave a message in the PR
<aparcar[m]>
lipnitsk: download speed here is low so I got wait times, please check comments
gaspode has quit [Quit: Woof bloody woof.]
gaspode has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 246 seconds]
Acinonyx has joined #openwrt-devel
<lipnitsk>
aparcar: i know the nested loop looks ugly, but seems to be a case of "it works well enough"
<lipnitsk>
not a bash/awk guru ;)
<aparcar[m]>
agree
<lipnitsk>
I should test it on my treewide patch refresh commit LOL
<lipnitsk>
maybe I'll revert that and see how well it detects things
<aparcar[m]>
fun
<aparcar[m]>
keep me posted once you think it's ready
<lipnitsk>
aparcar: it took 6 seconds on that monster commit
<aparcar[m]>
beautiful
<aparcar[m]>
yea looks good
<aparcar[m]>
please remove the debug commits and I'll merge it
<lipnitsk>
ok
<lipnitsk>
aparcar: done
<lipnitsk>
actually wait
<lipnitsk>
I want to fix shellcheck
<mangix>
lipnitsk: jeffreyto wants that patch backported to 21.02. I don't think we should.
<aparcar[m]>
mangix: why not?
<lipnitsk>
aparcar: okay, done for real now - please merge whenever
<lipnitsk>
mangix: that is completely your call... Sorry, don't think I can help much. I can see his point, but then again, running refresh before cherry-picking is not hard either...
<lipnitsk>
does the release branch see a lot of PRs typically?
<aparcar[m]>
lipnitsk: non invasive patches, yes
<aparcar[m]>
lipnitsk: isn't grep -v /src/ better? imagine a package is called `showsrc` or something
<aparcar[m]>
cornercase
<lipnitsk>
let me think. Yeah I strip that other slash earlier, maybe that should be done later
<lipnitsk>
or better yet, move grep -v "/src/Makefile" to happen earlier
rmilecki has joined #openwrt-devel
<lipnitsk>
aparcar: okay, fixed the cornercase
<lipnitsk>
BTW, just thought of a clever hack - do you guys enforce somehow that people base the PRs on a recent-ish tree? Otherwise somebody could base their work on an old tree without some CI features :)
<aparcar[m]>
lipnitsk: not sure how GH handles this.
<russell-->
mangix: if you set the +R mode for your nick (like in my example) that apparently blocks unregistered people from /msg'ing you
<russell-->
"Due to today's high wave of spam, you might want to set yourself +R to block PMs from unidentified users."
<SwedeMike>
they just msg:ed me some random words, anyone know what they're trying to do?
ldir has joined #openwrt-devel
<svanheule>
Hauke: could you also apply the sg150x patch (773949c15) on 21.02? otherwise the R6800 and R6700v2 won't have working LEDs in the release
ivanich has joined #openwrt-devel
danitool has joined #openwrt-devel
<rsalvaterra>
'morning!
<Grommish>
'Morning
Tost has joined #openwrt-devel
<rsalvaterra>
Hmm… just registered a fw3 complaint: "Warning: Section @nat[0] does not specify a protocol, assuming all"
<rsalvaterra>
I'm not sure I agree with this being a warning at all. The common case for NAT is doing it for every protocol (SNAT/DNAT/MASQUERADE), so why complain? :/
qdel has joined #openwrt-devel
slh64 has quit [Quit: gone]
<olmari>
Likely because "all" _can_ be something not wanted
<olmari>
and hence warn as it isn't failure, but potentially gives away more than is intended
slh64 has joined #openwrt-devel
koniu has quit [Ping timeout: 268 seconds]
adrianschmutzler has joined #openwrt-devel
<Grommish>
Is there a luCi app or mod that displays DHCP info with Hostname, IP, MAC, etc? Aside from the Dashboard, whcih doesn't show IP
<Grommish>
*sigh* Disregard ;p
<grift>
luci-app-ttyd can be used to display whatever you want
<Grommish>
Yeah, but I have console for that. I did find it however, at the bottom of the Status page
<Grommish>
I just never scroll down
<Grommish>
For some reason, one of the TV's is tryibg to use Google's DNS
<Grommish>
and I couldn't ID it
MichaelOF has joined #openwrt-devel
koniu has joined #openwrt-devel
daregap has joined #openwrt-devel
feriman has joined #openwrt-devel
<mangix>
rsalvaterra: no idea how to set the mode
<rsalvaterra>
mangix: Set the mode? Sorry, I'm missing context. :)
<mangix>
+R
<mangix>
ah I meant russell--
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<rsalvaterra>
Eheheh!
<russell-->
/mode mangix +R
<mangix>
Sweet
adrianschmutzler has joined #openwrt-devel
<russell-->
jow: should the xtables-addons in the packages feed have a PKG_BUILD_DEPENDS on kmod-crypto-hash?
<adrianschmutzler>
hi, I wonder whether we can convince quilt to not cut the index lines
<adrianschmutzler>
anybody has an idea, since the manual is not really easy ...
<Grommish>
ynezz: Advice for moving to a testing kernel? I've mod'ed the kernel_versions.mk, but do I just copy the patches-/confg-5.4 to a 5.10 version? The patches, only 1 had to be removed, the rest were still clean
<Grommish>
But I'm not sure how to build the kernel config from scratch
<Grommish>
the actual .config file, I mean
<guidosarducci>
rsalvaterra: one other thing that grows footprint re: sqm implementations is the "kitchen sink" of kmod-sched modules. I've been meaning to reorganize things more like ipt-mod-*. Is there other interest in that?
<rsalvaterra>
True… I have sch-* stuff I don't use at all. Maybe split sqm-scripts into variants…? I mean, most people probably use fq_codel and/or cake…
<guidosarducci>
rsalvaterra: well, split kmod-sched up, and then other consumers like sqm-scripts, qos-scripts, nft-qos, can be updated to use what's installed. It's not difficult; I have a 3-year old sqm rewrite that could do this now...
<guidosarducci>
rsalvaterra: the glaring example is every standard shaping qdisc being bundled together when most people will just use one.
<rsalvaterra>
I only use sqm-scripts, never tried anything else (isn't qos-scripts obsolete?)…
Antoine| has quit [Ping timeout: 240 seconds]
<adrianschmutzler>
Grommish: just look at the recent bumps that have been merged
<adrianschmutzler>
you can then just select the testing kernel via make menuconfig (in global options)
<Grommish>
That doesn't tell me how to generate the kernel .config
<Grommish>
Oh, Ive done that
<guidosarducci>
rsalvaterra: probably yes, but I was still asked to "fix" it when it broke from another change. :-) A few years ago I rewrote most of sqm-scripts for ease of use, maintainability, etc., mostly for friends/family I had to support. That's been my daily driver a long time.
<Grommish>
My issue is after copying patches-5.4 to 5.10, should I do the same thing with config-5.4..
Antoine- has joined #openwrt-devel
<rsalvaterra>
guidosarducci: Oh, my…! This is crazy, indeed. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/linux/modules/netsupport.mk;h=2c2fe82fa09ee9123353007aab6bb637e06bec42;hb=HEAD#l722
<adrianschmutzler>
Grommish: you copy config from 5.4 to 5.10 and then refresh via make kernel_oldconfig
<Grommish>
a better question might be is there a kernel_defconfig type option
<adrianschmutzler>
the first patch in the series not just copies patches, but also config (both without change)
<Grommish>
I'm being ignorant adrianschmutzler, but I'll figure it out :)
<rsalvaterra>
guidosarducci: You should see if tohojo accepts your sqm-scripts rewrite… :)
<guidosarducci>
rsalvaterra: yeah, many of those small "jelly-beans" belong in a core package, but hfsc, htb could be separate for example. I have notes mapping out a lot of changes, so will try to do it for current master.
Antoine| has joined #openwrt-devel
Antoine- has quit [Ping timeout: 260 seconds]
<rsalvaterra>
guidosarducci: Also this… https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/linux/modules/netsupport.mk;h=2c2fe82fa09ee9123353007aab6bb637e06bec42;hb=HEAD#l884
<russell-->
jow: test case, add CONFIG_PACKAGE_iptables-mod-condition=y to a vanilla config, the make target/linux/clean world ... my build is dying in the xtables-addons build due to missing kmod-crypto-hash dependency (only needed for some subpackages in addons, like kmod-ipt-sysrq)
<guidosarducci>
rsalvaterra: that ship has sailed! Tried back than, but faced pointless argumentativeness and outright obstruction, as a couple others also noticed and mentioned to me. Just never gotten around to widely sharing my version yet, but mean to soon ;-]
<guidosarducci>
rsalvaterra: yeah, there's lots of opportunity to clean up the netsupport modules... I'll ping you when I start the PR, probably a "WIP" type.
<rsalvaterra>
Gah… is it sacred, or something? Why can't we improve things when they can be improved? :/
<rsalvaterra>
Sure, I could help you testing, at least, since you already have a head start. :)
<guidosarducci>
rsalvaterra: not sacred, but when getting a review/merge done can take 6-9 months one tends to prioritize one's efforts.
<guidosarducci>
rsalvaterra: I also thought 20.xx was coming too soon and didn't have time to fix all the dependent packages. I guess I was wrong!
<rsalvaterra>
guidosarducci: I also understand the other side, reviewer bandwidth is scarce… I just keep pushing, since I'm quite patient… :P
<karlp>
adrianschmutzler: thanks for looking at quilt.
<karlp>
adrianschmutzler: one option would be dropping the requirement that refresh get run.....
<adrianschmutzler>
karlp: sorry, I don't get that
<adrianschmutzler>
and be aware that I'm looking at this for the first time, I just used it so far
<guidosarducci>
rsalvaterra: "pushy" helps too :-). But also, over the ~decade I've followed OWRT, reviewer bandwidth as well as attitudes go up and down. Things are certainly better than the bad old days.
<karlp>
well, manginx and friends pushed on us this massive "trample all the patches to one uniform style!!!" commit
<karlp>
which is ... yes, uniform.... and lets "refresh" run cleanly.
<karlp>
but was fairly clearly noise and removed useful data and context from completely valid patches.
<adrianschmutzler>
karlp: reference?
<guidosarducci>
rsalvaterra: thanks, I'll make sure to ping you on the PR.
<adrianschmutzler>
apart from that, note that I generally like stuff like the index being removed etc.
<karlp>
packages:treewide: refresh all patches... ?
<karlp>
you're clearly seeing the same thing now, that you refer to in your devel mail.
<rsalvaterra>
guidosarducci: Thanks! ;)
<adrianschmutzler>
well, my problem is not so much refreshing patches and removing unneeded stuff, I just think that particular issue I mentioned should be treated
<adrianschmutzler>
which would probably already remove 50 % of the lines in stuff like "refresh all patches"
<karlp>
exactly,
<karlp>
which is what I tried to raise on the PR, but.. well :)
<karlp>
refresh all the patches!
<mangix>
I don't know that there's a solution for the context lines.
<karlp>
so the solution is to destroy all context in patches?
<mangix>
.....
<guidosarducci>
russell--: ah, I forgot to ask if you could add your "Checkmark" (or whatever it's called) to the iproute2 PR. Thanks very much for looking.
<karlp>
take a nice perfectly formed upstream git patch file and just toss most of it out? to keep quilt happy?
<mangix>
I'm talking about what adrian mentioned
<mangix>
Patch description was not removed
<russell-->
guidosarducci: review is limited to people with write access which i don't have afaik
<adrianschmutzler>
mangix: but this is actually done by quilt?
rsalvaterra1 has joined #openwrt-devel
<adrianschmutzler>
cause I did not find any documentation on it (just want to make sure we don't just cut it ourselves somewhere)
<adrianschmutzler>
other stuff seems to have options, like --no-index etc.
<mangix>
AFAIK, quilt uses GNU diff by default.
rsalvaterra has quit [Ping timeout: 260 seconds]
<guidosarducci>
russell--: oh, I was asking because you're listed as the maintainer. Just a comment would do as well I suppose.
<karlp>
_heaps_ of them had only that level of change.
<adrianschmutzler>
be aware that if we don't truncate, we will get similar diffs on _all_ kernel patches
<adrianschmutzler>
that will be a hell of a patch
Tapper has joined #openwrt-devel
<mangix>
:)
<karlp>
so what'ðs the goal, support patch files from upstream, or make refresh generate the smallest change sets?
<mangix>
The goal is to remove fuzz and bad offsets
<plntyk>
wasnt line length extended in Linux Kernel recently - or at least "softened"
<rsalvaterra1>
I just remembered, now we've already branched 21.02, maybe it would be a good time to address the elephant in the room… the black sheep of mvebu, WRT1900AC v1/v2. :/
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<mangix>
Welcome back
<rsalvaterra>
Mamba/cobra are dumbing down the whole mvebu/cortexa9 subtarget, by being the only ones not supporting both NEON and VFPv3-D32.
<Borromini>
:P
<rsalvaterra>
Anything else (Armada 38x) is basically castrated at birth. :/
<Grommish>
Borromini: You still looking for octeon TZ wierdness?
<Borromini>
Grommish: yes, it's still on my list
<Borromini>
you bumped into something?
<Grommish>
I can confirm it at least
<mangix>
Seems there's a cortex-a9 target
<mangix>
Non NEON anor vfp
<Borromini>
Grommish: ok you only get UTC shown as well?
<Grommish>
I just put one of the Shields up as my live edge so I actually have acess to it
<mangix>
Move it there?
<Grommish>
No, actually, I get UTC set to UTC-3.. I have to offset by -8 to get EST
<adrianschmutzler>
karlp: mangix: I will have a look at the quilt code later; but having to make the kernel patch diff lines longer again will probably kill any attempts eventually
<Borromini>
Grommish: all over the place it seems...
<Grommish>
I'm fully able to select TZs
<Borromini>
but it doesn't do a thing?
<Grommish>
It does on the Time Zone page in luCi
<Grommish>
Interesting
<rsalvaterra>
mangix: We should move it somewhere, yes… Either that, or create yet another mvebu subtarget.
<rsalvaterra>
I don't believe the latter will fly…
<mangix>
It will not
<mangix>
.
<Borromini>
Grommish: in the LuCI overview do you see EST or what the router prints on the CLI?
<Borromini>
because for me it's both UTC no matter what (should be on CET)
<Grommish>
Status Page shows "Local Time" in UTC.
<Grommish>
If you go into System/System
<Grommish>
You can show Local time change when you mess with the drop down
<Grommish>
Now, its just showing Local time, regardless of what i set :D
<Grommish>
Anyway, if you find somehing I can help with, lemme know
<adrianschmutzler>
mvebu neon subtarget has been tried several times and never met acclaim at committers
<Borromini>
Grommish: will do, thanks. i have no idea what to dig for for now, lots of people already suggested stuff but all those settings seem standard, and ironically it all works on all my non-octeon stuff (it's basically a custom uci defaults script presetting all the timezone stuff here)
<Grommish>
my /var/TZ files is correct
<Grommish>
EST5EDT,M3.2.0,M11.1.0
<Borromini>
Hauke: would you mind backporting 773949c152, b5bc53813d and 06356f0020 to 21.02?
<karlp>
adrianschmutzler: mangix what about what I suggested that refresh only be pushed on patches that result in fuzz being applied?
<Borromini>
Grommish: yeah string is fully correct here as well.
<karlp>
rather than just blanket all patches?
<Grommish>
Borromini I'm going to give 5.10 a try to see what fails.. Aside from a wireguard error, nothing so far, so I'm hopeful
<Grommish>
I did a rebase to sweep up anything I missed
Ycarus has quit [Remote host closed the connection]
<Borromini>
Grommish: cool! you got octeon patches for 5.10 ready?
<Grommish>
Says it built fine. I had wg-tools and it died on those because its' built in now.. and a few personal packages that don't work right now.. other than that,. it's clean
<Grommish>
But, it'll have to wait for the test machine. Only one I have access to from here is the edge router ...
<Grommish>
so tempting
<russell-->
coward
<Grommish>
Very much so haha
<Grommish>
Of course, I can build Borromini an image ;p
<rsalvaterra>
Grommish: With current master, you can get WireGuard working if you compile it in the kernel (and select the wireguard-tools package). Gross hack, while support for 5.10 isn't merged, but better than nothing. :)
<Grommish>
I mean, under 5.10, you have to remove the wg-tools
Borromini has quit [Ping timeout: 246 seconds]
<Grommish>
Says it's un-needed since >5.6
<rsalvaterra>
Oh, unneeded? I missed that one…
Borromini has joined #openwrt-devel
<rsalvaterra>
No, you still need wireguard-tools to configure the connections.
<zx2c4>
lipnitsk: i pushed a bunch of changes
<Grommish>
rsalvaterra: gotcha.. Must have been in one of the comits I grabbed.. it was complaining wireguard-linux-compat is a no-no now
<rsalvaterra>
zx2c4: The memory savings are nice, to say the least. ;)
<rsalvaterra>
Grommish: You need to disable the kernel module compilation (kmod-wireguard), as it's still the compat version.
<Borromini>
Grommish: sorry wonky MT7613 radio :)
<Borromini>
timed out
<adrianschmutzler>
karlp: I actually like that uniform style
<adrianschmutzler>
however, due to that kernel patches problem, one might choose what you suggested eventually
<karlp>
well, you're going to get "noise" on _every_ first refresh right now, but at least it's only on the first refresh? :)
<Grommish>
rsalvaterra: kmod_wireguard now has a KERNEL-5.4 requirement, so it must have been fixed by a commit I grabbed after the error :)
<rsalvaterra>
Yes, that workaround was merged yesteday. :)
<rsalvaterra>
*yesterday
<adrianschmutzler>
karlp: well, the optimal case of cause would be if patches are submitted already after a refresh has been run
<Grommish>
do I have to manuaky enable that kmod in kernel?
<karlp>
that seems to be at odds witht he stated goal of making it easier to submit changes :)
<rsalvaterra>
Grommish: Yes, but not as a module. Built-in.
<Grommish>
rsalvaterra: Gotcha. Thanks :)
feriman has quit [Quit: WeeChat 3.0.1]
Darkmatter66 has quit [Ping timeout: 260 seconds]
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
Strykar has quit [Quit: /quit]
ldir has quit [Quit: *.net *.split]
Strykar has joined #openwrt-devel
victhor has quit [Ping timeout: 260 seconds]
victhor has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Read error: Connection reset by peer]
snh has quit [Ping timeout: 272 seconds]
snh has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 240 seconds]
snh_ is now known as snh
shibboleth has joined #openwrt-devel
victhor_ has joined #openwrt-devel
victhor has quit [Disconnected by services]
victhor_ is now known as victhor
<adrianschmutzler>
so, after several hours of trying to understand quilt, what have I found out?
<adrianschmutzler>
it's a diff bug
falk0n has joined #openwrt-devel
<adrianschmutzler>
diff -pu my/a.txt my/b.txt
<adrianschmutzler>
or not really a bug, rather they hardcode 40 characters max:
<adrianschmutzler>
karlp: and that will probably mean that the are seen as different from quilt anyway, so filtering refresh on changed files won't help here either
nitroshift has quit [Quit: Gone that way --->]
<karlp>
I was suggesting just to look in the logs for the "patch applied with fuzz" and only then consider any sort of patch refresh, rather than trying to automate it.
Tost has quit [Ping timeout: 260 seconds]
<adrianschmutzler>
ah, okay
<karlp>
because that's the only time the patches actualyl _need_ anything, and it instantly eliminates any noise changes.
<karlp>
so yes, flag/reject submissions that the PR builders find "fuzz applied" in the logs, but otherwise don't interfere.
<adrianschmutzler>
well, changing positions might also get a problem, just not so quickly
koniu has quit [Remote host closed the connection]
<karlp>
and buildbots doing daily snapshots can even autofile bugs on fuzz applied if someone bypasses the premerge checks
<karlp>
if it applies cleanly to the wrong place, refresh won't help anyway?
koniu has joined #openwrt-devel
<adrianschmutzler>
these things typically change gradually
<adrianschmutzler>
you have a patched driver with offset 10
<adrianschmutzler>
during next kernel refresh it's 50
<karlp>
right, but everytime they do, the daily buyildbots will have a fuzz line int he log
<adrianschmutzler>
then 100
<karlp>
and they can be addressed then.
<adrianschmutzler>
and suddenly it will be 150 and match to the wrong section
<karlp>
I'm not sayign to ignore them, fix them as they come up,
<adrianschmutzler>
this might happen without any fuzz
<karlp>
s/fuzz/with offset or fuzz/ then :)
<karlp>
that's what I meant anywya :)
<karlp>
but huge chunks of those refreshes were not even refreshing offset, just stripping the line endings and git index info
gromero_ has quit [Ping timeout: 272 seconds]
muhaha has joined #openwrt-devel
gromero has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
<grift>
linux 5.10 looks to work nicely on my wrt1900acs, dmesg looks ok theres 2 messages about how cpu hotplug and cpu idle are currently broken but otherwise looks normal
<rsalvaterra>
grift: Awesome! B)
<grift>
thanks for that
<rsalvaterra>
Yeah. Hotplug, idle and frequency scaling are basically broken. Hardware bugs, I guess.
guimo has left #openwrt-devel [#openwrt-devel]
Tapper has quit [Ping timeout: 240 seconds]
Tapper has joined #openwrt-devel
falk0n has quit [Ping timeout: 272 seconds]
falk0n has joined #openwrt-devel
falk0n has quit [Ping timeout: 256 seconds]
falk0n has joined #openwrt-devel
MichaelOF has quit [Quit: Konversation terminated!]
Darkmatter66 has joined #openwrt-devel
JMV2009 has joined #openwrt-devel
<philipp64>
russell--: it's defined in linux-5.4.99/include/crypto/hash.h ... What kernel are you building?
<JMV2009>
Worked on bluez-pulseaudio before. I don't think it works now. : [pulseaudio] ltdl-bind-now.c: Failed to open module module-bluetooth-discover.so: Error loading shared library module-bluetooth-discover.so: No such file or directory
<plntyk>
some pulseaudio modules might not be compiled or need extra package
<plntyk>
pulseaudio with bluetooth is kind of messy
<plntyk>
discover needs avahi
<plntyk>
probably
<Borromini>
russell--: did you get the chance to test 5.4.100 on your dir-860l?
<Borromini>
wondering if that instability issue is back.
<lipnitsk>
zx2c4: thanks, LGTM. I pushed a minor rename (duplicate 082-... patch in 5.10 backports)
<plntyk>
JMV2009, maybe try to recompile without -Dbluez5=false as build switch - it was added in update to 13.0
shibboleth has joined #openwrt-devel
<JMV2009>
plntyk: probably
zkrx has quit [Ping timeout: 240 seconds]
<zx2c4>
lipnitsk: super
<blocktrron>
lipnitsk: looking at the buildbots if we broke something
<blocktrron>
Looks like p1010 is under the wheels now
<blocktrron>
WDR4900 failed due to missing space on the kernel partition
<lipnitsk>
oh so some stuff was added that pushed it over the limit?
<blocktrron>
yes
<lipnitsk>
yeah, I didn't clause everything with LINUX_5_10
<lipnitsk>
maybe that's the problem?
<blocktrron>
But we were driving on tens of KB with that board anyway
<blocktrron>
So this was set to happen with 5.10 anyways
<blocktrron>
so it's fine
<lipnitsk>
ok
<blocktrron>
I'll just push a patch to disable the wdr4900
<lipnitsk>
okay, thanks, glad it's just a bloat fail (well, not really glad, but still)
<blocktrron>
We've had the discussion around 2 years ago
zkrx has joined #openwrt-devel
<blocktrron>
nobody cared to come up with a proper fix in the meantime
<blocktrron>
So let's move forward
<Borromini>
btw is ipq80xx a DSA target?
muhaha has quit [Quit: Connection closed]
JMV2009 has quit [Quit: Ping timeout (120 seconds)]
<Hauke>
svanheule: Borromini I will backport the changes to 21.02, but I think b5bc53813d is not needed as we do not want to support the realtek target in 21.02
<Borromini>
Hauke: i was keeping quiet since i wasn't sure if opinions had changed or not :^)
<Hauke>
enyc: I was not aware of this problem with the ath10k-ct firmware
<Hauke>
enyc: I do not have the time to debug this, but it would probably help to know since when this problem happens
<adrianschmutzler>
Hauke: we should decide about realtek at some point
<enyc>
hurricos: understand makefiles in principle and cound proabbly successuflly manage. Docker no, but happy to learn.
<hurricos>
it's got some hard-coded trees though
<hurricos>
ah, ok
<enyc>
hurricos: used to chroots and dpkg-buildpackage and all of that
<hurricos>
s/trees/filesystem paths/
<hurricos>
That bit I don't know about :^)
<enyc>
hurricos: are you saying there isn't an archive of downloads snapshots builds I could just 'use' ?
<hurricos>
they get cleaned I expect? It's more than a few gigs of artefacts ...
<enyc>
ok
<hurricos>
if you use that project above
<hurricos>
Well, actually, don't. It presupposes you know how to set up docker and possibly increase default volume size
<hurricos>
:Cc
<enyc>
in any case, why all this commit fun, couldn't I just swap aut the ath10k-firmware opkg or at leath the underpinning /lib/firmware/ etc file?
<hurricos>
but other than that you could clone that down onto a fresh machine under /devel/docker and literally just do `make built/openwrt-builder-$commit.sentinel`
<hurricos>
enyc: Kernel vermagic changes if you breathe on it
<hurricos>
you could possibly do the latter
<hurricos>
opkg's are just compressed .tar's, I think vaguely similar to how debian does it
<hurricos>
you could similarly git log `linux-firmware` and find the versions of *ct fw
<hurricos>
and checkout those and then copy them where you need.
<hurricos>
problem is driver<->fw may not play nice together necessarily
<hurricos>
just for Jan probably fine.
<enyc>
in any case, which firmware commit !?!?!?!
<ynezz>
Hauke: what about gcc version bump? :)
<hurricos>
Clone down linux-firmware tree from Torvdalds and git log the actual file you're looking at.
<hurricos>
it'll show you the commit that exist and approx when they endd up in OpenWrt. Probably.
<ynezz>
Hauke: I think, it's about time to switch
<hurricos>
there's ike 20 versions max
<hurricos>
ynezz: you folks love bleeding edge don't you :^)
Borromini has quit [Ping timeout: 260 seconds]
<ynezz>
well gcc10 is more then year old, no edge anymore
<Hauke>
ynezz: Yes I would like to use GCC 10 in master
<Hauke>
and musl 1.2
<ynezz>
so lets break it all at once or incrementaly? :p
<ynezz>
first gcc, then when dust settles bump musl?
<Hauke>
I would prefer to wait with gcc 10 till we have 21.02-rc1 or rc2
<hurricos>
Borromini: got the ports to come up on my P2041 :D
<hurricos>
ynezz: kidding :^) it's good practice
<hurricos>
I like knowing when my things are going to be broken
<Hauke>
till then we could see some bugs in master
<Hauke>
and then about 3 weeks after the gcc 10 update do the musl 1.2 update
<hurricos>
and the only way to know is to be on newer gcc, of course
<rsalvaterra>
Woohoo! Break^W Update it! \o/
<hurricos>
thanks you all for keeping it up
<rsalvaterra>
I don't know about musl, but gcc 10 is building all my images just fine.
<Hauke>
I think mangix prepared there some patches for gcc 10 and musl 1.2
<rsalvaterra>
(And has been for months.)
<hurricos>
nah, I just mean that in principle things can only break by being changed and they're going to have to change eventually
<ynezz>
Hauke: sounds like a plan
<Hauke>
ynezz: what is missing for 21.02-rc1?
<rsalvaterra>
Hauke: Well, the patch I sent you yesterday, fixing the Omnia would be nice… ;)
<Hauke>
jow: what is the status of DSA in LuCi? ;-)
<ynezz>
I'm not aware about anything blocking rc1 apart from luci/dsa
<Hauke>
rsalvaterra: Is this patch also needed for kernel 5.10?
<rsalvaterra>
Hauke: The three patches are already in 5.10, as part of the bringup I did.
<Hauke>
rsalvaterra: nice
<ynezz>
rsalvaterra: what's wrong with omnia in 21.02?
<hurricos>
I'm moving back over to Gitlab. Friend of mine convinced me the lab didn't need our own instance
<hurricos>
but knowing that you can selfhost all your runners / ci stuff
<ynezz>
it's based on labgrid, you don't even need gitlab for that
<hurricos>
this stuff is just too good
<hurricos>
yeah
<ynezz>
but I find it convenient for public consumption
<ynezz>
and colaboration
<hurricos>
oh
<hurricos>
This was actually what I was looking for!
<hurricos>
looking at those yamls ... am I to draw from this, as someone who knows nothing about pytest
<Tapper>
Just to let people know I have building for all my routers with gcc10 for a long time now and have no probs. The routers are r7800 wrt3200acm c7v2 wdr3600 1043nd and wdn750.
<philipp64>
pintyk: thanks will look shortly.
<hurricos>
... never mind. I've needed this badly and not sure how I'd not stumbled on it earlire. Thanks ynezz
<russell-->
philipp64: 5.4.99 on ath79
<Hauke>
ynezz: Do you have some documentation and code on how to duplicate your test setup?
philipp64 has left #openwrt-devel [#openwrt-devel]
<russell-->
Borromini: i haven't tested 5.4.100, most recent i've flashed is 5.4.99
<Hauke>
hurricos: tahnks
<hurricos>
well, not the duplicate part. But that bit is what I already do anyways - hook a bunch of stuff over serial to a host with storage and copy builds to the host and tftpboot from it
<ynezz>
Hauke: I plan to document it once it's past the proof-of-concept stage, when I've like 8 devices included
<hurricos>
it's very shallow though, pick a device and trace it and you'll see
<hurricos>
oh yeah, can it do power? I mean ... it can obviously, but I'm wondering about faulty esp switches I use
<Hauke>
ynezz: nice
<hurricos>
which work only 9 times out of ten ;(
<Hauke>
hurricos: I am also using a power switch with an ESP
<Borromini>
russell--: ok
<hurricos>
oh
<hurricos>
err, mine's WiFi. perhaps I should get something better.
<Hauke>
hurricos: I am also using a wifi one china
<hurricos>
`ssh`?
<ynezz>
labgrid has bunch of drivers, check list
<hurricos>
oh
<ynezz>
it's simple gpio relay :)
<Hauke>
it should be possible to add supprot for them pretty easily if it is not already there
<Hauke>
it supports mqtt and http
Acinonyx has joined #openwrt-devel
<hurricos>
Yeah, it's `http` curls that always fail for me, I was figuring it was an ARP cache issue since it's usually only when I open my laptop to turn on the lights
<hurricos>
anyways
<hurricos>
details
<hurricos>
it comes up a lot, faulty serial cables. But if you can shim drivers here then you can handle that type of thing.
<hurricos>
e.g. I saw some `expects` in the first link
<Hauke>
hurricos: you can check the status, that matches the real status for me
Acinonyx_ has quit [Ping timeout: 264 seconds]
<hurricos>
or if you have a u-boot with a really poor interrupt handler which drops every 238th character and need a way to recover
<hurricos>
but ultimately if you can automate most of it you can debug those issues very easily as they come up too.
<hurricos>
It's a different world out there o_o ....
<ynezz>
yeah, uarts and uboots is the most time consuming part :p
<hurricos>
lol ow
Borromini has quit [Quit: Lost terminal]
linzst has quit [Ping timeout: 240 seconds]
mwalle has quit [Ping timeout: 260 seconds]
<lipnitsk>
blocktrron: so was it an image too large error or that initramfs thing? Or both?
<russell-->
philipp64: same thing happens on 5.10.18
Snowblind has quit [Ping timeout: 272 seconds]
Snowblind has joined #openwrt-devel
dangole has joined #openwrt-devel
<lipnitsk>
blocktrron: also, thanks for fixing PKG_MIRROR_HASH - must be because I forgot to refresh it after updating PKG_SOURCE_DATE
<Grommish>
philipp64: Are you statically linking your x86_64 locally? That's a static v dynamic linking error it looks like
<philipp64>
Grommish: I can't think of anything that I'm doing locally that would diverge from what CI/CD does, but maybe I'm overlooking something obvious...
<hurricos>
the question is why fPIC isn't default
<Grommish>
Hey Hurricos :)
<hurricos>
locally you *should* see that first compile line as -fPIC
<Grommish>
philipp64: Well, I ask because is the buildbot dynamically linked by default?
<Grommish>
maybe a toolchain difference?
<philipp64>
hurricos: I was just thinking that too...
<hurricos>
everything is, but -fPIC protects you when making big jumps to shared libs
<hurricos>
it could be a microarchitectural difference. no cross compilation there if you're on x86
<Grommish>
Do targets support fPIC?
<hurricos>
so `lscpu` on the remote host
<Grommish>
err all targets I mean
<philipp64>
going to try something stupid, i.e. adding: TARGET_CFLAGS += $(FPIC) to net/strongswan/Makefile
<Grommish>
It's not stupid if you can revert it easy enough;p
<hurricos>
philipp64: That first compile line on remote should have -fPIC on local
<hurricos>
both net/strongswan/Makefile's are identical, so why the difference?
<hurricos>
that's what you want
<philipp64>
a lot of packages (like net/net-snmp) set it unconditionally, which seems sane.
<hurricos>
so yeah, settig it unconditionally seems sane. The opposite is sometimes considered an error
<philipp64>
hurricos: package/libs/gmp/Makefile contains TARGET_CFLAGS += $(FPIC) ... so I think the issue is when strongswan gets built without that...
<russell-->
my main point is that if xtables-addons relies on the kernel having built with kmod-crypto-hash (=m is enough), the build system should probably be selecting that somehow
<hurricos>
Yeah, I was just wondering why there would be a difference between your two hosts as to which option would be selected
<hurricos>
or rather, assuming there is one, verifying that assumption, etc.
DirkS has quit [Ping timeout: 260 seconds]
<hurricos>
Sorry ... I'm basically just telling you exactly what you tell me like emacs doctor mode at this point.
<philipp64>
though... gmp configures with --enable-shared --enable-static... whereas strongswan configures with --disable-static
<philipp64>
russell--: from what I can tell, on my system it gets defaulted, because it's definitely not in my env/kernel-config
<philipp64>
no, wait, it gets inherited explicitly from the target/linux/x86/config-5.4
<russell-->
yes, that's what i said above
<russell-->
but only on 32 of 63 config-5.4, not all targets
<philipp64>
but... you're building x86 for alix2...
<philipp64>
so you should be covered.
<russell-->
ath79
<philipp64>
odd that you're not.
dangole has quit [Remote host closed the connection]
<russell-->
12:35 russell--: philipp64: 5.4.99 on ath79
dangole has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
DirkS has joined #openwrt-devel
rmilecki has quit [Ping timeout: 240 seconds]
dangole has quit [Ping timeout: 272 seconds]
<philipp64>
sorry, missed that. can you set CRYPTO, CRYPTO_HASH, and CRYPTO_HASH2 explicitly and rebuild?
<Tapper>
Hi are the packages in 21.02 the same as what are in master at the mo?
<Tapper>
moment*
<Tapper>
Or is the a 21.02 package branch?
<pkgadd>
no, the feeds have also been branched off at the same time as the main repo - with backports happening on a case-by-case basis; obviously they are still rather similar
<Tapper>
OK thanks. I have switched to the 21.02 branch on the r7800 for testing.
<Tapper>
I'm going to stick with the 21.02 branch for a wile now until master settles down a bit.
<pkgadd>
Hauke: feel free to take anything you like from https://github.com/openwrt/openwrt/pull/3860 for your gs1900-8 patches, I think the specifications part would augment the commit message nicely