<lipnitsk> does parallel not work with it for whatever reason?
shibboleth has quit [Quit: shibboleth]
swex_ has joined #openwrt-devel
swex has quit [Ping timeout: 240 seconds]
<blocktrron> lipnitsk: successfully built mpc85xx-* as well as ath79-generic on 5.4 as well as 5.10 with the changes in my staging tree.
<blocktrron> I'll add some proper commit descriptions / squash them to your patches and apply them tomorrow evening
<lipnitsk> Great, thank you!
<blocktrron> :)
mmlb has quit [Quit: Ping timeout (120 seconds)]
mmlb has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
black_ant has quit [Ping timeout: 260 seconds]
koniu has quit [Remote host closed the connection]
Grommish___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Grommish has joined #openwrt-devel
madwoota has quit [Quit: .]
madwoota has joined #openwrt-devel
madwoota has joined #openwrt-devel
madwoota has quit [Changing host]
<philipp64> mangix: can I DM you?
<philipp64> lipnitsk: if you can fix the parallel build for a lot of these projects and upstream the fixes, then everyone wins...
<lipnitsk> philipp64: yeah, maybe I'll peek at it (haven't looked at all yet). Chances are it's some hornet's nest otherwise maybe it wouldn't have been a problem in the first place..
<philipp64> my recollection is that automake generates parallel-safe builds...
<lipnitsk> what do you mean by a lot of these projects?
<philipp64> but... not everyone uses autotools.
<lipnitsk> which ones are misbehaving to your understanding?
<lipnitsk> it's not just gettext?
<philipp64> libtool, uci, libxml2, mdnsresponder... freeswitch... there are a few.
<philipp64> might be more. just did a search but it wasn't exhaustive.
hbug__ has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
hbug_ has quit [Ping timeout: 268 seconds]
silverwhitefish has joined #openwrt-devel
<lipnitsk> philipp64: what did you search for? PKG_BUILD_PARALLEL:=0 ?
<philipp64> yes
<lipnitsk> yeah, probably set to 0 for good reason ;) funnily enough gettext-full does have it set to 1
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
* enyc ponders what https://github.com/greearb/ath10k-ct/issues/178 means for OpenWRT 21.02 .... switch away from -ct firmware? try to get it figured out further?
victhor has quit [Ping timeout: 246 seconds]
<Namidairo> using the same hardware on my archer c5 and I don't see the same thing
<Namidairo> wonder if it's environment or specific to certain devices
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.)
<owrt-1907-builds> build #273 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/273
<owrt-snap-builds> build #864 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/864
<mangix> philipp64: nope. parallel compilation for autotools is an afterthought. just like make
<mangix> it's possible but not by default
<mangix> meson is parallel by default. I don't think you can turn it off.
<owrt-snap-builds> build #798 of layerscape/armv8_64b is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/798 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
<enyc> Namidairo: hrrm... ok can you put that on the above ticket? Should there be an openwrt tracking bug to look into before release or otherwise?
<enyc> Namidairo: in one case, 3* SSIDs on 5ghz (ath10k) and also 2* SSIDs on 2.4ghz (ath9k) .... but nothing too onerous!
<enyc> Namidairo: will try to see if older logs/versions make apparent where it maybe used to work....
<enyc> Namidairo: thinking about it i have identical router with similar slightly-older config and older master build, I can swap that in and fix its' update config..., get info on ath10k versions etc.
rmilecki has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
nitroshift has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
<aparcar[m]> mangix: ping
Darkmatter66_ has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel
mattsm has quit [Ping timeout: 246 seconds]
<guidosarducci> aparcar[m]: in addition to the OWRT build automation, do we support any type of automated run-time testing? e.g. kernel self-tests or home-brewed
<mangix> aparcar[m]: pong
dedeckeh has joined #openwrt-devel
<aparcar[m]> mangix: I'm thinking how to detect best modified packages
mattsm has joined #openwrt-devel
<aparcar[m]> currently it only detects changes in Makefiles/test.sh
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<aparcar[m]> but since we now have AUTORELEASE modifications to makefile are not always required.
<aparcar[m]> it's not always package/<packagename>/<changes>
<aparcar[m]> but sometimes package/<top folder>/<packagename>/<changes>
<aparcar[m]> guidosarducci: not so far, we could run some qemu images I guess via an CI
<guidosarducci> aparcar[m]: that's what I was thinking too. we have malta, armvirt and x86, that together cover *a lot* or archs, word sizes, and endianness space
<aparcar[m]> guidosarducci: well do you have experience with those setups? maybe we can setup something
<lipnitsk> aparcar: there is also the case where pkg name != folder name
<guidosarducci> guidosarducci: not really, I've set up my own ad-hoc tests for packages I care about, but using upstream tests would be better
<aparcar[m]> lipnitsk: treason! which package?
<lipnitsk> one example is protobuf-c (pkg name is libprotobuf-c)
<guidosarducci> aparcar[m]: I worry that (as usual) much of the testing infra doesn't play well with cross-compilation/embedded stuff. Would need to look at it carefully.
<aparcar[m]> guidosarducci: it kinda works well at this point, qemu is kinda mounted and then the arch specific packages are run
<aparcar[m]> what runtime tests are you thinking of?
<guidosarducci> aparcar[m]: I meant the upstream's testing infra. Things like kernel self-tests on the networking side, BPF, etc.
<aparcar[m]> lipnitsk: ugh awkward. what do you suggest
<guidosarducci> aparcar[m]: even a basic runner based on QEMU would be a good start. There are some simple tests like "modprobe test_bpf" that already exist (and I've packaged the module)
<lipnitsk> aparcar: one way could be to grep for "PKG_NAME.*:=" while walking directories up, until you hit one match
<guidosarducci> aparcar[m]: I just don't understand enough of what exists for OWRT testing to gauge what's possible...
<aparcar[m]> guidosarducci: kernel stuff seems difficult with the current setup as it's within a docker setup. but we can run the full redis upstream tests for example
<aparcar[m]> anything not kernel related should work
<guidosarducci> aparcar[m]: redis? For kernel stuff could we not simple parse for output as usual?
<lipnitsk> aparcar: actually wait, you want the directory name, not PKG_NAME, since that's what make uses
Darkmatter66 has quit [Read error: Connection reset by peer]
<lipnitsk> some clever way to find where the Makefile is then get the dirname where it's in?
<lipnitsk> or find all Makefiles, then take off the Makefile part and match that path to what git said changed?
Darkmatter66 has joined #openwrt-devel
<aparcar[m]> lipnitsk: you want to do the thinking?
<lipnitsk> dunno. It's getting late here
<lipnitsk> Let me try.
<aparcar[m]> lipnitsk: I can also come up with something
<lipnitsk> give me a few min
<aparcar[m]> guidosarducci: do you have actual machines for testing?
<guidosarducci> aparcar[m]: I do my local stuff on an ubuntu box and another VM box. Is that what you mean?
<aparcar[m]> guidosarducci: I'll think of something
<aparcar[m]> lipnitsk: ping me if you figured something out, thanks for the nightshift
<guidosarducci> aparcar[m]: Thanks. BTW, some simple, concrete targets I was thinking of was: 1. self-contained test script, 2. iproute2 "make check", and 3. "modprobe test_bpf". Appreciate if you have some good pointers to how our current testing is set up.
<lipnitsk> aparcar: https://pastebin.com/8sFjtbAr
<lipnitsk> aparcar: inefficient, but works, I think ;)
<lipnitsk> assumes you are in root of repo. if not, some argument to find is needed
<lipnitsk> I'm sure it could be done faster with awk or something, so feel free to improve.
<guidosarducci> blocktrron: ping
<aparcar[m]> guidosarducci: all right I'll think about something
user| has quit [Quit: quit]
guimo has quit [Remote host closed the connection]
guimo has joined #openwrt-devel
<guidosarducci> aparcar[m]: cheers!
user| has joined #openwrt-devel
<lipnitsk> aparcar: I can make it into a PR tomorrow and test with CI
MichaelOF has joined #openwrt-devel
<aparcar[m]> lipnitsk: oh great please do
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
valku has quit [Remote host closed the connection]
ivanich has joined #openwrt-devel
Tost has joined #openwrt-devel
zatwai has quit [Ping timeout: 258 seconds]
<owrt-snap-builds> build #732 of lantiq/xway is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/732
<owrt-snap-builds> build #739 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/739
adrianschmutzler has joined #openwrt-devel
goliath has joined #openwrt-devel
Borromini has joined #openwrt-devel
sbrown__ has quit [Remote host closed the connection]
sbrown__ has joined #openwrt-devel
Dracos-Carazza has quit [Remote host closed the connection]
Dracos-Carazza has joined #openwrt-devel
adrianschmutzler has quit [Ping timeout: 240 seconds]
llange has quit [Ping timeout: 240 seconds]
adrianschmutzler has joined #openwrt-devel
llange has joined #openwrt-devel
adrianschmutzler has quit [Client Quit]
adrianschmutzler has joined #openwrt-devel
<Pepe> Btw channel topic is outdated as 19.07.7 was released
<Pepe> aparcar[m]: and there are no Docker images for sdk and rootfs for that version
<ynezz> both missing steps are documented https://openwrt.org/docs/guide-developer/releases/release-process but we still fail to execute them :)
<ynezz> maybe we need to convert it to some kind of task list with [x] ticks or such
<ynezz> this is a moment where I miss some usable issue system, where we could create ticket with all the tasks so the state tracking would be much easier
<rsalvaterra> Heh… I had to use lipnitsk's big hammer, but at least I now have WireGuard on 5.10, on my Omnia. :)
<owrt-snap-builds> build #735 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/735
victhor has joined #openwrt-devel
<rsalvaterra> zx2c4: How do I know which of the algorithms (scalar or NEON) are being used in WireGuard? I see them in /proc/crypto, but with refcnt at 1 (as WireGuard uses the libraries directly, not the crypto API, right?)…
<plntyk> dunno what "useful output" means
<rsalvaterra> Hmm… I'd like to avoid building with debug support… :P
<adrianschmutzler> rsalvaterra: I don't understand the changes to files-* in the mvebu patchset
<adrianschmutzler> Which files have actually been upstreamed?
<owrt-snap-builds> build #768 of omap/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/768
<adrianschmutzler> Just a few espressobins as it appears?
<rsalvaterra> adrianschmutzler: Yeah, git made a bit of a mess, it's not obvious from the diffstat.
<rsalvaterra> So, files/ is common to all kernel versions, files-5.4/ is specific to the 5.4 kernel version, correct?
<adrianschmutzler> so, espressobin-emmc, -v7 and -v7-emmc are upstreamed?
<rsalvaterra> Yes, those are upstreamed.
<adrianschmutzler> rsalvaterra: yes, files/ is common, so your copying of files/ to files-5.10/ does not make much sense ;-)
<adrianschmutzler> But I will probably just fix that myself
<rsalvaterra> It does when you don't want to make big mistakes (and I did :P).
<rsalvaterra> So, I first made sure I had files-5.4/ and files-5.10/. Only then I started factoring things into files/.
<rsalvaterra> As files-5.10/ ended up empty, I removed it.
<adrianschmutzler> then it's probably just not distributed well over the patches
<adrianschmutzler> anyway, as we see files might need special treatment
<rsalvaterra> You're the fan of small steps at a time… ;)
<rsalvaterra> (And I am too.)
<adrianschmutzler> btw, how did you do kernel_oldconfig now? (which commands/sequence?)
<rsalvaterra> 1) make kernel_oldconfig
<rsalvaterra> 2) make kernel_oldconfig CONFIG_TARGET=subtarget (for each subtarget)
<rsalvaterra> I'm assuming the hierarchy is generic -> target -> subtarget.
<adrianschmutzler> yes, I'm just never sure what exactly kernel_oldconfig does when subtargets are around
<rsalvaterra> Yeah, it updates the main target. It's what we want. :)
<rmilecki> adrianschmutzler: thanks for porting that backport patch from 5.4 to 5.10
<rmilecki> adrianschmutzler: unfortunately nbd_ missed more patches, so one should compare both trees
<rmilecki> adrianschmutzler: 402-v5.12-0001-dt-bindings-mtd-move-partition-binding-to-its-own-fi.patch and 402-v5.12-0002-dt-bindings-mtd-add-binding-for-BCM4908-partitions.patch are mssing too
<rmilecki> i didn't check what else possibl
<adrianschmutzler> rmilecki: mom
<adrianschmutzler> hmm, strange
meffe has quit [Quit: upgrade]
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
<adrianschmutzler> yes, I understand what happened now: the two-level numbering tricked me
meffe has joined #openwrt-devel
<adrianschmutzler> you add four 402-v5.12-000x
<adrianschmutzler> and then removed two of them again
<adrianschmutzler> but I assumed all of them were removed again
lucenera has joined #openwrt-devel
<adrianschmutzler> so I didn't add them during my check a week ago
<adrianschmutzler> but I only looked at history up to (including) december 2020
<rmilecki> maybe it's worth trying diff -u backport-5.4 backport-5.10
<adrianschmutzler> so, if something very old slipped, I wouldn't have it
<rmilecki> not sure how easy to understand outptut will be
<adrianschmutzler> well, diffing means you have to check for every removed patch manually
<rmilecki> right
Net147_ has quit [Read error: Connection reset by peer]
<rmilecki> may be a lot of work for 5.4 -> 5.10
<adrianschmutzler> I tried that first, but then gave it up as it would require a substantial amount of time
<rmilecki> ok
<rmilecki> i understand
<adrianschmutzler> essentially you would have to do the kernel bump _again_
Net147 has joined #openwrt-devel
<adrianschmutzler> so, I thought checking the history would be a good compromise, assuming the general job done during migration is fine
<adrianschmutzler> btw I also checked patches and hack dirs
<adrianschmutzler> so, the main risk would be that nbd_ removed a patch during the process he wanted to work on later, and forgot to do that
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
opal has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
<adrianschmutzler> rsalvaterra: any reason why only one of the 6 functional patches in v5.11 was taken for turris omnia?
<rsalvaterra> kab-el: I just noticed, is there any reason we're not exposing the atsha204a at i2c@5, on the Omnia device tree?
Acinonyx has quit [Ping timeout: 260 seconds]
<rsalvaterra> adrianschmutzler: I told tmn505 I wanted to first get the exact same functionality we had with 5.4, so those patches will be added in the future (when I add support for the LEDs, for example).
<owrt-snap-builds> build #799 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/799
<adrianschmutzler> okay. I probably will leave out the turris omnia patches for now, though, anyway
<rsalvaterra> adrianschmutzler: In other words, we're at 5.10 plus bug fixes only, minus LEDs.
<rsalvaterra> Uhh… no, we need those.
<adrianschmutzler> reads like enabling a feature?
<rsalvaterra> They fix the hardware buffer management and the IRQ storm.
<rsalvaterra> Wait, are we on the same page? Which patches?
<adrianschmutzler> mvebu: fix the Turris Omnia device tree
<adrianschmutzler> There, it says "enable and fix". This means that without the patch, it's disabled and thus won't hurt :-)
<rsalvaterra> These are the patches I'm talking about: 002-ARM-dts-turris-omnia-enable-HW-buffer-management.patch, 100-ARM-dts-turris-omnia-fix-hardware-buffer-management.patch, 101-ARM-dts-turris-omnia-configure-LED-2--INTn-pin-as-interrupt-pin.patch.
<rsalvaterra> 002 and 101 enable/fix hbm, it's been working for a long time already on Linksys hardware with the same SoC.
<rsalvaterra> (I already sent a patch to enable/fix hbm on 21.02 too.)
<rsalvaterra> 101 fixes the GPIO IRQ storm.
<adrianschmutzler> I mainly just don't want to have to review these.
<rsalvaterra> adrianschmutzler: It hurts network performance, especially at small packet sizes. :P
<nitroshift> rsalvaterra, o/
<rsalvaterra> Hey, nitroshift! o/
<adrianschmutzler> but it will still boot and not explode without them?
<nitroshift> what hardware buffer manager on mvebu are you talking about?
<nitroshift> so far there is only software buffer manager
<rsalvaterra> adrianschmutzler: If that makes you more comfortable, those patches were approved upstream.
<adrianschmutzler> well, give me two links and I might be fine :-)
<rsalvaterra> nitroshift: I'll get to you, let me just "unstress" adrianschmutzler. :)
<nitroshift> :)) ok
<adrianschmutzler> doesn't look like they made it in the 5.12 set
<rsalvaterra> Ok, for the IRQ storm fix, reviewed by Andrew Lunn: https://marc.info/?l=linux-arm-kernel&m=161394081106303&w=4
<rsalvaterra> For the hbm, reviewed by Marek Behún: https://marc.info/?l=linux-arm-kernel&m=161357782411611&w=4
<adrianschmutzler> okay, and "just" reviewed means we do not know when and whether they will land in kernel
<adrianschmutzler> but that should be good enough for us at the moment
<rsalvaterra> Let's make a bet…? ;)
<adrianschmutzler> It's all fine
<rsalvaterra> It's not a matter of "if", just a matter of "when" (for the IRQ storm patch) and "how" (for the hbm fix, as it's being discussed the possibility of including in the generic SoC .dtsi).
<adrianschmutzler> but stuff like the "how" would normally be something you would wait for
<rsalvaterra> nitroshift: About hbm, you're talking about the WRT1900AC v1, right?
<adrianschmutzler> anyway, see my nitpickedly fixed version here, while I build-test: https://github.com/adschm/openwrt/commits/mvebu10y
<rsalvaterra> nitroshift: Check for something like this on your dmesg: [ 1.536185] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
<adrianschmutzler> hmm, that CONFIG_POWER_RESET_LINKSTATION is set up strangely
<rsalvaterra> Oh…? I wasn't prompted for that.
<adrianschmutzler> not your fault, just generally
<nitroshift> rsalvaterra, got confused, you're right
<adrianschmutzler> it's =m in modules, but disabled in the subtargets, and not set in the target ...
<rsalvaterra> adrianschmutzler: ack for your nitpicks, thanks. :)
Tapper has joined #openwrt-devel
<rsalvaterra> I have a question which has been bugging me for a while… Let's say I have a system for which the Wi-Fi driver is basically in maintenance mode. Is there any easy way to build an image without the compat stuff?
<adrianschmutzler> build-testing will require https://github.com/openwrt/openwrt/pull/3896 ?
<rsalvaterra> For mvebu? Not at all, I don't have that in my tree.
<rsalvaterra> Well, wait. You have WireGuard?
<rsalvaterra> In that case, you need a patch, yes.
<adrianschmutzler> I will just do a test with buildbot settings
<adrianschmutzler> which would want to build at least kmod-wireguard ...
<rsalvaterra> I shamelessly stole this one: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commit;h=39fe90daccb410ab0bbc82227bc3f875c97fe4f0
<rsalvaterra> This won't build the module, but WireGuard will work if you select it (built-in) in the kernel configuration.
<rsalvaterra> In either case, the build won't fail.
* rsalvaterra eagerly waits for the big-ass WireGuard pull to land…
<adrianschmutzler> I'm still curious how this will end
<rsalvaterra> What do you mean? :)
<rsalvaterra> The migration from compat to patches in 5.4?
<adrianschmutzler> yes
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<rsalvaterra> I'm *really* looking forward to it.
<rsalvaterra> It's so much cleaner…
csrf has joined #openwrt-devel
<owrt-2102-builds> build #10 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv7/builds/10
Darkmatter66 has quit [Ping timeout: 256 seconds]
<rmilecki> adrianschmutzler: i'd like to partially merge https://github.com/openwrt/openwrt/pull/3583 today - with some fixups
<rmilecki> adrianschmutzler: i think / hope your comments were addressed
<adrianschmutzler> rmilecki: yes.
<rmilecki> adrianschmutzler: thank you for looking at that MR
<adrianschmutzler> I just wonder whether stuff like ucidef_set_led_default is really needed. But probably patching a default-on into DTS is not worth it ...
<adrianschmutzler> btw, since this LED is selected in diag.sh:
<adrianschmutzler> will it stay on or off after boot?
<adrianschmutzler> done) status_led_on ...
<adrianschmutzler> hmm, looks like the ucidef_set_led_default "logo" "Power" "bcm53xx:white:power" "1" can be just removed
<adrianschmutzler> but if you don't want to touch the code again, I'm also fine with the current state
<rmilecki> adrianschmutzler: bcm53xx uses 99% of upsteam DTS code and we don't have some code that is commonly used in OpenWrt, like those aliases
<rmilecki> i'm not well aware how it looks like
<rmilecki> I'll have to clean it up somehow
<rmilecki> that bcm53xx:white:power should be default-on in DTS, weird
<rmilecki> or should be set by some .sh code
<rmilecki> i'll check that
<adrianschmutzler> as I understand it, it's picked up by the code in base-files/etc/diag.sh
<rmilecki> it should be, i believe
<adrianschmutzler> so, default-on will only be relevant during first 3 seconds
<rmilecki> right
<adrianschmutzler> then diag.sh will blink and after boot is finished, it should make the LED solid-on
<adrianschmutzler> those ucidef_set_led_default lines are typically put by people so they can only change a value, but don't have to add the full uci block themselves (if they don't use luci)
<adrianschmutzler> personally, I think that's not really necessary, and particularly not for a LED which is used in diag.sh
<adrianschmutzler> for the general subject, one could of course just add local patches that insert led-* aliases into the DTS files and then use generic diag.sh
<adrianschmutzler> but I don't really think that's worth the effort
<adrianschmutzler> particularly since we still do not know how to use this feature with the new color/function properties, where we cannot determine the LED name from DT anymore
<adrianschmutzler> which is a big pain in the ...
<owrt-2102-builds> build #10 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm63xx%2Fgeneric/builds/10
Rene__ has quit [Quit: leaving]
dangole has joined #openwrt-devel
<rsalvaterra> I guess now I can start working on the Omnia LEDs… mangix will be happy. :)
* rsalvaterra runs
Rene__ has joined #openwrt-devel
<lipnitsk> adrianschmutzler: any advice on how to move forward with that WireGuard PR? It seems pretty quiet now on the mailing list and in the PR comments. Is it a matter of following up? If so then with who?
<owrt-2102-builds> build #10 of ipq40xx/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ipq40xx%2Fmikrotik/builds/10
<adrianschmutzler> well, my advice on that was not valued very highly
<adrianschmutzler> IIRC correctly, David said he prefers keeping the compat version, and I said you should discuss this on the list ASAP
<adrianschmutzler> no other committer was seen on the scene yet, and you (plural) decided to do otherwise
<adrianschmutzler> This does not imply any judgement, just summarizing my perception here ...
<blocktrron> adrianschmutzler lipnitsk: i don't prefer keeping the compat version
<blocktrron> I don't like keeping that pile of patches on top of 5.4, but since they simply do poof once 5.4 gets nuked im fine with that
<blocktrron> I'd rarther have 800 good wireguard backport-patches than one hack patch to say "ARMv8" in procfs
zkrx has quit [Ping timeout: 272 seconds]
<blocktrron> lipnitsk: I'll take care of the wireguard part. Either I'll find time today / tomorrow or on the weekenc
<rsalvaterra> FWIW, I'd also choose patches over compat any day…
<rsalvaterra> Probably because I finally got the hang of quilt. :P
<blocktrron> I'm not a wireguard user ;)
nitroshift has quit [Ping timeout: 272 seconds]
<rsalvaterra> blocktrron: Really? Wow… I can't live without it anymore. Saved my life when I've been to Brazil.
<rsalvaterra> (Because homebanking apps on the phone. :P)
<blocktrron> Never had these issues when traveling in the EU
<blocktrron> But i can understand people being happy they don't have to put off with OVPN
* Borromini is happy wireguard is integrated into his lineageos image
<rsalvaterra> You were lucky… Homebanking systems tend to complain loudly when you suddenly log-in from across the ocean… ;)
<blocktrron> hehe
<rsalvaterra> Borromini: I want! ;_; Unfortunately my x2 isn't built with the kernel module (Linux 3.18, unfortunately)…
<lipnitsk> blocktrron: great! Thanks. zx2c4 will be happy to see this too.
<zx2c4> Ive never used quilt!
zkrx has joined #openwrt-devel
<zx2c4> Been doing kernel dev without it for a long time and somehow never made the leap
<zx2c4> My loss probably
<zx2c4> blocktrron: hit that green merge button! :P
<rsalvaterra> zx2c4: Quilt is… interesting. :P
<Borromini> rsalvaterra: do you roll your own? i'm lucky enough to have the rom devs integrate it
<rsalvaterra> Borromini: I thought about it, by only have enough RAM to build LineageOS if I pool all my machines. :P
<Borromini> :P :P
<Borromini> yeah newer android releases are beasts
<Borromini> i remember running into issues with 16 GB of RAM...
<rsalvaterra> Is there a way to specify a subtarget in a module DEPENDS? Something like @TARGET_mvebu_cortexa9?
<rsalvaterra> Or do we have @SUBTARGET?
<Borromini> rsalvaterra: like you said
<Borromini> @TARGET_ramips_mt7621
<rsalvaterra> Borromini: <3
<Borromini> ♥️
<rsalvaterra> @TARGET_mvebu_cortexa9 it is. :)
* Borromini found an irssi emoji plugin
<rsalvaterra> (Makes no sense having Turris Omnia LEDs anywhere else…)
<Borromini> :)
<Borromini> rsalvaterra: i had this e.g. until we discovered that driver only likes =y and not =m : https://paste.debian.net/plain/1186614
<rsalvaterra> I haven't built the drivers yet… I guess we'll find out soon.
<Borromini> this one is 'special', upstream knows it won't work as =m
Tapper has quit [Quit: Instantbird 1.6a1pre -- http://www.instantbird.com]
Tapper has joined #openwrt-devel
valku has joined #openwrt-devel
dangole has quit [Ping timeout: 272 seconds]
decke has joined #openwrt-devel
<owrt-2102-builds> build #9 of x86/geode is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/x86%2Fgeode/builds/9 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
<Tapper> rsalvaterra Hi a bit OT sorry, but do you know if there is a build of it for the GS10 yet?
<rsalvaterra> Tapper: I have no idea.
<Tapper> OK thanks
<Tapper> I would like a proper build not some dodgey one from XDA.
<Tapper> What graphic did x d a show up as?
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
<rsalvaterra> noltari: I'm curious, is bmips to bcm63xx what ath79 is to ar7xxx?
<noltari> rsalvaterra: yeah, exactly that
<rsalvaterra> Great, thanks! :)
<Borromini> gs10 router?
<Borromini> Tapper: ^^
decke has quit [Quit: Leaving.]
<noltari> rsalvaterra: some people will probably hate me for having the same devices supported by two different targets once again :_
<olmari> well... I did welcome ath79 when it came out... and still do
<Borromini> noltari: but bcm63xx will be phased out i presume just like ar71xx?
* Borromini does as well
<olmari> if bmips is similar thing, ef the naysayers
<noltari> Borromini: that's the idea
<rsalvaterra> noltari: Oh, come on, really? o_O
<noltari> but we need to have working PCI/PCIe and wireless drivers first
<Borromini> noltari: cool.
<Borromini> oh do wireless drivers differ as well? so it's not just a move to a dts target
<olmari> owrt could jsut drop the "old" thing suddenly so no double thing exist, but tell me again how THAT's going to pan out ;D
<noltari> I'm focusing on upstreaming the few patches that we have right now
<olmari> is it more of driver thing or "just" configuration thing?
<rsalvaterra> noltari: One thing bugs me, though… what's missing to start upstreaming all of ath79, device trees, drivers and whatnot?
<noltari> rsalvaterra: what do you mean?
<noltari> olmari: both?
<olmari> I dunno, it was question =)
<rsalvaterra> noltari: I mean, getting ath79 in the kernel proper.
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 97.8% packages reproducible in our current test framework.)
<noltari> rsalvaterra: I don't know much about ath79. I'm just talking about bmips...
<rsalvaterra> noltari: Sorry, I deduced you were involved in ath79, as you said you were afraid people would hate you for doing the same again. :)
<noltari> rsalvaterra: ah, no, sorry!
<rsalvaterra> It's just that we're carrying so many patches, drivers, device trees…
<Borromini> noltari: from what i gathered ath79 was mostly about moving ar71xx to devicetree.
<Borromini> anyone here using the image generator?
<Borromini> i'd like to know if it contains tplink-safeloader as well (i suppose so)
<adrianschmutzler> The question is whether upstream wants a mixed bag of mach and dts
<rsalvaterra> adrianschmutzler: No mach-* for upstream. Linus made himself very clear, years ago.
<rsalvaterra> Everything must be described with device trees.
<Tapper> Borromini Hi know mate I was on about a phone. Samsung GS10
<Borromini> oh
<rsalvaterra> adrianschmutzler: It started here: https://lwn.net/Articles/392135/
dedeckeh has quit [Ping timeout: 240 seconds]
<hurricos> Is ath79 still mach-y?
<rsalvaterra> adrianschmutzler: And up to this point: https://lkml.org/lkml/2011/3/30/379
<hurricos> I thought all of the stuff got dropped there.
<rsalvaterra> No, ath79 is device tree based, like God intended. :P
<hurricos> Other than that, how big would a PR for ath79 actually *be* though?
<hurricos> or sorry. Github terminology bastardization. A patchset?
<hurricos> ... wait
<hurricos> Never mind. I see. This is about bmips
<hurricos> I was beginnig to sweat. "ath79 ... not mainline? What about code rot???"
<Borromini> lol
<rsalvaterra> hurricos: It would probably be big, but nothing unmanageable, I think.
<hurricos> rsalvaterra: So it's not mainline, but also not far. At this point I just have to ask, what even *is* MIPS
<hurricos> What is RAM. What are computers. Sigh
MichaelOF has quit [Quit: Konversation terminated!]
<hurricos> I like how neat device trees are but they totally conceal a lot of quirks from the bootloader
<rsalvaterra> MIPS is actually well maintained upstream, even for really exotic stuff (N64 support was just added, for example).
<hurricos> like, it's not what's actually on the board
<hurricos> or not just that, but also the variations shimmed in by U-boot. SATA on APM82181 only works if properly initialized by U-boot it seems
<hurricos> (as an example)
<hurricos> I should stop counting my blessings and be thankful as much works as it does
<rsalvaterra> adrianschmutzler: I totally missed the fact that the Omnia's .dts LED node was added in disabled state. No LEDs for 5.10, I guess mangix is safe, for now… :P
gromero_ has joined #openwrt-devel
<adrianschmutzler> rsalvaterra: I already wondered, but was not sure whether I missed something
<adrianschmutzler> mvebu builds fine, so let's throw it in
gromero has quit [Ping timeout: 256 seconds]
<rsalvaterra> \o/
<PaulFertser> rsalvaterra: that last lkml link of yours, hm, that's not what happened eventually, right? The "crazy tables" just migrated to dts, but still maintained along with the kernel, as an inherent part.
<rsalvaterra> Yes, of course. The point is .dts became the standard way to describe ("platformless") hardware.
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 272 seconds]
Tapper1 is now known as Tapper
Darkmatter66 has joined #openwrt-devel
Night-Shade has joined #openwrt-devel
damex has quit [Ping timeout: 240 seconds]
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
damex has joined #openwrt-devel
damex has quit [Read error: Connection reset by peer]
damex has joined #openwrt-devel
kubrickdave has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
dedeckeh has joined #openwrt-devel
<philipp64> dedeckeh: Can you please review the one-line patch to firewall3 I mailed out last Friday? http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033907.html
Borromini has quit [Ping timeout: 240 seconds]
<guidosarducci> FYI, for those using mips/malta for development, kernel 5.10 support comes with PR https://github.com/openwrt/openwrt/pull/3881. Hopefully that gets reviewed/merged.
KGB-2 has quit [Ping timeout: 240 seconds]
Borromini has joined #openwrt-devel
bookworm has quit [Read error: Connection reset by peer]
bookworm has joined #openwrt-devel
<lipnitsk> blocktrron: thanks for merging kmod changes - I have rebased https://github.com/openwrt/openwrt/pull/3885 on top of latest master
<rsalvaterra> adrianschmutzler: The ESPRESSObin is Cortex-A53… ;)
<rsalvaterra> So it's run-tested too. :)
<adrianschmutzler> looks like I copied that from v3 series ...
<rsalvaterra> No worries, it works, that's what matters. :)
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
shibboleth has joined #openwrt-devel
joaohcca has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
joaohcca has quit [Quit: Connection closed]
Tost has quit [Ping timeout: 256 seconds]
kubrickdave has joined #openwrt-devel
dansan_ has quit [Ping timeout: 240 seconds]
dansan_ has joined #openwrt-devel
<pkgadd> rsalvaterra: I'd guess the biggest hurdle for getting the rest of ath79 mainlined would be ag71xx, mainline has a stripped down version of it which won't work on most ath79 devices - that's slowly getting expanded, but it's a hell of a maze to get all the necessary bits and pieces refactored and done properly - beyond that big hurdle, it's probably mostly 'just' a huge amount of devices to take care
<pkgadd> of
Tapper has joined #openwrt-devel
dansan_ has quit [Remote host closed the connection]
dansan_ has joined #openwrt-devel
dansan_ has quit [Remote host closed the connection]
dansan_ has joined #openwrt-devel
dansan_ has quit [Remote host closed the connection]
dansan_ has joined #openwrt-devel
dansan_ has quit [Excess Flood]
shibboleth has quit [Quit: shibboleth]
dansan_ has joined #openwrt-devel
dansan_ has quit [Ping timeout: 240 seconds]
bkallus has quit [Quit: Leaving]
<lipnitsk> zx2c4: thanks, looks like we didn't conflict there with our force pushes :)
<zx2c4> haha
<zx2c4> --force-with-lease is a friend
<lipnitsk> ooh that's nice - haven't used that before
<lipnitsk> fails if you haven't fetched latest stuff?
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 240 seconds]
Tapper has quit [Quit: Instantbird 1.6a1pre -- http://www.instantbird.com]
dedeckeh has quit [Ping timeout: 240 seconds]
<rsalvaterra> pkgadd: I thought ag71xx wasn't even in the mainline, so that's not bad news.
<rsalvaterra> Yes, I was looking at it already. ;)
<hurricos> pkgadd: That's good to know, with any luck whatever makes it into mainline won't require any extreme tweaks to dts' pll_data or anything whacky like that
dansan_ has joined #openwrt-devel
rmilecki has quit [Ping timeout: 264 seconds]
dansan_ has quit [Ping timeout: 264 seconds]
dangole has joined #openwrt-devel
<Hauke> rsalvaterra: why is the upstream commit difefernt from the one you want to add to OpenWrt? https://git.kernel.org/linus/018b88eee1a2efda26ed2f09aab33ccdc40ef18f
<lipnitsk> zx2c4: I don't see the "kconfig: use arm chacha even with no neon" at https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y - is it there, or are you planning to add it later?
<Hauke> rsalvaterra: in the upstream kernel MBUS_ID is not modified
<rsalvaterra> Hauke: Oh, you missed the discussion. ;) Wait, don't merge that yet, I was just about to mark it as superseded, exactly to make it more clear.
<Hauke> ok
Borromini has quit [Quit: leaving]
<rsalvaterra> Actually, I already did.
<Grommish> Someone was asking about Octeon and TZ settings. Ping that person ;p
<rsalvaterra> Hauke: I'll send a new patch which will include everything, three patches in logical sequence, enabling/fixing hardware buffer management and the IRQ storm I've been seeing for years on the Omnia.
<rsalvaterra> Hauke: If want to have a look at the result, meanwhile, here it is: https://github.com/rsalvaterra/openwrt/commit/a4da42b814e30f6a7b354e2418ba8486a9c82f2a
<Grommish> Something is settng UTC to be UTC-3. I had to go back to -8 to read the correct time for EST
<pkgadd> Grommish: youre looking for Borromini
<Grommish> Thanks pkgadd.. Ping Borromini then :)
<Grommish> Or I'll remember later since he's not on
foxtrot has quit [*.net *.split]
jow has quit [*.net *.split]
user890104 has quit [*.net *.split]
wigyori has quit [*.net *.split]
dangole has quit [Ping timeout: 272 seconds]
<zx2c4> lipnitsk: yea, it'll be in there this week after the net.git sync
<lipnitsk> okay, I figured it was some process like that - thanks
<lipnitsk> zx2c4: I just did a minor push to add a note to the backport patch before my sign-off.
<zx2c4> For now just stick with the commits i put in there originally
<zx2c4> Ah cool
<lipnitsk> just for posterity
wigyori has joined #openwrt-devel
user890104 has joined #openwrt-devel
jow has joined #openwrt-devel
foxtrot has joined #openwrt-devel
<Hauke> rsalvaterra: thanks
<Hauke> as they have a Fixes tag they will probably added to 5.4 later anyway
<rsalvaterra> Hauke: That's my hope, but we'll still need the hardware buffer management backport for 21.x. The other two patches will probably become obsolete with a future stable kernel update.
<Hauke> rsalvaterra: ok
<Hauke> does anyone know why CONFIG_HAVE_ARM_ARCH_TIMER is not unset in generic 5.10 any more, but was in 5.4?
<zx2c4> lipnitsk: are we ready to have Hauke or blocktrron merge?
<lipnitsk> blocktrron said he will by this weekend
<lipnitsk> or by next week :)
<zx2c4> Bah, so much waiting
<zx2c4> Hauke: maybe you want to do it now so we can get it over with? :)
<rsalvaterra> Hauke: I saw that too. CONFIG_HAVE_ARM_ARCH_TIMER makes no sense on Cortex-A9, only A7 and A15, if I'm not mistaken.
<lipnitsk> zx2c4: yes, we are ready. I polish things as they come to mind, but it all works, so just a matter of any feedback from core folks at this point
<rsalvaterra> zx2c4: Oh, the WireGuard merge? Let me get the popcorn… :D
m4t has quit [K-Lined]
<Hauke> zx2c4: I didn't look closely into the wiregurad changes
m4t has joined #openwrt-devel
ivanich has quit [Read error: Connection reset by peer]
<zx2c4> Hauke: all the more reason to press the green merge button!
<zx2c4> Big improvements, anyway. Finally using the upstream code
<Hauke> rsalvaterra: why does the CONFIG_HAVE_ARM_ARCH_TIMER make no sense on cortex A9? is this not needed for the arm global timer?
<rsalvaterra> Hauke: Different things. The global timer is shared by all cores, the architected timer is introduced with A7/A15 and is a per-core timer.
fblaese has quit [Quit: irc_error]
<lipnitsk> zx2c4: I don't know if you want to push for cherry-picking the backport into 21.02, but 5.4 will eventually be deleted from master with no planned 5.4 release off master anymore, AFAIK
<lipnitsk> zx2c4: Otherwise, 21.02 will use wireguard-linux-compat
<Hauke> rsalvaterra: thanks for the clarification
<rsalvaterra> FWIW, I'd *really* love to see 21.02 dropping compat for WireGuard.
<lipnitsk> I can just open a 21.02 PR and see where it goes from there
<lipnitsk> :)
* rsalvaterra would also like OpenWrt to drop compat entirely. And a unicorn. :P
<zx2c4> Hauke: I'd prefer the backport in 21.02 rather than compat. Let's get this in master first and then we can do 21.02
<zx2c4> So hoping that PR gets merged soon (today? now?) so that we can move onto next steps
<zx2c4> lipnitsk: oh great
<lipnitsk> yeah I can wait for now..
<Hauke> I do not have time before the weekend
<enyc> Hauke: did you see the fun with -ct firmware? uerr .... been busy on other task myself.
<enyc> * enyc ponders what https://github.com/greearb/ath10k-ct/issues/178 means for OpenWRT 21.02 .... switch away from -ct firmware? try to get it figured out further?
<enyc> 03:53 < Namidairo> using the same hardware on my archer c5 and I don't see the same thing
<enyc> 03:59 < Namidairo> wonder if it's environment or specific to certain devices
<enyc> ought to be able to get similar BT-HHv5a (lantix xrx200 with ath9x+ath10x) out with previous master build (january?) and see how that is...
dangole has joined #openwrt-devel
kontaxis has quit [Remote host closed the connection]
pine127_ has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
pine127 has joined #openwrt-devel