<aparcar[m]>
mangix: doesn't look like it. I'm still in favor for a codeowners file and grant more maintainers access.
<mangix>
he's been consistenty asking in his PRs
<aparcar[m]>
there is no good platform to discuss such things, I'm wondering if we should enable github discussions for such matters.
<aparcar[m]>
I doubt many packages.git maintainers actively follow adm or devel mails
hbug has joined #openwrt-devel
DragoonAethis has quit [Quit: hej-hej!]
tobleminer-tSYS has quit [Quit: AS4242423214]
<mangix>
from a different channel:
<mangix>
02:57 <@DEATH> Would it hurt someone's feelings if OpenWRT wiki had factory flash instructions for ER-X that actually work?
<mangix>
02:58 <@DEATH> initramfs.bin doesn't work, not the current one, not older ones. The .tar works. Apparently the problem is widely reported?
tobleminer-tSYS has joined #openwrt-devel
<mangix>
03:01 <@DEATH> Doing exactly what the wiki tells you = zomg error.
hbug___ has quit [Ping timeout: 268 seconds]
DragoonAethis has joined #openwrt-devel
bkallus has joined #openwrt-devel
gromero has joined #openwrt-devel
gromero_ has quit [Ping timeout: 246 seconds]
Huntereb has joined #openwrt-devel
bkallus has quit [Remote host closed the connection]
gromero has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
gromero has joined #openwrt-devel
gromero_ has joined #openwrt-devel
gromero has quit [Read error: Connection reset by peer]
gromero__ has joined #openwrt-devel
gromero_ has quit [Read error: Connection reset by peer]
gromero__ has quit [Read error: Connection reset by peer]
gromero__ has joined #openwrt-devel
gch9812133 has joined #openwrt-devel
gch9812133 has quit [Client Quit]
gch981213 has quit [Read error: Connection reset by peer]
danitool has quit [Ping timeout: 240 seconds]
<aparcar[m]>
mangix: my feelings could endure a working er-x image.
<aparcar[m]>
mangix: would you mind merging iperf and request the changes. That way we'd had the same state as now in the history
* enyc
meows
<enyc>
I understand OpenWRT-DSA not to be complete in 20.xx, lantiq and some others still using swconfig...
Tapper has joined #openwrt-devel
* mangix
meows back
Huntereb has quit [Read error: Connection reset by peer]
<mangix>
enyc: this is true. patches welcome
<pkgadd>
enyc: (afaik) the stated goal for 20.xx is not to have DSA everywhere (yet), but to have DSA support roughly feature complete with legacy swconfig (in netifd (mostly done) and luci (PR mostly functional, but not yet merged to luci/ master)) - and to move further targets as they get ready (ipq40xx and ipq806x aren't too far away from being ready, ath79/ ar8327n is imaginable, but will need quite some
<pkgadd>
efforts)
<pkgadd>
and yes, SDA for lantiq is being worked on as well (mainline)
<pkgadd>
s/SDA/DSA/
<enyc>
pkgadd: i see, also seems to me like this is basically an inevitable-change and a 'tidy up' to complete later, no functional need to try to fully-complete or any of that.
<enyc>
[at the moment]
<pkgadd>
enyc: this https://github.com/openwrt/luci/pull/4307 is basically the major piece missing for (very rough) feature equivalence between swconfig support vs DSA support
<pkgadd>
and yes, targets can be migrated one by one
<enyc>
pkgadd: I'm using lantiq so many not see this much
<enyc>
pkgadd: I notice example showing MTU's per interface pictured....
<pkgadd>
I've lightly tested it on realtek (rtl8382m) and was quite happy with it so far
<enyc>
I've experienced the problems with inability to select MTU on vdsl/pppoe and all that...
<pkgadd>
so far my ZyXEL gs1900-8 is my first and only device (really-) using the DSA framework so far, and that one never had swconfig drivers (nor do I need to bother about PPPoE and lower MTUs on a managed switch)
<enyc>
pkgadd: hrrm my PPPoE/vdsl is probably not about the switch....
<enyc>
pkgadd: is PPPoE over lantiq DSL driver
<pkgadd>
enyc: I haven't looked into DSA on lantiq so far (my bthub5 is just using plain master)
<enyc>
pkgadd: how often do you update?
<enyc>
hostapd - 2020-06-08-5a8b3662-28 -- hrrrm this is the other area holding-up openwrt-20 ? waiting for some extra drivers etc ...?
<enyc>
patches i should say
<pkgadd>
it depends, a lot - last time ~5h ago. I follow the commits going into master and update as I see important or interesting commits going in (respectively interesting/ unmerged patches being proposed), on average probably somewhere between 1-2 times a week to 6-8 weeks at most
<enyc>
i've been testing mine doesn't crash ;p
<enyc>
was in some tizwoz rebooting itself before, seems now to be ''stable'' .... I put on network log, and serial-console log with '4' debug selected at bootup...!
<pkgadd>
hostapd is (imho) not contentious topic, any changes (apart from targetted fixes) would basically reset the clock and invalidate prior testing, so a bigger update (which is needed for proper 802.11ax support) will have to wait for post-2020-xy
<enyc>
and now its not crashing ;p
<enyc>
pkgadd: in any case are there 'supported devices' that would benefit *anyway* ?
<pkgadd>
probably
<enyc>
pkgadd: and could those 802.11ax devices simply have updated hostapd option for *them* i.e. a backport ?
<aparcar[m]>
mangix: merge?
<pkgadd>
no
<enyc>
pkgadd: ok i'm used to handling debian ubuntu linuxmint ... packaging there, why does 'no' apply here in the openwrt-case ?
<pkgadd>
it's not a reasonable option for 20.xy.X to retrofit 802.11ax support
<pkgadd>
and it's not exclusively hostapd which would need- or profit from changes for 802.11ax support
<pkgadd>
all that is $next_release (respectively master after branching off openwrt-2021.xy)
<enyc>
pkgadd: ok so what needs sorting out in the social/political/people/etc matters to cause the openwrt-20 branch to be time to happen?
<enyc>
contentious question too?
<pkgadd>
enyc: I'm not an OpenWrt developer, nor can speak for the project - don't ask me
<pkgadd>
I just see the code and realize what (imho) is missing/ needs doing, but that's it
murphyslawbbs[aw has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
<enyc>
aparcar[m]: have done, theres' a mail-thread about the DSA, i see LuCI commits in progress there...
<enyc>
aparcar[m]: no links about the hostapd ... anything about 802.11ax controversies or so
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
dangole has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
mixi_ has quit [Read error: Connection reset by peer]
mixi_ has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<blocktrron>
enyc: there isn't any controversies I'm aware of in regards to 802.11ax
<enyc>
blocktrron: ok pkgadd was basicaly asying as a non-dev not sure if to keep backporting/updating hostapd in order to support 802.11ax etc
<blocktrron>
i don't think this happens this close to the release. HE rates will be supported in the upcoming release, however te full WiFi 6 featureset might be absent. Also implementations in LuCI might not work that well
ivanich has quit [Quit: Konversation terminated!]
<blocktrron>
There are only two WiFi 6 devices in OpenWrt at this point, one of which seems to be china only. So this shouldn't be that much of an issue currently.
ivanich has joined #openwrt-devel
<enyc>
blocktrron: hrrrrrrrrrrrrrrm ok yes just found htat HE is name of 802.11ax =)
<blocktrron>
There's more (TWT, BSS coloring) which is still missing from UCI to my knowledge
<blocktrron>
However this might be due to them currently missing ion the driver side (not sure, haven't looked into)
<enyc>
blocktrron: hrrm... nad how well supported ary drivers/devices/bugginess there of the 802.11ax devices etc etc anyhow! good question!
<shibboleth>
would be great if this could be merged before 20.xx
<shibboleth>
kudos to jacekowski, tested and confirmed by me and pkgadd
<shibboleth>
somehow it ended up in /dev/idle on patchwork
<ldir>
hmmm, trying to upgrade apu2 with image built from latest master, sysupgrade reporting "Device pc-engines-apu2 not supported by this image Supported devices: generic"
mixi__ has joined #openwrt-devel
mixi_ has quit [Ping timeout: 264 seconds]
<adrianschmutzler>
shibboleth: well, as you see, it's marked "Changes Requested"
<adrianschmutzler>
so nobody will merge it
<shibboleth>
i misread it as "changes being considered", basically. i should ask him to resubmit as ipq806x/general instead of the zyxel specifically?
<adrianschmutzler>
Well, ask him to address the requested changes. There are obvious formal shortcomings and then a discussion about the content which I didn't follow.
<ldir>
adrianschmutzler: f52081bcf938efcd910832f3c3713ab9f3ca0738 has b0rked sysupgrade for me on an x86 apu2.
<ldir>
I've reverted it in my tree for the moment. My guess is that "pc-engines-apu2" != "generic"
<shibboleth>
which "format"/syntax would you suggest/advise for a "general" arch dts addition/change?
<shibboleth>
patch each of the affected dts?
<adrianschmutzler>
ldir: strange. possibly something in x86 expects SUPPORTED_DEVICES to be empty?
<adrianschmutzler>
without having looked, this sounds to me like it's broken in x86 ...?
<shibboleth>
alright. jace happens to be online. jacekowski, thoughts?
<ldir>
I don't know how it's supposed to work - I don't see individual build options for 'apu2' etc just 'generic' - so if we're expecting an image for all potential x86 boards then that isn't going to happen.
<adrianschmutzler>
ldir: try adding `SUPPORTED_DEVICES :=` to Device/Default in x86/image/Makefile
philipp64 has quit [Ping timeout: 260 seconds]
philipp64_ is now known as philipp64
<ldir>
ok I'll let you know
<adrianschmutzler>
but I still wonder how this breaks, I'd have expected x86 to completely ignore SUPPORTED_DEVICES
<adrianschmutzler>
I will try grep for where the message is generated, maybe I can find out more
mixi_ has joined #openwrt-devel
<jacekowski>
so what do you need me to do?
<shibboleth>
jacekowski, looks to me: resubmit, change subject, add comments
<ldir>
adrianschmutzler: this will take some time - a glibc patch has snuck in so make is rebuilding the toolchain as well - grrrr!
<jacekowski>
ok, will look into doing that
<shibboleth>
ty
mixi__ has quit [Ping timeout: 272 seconds]
mixi__ has joined #openwrt-devel
<adrianschmutzler>
ldir: what I don't understand is why the device uses SUPPORTED_DEVICES at all; x86 has a custom platform_check_image, so it should not care about SUPPORTED_DEVICES at all ...
<ldir>
I haven't looked at it at all, sorry - just reporting my experience....and reverting that one patch fixed it.
mixi__ has quit [Read error: Connection reset by peer]
mixi__ has joined #openwrt-devel
<adrianschmutzler>
ldir: ah, I've found it
<adrianschmutzler>
x86 uses append-metadata
mixi_ has quit [Ping timeout: 272 seconds]
<adrianschmutzler>
and that checks whether SUPPORTED_DEVICES is empty
<adrianschmutzler>
will have to have a closer look there
mixi__ has quit [Read error: Connection reset by peer]
<adrianschmutzler>
so, setting SUPPORTED_DEVICES to empty as suggested above will almost certainly work
<adrianschmutzler>
at least until I've found a better way
mixi__ has joined #openwrt-devel
<ldir>
he he - great, thank you
<adrianschmutzler>
okay, now let's find out how many targets are affected :-(
mixi__ has quit [Read error: Connection reset by peer]
mixi__ has joined #openwrt-devel
<ldir>
adrianschmutzler: always glad to be the 'regression canary' :-)
<ldir>
better it be found early
<adrianschmutzler>
well, that's indeed very valuable here, because I still don't understand why this happens, only how
mixi__ has quit [Read error: Connection reset by peer]
<adrianschmutzler>
so, I was totally unaware in the first place that this could break at all this way
mixi__ has joined #openwrt-devel
<ldir>
he he - a learning opportunity :-D
<adrianschmutzler>
would be nice if you could verify my workaround, then I would patch that into the affected targets
mixi__ has quit [Read error: Connection reset by peer]
mixi__ has joined #openwrt-devel
<ldir>
I'll let you know - as I said unfortunately I'm having to rebuild the toolchain.... on my macbook.
<adrianschmutzler>
I won't really be available for the next 1-2 hours anyway
<adrianschmutzler>
just quickly going through targets now before I have to leave again
<ldir>
oooh installing a native 'ccache' implementation has helped speed toolchain rebuilds a bit.
mixi__ has quit [Ping timeout: 264 seconds]
<adrianschmutzler>
okay, looks like the only other affected target is octeon for a single device, and this looks like a mistake to me
<adrianschmutzler>
aparcar[m]: do you know why x86 uses append-metadata?
<aparcar[m]>
signatures are added in that step
<aparcar[m]>
ucert/usign
<aparcar[m]>
does it cause trouble?
<adrianschmutzler>
well, it adds SUPPORTED_DEVICES if they are not empty
<adrianschmutzler>
which breaks sysupgrade since they are not empty by default now anymore
<adrianschmutzler>
just wanted to make sure this is intentional, because essentially only x86 does this
<aparcar[m]>
only x86 appends metadata?
Borromini has quit [Quit: Lost terminal]
<adrianschmutzler>
without using SUPPORTED_DEVICES for upgrade
<adrianschmutzler>
or at least setting it up properly
<nyt>
so what's the proper procedure for having sysupgrade work on generic x86?
<adrianschmutzler>
in other words: x86 is the only target using append-metadata with adding the supported-devices json
<adrianschmutzler>
The fix for the current situation is simply adding `SUPPORTED_DEVICES :=` to Device/Default in the target.
<nyt>
/tmp/sysinfo is never created if board_vendor and sys_vendor are empty
<adrianschmutzler>
I just wonder about how append-metadata is used here.
<nyt>
hm product name and board name exist though (continues reading)
<adrianschmutzler>
note that supported_devices is about images, you are looking at the other side of the match
<nyt>
i just ran into this since building a new image for the first time in 240 days
urjaman has quit [Read error: Connection reset by peer]
<nyt>
in lib/preinit/01_sysinfo [ -n "$vendor" -a -n "$product" ] || return
urjaman has joined #openwrt-devel
<nyt>
so /tmp/sysinfo is never made
<nyt>
cat: can't open '/tmp/sysinfo/board_name': No such file or directory
<nyt>
Sat Jan 23 16:09:53 EST 2021 upgrade: Device not supported by this image
<nyt>
Sat Jan 23 16:09:53 EST 2021 upgrade: Supported devices: generic
anonzadas has quit [Quit: ZNC 1.6.5+deb1 - http://znc.in]
<nyt>
oh
<adrianschmutzler>
yes, and that's why comparing it with "generic" in metadata yields false
<adrianschmutzler>
nothing != generic
<adrianschmutzler>
so, one could also just provide the proper board_name and would not have to change the image
<adrianschmutzler>
I just would not have expected the whole mechanism to be active at all, with platform_check_image set inside x86.
<nyt>
well, board name and product name exist
<adrianschmutzler>
well, I think I will just add SUPPORTED_DEVICES and then somebody actually using x86 should check whether the upgrade mechanism can be improved
<nyt>
but board vendor and sys vendor are empty
<nyt>
so 01_preinit just bails without writing anything
Acinonyx_ has joined #openwrt-devel
<ldir>
on my apu2 sysinfo/board_name & model are set
<adrianschmutzler>
probably the cleanest way would be to split out the ucert stuff from append-metadata so it can be called separately
<adrianschmutzler>
The current problem is actually caused because append-metadata now actually appends metadata
feriman has quit [Quit: WeeChat 3.0]
<ldir>
build getting closer to finishing....
<adrianschmutzler>
maybe aparcar can have a look into that
<adrianschmutzler>
I will have dinner now ...
Acinonyx has quit [Ping timeout: 256 seconds]
feriman has joined #openwrt-devel
<nyt>
so i have a build that supports any x86 device as well as apu2, if i set supported_devices to something other than empty, how is it supposted to work in this case?
<nyt>
this is silly :/
<aparcar[m]>
adrianschmutzler: sure can
<nyt>
preinit should probably be dumping 'generic' into /tmp/sysinfo instead of empty
<nyt>
or something
<ldir>
adrianschmutzler: this hack has worked for me https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=f12b2107a0879ff58c1f47d90b846bae534bc084