#openwrt-devel on 2021-03-21 — irc logs at freenode.irclog.whitequark.org

01:00 <mangix> error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out

01:00 <mangix> wonder if I wrecked it

01:55 <aparcar[m]> ynezz: I don't think they support the feature just yet, but we could ask it to be added. They're quite actively mess around with the CI

02:14 <mangix> hrm surprised libtorrent-rasterbar needs libatomic given that it uses boost

02:46 <aparcar[m]> mangix: looking at the amounts of PRs you opened and the CI sweating I see the next data center burning

02:46 <aparcar[m]> now my test wouldn't even start...

03:14 <mangix> aparcar[m]: hahaha

03:15 <mangix> pretty sure the CI is running in some VM.

03:15 <mangix> shared by other stuff.

03:46 <aparcar[m]> mangix: could you please use a rebase rather than a merge commit? The log is flodded with merges of packages that don't influence one another, I don't see the point

04:00 <mangix> aparcar[m]: it's a point of contention. turris people don't like rebase since it removes GPG signatures. david woodhouse doesn't like it since it not the "true" history.

04:00 <mangix> but yeah rebase does look better.

04:19 <aparcar[m]> mangix: not sure what's preferred, I just hate the visual noise

04:27 <mangix> aparcar[m]: sure. maybe github should add a warning if a rebase would get rid of GPG signatures.

04:40 <aparcar[m]> support@github.com I guess

05:17 <sodo> can somebody plz help me solve this issue

05:17 <sodo> https://github.com/openwrt/openwrt/pull/3991?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDE2ODc4NzM1OTU6MTc3MjE2NTY%3D&notifications_query=is%3Aissue#pullrequestreview-611695635

05:34 <aparcar[m]> sodo: help as in merge?

05:36 <sodo> aparcar: see my last review

06:10 <Grommish> Anyone want to give me a hint on this? Please? :) https://forum.openwrt.org/t/package-menuconfig-options-toggle/91750

06:34 <guidosarducci> Grommish: you don't really describe the use case or objective beyond that they're mutually exclusive. Have you considered "choice" / "endchoice" block?

06:35 <guidosarducci> Grommish: ^^^ would work if one or the other *has* to be selected... more detail needed.

06:37 <guidosarducci> aparcar[m]: I think I know what's going on with the x86/64 buildbot failure. That's a 5.4 build with all modules enabled, right?

06:43 <Grommish> guidosarducci: I looked at Tristate, but not very hard. It should be One, or the other, or NEITHER, but never both

06:43 <Grommish> So maybe a 3-part choice would be appropriate

06:44 <Grommish> You can compile with lua, luajit or neither, but never lua AND luajit

06:46 <aparcar[m]> Yes

06:46 <guidosarducci> Grommish: Yeah, or you need some abstraction between what you present to users and the low level config options. TBH, it's confusing to say you can use luajit without lua.

06:47 <Grommish> guidosarducci: It's how they have it laid out.. if i build with both flag options it says No No No :)

06:47 <Grommish> so it's either --with-lua and --with-luajit or neither flags, but not both together

06:49 <Grommish> and since it's an engine option, I have to present the option AFAIK.. has to be built in

06:51 <Grommish> It good news is, I can verify rust-lang works with mipsel 24kc now hehe

06:51 <guidosarducci> Grommish: my point was about usability. If you simply want to pass through the raw configure options then your 3-choice option works.

06:52 <Grommish> guidosarducci: I need to present the option, wihch I am going to read with a ifeq() check on CONFIGURE_ARGS to add to them if they are active

06:52 <Grommish> since I don't know a better way to do it

06:56 <Grommish> guidosarducci: https://github.com/Itus-Shield/packages/commit/044f11a85112c27909aa4ebd00d609361e52a60f

06:57 <guidosarducci> aparcar[m]: if it's an ALL_KMODS build, I think the presence of new kmod-ledtrig-audio is being picked up by one of the other sound drivers. Easiest thing, and likely more robust long term would be something like: https://github.com/guidosarducci/openwrt/commit/1b26f2383fcd6cddd5d4c9b44860cc1b64785723

06:59 <owrt-snap-builds> Build [#10](https://buildbot.openwrt.org/master/images/#builders/31/builds/10) of `layerscape/armv8_64b` failed.

07:01 <Grommish> guidosarducci: I will probably move the ifeq checks to a separate .mk so I can keep Makefile cleaner

07:03 <guidosarducci> Grommish: why not have SURICATA_ENABLE_LUAJIT depend on SURICATA_ENABLE_LUA, which makes sense to users, and deal with the mutex in your make logic? That was my point.

07:04 <Grommish> guidosarducci: Because SURICATA_ENABLE_LUAJIT doesn't depends on SURICATA_ENABE_LUA at all, other than they both can't be on

07:04 <Grommish> These flags enable Lua or LuaJIT support in the Suricata engine, not required host packages

07:05 <Grommish> So it's one or the other, or neither, but not both

07:06 <Grommish> I looked at the kconfig stuff because it's based on that, but I couldn't figure out a way to negate a package if another is selected.. I tried to with the negated DEFPENDS ON

07:06 <Grommish> but it didn't work right, so I posted

07:45 <Grommish> guidosarducci: choice/endchoice works for waht I need :) Thanks!

08:46 <aparcar[m]> guidosarducci: ping

08:46 <guidosarducci> aparcar[m]: pong, just heading off soon

08:47 <aparcar[m]> guidosarducci: i'll compile your patch real quick and see if it fixes things

08:47 <guidosarducci> aparcar[m]: OK, there's a PR with you mentioned too

08:48 <aparcar[m]> thanks, you're argumentation makes sense to me :)

08:48 <guidosarducci> aparcar[m]: I didn't have time myself to do a full ALL_KMODS build yet either.

08:49 <aparcar[m]> i'm on it

08:50 <guidosarducci> aparcar[m]: thanks, signing off now, will check in later.

08:50 <aparcar[m]> bye bye

08:55 <Grommish> aparcar[m]: is it failing and killing the buildbot?

08:55 <aparcar[m]> it's breaking the build, yes

08:56 <Grommish> aparcar[m]: If you add a IGNORE_ERRORS"m n" to the make call, it'll continue on the failed module builds

08:56 <Grommish> instead of killign the whole thing

08:56 <aparcar[m]> Grommish: I think that's not the idea when building KMODS

08:57 <Grommish> aparcar[m]: Well,, If you're building ALL kmods, it would build for ones not necessarily for the target, no?

08:57 <Grommish> because it sets them all to M

08:59 <Grommish> I know I had to do that for CONFIG_ALL because it set everything to M, dependancies be damned

09:02 <aparcar[m]> Grommish: afaik all possible targets are installed because the kernel needs some linking whatever stuff, if one of the modules fails the creation of the linking map fails and therefore the whole thing

09:02 <aparcar[m]> poorly explained, but it's different from compiling regular packages since kmods change the resulting kernel

09:02 <Grommish> Gotcha :)

09:11 <aparcar[m]> ls

09:13 <aparcar[m]> nbd: morning

09:14 <aparcar[m]> do you have an explanation why the following prints the packages added in target/linux/mvebu/Makefile twice? TOPDIR=$(pwd) make --no-print-directory -f target/linux/mvebu/Makefile val.DEFAULT_PACKAGES

09:23 <aparcar[m]> nbd: okay it just needed a DUMP=1

09:27 <sodo> .

09:43 <kristrev> Hi. I have mainly been working on 19.07, but thought I should start looking at 21.02 now that it has been branched and is being prepared. I know that the two versions are incompatible due to the switch to DSA, but as far as I could see, after dsaconfig was added then writing a uci-defaults script converting from swconfig to dsa should be possible (at least for ramips)

09:44 <kristrev> Is there somethere I am missing and there is a good reason why such a script hasn't been written, or is "just" because noone has had time?

09:44 <mangix> patches welcome :)

09:45 <kristrev> Just what I wanted to hear :)

09:46 <kristrev> I just wanted to know if there was any point in starting working on such a script or not

09:47 <Borromini> kristrev: i think the devs decided not to facilitate migration by providing scripts

09:50 <kristrev> Ah, ok, I see now that I also missed that dsaconfig was reverted

09:52 <Borromini> dsaconfig isn't about migrating swconfig settings though afaik

09:54 <kristrev> I need to develop ... something to facility upgrading the devices I am responsible for, if I can make something useful I will share it and see how it goes

10:01 <aparcar[m]> guidosarducci: you fixed it, thank you

10:02 <aparcar[m]> sodo: I just finished another review, I'll look into your issue

10:03 <sodo> aparcar thanks

10:28 <ynezz> aparcar[m]: surely not interested in some proprietary stuff, just wanted to confirm my findings, that it's not possible

10:29 <aparcar[m]> Ack

10:31 <ynezz> philipp64: hardware is cheap nowadays, so that's not a problem, I've integration of QEMU based devices in the works, so after that we would've broader range of arm/mips/x86 targets available

10:32 <ynezz> philipp64: and for x86/64 real device testing I would probably go with apu4

10:35 <ynezz> philipp64: if you're offering help, then what is needed now is improvements of the test cases, so the test runs has increased coverage and thus higher value and probabilty to catch regressions

10:39 <ynezz> each DUT (device under test) is connected to the test runner/executor via serial console and with WAN and LAN port (soon 2 LAN ports), so it's possible to perform testing of network setup from both WAN/LAN perspectives - DUT can thus be reached over serial and/or network during the test

10:49 <aparcar[m]> ynezz: what do you use as runner/executor?

10:54 <PaulFertser> kristrev: you should discuss that with jow , he had his hands elbows-deep in there recently.

10:57 <kristrev> PaulFertser: Thanks, will try to contact him

11:07 <kristrev> My plan is to get a bit more familiar with DSA, prepare a first version of a solution and then share it on the ML. While the solution probably wont be perfect, I believe discussions are easier when there is something concrete to look at

11:37 <owrt-snap-builds> Build [#12](https://buildbot.openwrt.org/master/images/#builders/4/builds/12) of `x86/generic` completed successfully.

11:38 <owrt-snap-builds> Build [#13](https://buildbot.openwrt.org/master/images/#builders/8/builds/13) of `x86/64` completed successfully.

12:01 <ynezz> aparcar[m]: gitlab runner

12:05 <Grommish_> In this rust-lang package, it compiles into an archive of installation files for the host_target toolchain, then uses this file in any future calls. if the package gets accepted, will the buildbot create the archives for use and download?

12:06 <f00b4r0__> hmm. Is there a way to set the DUID for WAN6 dhcpv6 requests?

12:09 <ynezz> aparcar[m]: gitlab runner -> docker container -> labgrid (power on device, boot device using initramfs over tftp) -> wait for LAN up -> execute cram tests -> https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/blob/master/.gitlab/testbed.yml#L51

12:47 <OutBackDingo> ok guys, i need a c dev for a quick project

12:48 <OutBackDingo> paid work, take you a day maybe 2

12:51 <owrt-snap-builds> Build [#18](https://buildbot.openwrt.org/master/images/#builders/1/builds/18) of `ath79/generic` completed successfully.

13:25 <sodo> aparcar: i fixed typo(i add ":" after pushing) but failes with same error

15:01 <owrt-snap-builds> Build [#11](https://buildbot.openwrt.org/master/images/#builders/59/builds/11) of `x86/geode` completed successfully.

15:40 <owrt-snap-builds> Build [#10](https://buildbot.openwrt.org/master/images/#builders/52/builds/10) of `x86/legacy` completed successfully.

18:40 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

20:00 <enyc> somebody please remind me where the 21.02SNAPSHOT images are =) with thanks!

20:04 <SwedeMike> enyc: https://firmware-selector.openwrt.org/ has a dropdown that includes 21.02snapshot

20:06 <enyc> SwedeMike: not work to give a link BUT that gave me the $clue I needed the - !!

20:06 <enyc> SwedeMike: now found /releases/21.02-SNAPSHOT/

20:06 <enyc> thankyou =)

20:17 <Borromini> enyc: no browser history? :)

20:18 <enyc> Borromini: ages ago... lots been done, different machine likely, .........

20:21 <Borromini> :)

20:21 <Borromini> glad you're helping testing

22:30 <f00b4r0> hmm odd. The conntrack '-f' selector doesn't seem to do anything on owrt 19.07 (trying to show only ipv6 conntrack shows everything)

23:02 <guidosarducci> aparcar[m]: thanks for testing that fix.

23:49 <mangix> hrm dango's not here

23:49 <mangix> curious how to open this linksys router

23:50 <mangix> i really don't want to break the plastic

23:50 <stintel> use a torch and it will melt ¯\_(ツ)_/¯

23:51 <mangix> hahaha

23:51 <dorf> clips 'n screws, mangix.

23:51 <mangix> dorf: I don't see any screws

23:52 <pkgadd> any clues in the fcc images?

23:52 <dorf> under stickers, or maybe just clips?

23:52 <dorf> a spadger or similar tool probably required.

23:53 <mangix> oh

23:53 <mangix> it does have screws

23:53 <mangix> well hidden

23:53 <stintel> that's one of the reasons I prefer buying stuff with console port

23:56 <pkgadd> o.k., https://fcc.io/K7S-03571 judging from the e8450 case, four screws on the bottom, under the stickers