<yolo>
there is `define Package/softflowd/install` in the Makefile, why 'make package/feeds/packages/softflowd/install' fails saying "no rule to make package.../install"? {clean,compile} are not present in the Makefile which means they're default, both worked fine
<yolo>
it has been a while, i think the make {clean,prepare,compile,install} changed these days
<stintel>
make package/softflowd/{clean,install}
<stintel>
or s/install/compile/
<yolo>
so compile and install can not coexist?
<yolo>
used to do {clean,prepare,compile,install}, even {deploy}
<stintel>
I'm not entirely sure about compile/install, but your main issue is make package/feeds/packages/softflowd/... vs make package/softflowd/... afaik
<yolo>
in fact, make package/../install fails, compile/clean works OK
<stintel>
then install is not valid
<stintel>
it's valid for target/linux/install
<yolo>
so the make works for 'official' packages under package/ not those under package/feeds/packages then
<yolo>
i mean when install is used, will look into it
<stintel>
no, make package/$PKG_NAME/.... works for everything under package/ so that includes feeds
<stintel>
but there is no package/$PKG_NAME/install target
<yolo>
softflowd does have a install target, why package/feeds/packages/$PKG_NAME/install not working is beyond me
<dwfreed>
no, it has a defined install *function* not a target
<dwfreed>
and the package/foo/compile target makes the entire package
Tapper has quit [Ping timeout: 480 seconds]
paper_ has quit [Ping timeout: 480 seconds]
paper_ has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #openwrt-devel
csrf1 has quit [Quit: Leaving]
cbeznea has joined #openwrt-devel
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<aparcar[m]>
anyone got experience with "vendoring" OpenWrt?
goliath has quit [Quit: SIGSEGV]
danitool has joined #openwrt-devel
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
f0g has joined #openwrt-devel
<f0g>
jow: Excellent explanation. Thanks a lot.
<hgl>
jow, it seems when a service is stoped, "/etc/init.d/<svc>" reload would restart it. In acme hotplug, I'd like to make reloading a service a no-op if the service is stopped, any idea how to do that?
<hgl>
Is it possible to rely on procd to do the reloading? I'd really prefer to refrain from manually checking if a service is stopped in the acme hotplug script.
<hauke>
They have the script in scripts/gen_config.py to generate profiles
<hauke>
better to apply profiles and merge them
<hauke>
I do not know if that is what you are looking for
<aparcar[m]>
yea I think I initially created the gen_config.py script 😄
<aparcar[m]>
I'm looking for a clean way to bundle all dependencies so you'd need no internet access to rebuild something
<aparcar[m]>
so basically store openwrt.git, feeds and dl/
<aparcar[m]>
I may look into creating a script for that
<hauke>
ok I do not know of a script
<hauke>
you could build one and then store these folders
<aparcar[m]>
okay thanks!
bluew has quit [Ping timeout: 480 seconds]
<f00b4r0>
aparcar[m]: color me interested :)
<aparcar[m]>
f00b4r0: for a vendor script?
<f00b4r0>
for whatever tool that allows to freeze assets and not require internet access to build. Although I'm leaning on IB personally, if it can be applied there it's something that may be useful for my shenanigans :)
<jow>
hgl: you probably could use service triggers
<jow>
hgl: why rely on ubus events
<jow>
s/why/which/
<hgl>
jow, thanks, that's what I thought. do you happen to know any code example in openwrt repo that I can follow to create acme listen triggers in services and make hotplug scripts trigger it?
<hgl>
actually, this doesn't sound right. it should be acme itself that triggers, and directly cause services to reload?
<f00b4r0>
is there an easy way to check if a device has been "upgraded", i.e. flashed with preserving config files?
<hgl>
f00b4r0, you may be asking an xy problem, maybe describe what you're really trying to do?
<f00b4r0>
i want to detect a device that was upgraded instead of freshly installed / flashed with -n / firstbooted
<jow>
hgl: for examples for listening on events see `grep -r raw_trigger package/`
<jow>
hgl: for sending these events use `ubus send yourevent.name`
<jow>
hgl: the number argument to procd_add_raw_trigger() is the coalesce timeout, multiple events received within this time interval are aggregated and result in only one reload
<Borromini>
f00b4r0: if there's a setting you're *always* changing, you could check uci for that
<jow>
hgl: or only one invocation of the action rather, but you're most likely going to use "/etc/initd/whatever reload" as raw trigger action
<jow>
aparcar[m]: I am not opposed, depends on the overhead though. And whether the backend infra can handle the increased load
<jow>
once this becomes the default, the inbound requests will likely increase substantially
<aparcar[m]>
jow: I'd give it a try, ideally more people would have a look at the javascript code though
<aparcar[m]>
backend uses queueing, should work fine for now
<aparcar[m]>
worst case you wait 5 minutes in a queue before the image is done
<jow>
ldir: stat-genconfig issue solved by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1b90c7441b81aee7b1212e8918e3ec7144375d96
<Borromini>
aparcar[m]: if it gets included by default, it would be handy if some marker was set to indicate it's not a vanilla OpenWrt image
<aparcar[m]>
Borromini: like "i've been create using ASU"?
<jow>
there's OPENWRT_TAINTS in /etc/os-release
<Borromini>
yeah, cause if they'll ask for support that might be a factor too (including extra packages etc, rootfs getting full, ...)
<jow>
you would need to extend include/version.mk to look for a specific environment variable or something, e.g. ASU_BUILD=1
<jow>
if present, add "asu" or a similar marker to the tain list
<jow>
and change your asu build process to set this env var
<aparcar[m]>
asu always uses image builders
<hgl>
jow, thanks for the tips, but wouldn't using "/etc/init.d/whatever reload" cause the same problem again, restarting a stopped service?
<aparcar[m]>
we could just make it pass a command like CONFIG_TAINT=asu
<jow>
hgl: no because when a service is not started, it will not have registered an event listener
<jow>
and when a service is stopped, its listeners get removed as they're part of the service runtime state
<jow>
aparcar[m]: yes, would work too
<hgl>
oh, i forgot about that. yes, that can work.
<aparcar[m]>
jow: could you spent some 15 minutes scroll over the JS code and give me pointers on what to improve?
<aparcar[m]>
I'll pay you back at the next openwrt conference/meetup with drinks or something
<hgl>
jow, hmm, looks like in that case there no need for each service to add a hotplug script to be reloaded? for the acme package, maybe I should just leave hotplug for regular users to use?
<jow>
hgl: right, instead each service needs to amend its init script
<jow>
hgl: and whatever is performing hotplug-call acme now needs to do ubus send acme instead
<hgl>
maybe I should do both? otherwise user's custom acme hotplug scripts won't be called?
<jow>
right
<jow>
both, then
<hgl>
cool
<jow>
aparcar[m]: code looks okay. it uses some ES6 features but that is okay, I think we can start using ES6 in LuCI now
<jow>
pre-edge support is likely broken anyway and pre-chrome-edge itself is also discontinued already
<aparcar[m]>
jow: thanks
<aparcar[m]>
I merge it then...?
<jow>
aparcar[m]: feel free to
<jow>
eventually we should merge the app into luci-mod-system
<jow>
and clean up the "flash operations" page while we're at it
<jow>
it has too many ... things
<jow>
we should have one menu item for backup & restore
<jow>
one for upgrade (asu, upload image)
<jow>
and one for the rest (mtd block download, reset)
<jow>
but maybe reset should go into backup/restore
<jow>
and mtdblock download somewhere into system/system
<aparcar[m]>
agree
<aparcar[m]>
I thought about that, too, anyway a first step is to have more people use it
<aparcar[m]>
I'll try to create a javascript library for image requests, so the firmware-selector and luci could use the same code
Piraty has quit [Remote host closed the connection]
<stintel>
ufff, something is causing perl to built again
cc0 has quit [Remote host closed the connection]
rua has joined #openwrt-devel
dangole_ has joined #openwrt-devel
<robimarko>
[Pokey]: Not really, I am not familiar with MT7621 nor ramips in general
<[Pokey]>
robimarko: Nothing really to do with that, more to do with whether we want the switch LEDs controlled via GPIO or left to the switch to deal with
cc0 has joined #openwrt-devel
cc0 has quit [Remote host closed the connection]
dangole has quit [Ping timeout: 480 seconds]
* stintel
considers a PR to drop perl and everything depending on perl from the packages feed, since nobody cares to fix the build breakage
cc0 has joined #openwrt-devel
<robimarko>
[Pokey] That is something that would ideally be controlled/blinked by the switch as that is HW offloaded
<robimarko>
However, there is really not standardised config interface to configure HW offloaded LED-s
<nbd>
maybe make an led trigger that enables offload and is attached to the switch leds by default
<nbd>
and can only be bound to switch leds
<robimarko>
nbd: There has been at least 3 attempts to get some kind of way to offload LED-s upstream
<robimarko>
But there is always somebody who is not happy with X, Y or Z
<nbd>
do you have links to those attempts?
<nbd>
one advantage of the approach that i'm proposing is that it requires no core API changes, it can be completely local in the switch driver
<rmilecki>
nbd: any idea what may be a limitation here? why
<rmilecki>
why I don't see anything interesting in perf?
<stintel>
hmmm we probably should have bumped PKG_RELEASE in package/mac80211/Makefile because now we can't really guarantee that 5.10.147+5.15.58-1-2 contains the fixes ?
<stintel>
package/kernel/mac80211/Makefile*
Gaspare has joined #openwrt-devel
dangole_ is now known as dangole
goliath has quit [Quit: SIGSEGV]
gladiac has joined #openwrt-devel
<mrkiko>
I was intending to sysupgrade, but was wondering if I need to re-do my wifi config or something due to the phy rename patch. Or if I can sysupgrade normally keeping my config. I am running snapshot, upgrading to newer one.
valku has joined #openwrt-devel
Borromini has joined #openwrt-devel
<Mangix>
[Pokey]: if you don't want to control the LEDs, sure
<[Pokey]>
Mangix: Its not about me, really
<[Pokey]>
I am merely a single user
<Mangix>
Sure it is
<[Pokey]>
others will have this device too
<[Pokey]>
Mangix: Are any upstream LED configuration proposals merge-ready and its just social disagreement?
<Mangix>
Sure, Ansuel has one. I think he wants it merged upstream first.
<[Pokey]>
I suppose we should wait for Ansuel first then before proceeding
<robimarko>
As far as I remember, part of the issue is that nobody from the LED crowd commented, only netdev guys
goliath has joined #openwrt-devel
<[Pokey]>
Oh we're taking linux kernel grade upstream
Gaspare has quit [Quit: Gaspare]
<[Pokey]>
That will take months at minimum won't it
<[Pokey]>
Mangix: Can you think of any way that we could easily put something in userspace to let the user decide if the LEDs are switch or system controlled?
<Mangix>
Nope.
<[Pokey]>
arinc is right, most users will be using a LAN bridge and will expect cross port communication to flash
<Mangix>
OEMs write their own hackish tools to write to registers
<Mangix>
What do you mean cross port communication?
<Mangix>
I can communicate between devices on the bridge just fine.
<[Pokey]>
But no LED indication of that communication occurs
<[Pokey]>
If it did, this would be a non-issue entirely
<Mangix>
Oh I just turn mine off. I hate LEDs.
<[Pokey]>
I kinda sussed that from your GH comment
<[Pokey]>
I do not think you are invalid to do that or what that at all, but I do think you are in the minority for people who would prefer to see activity are likely more common
<[Pokey]>
s/what/want
<rmilecki>
LED subsystem needs some bigger refactoring: adding support for using multiple triggers at the same time, handling hw triggers and switching between software & hardware control
<rmilecki>
so it's a bit task :/
<[Pokey]>
[yesterday 13:49:11] <[Pokey]> [ 4.653629] OF: /leds/led-lan1: could not get #gpio-cells for /ethernet@1e100000/mdio-bus/switch@1f
<[Pokey]>
[yesterday 13:49:11] <[Pokey]> [ 4.663188] leds-gpio: probe of leds failed with error -22
<[Pokey]>
I do wonder if theres a way to affect this scan from a script or something which would allow a configuration option to be set via userspace to choose what mode you want
<[Pokey]>
AFAIK if we just skip configuring those LEDs they'll just default to hw control
<[Pokey]>
how easy that is however is beyond my knowing
<[Pokey]>
Does chanding the DTSI change the vermagic or otherwise result in mismatching kmods
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #openwrt-devel
srslypascal is now known as Guest3397
srslypascal has joined #openwrt-devel
<mrkiko>
[Pokey]: no
Guest3397 has quit [Ping timeout: 480 seconds]
<[Pokey]>
mrkiko: ty. Mangix That does make it easier to do a DTSI tweaked custom build with little hassle
cbeznea has quit [Quit: Leaving.]
<Mangix>
sure but I like auc
Borromini has quit [Ping timeout: 480 seconds]
<[Pokey]>
Mangix: Do you object to reversal of the change for now, for I doubt you will be using this specific device, and we maybe open an issue based on it referencing specifically the 3 devices we have looked at and the switch chipset? I would like to get this device supported sooner rather than later and LEDs are something that can be revised later in another PR
<Mangix>
Feel free to do so
<Mangix>
I do object to doing so for the rt1800 as I use it.
<[Pokey]>
Mangix: I have no intention of opening a PR to change already-merged devices nor including any change to any other device in this PR
<slh>
I would call that 'normal' ath10k firmware noise, nothing you could do
<Tapper>
After that it droped all wifi from the 5ghz and made them all connect again.
<Tapper>
all devices
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<Borromini>
Tapper: 22.03?
<ldir>
jow: Can confirm the batshit craziness is resolved ;-)
<[Pokey]>
Borromini: From my thoughtless mini scan of the forum, you've worked with ProCurve switches before?
cmonroe has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<Borromini>
[Pokey]: as in a one-time deployment, yes... they run OEM firmware here though.
<[Pokey]>
Borromini: Fair
<Borromini>
i suppose the latter is not what you're after :)
<[Pokey]>
I can see in the ROMMon on my unit I can Xmodem new firmware to it but nobody seems to have bothered to investigate firmware for ProCurve devices
<[Pokey]>
Nor Cisco ones
<Borromini>
that they're Realtek devices?
<[Pokey]>
So I suppose they're such specialised hardware people nope the hell out
Luke-Jr has joined #openwrt-devel
<[Pokey]>
?
<Borromini>
i believe there is a patch set pending for quite a few 1920 devices
<[Pokey]>
Borromini: If you have cheap ones to point me to I'm game
<aiyion>
well.
Luke-Jr has joined #openwrt-devel
<Borromini>
D-Link DGS-1210-52 e.g.?
<Borromini>
i'm not saying they'll be cheap, any reason you're looking at Fast Ethernet ones (which the 2510 seems to be?)
<[Pokey]>
Borromini: Because A) I have it and B) heccin cheap
<Borromini>
:P
<[Pokey]>
I have 4 of these fookers
<Borromini>
so you can afford to smoke some eh
<slh>
if you're lucky, the 24 port HPE 1920 (JG924A) may go for ~30 EUR
<[Pokey]>
Borromini: Prefer not to lol
<slh>
the gs1900-24/ 24e /was/ around 45 EUR a year ago, now they're more around 60 EUR
<[Pokey]>
I'm such a cheapskate
<slh>
sadly fast-ethernet switches are just useless, I have an Alcatel OmniStack 6124 - feature wise it would have been fine'ish, but 100 MBit/s and loud fans meant that I've never actually used it (it will take a trip to the recycling centre shortly)
Gaspare has quit [Quit: Gaspare]
<[Pokey]>
I hate spending money on stuff :P
<slh>
c8051 based
<[Pokey]>
I picked up a Cisco 1941 for £5 at a boot sale
<[Pokey]>
Borromini: BCM5248 switch chips
<Borromini>
8x 100 Mbps eh :)
<[Pokey]>
Borromini: Ye.
<[Pokey]>
48 ports of that and 2 ports of gigabit
<Borromini>
;)
<Borromini>
a whole whoppping 2 eh.
<[Pokey]>
I only have 100mbit internet
<[Pokey]>
Realistically I could use this and see no performance hit in my network with regards to internet access
<[Pokey]>
I don't do too much inter-device communication either so gigabit wouldn't be a hurtful loss there either
<slh>
I paid 20,99 EUR for an 8-port all-sg8208m two weeks ago (including 6 EUR shipping), but that one is actually useful (and yes, that was right at the top of what I would have paid) - compared to 100 MBit/s stuff that just serves as a modern art installation
<[Pokey]>
slh: The only one of those on eBay for me is £96
<Borromini>
slh: is that master with the link icon patches? That LuCI PR?
<slh>
[Pokey]: Allnet is mostly a german reseller for (sometimes) braded stuff, it's the same hardware as the ZyXEL gs1900-8, just with a totally braindead and insecure OEM firmware (and 'unknown', meaning more likely to fly under the radar --> cheaper)
<Borromini>
(sorry the screenhot clearly says snapshot)
<[Pokey]>
slh: Fair!
<[Pokey]>
Cisco Integrated Services Routers Generation 2 (Cisco ISRs G2) have dual core CPUs on the motherboard. The first core runs Cisco IOS software as Cisco Integrated Services Routers (ISRs) do; the second core, or the Embedded Service Engine, is capable of running Linux-based applications.
<[Pokey]>
Damn, I have this on my router. Wonder if this could be abused...
Gaspare has joined #openwrt-devel
<[Pokey]>
No apparently not haha
<[Pokey]>
The only supported linux application is of course a single Cisco one
<Habbie>
just find a security hole ;)
Borromini has quit [Quit: leaving]
noahm has quit [Quit: reboot]
csrf has joined #openwrt-devel
csrf has quit [Remote host closed the connection]
csrf has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
bluew has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
<Tapper>
Borromini no mate it was a master build. I just flashed a new one so I will let people know if it messes up again.