ianchi has joined #openwrt-devel
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]
<owrt-2102-builds> build #9 of mpc85xx/p1010 is complete: Exception [exception dlfindbinpl df ccachestat] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mpc85xx%2Fp1010/builds/9 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
<owrt-snap-builds> build #816 of tegra/generic is complete: Exception [exception dlfindbinpl df ccachestat] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/816 blamelist: Rosen Penev <rosenp@gmail.com>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Daniel Golle <daniel@makrotopia.org>,
<owrt-snap-builds> Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>, Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>, Rui Salvaterra <rsalvaterra@gmail.com>, Sander Vanheule <sander@svanheule.net>, Stijn Segers <foss@volatilesystems.org>, Shiji Yang
<owrt-snap-builds> <yangshiji66@qq.com>, DENG Qingfang <dqfext@gmail.com>
hbug___ has joined #openwrt-devel
hbug__ has quit [Ping timeout: 268 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
ianchi has quit [Quit: Connection closed for inactivity]
<russell--> fyi: xtables-addons build is failing for me
<russell--> ERROR: "crypto_alloc_shash" [/home/openwrt/src/lede/build_dir/target-mips_24kc_musl/linux-ath79_generic/xtables-addons-3.13/extensions/pknock/xt_pknock.ko] undefined!
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.)
<aparcar[m]> lipnitsk: ping
<lipnitsk> hey
<lipnitsk> haven't quite gotten to that script yet, maybe in an hour or so?
<aparcar[m]> sure just wanted to make sure I did not miss the PR
<lipnitsk> nope, was busy
<aparcar[m]> no stress
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
<lipnitsk> aparcar: ping
<aparcar[m]> lipnitsk: pong
<aparcar[m]> ack
<lipnitsk> still has a temp commit
<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.
<aparcar[m]> if you developed a taste for CI, please check https://github.com/openwrt/packages/issues/14870
<lipnitsk> fun
<lipnitsk> don't know if I like it that much :)
<lipnitsk> how frequent is that issue?
<lipnitsk> or rather, how often does it result in failures? Or does it cause CI to miss checks?
<mangix> lipnitsk: most people that backport PRs are the turris people. They're competent.
<mangix> Backporting is not something typically done.
weijie has quit [Quit: Ping timeout (120 seconds)]
weijie has joined #openwrt-devel
nitroshift has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
Ivan__83 has quit [Quit: Miranda NG]
<russell--> something in the xtables-addons package required kmod-crypto-hash, but it isn't configured in for some reason
goliath has joined #openwrt-devel
<russell--> fudged by CONFIG_kmod-crypto-hash=m, this seems like a regression somewhere
ldir has left #openwrt-devel ["Bat!"]
<mangix> hmm I'm getting spam for some reason
<Grommish> ?
<russell--> freenode spam? /mode russell-- +R
<mangix> nah. random freenode accounts messaging me with completely random messages
<Pepe> Maybe they are trying to check if you are using screen and crash your instance like they are doing that for Minecraft servers?
<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 ...
<guidosarducci> russell--: thanks for verifying iproute 5.11. Are you otherwise OK with https://github.com/openwrt/openwrt/pull/3904?
<russell--> guidosarducci: yes, looks fine to me
<guidosarducci> Damn conspiracy theory spam...
<guidosarducci> russell--: great, thanks. I'd like to see this as the baseline for 21.02 too, it should be clean.
<rsalvaterra> Ouch… iproute is getting really fat…
koniu has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
koniu has joined #openwrt-devel
<guidosarducci> rsalvaterra: most things just got skinnier due to dropped dependencies
<russell--> the default ip command comes from busybox iirc
<guidosarducci> and the ip-tiny from iproute2 has been manually gutted to reduce size
<rsalvaterra> Yeah, I only use ip from BusyBox, ever since I fixed wireguard-tools to not depend on ip-tiny… but I need tc for sqm-scripts. :)
<guidosarducci> rsalvaterra: and there's no "light" version of tc. What would you drop: filters, classes, or qdiscs? :-)
<ynezz> (Re: 5.10 LTS Kernel: 2 or 6 years?)
<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?
<owrt-2102-builds> build #9 of lantiq/xway is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/lantiq%2Fxway/builds/9 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Daniel Gonz?lez Cabanelas <dgcbueu@gmail.com>
<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 ;-]
<owrt-snap-builds> build #774 of apm821xx/nand is complete: Failure [failed gcc] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/774 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
<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.
Borromini has joined #openwrt-devel
<karlp> the line truncation is the biggest source of wtf noise though
<adrianschmutzler> probably I will have to look at the quilt source
<karlp> I can live witht he other mangling just fine
<karlp> but the line truncation genuinely makes the patches worse.
<mangix> I am not a fan of the truncation either.
<karlp> but you went ahead with it anyway?
<karlp> even with ones that didn't do any truncation, you removed irreelvant htings, with no refresh, in things like https://github.com/openwrt/packages/commit/5d8d4fbbcb5c5de9370711c19bb3510210989a98#diff-424aeb52001f2adea4b697d7ee2b37cebec68ac87936f1700c7bd8a3be2be5c1L12
<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> Everything but 100-* moved over clean
<Grommish> It had been upstreamed
<Grommish> and it says it built
Ycarus has joined #openwrt-devel
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
<Borromini> :^)
<Grommish> I almost want to test this ;p
<Borromini> haha
<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
<lipnitsk> blocktrron: uh oh - the kmod PR?
<blocktrron> yup
<blocktrron> let me check
<lipnitsk> do you have fail link?
<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
* Borromini is in favour of keeping it in 21.02
JMV2009 has joined #openwrt-devel
Borromini has quit [Ping timeout: 260 seconds]
victhor_ has joined #openwrt-devel
<owrt-2102-builds> build #14 of ath25/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath25%2Fgeneric/builds/14 blamelist: Daniel Golle <daniel@makrotopia.org>
victhor has quit [Ping timeout: 240 seconds]
Borromini has joined #openwrt-devel
victhor__ has joined #openwrt-devel
victhor__ is now known as victhor
victhor_ has quit [Ping timeout: 240 seconds]
<philipp64> anyone have a template .xml file for qemu/libvirt on CentOS to run an x86_64 UEFI guest?
<philipp64> indeed, what about creating a directory in the repo and storing such information for testing, etc?
Tost has joined #openwrt-devel
<plntyk> probably separate repo is better - uefi guest requires OVMF firmware package installed
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<plntyk> philipp64, added uefi cmdline for qemu on https://openwrt.org/docs/guide-user/virtualization/qemu
<plntyk> with libvirt you simply select uefi in virt-manager when creating new machine
<philipp64> OVMF is usually part of the platform (host) packaging...
<philipp64> why, have you gotten it to work?
dedeckeh has joined #openwrt-devel
<plntyk> on archlinux host i am running several uefi-enabled guest images
<plntyk> even some uefi-applications do work in qemu
<philipp64> can you paste your XML?
<plntyk> philipp64, https://paste.debian.net/1186804/ for example
<plntyk> with cmdline qemu you can map a normal folder to a fat drive - dunno how syntax is in libvirt
<Hauke> svanheule: Borromini backprot is done
<svanheule> Hauke: thanks!
<Borromini> Hauke: thanks a lot.
<enyc> Hauke: ok, how would I get back-versions of master or so to test? I have at least one older device...
<enyc> [which has jan-ish master on it, would need to check problem NOT happening there]
<enyc> then somehow 'work forwards'
<Hauke> enyc: you could try to revert a commit updating the ath10k-ct firmware to just use a older version
<Hauke> when did this work the last time?
<enyc> Hauke: i'm not yet a git-voodoo / bulding my own, have been using Master builds or 21.02SNAPSHOT builds as downloads.openwrt.org provides
<enyc> Hauke: I would need to check but I believe i wasn't having toruble with ~january-ish master build
<blocktrron> aparcar[m]: "build/json: generate json file for initramfs" broke mpc85xx-p1010, can you check that?
<hurricos> enyc: are you good at Makefiles and Docker?
<hurricos> If so, I have https://git.laboratoryb.org/hurricos/docker-builder that gives Makefile recipes to build a Docker image of the builder and then build a particular config at a particular commit
<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?
<ynezz> cosmetic stuff :p
<rsalvaterra> It's not in 21.02, it's all the way back to 18.06.
<ynezz> 18.0 is EOL
<ynezz> 18.06
<rsalvaterra> I know it's EOL, but the IRQ storm was there. :P
linzst has joined #openwrt-devel
<rsalvaterra> ynezz: Do you have an Omnia to test? :)
<ynezz> are you scared to open gitlab.com javascripts in your browser?
<rsalvaterra> Uh? What do you mean?
<ynezz> [x] Turris Omnia with 21.02 snapshot on initramfs 5 hours ago
Borromini has joined #openwrt-devel
<olmari> spooky... be afraid, be ver yafraid ;P
<rsalvaterra> Oh, three of them? o_O
<rsalvaterra> Sorry, hadn't scrolled down… XD
<rsalvaterra> ynezz: See if you can find this on your Omnias' dmesg… ;)
<rsalvaterra> [ 1.523761] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
<rsalvaterra> Before my patch, of course. :P
<ynezz> that logread log contains dmesg
<rsalvaterra> Nope! Can't find it. :D
<hurricos> ynezz: You have physical machines set up to grab from your gitlab ci pipeline?
* rsalvaterra admits not being very GitLab-literate yet…
<hurricos> ... that's obviously what I'm looking at and I'm jealous
<zorun> nice setup
<hurricos> curl registry.gitlab.com/ynezz/openwrt-device-runtime-testing/testbed<RET> >:(
<ynezz> hurricos: thats for docker
<hurricos> I know, registry :'(
<hurricos> You have literally everything setup
<hurricos> just curious about the dockerfile used for your base .... builder image? wait
<hurricos> that's ...
<ynezz> it's in that repo
<hurricos> thanks
<hurricos> Yeah, OK. I'm sold
<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?
<hurricos> Hauke: It's all there, orchestrated as a gitlab runner: see https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/blob/master/.gitlab-ci.yml
shibboleth has quit [Quit: shibboleth]
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
zatwai has joined #openwrt-devel
<Hauke> ynezz: my frsit task would be to get labgrid running here with my hardware
<Hauke> boards, power switch, ....
philipp64 has joined #openwrt-devel
<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
<philipp64> russell--: I'm building master on x86_64 just fine... wondering what the differences might be?
JMV2009 has quit [Quit: Connection closed]
<russell--> are you compiling xtables-addons?
<russell--> check your .config and see if something else is pulling in kmod-crypto-hash
<rsalvaterra> Hauke: Now for something completely different, I want to add pause frame configuration to devices in /etc/config/network. :P
<rsalvaterra> Something like: option pause 'autoneg off rx off tx off', for example.
<philipp64> Does your linux build with CONFIG_CRYPTO_HASH2 ?
<rsalvaterra> The motivation is obvious: flow control interacts badly with SQM.
<Hauke> rsalvaterra: would be a nice feature
<rsalvaterra> I don't exactly like the configuration suggestion, but that's a bikeshed for some other time, I guess.
<philipp64> besides xtables_addons, there are dozens of things that depend on kmod-crypto-hash
<philipp64> russell--: what does "make menuconfig" tell you about it?
<philipp64> russell--: on my system, https://paste.ubuntu.com/p/Gx2bcF3x9t/
<philipp64> also: target/linux/x86/config-5.4:CONFIG_CRYPTO_HASH2=y
<philipp64> russell--: and https://paste.ubuntu.com/p/BbghJBCQzN/
<russell--> kmod-crypto-hash is selected on x86 (e.g. on my alix2 build)
<russell--> 32 of 63 of the config-5.4 files have CONFIG_HASH=y (e.g. with "find target/linux -name config-5.4 | xargs grep CRYPTO_HASH=" )
<blocktrron> lipnitsk: it's the initramfs
<blocktrron> I've misread the log and pretty much stopped reading at wdr4900 file not found
<aparcar[m]> blocktrron: will do
<blocktrron> aparcar[m]: i have a fix already
<aparcar[m]> blocktrron: lovely, thanks
<philipp64> russell--: if you have CRYPTO==y && CRYPTO_HASH==y then CRYPTO_HASH2=y
<philipp64> anyone want to venture why CI/CD is seeing https://paste.ubuntu.com/p/YTs5f9Yzc7/ ... but I don't see this when I build?
<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> phiplipp64: What's the env on the CI?
<hurricos> is it Alpine?
<hurricos> (based)
<ynezz> hurricos: https://git.openwrt.org/?p=buildbot.git;a=blob;f=docker/buildslave/Dockerfile;h=9ee3ae40fc29707b3c2853fb37ea3e3064929909;hb=HEAD
<hurricos> and your local's also debian or rhel eh?
<hurricos> yeah -fPIC that, ... it seems sane. I just don't think assuming is a good idea
<hurricos> otoh, if it's not sane :^) ....
<philipp64> hurricos: no, I'm not that adventuruous.... ubuntu-20.04-2
<hurricos> also I brazenly stole all I know about this in the last 100 seconds from https://stackoverflow.com/q/16575877
<philipp64> fingers crossed for https://github.com/openwrt/packages/pull/14890
<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?
<philipp64> pintyk: not sure what's going on... I'm using https://paste.centos.org/view/895c735f and it boots then hits 100% but there's no output...
protodave has quit [Quit: ZNC - https://znc.in]
protodave has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
Darkmatter66 has quit [K-Lined]
pkgadd has quit [Quit: leaving]
black_ant has quit [Ping timeout: 240 seconds]
pkgadd has joined #openwrt-devel
<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