danitool has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
isak has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
drikus_ has quit [Ping timeout: 480 seconds]
drikus has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
<Mangix>
hmmm
<Mangix>
what is this safeloader-partitions
rua1 has quit [Quit: Leaving.]
isak has joined #openwrt-devel
cbeznea has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
valku has quit [Quit: valku]
dangole has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest2076
floof58 has joined #openwrt-devel
Guest2076 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openwrt-devel
Tapper has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
PaulFertser has joined #openwrt-devel
cbeznea has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
robimarko has joined #openwrt-devel
Borromini has joined #openwrt-devel
<robimarko>
What is the situation with targets moving to 5.15?
srslypascal is now known as Guest2105
srslypascal has joined #openwrt-devel
<robimarko>
Especially now that 6.1 is actual
Guest2105 has quit [Ping timeout: 480 seconds]
<\x>
any platforms that have 6.1 as testing?
<robimarko>
None as generic 6.1 is just a PR for now
<robimarko>
But I am asking as so far we did not have a case with 3 kernel versions
<\x>
ah
<\x>
807x prepped for 6.1?
<\x>
oooooooooooooo it is
<robimarko>
Havent really made a 6.1 build as I constantly rolling on next
<robimarko>
But its not hard as a lot of stuff made it into 6.1
srslypascal has quit [Ping timeout: 480 seconds]
<Borromini>
:)
* Borromini
still thinks mvebu should be migrated to 5.15 and the all kmods thing fixed
<robimarko>
mvebu has to be migrated to 5.15 by default
<robimarko>
I forgot that got reverted
<Borromini>
yes, I understand it's broken but bmork provided a quick fix... that seemed less pain to me than keeping it on 5.10 with the WRT AC series switch bug
<stintel>
robimarko: I wanted to do qoriq a few times but have this crash - I now found what causes it, will try repro on 5.10, if it crashes there too I'll bump, it's the only problem it has
<nbd>
robimarko: btw. please use @!LINUX_5_10 instead of @LINUX_5_15
<robimarko>
nbd: Yeah, good idea
<robimarko>
I found a bunch of those while helping Ansuel with 6.1
<stintel>
we should probably set some deadline for targets to be on 5.15
<robimarko>
I guess that would depend on the timeline for 23.x
<nbd>
robimarko: also, for the mhi/qrtr removal, please drop the removed files from the patch and remove them via commands in Build/Prepare
<nbd>
otherwise the patch gets annoying on every update
<nbd>
robimarko: other than that, the PR looks good to me
<nbd>
actually, one more thing
<nbd>
i think the ethernet encap/decap offload is a bad default as long as it breaks WDS
<nbd>
better to tell users to enable it only if they know that they're not going to use WDS
<nbd>
otherwise i expect a number of annoying bogus bug reports
<nbd>
maybe even patch the driver to complain loudly if WDS is enabled when encap/decap offload is enabled
<robimarko>
Yeah, that is why I kept that commit separate
<robimarko>
I was thinking of maybe adding a config option for that in menuconfig
<nbd>
please don't. people can use /etc/modules.conf for it
<nbd>
it would also be a good idea to keep reporting the WDS breakage with encap offload upstream
<stintel>
linux-firmware change should probably go before mac80211: add ath11k PCI support ?
<robimarko>
Ok, I will just drop it for now
<Borromini>
is this WDS breakage general across all drivers?
<robimarko>
stintel: FW doesnt really matter
<stintel>
robimarko: is it not needed?
<nbd>
Borromini: it's just ath11k being crappy
<robimarko>
It is
<\x>
Borromini: happens with ahb too
<robimarko>
but nothing is pulling it by default
<stintel>
still, adding a driver before adding firmware that needs it seems backwards
<robimarko>
Ok, its easy to change
<stintel>
that it needs*
<nbd>
Borromini: mac80211 handles wds with encap/decap offload just fine, and it works with mt76
<stintel>
it's not going to break bisecting, but I'd add the firmware first, so that as soon as the ath1k pci support commit is in, it is actually usable from that commit
<robimarko>
Yeah, i will flip the ordering
<stintel>
thanks
<stintel>
now I should *really* have another go at the bsap3040 :P
<stintel>
I have some ath11k cards collecting dust and the bsap3040 is the only device that can take them (if I figure out the extra power requirement)
<robimarko>
Depends on the cards you get
<robimarko>
QCA6390 is light
<stintel>
it's those 8devices with external power header
<robimarko>
Yeah, forget those
<robimarko>
Those are monsters
<Borromini>
nbd: \x: ok thanks
<robimarko>
BTW, did they fuse the board-id in yours
<stintel>
robimarko: asking me?
<robimarko>
Yeah
<stintel>
haven't been able to check
<robimarko>
You will want to
<robimarko>
So you can have it replaced if its one of the early ones
<stintel>
because a/ haven't been able to boot OpenWrt on the bsap3040 yet and b/ no idea how to check that
<robimarko>
Driver will tell you during boot
<robimarko>
If its 0xff
<stintel>
aight, thanks
<robimarko>
Then you know they did not fuse it
<stintel>
I ordered those a long time ago, probably should have just cancelled that order
<stintel>
but on the day I wanted to do that they sent me a shipping notification
<robimarko>
Hehe
<robimarko>
Compex now have miniPCI-e ones
<robimarko>
That only need 3.3V
<robimarko>
Obviously TX power is reduced
<stintel>
maybe I could have another look at the AP7060DN
<stintel>
that's not 6G but still 8x8 5GHz ax seems like a fun toy
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openwrt-devel
<robimarko>
Is that the fancy IPQ8074 one with SFP?
<stintel>
no SFP but 10GbE PoE++ uplink
<robimarko>
Even better
<stintel>
the u-boot is completely crippled though
<stintel>
so the first step would be to figure out how to build u-boot, then clamp-flash it
<stintel>
on the SPI NOR
<robimarko>
Thats easy if its close enough to one of the reference designs
<stintel>
robimarko: what's the best way to figure that out?
<robimarko>
By looking at what the stock FW firmware uses
<robimarko>
If you have acess to bootlog its easy
<stintel>
I do
<robimarko>
Just check the model
<robimarko>
But that does not guarantee that they did not modify the board too much
<robimarko>
I have a docker container for building this
<stintel>
public container or mind sharing the Dockerfile?
<hgl_>
tohojo: let's discuss here if you're there?
<robimarko>
I just manually made one
<robimarko>
So I dont have a dockerfile
<stintel>
k
<robimarko>
Just used the standard 16.04 ubuntu with a volume with the u-boot directory
<stintel>
got it
<hgl_>
about if we should expose /var/run/acme/challenge or $run_dir/challenge
<robimarko>
I can build an image
<robimarko>
If you want
<stintel>
no need, I'm fluent in docker/podman
<robimarko>
Thats not the hard part
<tohojo>
hgl_: sure, I'm here
<stintel>
ah you meant u-boot image
<robimarko>
Yeah
<stintel>
I thought you meant container image ;p
<hgl_>
cool, which one do you think is better, absolute value or a variable?
<stintel>
well if you have everything set up for it and know the landmines, sure
<robimarko>
stintel: Recently had to build images so I have everything ready
<robimarko>
Can you just interrupt u-boot and run version
<robimarko>
I think they are still running 32 bit U-boot images
<stintel>
give me 5-10 minutes
<tohojo>
hgl_: my thought is that since everything else comes from exported variables, it seems odd that this particular value should be hard-coded?
<stintel>
need to reassemble :P
<tohojo>
hgl_: also makes it harder to change in the future, say if we need to move from /var/run to /run or something
<hgl_>
tohojo: i see your point. i think the difference is that the values we export are all user options, were the challenge dir value isn't
<hgl_>
tohojo: actually, i forgot that think value is actually a standardized value should be hard coded, because httpds need to specify this value in their conf to serve acme challenges
<hgl_>
*this value
<hgl_>
so we can't really make it into a variable
schwicht has joined #openwrt-devel
<tohojo>
yuck
<hgl_>
yeah, we have to standardize it like we did with /etc/ssl/acme
<tohojo>
doesn't have to mean it can't be a variable in the code, though...
<hgl_>
tohojo: do you think we should use a better path?
<stintel>
gahhh I really need to order me 10 USB to RJ45 console adapters
aleksander has quit [Quit: Leaving]
<hgl_>
tohojo: if it's a standardized value, I'm not sure giving acme-clients an extra value to depend on for the same value is that useful.
<tohojo>
hgl_: having hardcoded paths scattered everywhere is a terrible practice regardless of the stability of those paths 🙂
<hgl_>
tohojo: well, they serve different purposes, kinda unavoidable 😂
<stintel>
o-oh
<stintel>
no output
<tohojo>
hgl_: no it isn't, just export it and use $run_dir ? 🙂
<stintel>
ah, default baud rate
<hgl_>
tohojo: so that means, acme-client hooks should use $run_dir, but httpds should use /var/lib/acme/challenge?
<stintel>
robimarko: Password for uboot cmd line :
<stintel>
sigh
<stintel>
aha
<tohojo>
hgl_: yup - human-facing configuration uses the path, code uses the variable...
<tohojo>
and another handful at the end of the file
<hgl_>
well, that could be optimized by define a variable in the acme-client itself. I'm asking if you think we defined too many standard paths?
<hgl_>
and to be honest, you don't see people complaining repeating nine times of /usr/lib/python something, once they get used to the paths :)
<stintel>
fatal: bad revision 'v5.10.158..v5.15.80'
<stintel>
what am I doing wrong again
<stintel>
ah, git fetch linux-stable
<hgl_>
tohojo: If you don't object, I'm going to remove the $challenge_dir variable, since it doesn't really fit in with the rest variable we export...
<tohojo>
hgl_: in terms of consumers I think we only define two integration points, right? /etc/ssl/acme and /var/lib/acme/challenge ? so export those as $cert_dir and $challenge_dir ?
<hgl_>
tohojo: we also define /usr/lib/acme/hook and /usr/lib/acme/functions.sh integration points, oh and /usr/lib/acme/notify
<tohojo>
hgl_: not for consumers of the certificates - those are only used for people two implement a backend
<tohojo>
i.e., everything that's not part of an acme-* package
<hgl_>
tohojo: i see. how they going to use $cert_dir and $challgen_dir if, for example, they need to use it in a nginx conf?
<tohojo>
in configuration files would still need to enter them manually, obviously...
<hgl_>
i don't understand, so what's the use for exporting them?
<tohojo>
for hook scripts
<hgl_>
isn't hook script only for acme-* packages?
<tohojo>
sorry, hotplug scripts
Kiste has left #openwrt-devel [#openwrt-devel]
<tohojo>
although we only really have one, for haproxy
<tohojo>
and what it's doing really should be in a service hotplug script (writing into certs_dir)
<hgl_>
tohojo: i'm not sure using hard-coded value in configs, but variabels in hotplug scripts in the same package is a good practice to encourge to be honest.
<tohojo>
hgl_: the difference is that hotplug scripts is something that ships with the package and users are not expected to modify them
<tohojo>
whereas daemon config is something we expect users to input manually
<hgl_>
tohojo: the point of using variables, IMHO, is to signal that they shouldn't care about the real value, because it can change, but we have standardarized the value, if we change them we break httpd config files, do I really see a value of providing variables here. but maybe I missed your side of views? Why do you favor variables in this case?
<hgl_>
*so I don't really
<tohojo>
hgl_: every value used in a piece of code should be set exactly once in that codebase; if it's being used in multiple places that implies a variable
<tohojo>
otherwise you get bugs because values diverge
<tohojo>
your update to the PR already fixed one such bug, in fact...
<hgl_>
tohojo: I respectfully disagree. FHS paths are really defined in variables. If consumers want to save some typing, they could define the variable themselves.
<hgl_>
*aren't
<tohojo>
hgl_: it's not about saving typing, it's about exporting a consistent interface. anyway, I don't really want to spend more time on endless bikeshedding of this issue; I'll just merge your PR as-is and fix up the rest myself...
<stintel>
[ 9.921659] F2FS-fs (loop0): Failed to read root inode
<stintel>
FFS
<stintel>
karlp: ^
<stintel>
now hitting this on qoriq
<stintel>
so yeah, definitely something hosed in f2fs
<hgl_>
tohojo: there is already a consistent interface, it's the path we define. You're of couse free to modify the package since you're the maintainer, but since I also contributed some siginificent code, I'd appreciate if you don't try to big-foot. I'm not fan of bike shedding too, and I appreciate the time you took to review code. But we are talkign about designing a base package
<hgl_>
for other packages to depend on. What we choose to expose can have a big impact here.
<tohojo>
hgl_: not really? the main contract remains the same: packages depend on /etc/ssl/acme and /var/run/acme/challenge - exporting those just makes that explicit
<Borromini>
stintel: do you have VLANs set up on your GS108T v3?
<Borromini>
my GS1900-10HP is fine but my GS108t v3 isn't cooperating
<hgl_>
tohojo: I think I see your point. So it's really in hotplug scripts that we should make the paths more explicit? Then the $challenge_dir in my PR really didn't do that, and in hotplug scripts maybe the variables should be in upper case? The lower case convention we took were really for user options.
<tohojo>
hgl_: yeah, I'm OK with upper-casing them 🙂
<hgl_>
tohojo: so CERT_DIR and CHALLENGE_DIR?
<hgl_>
tohojo: do you want to write the fix or I should send the PR?
<tohojo>
hgl_: yeah; I'll push a PR in a sec
<hgl_>
cool
<tohojo>
hgl_: I also think we should move the combined certificate thing out of the haproxy hotplug script... a combined bundle seems like something the framework should provide?
<tohojo>
also not great that it's writing into CERT_DIR
<Borromini>
stintel: nevermind, PEBKAC.
<hgl_>
my rationale was to stick with what certbot provides, but I'm not against doing it in the base package since haproxy is popular. I just hope that doesn't mean we have to support other kinds of combined certificate for other new httpds.
<Borromini>
:facepalm:
<stintel>
Borromini: :D
<tohojo>
hgl_: what other kinds of combined certificates are there? 🙂
<hgl_>
we will only know when the PRs come in :)
<stintel>
dd: invalid argument 'sync' to 'oflag'
<stintel>
ugh busybox
minimal has joined #openwrt-devel
<Borromini>
:P
<tohojo>
hgl_: well the 'cat' bundle is pretty common; if there are other bespoke things, hotplug scripts can create them, but store them somewhere private to that daemon
<stintel>
this f2fs bug is seriously annoying though
<stintel>
[ 9.897490] mount_root: overlay filesystem in /dev/loop0 has not been formatted yet
<hgl_>
tohojo: sure. I'll leave that to you as well?
<stintel>
I added f2fsck to the image and that made it big enough to overwrite the start of the previous overlay
<tohojo>
hgl_: and sorry for being terse, didn't mean to just override you; I do really appreciate all the work you've done on refactoring the acme scripts! 🙂
valku has joined #openwrt-devel
<stintel>
yep. f2fs is definitely very broken
<stintel>
flash my 2nd m300, dead
<jow>
let's drop it then?
<jow>
we have far too many variations anyway
<stintel>
well it's been working quite well for long enough
<stintel>
but some bug crept in a recent kernel
<stintel>
and it seems to hit very often
<stintel>
I guess the mass users of this aren't on 5.15 kernel yet
<jow>
yeah, but it's a niche usecase within a niche usecase
<jow>
... within a niche usecase
<shibboleth>
stintel, we last spoke a few months back re wpa8630 sysupgrade
<shibboleth>
seems something is broken, there's just no way this device will retain config. free space=98%
<stintel>
jow: what bothers me more is that procd tears down the loopback device and it's impossible to even fsck
<stintel>
shibboleth: probably we should increase the thresholds that decides jffs2 vs f2fs overlay
<jow>
stintel: then let's change procd?
<stintel>
jow: I will look into it
<shibboleth>
dunno about that, but the status quo has been a shit-show ever since this device was moved to "tiny". also, "jwmulwalleysomething" is not on irc
<jow>
still, having to support two overlay fs choices which are seemingly randomly (I know,, based on size threshold) chosen is just a recipe for future issues
<stintel>
jow: just didn't have a repro ... and now it's on my main router - needs to be fixed
<jow>
it duplicates the likelyhood of bugs and halves the attention/avaialöble manpower for fixes
<stintel>
but I'll spin up a VM and see if I can repro there
<jow>
coupled with the additional complexitly of the offsetted-loopback setup etc. it quickly becomes an unmaintable mess
<stintel>
so we should drop f2fs and go back to jff2s and block2mtd ?
<stintel>
not sure I'm really in favor
<jow>
would be the most straightforward course of action ihmo
<jow>
or always use f2fs and fix it for good
<jow>
I like arch linux' intro to f2fs
<jow>
"F2FS has a weak fsck that can lead to data loss in case of a sudden power loss" "If power losses are frequent, consider an alternative file system."
<jow>
sounds like a prime choice for embedded targets not even featuring a proper shutdown :)
<jow>
possible that the above info is outdated though
<stintel>
f2fs doesn't work on really small so we can't always use it
Borromin1 has joined #openwrt-devel
* stintel
labels today as another yak shaving day
<jow>
but isn't data loss a higher risk on larger storages? on small ones you wouldn't store valuable data to begin with
<stintel>
data loss is always a risk, if it's valuable data you should have backups
<jow>
anyhow, I understand that this wasn't your choice, it just broke on you
<stintel>
can't really speak for the data loss on power loss - I have a big UPS here
<stintel>
but it's been working quite well
<stintel>
and right now this happens just on sysupgrade
<stintel>
so it's just a bug that needs tracking down
<stintel>
and procd handling improved
<stintel>
I'll have a go at the latter
<stintel>
and maybe report it on some mailinglist
<stintel>
shibboleth: what's the size of your overlay ?
Borromini has quit [Ping timeout: 480 seconds]
<shibboleth>
stintel, sure, but "oh snap, RCE in wpad, gotta flash" -> "fiddlesticks, reverted to default config" = "bad times all around"
<stintel>
ok so I found the commit that causes the xfrm crash
<shibboleth>
Filesystem 1K-blocks Used Available Use% Mounted on
<shibboleth>
dunno if these figures are sufficient?
<stintel>
I'll look at it later, want to fix this xfrm bug first so I can bump qoriq to 5.15
<shibboleth>
k
<mrkiko>
stintel: yeah, and before that you might look at the f2fs changes from 5.15 to 6.1. Not a straightforward process maybe, but may save you some time later
<Slimey>
interesting adtran is saying its something in our environment at all three campuses thats causing these waps to die with more details coming soon
<stintel>
mrkiko: pretty sure this is something that was introduced in an LTS bump so it should be fixed there
<Slimey>
stintel nice i can test that out, 5.15 bump
<stintel>
Slimey: been running that for months, only problem is the xfrm crash when my phone is connected to strongswan via WAN then I come home and it connects to wifi (lan)
<stintel>
lolwut, this references a strongswan bug which claims to run OpenWrt 21.0.2 with kernel 5.15.32
Gaspare has joined #openwrt-devel
<robimarko>
That looked "fun" to figure out
<robimarko>
Ask the reporter which Chinese flavor is he running
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<stintel>
> There is no such thing. OpenWrt 21.02 only supports kernel 5.4. Please ask whoever supplied you with this OS to stop using the OpenWrt name.
<stintel>
not too harsh?
<robimarko>
Too light for my approach
<robimarko>
I am sick of the various china forks
<robimarko>
Conviently they also like to change the authors of stuff they pick
<stintel>
seriously?
<robimarko>
Yeah
<f00b4r0>
yeah they do that. I've seen it too
<robimarko>
The "coolsnowwolf LEDE" had stolen most of the ipq807x target
<f00b4r0>
can't tell for sure whether it's malice or sheer incompetence. The latter requiring less smarts of course, so more common ;P
<robimarko>
I am trying to believe its just incompetence
<f00b4r0>
same
<robimarko>
I am having people open issues against my repo but they are running QSDK or more common one of the China QSDK/OpenWrt monstruosities
<stintel>
I guess incompetence could be .. squash a whole bunch of commits, lose the history, and original authors
<robimarko>
I wish they squashed
<stintel>
this squashing seems to be common practice in a whole lot of oss projects
<f00b4r0>
stintel: it looks for the most part as if they never heard of "git am"
<f00b4r0>
or a proper git pull+merge from foreign repo
<robimarko>
They just dont care
<f00b4r0>
*nod*
<robimarko>
My issue is that they just take, and take, and take
<robimarko>
But never contribute back
<robimarko>
However they like to make requests for support or that they are missing something
<stintel>
:)
<stintel>
I closed some issue like that recently
<robimarko>
I have to say closing issues like that gives me some satisfaction
zatwai has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
zatwai has joined #openwrt-devel
cbeznea has joined #openwrt-devel
danitool has joined #openwrt-devel
DeadEnd has quit [Remote host closed the connection]
cc0 has joined #openwrt-devel
cc0 has quit [Read error: Connection reset by peer]
cc0 has joined #openwrt-devel
cc0 has quit [Remote host closed the connection]
cc0 has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
<Znevna>
let's crash my wifi
<Znevna>
yup, still crashes
<Borromin1>
Znevna: with the lowered flash speed?
<Znevna>
oh, no, that ppe0 thing
<Znevna>
c6u was stable with spi freq lowered to 66MHz
<Znevna>
no more missing pcie devices
<Znevna>
how are those related beats me
<Znevna>
could it be it was trying to read something from spi and failing silently but kept something busy just enough to miss the pcie detection?
<Borromin1>
:)
Borromin1 is now known as Borromini
<Znevna>
¯\_(ツ)_/¯
vglfrei1 has joined #openwrt-devel
vglfrei1 has quit []
vglfrei1 has joined #openwrt-devel
<ukleinek>
I have a temperature + humidity sensor here, the temperature value is shown just fine in the webif, the humidity sensor however doesn't appear.
<ukleinek>
I guess I need to expand applications/luci-app-statistics/htdocs/luci-static/resources/statistics/rrdtool/definitions/sensors.js, but I have no idea and would welcome a hint.
vglfrei1 is now known as dether_
dether_ is now known as dether
dether has quit [Quit: Bye!]
dether has joined #openwrt-devel
dether is now known as Guest2164
Gaspare has joined #openwrt-devel
vglfrei has quit [Quit: Bye!]
Guest2164 is now known as dether
dether has quit [Quit: Bye!]
dether has joined #openwrt-devel
Borromini has left #openwrt-devel [#openwrt-devel]
cbeznea has quit [Quit: Leaving.]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<rmilecki>
Mangix: feel free to ask me about safeloader-partitions
<rmilecki>
Mangix: basically we have a Linux MTD parser that reads partitions table from flash and registers MTD partitions as specified there
<rmilecki>
Mangix: that doesn't require to hardcode any offsets that may actually change
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Gaspare has quit [Quit: Gaspare]
robimarko has quit [Quit: Leaving]
csrf has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
bluew has joined #openwrt-devel
<jow>
stintel: dunno. users should set firewall.wan.forward=accept if they need it...
<jow>
it is almost certain that nobody will pick up such vague suggestions and that these tickets will rot
<jow>
and the very low effort that went into writing this feature request does not exactly inspire volunteers to do it
<stintel>
jow: I agree that the user should set it if needed
<stintel>
but they could do things properly and use xfrm interfaces
<stintel>
I closed it
<stintel>
I also closed one issue today and referred the user to the forum/ML/IRC, as it's clear they had no idea what they were doing, or how to produce the data we need to actually help them
<stintel>
the issue tracker is not the place for this kind of help
<stintel>
no luck so far injecting a non-crippled u-boot in the AP7060DN NOR
<stintel>
now I found 2 locations with an "OpenWrt" FIT image
<stintel>
maybe I can inject a kernel instead
<stintel>
wait we have no issue template whatsoever?
<jow>
maybe we should discourage feature requests in the issue template
<jow>
once we add one, that is
<jow>
a feature request should come in the form of a proposal that explains function, scope, requirements and drawbacks
<jow>
and not "hey guys, plz do vepa"
<jow>
if discourage is too harsh then maybe a standard text to autoclose such tickets
<jow>
or rather to close that tickets manually, referring users to forum and mailing lists for discussion
<stintel>
I'll play a bit with issue template
<stintel>
also discourage first-time builders from opening an issue because their build fails
<stintel>
they're almost certainly doing something wrong
<jow>
also explaining that questions for help/support will be closed
<jow>
but I fear that the result will be intimidating
<jow>
the "plz do $feature" guys won't read it anyway and just dump their thoughts into an issue
<jow>
and those with a legitimate concern will potentially refrain from posting an issue due to the long list of "don't" points