<lipnitsk>
zx2c4: okay, finally reproduced it. will work on it now
eliasmagn has quit [Ping timeout: 240 seconds]
<blocktrron>
lipnitsk: I've merged your 5.10 packaging changes, Will start some tests on 5.4 and 5.10 on some targets prior to merge
<lipnitsk>
thanks, do you have changes on top of mine or just those?
<blocktrron>
ping me here or via E-Mail in case you don't hear back on that
<blocktrron>
Just those for now
<lipnitsk>
great, thanks.
Robby has quit [Ping timeout: 264 seconds]
<blocktrron>
Just don't @ me on GitHub, i don't have notifications for that
<lipnitsk>
understood
<blocktrron>
I mean, you can do that but it won't help with anything :P
<lipnitsk>
I know how to best bug you now
<blocktrron>
I'll have to catch up on the state of wireguard.
<blocktrron>
I don't have a strong opinion on which way to go, as long as the ugly party disappear once 5.4 is nuked
<lipnitsk>
yes, working out a kink or two, but it is looking good. Don't be scared by all the patches there - zx2c4 signed up for maintaining that. The main question is what to do about 21.02 I think
<mangix>
lipnitsk: keep using the module?
<zx2c4>
blocktrron: ugly party?
<zx2c4>
mangix: im not going to maintain wireguard-linux-compat on openwrt anymore
<zx2c4>
that's old crusty code that doesnt have a reasonto exist in openwrt land
<lipnitsk>
mangix: you mean, keep using wireguard-linux-compat on 21.02?
<blocktrron>
zx2c4: ugly not in that sense, i refer to that bug pile of patches as being rather ugly while performing eventual kernel updates
<blocktrron>
not sure how much they interfer though
<zx2c4>
blocktrron: oh. theyre usually pretty standalone
<mangix>
lipnitsk: the question is why not.
<zx2c4>
i maintain that tree over gregkh's
<rsalvaterra>
It would be nice to kill wireguard-linux-compat from 21.02 too, if still possible… :/
<lipnitsk>
mangix: maintenance? fresh release with crusty old stuff doesn't sound like a good idea. 21.02 branch is still young and these patches are stable
<mangix>
note that exfat in the kernel is also implemented as a module
<mangix>
since it was introduced with kernel 5.8
<blocktrron>
zx2c4: that sounds good. And I've meant "big pile", not "bug pile". That's easy misunderstood :P
lmore377_ has quit [Remote host closed the connection]
lmore377 has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
<Grommish>
Not OpenWrt related, but has anyoine setup a local BitWarden server to handle passwords?
<Grommish>
I've got an old Barracuda SpamAssassin box that I am repurposing
zjason has joined #openwrt-devel
lmore377 has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
<lipnitsk>
I have a KCONFIG vs DEPENDS question if anybody is online... Struggling to define an optional kernel module dependency. It works during target/linux/compile and during package/kernel/linux/compile but fails at package/install. The idea is that if a CONFIG option is defined then a dependency is needed, but if not then it is not needed. So I think adding +OPTION:kmod-xxx to the DEPENDS. The problem is that all modules
<lipnitsk>
are built together, so OPTION is selected during the build, but OPTION is only set to 'm', not 'y', so kmod-xxx.ipk is not built for rootfs... Any way to fix this?
<lipnitsk>
any way to force OPTION to 'y' if it was 'm', but not depend on it if it was 'n' or absent?
lmore377 has quit [Remote host closed the connection]
lmore377 has joined #openwrt-devel
lmore377_ has joined #openwrt-devel
lmore377 has quit [Ping timeout: 264 seconds]
<Namidairo>
Grommish: bitwarden_rs works well just remember to setup db backups
<Grommish>
I was looking at the docker image
danitool has quit [Ping timeout: 240 seconds]
<Grommish>
Ironically, I don't want to mess with rustlang outside of the build system
dorf has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<lipnitsk>
another way of putting my problem is: does OpenWrt build system support not enforcing module dependencies that are guarded by IS_REACHABLE in the kernel code, thereby making the dependency optional?
goliath has joined #openwrt-devel
<owrt-snap-builds>
build #305 of mpc85xx/p1010 is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1010/builds/305 blamelist: Moritz Warning <moritzwarning@web.de>, Georgi Valkov <gvalkov@abv.bg>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
xxiao has joined #openwrt-devel
<Grommish>
lipnitsk: You should ping jow on that, and see if he answers (in addition to the rest).
<Grommish>
but it'll at least show up on his end, if he knows and can answer
<lipnitsk>
zx2c4: by successfully, I mean that it got past the package/install error related to kmod-crypto-kpp. The build still failed because the resulting image was too big for some target, but that looked completely unrelated to any of the crypto changes.
Darkmatter66 has quit [Ping timeout: 256 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
hbug_ has quit [Remote host closed the connection]
hbug_ has joined #openwrt-devel
feriman has joined #openwrt-devel
<RaspberryJam>
I run openwrt on a wireless access point. I need to get a poe managed switch, I see that openwrt has preliminary support for some of these switches with a realtek chipset.
<RaspberryJam>
There's a trendnet switch that has the specs I want but there is no official confirmation openwrt works on it, I made a forum post about it.
<RaspberryJam>
If I order one of those switches what would be the most effective way to help openwrt run on it? Would I just post pictures of the board, try to flash it with a dev rom, and report what happens?
<ynezz>
if you're not willing to tackle this yourself, then just buy one which has already support
<guidosarducci>
BTW 21.02 SNAPSHOT IB was working 2 days ago, but current one fails with many errors like: "Packages for mtd found, but incompatible with the architectures configured". Known issue?
svanheule has quit [Ping timeout: 256 seconds]
<plntyk>
think so -its related to abi changes
<plntyk>
i have it too
<plntyk>
guidosarducci, look at some fixes in felix tree - think those are not submitted/backported yet
<guidosarducci>
plntyk: only other thing I can think is if package builds aren't complete even though the IB is available...
<plntyk>
build: reorder more BuildPackages lines to deal with ABI_VERSION
<guidosarducci>
plntyk: all that stuff worries me... I saw a complete NOP change to a package I maintain, so really wondering changes are based on.
<guidosarducci>
plntyk: will look at his tree too, thanks
<guidosarducci>
plntyk: ^ "wondering what changes are based on"
<plntyk>
guidosarducci, there are some other changes in the build system on the way - some to make compile / recompile times shorter
<plntyk>
and the abi change was probably done to make security updates "easier"
<plntyk>
and/or "fix" buildbot stuff when releasing
<plntyk>
some packages / upstream "behavior" is "stupid" too - like mpd
heffer has quit [Quit: heffer]
heffer has joined #openwrt-devel
<guidosarducci>
plntyk: should I even ask "what changes?" It begs the question of what's been slowing things down. But TBH I find things pretty quick once ccache is enabled, downloads are cached.
<plntyk>
"embedded" player that changed to C++17 - while some platforms have problems with "modern" languages / compiler support
<plntyk>
doing stuff faster sometimes exposes more bugs like parallel build flags becoming necessary
<plntyk>
felix has some change that should decrease buildtime on autoconfig stuff
Grommish has quit [Ping timeout: 264 seconds]
<guidosarducci>
plntyk: right, the parallel builds can be flakey if pushed I've seen too
<rsalvaterra>
'morning
<plntyk>
good morning
<guidosarducci>
ldir: ping
<rsalvaterra>
I'm… seeing a git send-email borderline crazy behaviour: git send-email -7 works, -9 works, -8 doesn't work, gives me a "No patch files specified!". Any ideas?
Grommish has joined #openwrt-devel
<plntyk>
look at patch series with "file" tool - maybe it points out something
ivanich has joined #openwrt-devel
RaspberryJam has quit [Quit: Connection closed]
<rsalvaterra>
Oh, wow…! Making -8 the last argument seems to have worked. Composing…
<rsalvaterra>
Yeah, it work. Perl shenanigans, for sure…
<rsalvaterra>
*worked
novski has quit [Quit: Connection closed for inactivity]
Borromini has joined #openwrt-devel
Grommish has quit [Ping timeout: 264 seconds]
nitroshift has quit [Quit: Gone that way --->]
swex_ has quit [Ping timeout: 256 seconds]
swex has joined #openwrt-devel
Grommish has joined #openwrt-devel
svanheule_ has quit [Quit: svanheule_]
svanheule has joined #openwrt-devel
victhor has joined #openwrt-devel
AUser_ has joined #openwrt-devel
AUser has quit [Ping timeout: 260 seconds]
AUser_ is now known as AUser
jacekowski has quit [Ping timeout: 260 seconds]
jacekowski has joined #openwrt-devel
eliasmagn has joined #openwrt-devel
eliasmagn has quit [Client Quit]
eliasmagn has joined #openwrt-devel
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
<eliasmagn>
Hy guys why to use uci_get insteat of uci get in init scripts?
<owrt-snap-builds>
build #863 of sunxi/cortexa53 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/863 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Georgi Valkov <gvalkov@abv.bg>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
mattsm has quit [Quit: Ping timeout (120 seconds)]
mmlb has quit [Quit: Ping timeout (120 seconds)]
mattsm has joined #openwrt-devel
mmlb has joined #openwrt-devel
victhor has quit [Ping timeout: 240 seconds]
<zx2c4>
lipnitsk: okay the issue is having dependencies in the arch-specific things
<zx2c4>
because you evaluate the equivalance wit ha global if
<zx2c4>
im fixing it -- ill forcepush
dedeckeh has quit [Quit: Connection closed]
<zx2c4>
though that might get messy. perhaps we just want to unconditionally depend on CONFIG_KPP
gromero_ is now known as gromero
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 272 seconds]
Darkmatter66 has quit [Ping timeout: 260 seconds]
Acinonyx_ has quit [Ping timeout: 246 seconds]
Acinonyx has joined #openwrt-devel
HeMan has joined #openwrt-devel
<ynezz>
is there anyone who has flashed openwrt to omnia from the stock u-boot?
<ynezz>
my device is running U-Boot 2019.07 (Oct 05 2020 - 23:50:39 +0000), Build: jenkins-turris-os-packages-dragons-omnia-1753
<ynezz>
but it seems like I'm not able to write anything to emmc, any 'mmc write' command fails in u-boot, have I missed something like some hidden read-only knob or such "feature" ?
<ynezz>
my idea is something like 'dhcp ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-sysupgrade.img; mmc dev 0 0; run set_blkcnt; mmc write ${kernel_addr_r} 0 ${blkcnt}'
feriman has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
eliasmagn has quit [Quit: Connection closed]
<plntyk>
ynezz, "protect" command seems available on u-boot turris fork
<ynezz>
so upstream perhaps needs some vendor magic
<rsalvaterra>
ynezz: That DRAM training failure doesn't sound very desirable… :P
<ynezz>
I guess it's some mvebu feature :p
<rsalvaterra>
It's a shame it's not ECC… :(
<stintel>
yay, negative pcr test, flight booked
<ynezz>
rsalvaterra: actually if booted after power cycle
<ynezz>
s/if/it/
<rsalvaterra>
ynezz: No errors, this time?
<ynezz>
no, just emmc doesn't work :p
<rsalvaterra>
In other news, is it just me, or is the 5.10 kernel really big, compared to 5.4…?
<ynezz>
this one even boots, cool U-Boot 2021.04-rc1-00199-gf08e6d70c7f4 (Feb 22 2021 - 15:22:42 +0100)
<ynezz>
but still emmc bummer, MMC write: dev # 0, block # 0, count 21993 ... mmc write failed
adrianschmutzler has joined #openwrt-devel
<lipnitsk>
zx2c4: looks better than my hack. I tried playing with custom kconfig, but didn't try the imply. I'll test it out with a couple of build combinations
<lipnitsk>
zx2c4: thanks for marking the lobs HIDDEN too, I considered doing that, but didn't for whatever reason
<rsalvaterra>
Nothing like a patch to stir things up, heh? :)
<rsalvaterra>
Ouch. I need to refresh/rebase my generic patches to 5.10… :/
<guidosarducci>
rsalvaterra: 5.10 big vs 5.4 in what sense? sources or binary?
HeMan has quit [Quit: Connection closed for inactivity]
<owrt-snap-builds>
build #731 of lantiq/xway is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/731 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
<owrt-snap-builds>
build #738 of ramips/mt76x8 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/738 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
<rsalvaterra>
guidosarducci: Binary, of course. But I haven't tested an equivalent configuration (I usually don't build modules, my kernels are as monolithic as possible).
guimo has quit [Remote host closed the connection]
<guidosarducci>
rsalvaterra: I thought you meant sources... I've been doing some surveys of our kernel sizes going way back (and a little forward), and was surprised to find the ath79 lzma'ed 5.10 kernel only ~30KB larger than 5.4.
<rsalvaterra>
Heh… who cares about source code size? ;)
<guidosarducci>
rsalvaterra: usually our kernels grow by ~200KB/year last few years, which impacts future partitions, etc.
<rsalvaterra>
guidosarducci: That's probably also related to compiler version bumps.
<rsalvaterra>
For example, gcc 10 inlines much more aggressively.
<guidosarducci>
rsalvaterra: yeah, but more functionality gets packed into the "monolithic" part too, even not turning on new stuff.
<guidosarducci>
rsalvaterra: hmmm, I'd be really surprised if it was down to compilers, given how much tuning towards small sizes takes place.
<guidosarducci>
rsalvaterra: and all my experiments used the default compiler.. too scared to use gcc 10 full time yet.
<rsalvaterra>
I've been using gcc 10 for months, already… ath79 (24/74Kc), mipsel (mt7621), mvebu (cortexa9) and x86-64 compile and run perfectly.
guimo has joined #openwrt-devel
<guidosarducci>
rsalvaterra: and you're seeing big binary size increases? My usage has been testing with musl 1.2.x occasionally, so maybe more fragile than your usage.
<rsalvaterra>
Oh, I haven't touched musl yet… I'll wait for mangix. :P
<noltari>
I'm loving all this sudden attention from the buildbots :P
<zx2c4>
lipnitsk: things seem to more or less work for you?
codehero has joined #openwrt-devel
codehero has quit [Client Quit]
<lipnitsk>
zx2c4: testing now. I think they will though, because 'imply' seems to do the trick in upgrading CONFIG_PACKAGE_kmod-crypto-kpp from 'm' to 'y'
<lipnitsk>
more general question though - since openwrt probably will never build these modules into the kernel, won't IS_REACHABLE always return false?
<lipnitsk>
then we are really wasting space by adding kpp at all
<lipnitsk>
maybe some OpenWrt build system changes are needed to support excluding certain optional dependencies, though not sure how prevalent this case really is.
<lipnitsk>
zx2c4: I think there is wrinkle with your change - when I deselect CONFIG_PACKAGE_kmod-crypto-ecdh there are no more strong dependencies on CONFIG_PACKAGE_kmod-crypto-kpp, but it still gets set to 'y'. So the 'weak' thing doesn't appear to be working for me.
<lipnitsk>
zx2c4: in fact, even making a brand new .config, and only enabling luci-app-wireguard will bring in KPP, sadly.
<zx2c4>
lipnitsk: but, you can explicitly go in and uncheck KPP
<zx2c4>
imply is annoying. it allows you to opt-out, but it opts you in by default
<zx2c4>
but it's the closest we get to the weakdep that we need
<lipnitsk>
zx2c4: you are right. I think my hack was probably a little more automatic, but more kludgy too :)
<lipnitsk>
zx2c4: I was able to manually uncheck kpp (I guess you un-HIDDEN it?)
<lipnitsk>
zx2c4: still it seems that IS_REACHABLE branches in curve25519 will never run on OpenWrt, unless I'm misunderstanding something
<kab-el>
ynezz: I replied to your patch. It seems that U-Boot shouldn't be denying writes if disable-wp is not present, when there is no wp control mechanism (at least according to Linux mmc-controller device-tree binding documentation)
<ynezz>
kab-el: thanks for the review, without this I'm not able to write anything to emmc
<ynezz>
stock/vendor 2019.07 or latest 2021.04
<ynezz>
any 'mmc write' call fails
<kab-el>
ynezz: the correct solution here is to fix U-Boot's mmc code, to start behaving according to documentation
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<ynezz>
maybe it's just armada sdhci pins?
Tost has quit [Ping timeout: 264 seconds]
<grift>
yes the file is mislabeled
<grift>
wrong chn
<rsalvaterra>
tmn505: ping
<rsalvaterra>
tmn505: It's the first time I'm adding a reviewed-by tag, ever. Do I add it for each and every patch, or just the cover letter?
<tmn505>
for each patch
<tmn505>
the same with other tags
<rsalvaterra>
Thanks, will do.
opal has quit [Ping timeout: 268 seconds]
Darkmatter66 has joined #openwrt-devel
opal has joined #openwrt-devel
zatwai_ has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
zatwai has joined #openwrt-devel
<rsalvaterra>
tmn505: Sent. Some email threading weirdness with patch #1, I don't know what happened… :/
shibboleth has joined #openwrt-devel
blb4393 has joined #openwrt-devel
<tmn505>
rsalvaterra: LGTM. The patches in patchwork ocasionally are clasified outside of the series but I don't know specifics, happened to me few times.
<rsalvaterra>
tmn505: Yeah, it happened to me too on other occasions. Anyway, thanks for your patience! :)
dedeckeh has joined #openwrt-devel
kubrickdave_ has quit [Read error: Connection reset by peer]
kubrickdave has joined #openwrt-devel
Tost has joined #openwrt-devel
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
<rmilecki>
noltari: do you need "mtd fixtrx firmware"?
<rmilecki>
does that target use trx at all?
danitool has joined #openwrt-devel
Darkmatter66_ has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
<noltari>
rmilecki: yes, it’s needed on some devices
<rmilecki>
o
<rmilecki>
ok
valku has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
micmac1 has joined #openwrt-devel
<lipnitsk>
blocktrron: I see you made some small fixes - let me know if you want me to squash your kernel module .mk fixes into my kmod commit
feriman has quit [Quit: WeeChat 3.0.1]
<shibboleth>
can "master" build a "generic" ath79 mikrotik image (like the ones for ar71xx/19.07) or will support for each model/device have to be added separately?
<shibboleth>
like, for 1907 you'll find a couple of "generics", like nor/nand, small/large, ac/non-ac
<stintel>
Borromini: Dubai!
<Borromini>
stintel: to get vaccinated? :P
<Borromini>
enjoy though!
<stintel>
to get vitamin sea and sun
<stintel>
don't need a vaccin, covid is a hoax
* stintel
hides
<rsalvaterra>
Oh, I survived an hoax! :P
<rsalvaterra>
*a hoax
dedeckeh has quit [Quit: Connection closed]
Huntereb has joined #openwrt-devel
<Borromini>
💩
<blocktrron>
lipnitsk: ill let you know
rmilecki has quit [Ping timeout: 265 seconds]
micmac1 has quit [Quit: leaving]
<mangix>
jesus gettext is so slow to compile
<mangix>
gotta love the garbage build system is has
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
victhor has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Huntereb has quit [Read error: Connection reset by peer]
ivanich has quit [Quit: Konversation terminated!]
koniu has quit [Ping timeout: 268 seconds]
Tost has quit [Ping timeout: 256 seconds]
koniu has joined #openwrt-devel
<aparcar[m]>
mangix: aren't there better alternatives?