swex has joined #openwrt-devel
danitool has quit [Ping timeout: 240 seconds]
aszeszo_ has quit [Ping timeout: 240 seconds]
aszeszo has joined #openwrt-devel
<pkgadd> mangix: there are basically only two options, ipq807x with qcn5024/ qcn5054 or mt7915e with either mt7621a or mt7622a underneath. the former exists, but is expensive - the later hasn't really reached the market yet (there are some underpowered APs with mt7621a+mt7915e announced, but I don't think you can get them yet)
<pkgadd> ipq807x has basic target support, and there are some efforts around adding support for the Xiaomi Mi AIoT Router AX3600 - but that isn't really available yet. hnyman seems to have scored the Netgear rax120, due to its price the ax3600 seems to have a little more backing behind it
aszeszo has quit [Quit: aszeszo]
<pkgadd> it's in sight, but not really there *yet*. ipq60xx and ipq50xx will be cheaper, but that's still very volatile (patches are still in the process of getting processed mainline, both basic SOC support and for ath11k)
<pkgadd> due to the well-known SOCs underneath, Mediatek m7915e might be quicker to get OpenWrt support - once some devices shipping it arrive on the market (although I'd skip anything with mt7621a in favour of waiting for mt7622a+mt7915e). but ipq807x pretty much has a head start so far
<pkgadd> Xiaomi Redmi Router AX6 would be a cheaper variant of the AX3600, only two radios instead of three (the third radio is a 1x1 ath10k 2.4+5 GHaz WLAN card, originally meant for Xiaomi's AIoT ecosystem) - but lower tx power (half of the ax3600 values)
<blocktrron> pkgadd: mt7621 + mt7915 is available since months in form of the D-Link DIR-X1860
<pkgadd> blocktrron: ah, o.k., thanks
greearb_ has quit [Remote host closed the connection]
greearb_ has joined #openwrt-devel
<blocktrron> It's niche i admit
<blocktrron> And mt7915 support isn't there in master yet, but i think this is the path of least resistance atm
<blocktrron> Also i assume the MT7915D+MT7621 will be the most prominent choice for sub-100 2x2 DBC designs.
<pkgadd> I've seen a lot of activity around it on linux-wireless@vger, so I just assume it won't be too far away. and obviously using a well-known SOC underneath will make supporting it easier ('just' the new wireless driver to take care of), but at least mt7621a imho feels too slow for an 802.11ax capable router
<blocktrron> Well, certainly a upgrade considering 2x2 802.11ac gear with 100 Mbit/s ports
<pkgadd> the ax3600 with ipq8071a and 4*1.4 GHz cortex a53 is kind of tempting me, considering its price to performance ratio
andi- has quit [Remote host closed the connection]
andi- has joined #openwrt-devel
swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
hbug has joined #openwrt-devel
victhor has quit [Ping timeout: 260 seconds]
gch9812131 has joined #openwrt-devel
hbug___ has quit [Ping timeout: 240 seconds]
gch981213 has quit [Read error: Connection reset by peer]
gch9812131 is now known as gch981213
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Grommish has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<mangix> pkgadd: i asked as gch981213 added an mt7621 unit with ax
<mangix> that specific unit seems to have pretty little RAM though...
tchebb has joined #openwrt-devel
<pkgadd> mangix: hmm, which device?
Devastator has quit [Quit: ZNC 1.8.1+deb1~bpo10+1 - https://znc.in]
Devastator has joined #openwrt-devel
swalker_ has joined #openwrt-devel
caravel has quit [Quit: Konversation terminated!]
swalker has quit [Ping timeout: 260 seconds]
<pkgadd> ah, https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=23be410b3d1267c752bf9f6e5c8f5a514dc562c4 -- the lower-end ipq50xx/ ipq60xx devices will probably also ship with 256 MB RAM (hopefully few)
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
<pkgadd> e.g. Xiaomi Mi AX1800, IPQ6000, 4*1.2 GHz, 128 MB flash, 256 MB RAM
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
<mangix> maybe ath10k devices need more RAM because of the firmware. who knows.
<mangix> erm eth11k
<pkgadd> at least the proprietary driver doesn't seem to be that bad, looking through the early ax3600 reports suggests around 256 MB RAM usage (of 512 MB)
<pkgadd> using xiaomi's OEM firmware
daregap has joined #openwrt-devel
nitroshift has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
daniele- has joined #openwrt-devel
skolev has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
skolev has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch981213 has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
<russell--> blogic: in netifd's system-dummy.c, shouldn't line 60 be "bridge" instead of "brctl"?
<russell--> 82bcb641 (John Crispin 2020-07-12 18:50:19 +0200 60) D(SYSTEM, "brctl vlan %s %s %s vid=%d pvid=%d untag=%d\n",
aszeszo has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
Borromini has joined #openwrt-devel
Ycarus has joined #openwrt-devel
eduardas has joined #openwrt-devel
eduardas has quit [Client Quit]
grift has quit [Quit: Bye]
ivanich has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 246 seconds]
rsalvaterra has joined #openwrt-devel
<rsalvaterra> Morns!
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<blogic> russell--: russell-- that is just debug code for the dummy handler
<blogic> russell--: but yeah, I beleive felix added that when he merged the commit
<rsalvaterra> nick[m]: I guess 4.19 on ath79 can now die peacefully. :)
<Borromini> the jffs2 issue got solved huh? :)
<rsalvaterra> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b
<rsalvaterra> And it was indeed related to the protection bits.
<Borromini> :)
<Borromini> so now we can have 20.10? 0:-)
<rsalvaterra> That's for the "upper management" to decide. :P
<Borromini> :P :P
<rsalvaterra> Ooh, Linux 5.10-rc1 is out. Imma checkin' out the new toys.
* enyc meows
grift has joined #openwrt-devel
<nitroshift> rsalvaterra, so 5.9 is the next lts?
<grift> when you install a package, say unbound-server , then what exactly adds the unbound group to /etc/group?
<grift> aparcar[m]: know?
<grift> trying to find that code dunno where to look
<rsalvaterra> nitroshift: I don't know. Has gregkh already "blessed" the new LTS?
<nitroshift> rsalvaterra, i have no idea, that's why i asked
<rsalvaterra> Nope, the LTS is stil at 5.4.
<rsalvaterra> *still
<PaulFertser> grift: opkg itself I guess, following Require-User attribute added to the package metadata.
<nitroshift> rsalvaterra, yeah, that's what kernel.org says too, thought you might have some other undisclosed news ;)
<rsalvaterra> nitroshift: This is free software, hopefully there are no undisclosed news. :P
<PaulFertser> grift: I see, it's not opkg, package/base-files/files/lib/functions.sh processes that metadata in add_group_and_user()
<PaulFertser> In default postinst script.
<grift> thanks ill have a look
<PaulFertser> grift: if you have issues understanding shell scripting I can try to help
<PaulFertser> grift: why is that you're interested in this topic?
<grift> essentially i just want to know how it "replaces" files like /etc/group
<grift> it seems it creates a file and then mv's it to /etc/group
<grift> would like to know if that file name has some kind of reliable pattern like for example /etc/group.backup or /etc/group.tmp
<grift> echo "${name}:x:${gid}:" >> ${IPKG_INSTROOT}/etc/group
<grift> make me wonder ..
daniele- has quit [Quit: daniele-]
<Borromini> >> just tacks it onto the contents of the file
<Borromini> IPKG_INSTROOT by default points to / unless you use extroot, i guess
<grift> yes strange though...
<Borromini> how so? :)
<grift> ill have to dig into this a bit and if i can't explain it table that issue for a while
<grift> editing /etc/group in that scenario seems to mess with its label, but it also edits /etc/passwd and that label is fine
<nick[m]> rsalvaterra: yep I think we can remove 4,19 now ;) but ath79 has still some issues with 5.4er kernel since dts files are sometimes wrong :/
<rsalvaterra> Oh… :/
psnsilva has joined #openwrt-devel
<Borromini> grift: you mean with selinux?
psnsilva has quit [Remote host closed the connection]
<grift> yes
<grift> anyway i guess i will hit it again and deal with it later
<grift> might be sed
<grift> i suppose in some cases it uses sed and i guess sed creates a backup file with a random suffix
<grift> and i cant anticipate files with random names
<Borromini> sed for post-removal, i suppose
<grift> o right might have been my removal of the dnsmasq package...
<grift> where is that function for "post-removal"?
<Borromini> in a postinstall script, probably
<grift> but yes if thats what is cuasing it then specifying a fixed extension would solve it ie sed -i ".bak" ...
matteosilex has joined #openwrt-devel
matteosilex has quit [Client Quit]
<grift> no its not any removal, because the dnsmasq user/group isnt removed on removal of the dnsmasq package
<grift> anyway i will table this and move on
<Borromini> grift: dnsmasq is different, it's a base package
<Borromini> that might influence things.
<Borromini> unbound is completely optional
samantaz_ has quit [Ping timeout: 260 seconds]
feriman has joined #openwrt-devel
grift has quit [Quit: Bye]
MarioH has quit [Quit: ZNC 1.8.2 - https://znc.in]
xback has joined #openwrt-devel
<xback> ping f00b4r0
<f00b4r0> xback: pong
<xback> good morning
<xback> Quick question
<xback> We've just received a new batch of RB922 today which seems to be yet another revision.
<xback> although the board serials dont indicate it
<xback> but they have big yellow capacitors now
<f00b4r0> heh
<xback> We've just flashed them .. and wifi is again not detected
<f00b4r0> sweeet
<xback> the boards contain a onboard ath10k and we've placed a ath9k 2x2 in the pcie slot
<xback> ps. I;m running latest 19.07
<f00b4r0> xback: fwiw there seems to be very few people interested in keeping mikrotik devices afloat, to the point I wonder if we should just drop them going forward
<xback> drop Mikrotik?
<f00b4r0> drop support for their devices
<f00b4r0> to boot, the NAND-based device support is completely broken-by-design.
gch9812132 has joined #openwrt-devel
<xback> I'm more than willing to aid in keeping them alive
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
<f00b4r0> if anything we should advertise that and not mark these devices as "supported" in a way that can confuse prospective buyers into believe the support is on par with anything else
<f00b4r0> believing*
gch981213 has quit [Read error: Connection reset by peer]
gch9812132 is now known as gch981213
<f00b4r0> xback: those 922 are NAND-based, right?
<damex> f00b4r0: there is really interesting devices from mikrotik...
<f00b4r0> damex: sure, but nobody really cares and mikrotik is (actively or passively) making it very hard for us to deal with their stuff
<damex> hEX PoE (RB960PGS) is quite unique
<damex> f00b4r0: hmm... i thought people still use them and add support for their boards (from time to time?)
feriman has quit [Quit: WeeChat 2.9]
<damex> what kind of support do you need for it to be justified? :)
<f00b4r0> damex: it's commit and forget, and most of the time it's "commit garbage and forget"
<zorun> there definitely is interest to keeping them supported
<f00b4r0> good to hear
<karlp> are you saying that only mikrotik support is "garbage and forget"? that seems particularly prejudiced.
<zorun> but I agree these revision changes are really annoying (we are considering changing vendor just because of this)
<f00b4r0> karlp: lol; touché
<damex> i see that they're kinda 'generic target' that supports all of them. would it be better if they would get split and build would be per device
<zorun> damex: that's a sensitive discussion :)
<f00b4r0> damex: we've already been through that avenue. I suspect this is going to make things even worse, but I'm not keen to reopen that debate
<damex> maybe if we (or someone) pay more attention to each device in question - quality of the outcome might be better
<f00b4r0> ...
<damex> f00b4r0: uh... okay :(
<f00b4r0> xback: anyhow, those NAND device, ISTR you're deploying them in the field. It's probably best if you're aware you're sitting on a ticking timebomb with each of them
<xback> f00b4r0: yes. they are NAND
<xback> we currently roughly have about 100 of them running in the field offshore
<f00b4r0> ugh
<f00b4r0> don't update them too often then :P
<xback> the only issue ever seen so far is that sysupgrade sometimes fails
<xback> something appeared to be changed in nand
<xback> and I need to set sysupgrade executable bit again at that point
<f00b4r0> well
<xback> I did not encounter that with rb912 (also nand)
<f00b4r0> that sounds pretty harmless in comparison to what can (and will) happen
<f00b4r0> the kernel partition will eventually die abruptly. We do not manage badblocks _at all_ on that partition.
MarioH has joined #openwrt-devel
<f00b4r0> thanks to the extremely stupid kernel2minor "workaround"
<xback> is that patch backportable to 19.07?
<f00b4r0> the one I linked?
<f00b4r0> I suppose so
<xback> just tried and didn't apply. checking now
<xback> ah. 19.07 is at v0.3 still :-)
<f00b4r0> heh
<f00b4r0> note that this is still not in master
<f00b4r0> not sure why it's not so.
<xback> no worries. I'll take care of it
<xback> I've been absent for quite some time due to other tasks
<f00b4r0> i can't guarantee this'll fix your woes, it's possible mikrotik once again did something clever ;P
<f00b4r0> no worries, I'm currently rather busy setting up shop (I quit my job and am going full freelance ;)
<f00b4r0> john-tho has been extremely helpful in the meantime, btw
<stintel> f00b4r0: congrats!
<f00b4r0> stintel: heh, we'll see how that pans out :)
<f00b4r0> but thanks
<xback> I followed the discussion from a distance with john-tho
<xback> very interesting stuff
<xback> and congratz with your shop :-)
<stintel> going full freelance + moving to Bulgaria (10% tax) were some of the best decisions I ever made
<f00b4r0> he basically implemented everything I was looking forward.
<f00b4r0> native compressed elf boot, and he also has a rather neat fix for the 4K_SECTORS nightmare
<nick[m]> is there an example how to findout the correct settings for rgmii ethernet interface?
<f00b4r0> stintel: i hope it'll be the same for me. I guess the timing is tricky (right for me, not so right for the rest of the world), but I feel confident :)
<damex> nick[m]: maybe stock will have it in device tree? or uboot?
<f00b4r0> stintel: out of curiosity, you moved to Bulgaria from ?
<stintel> f00b4r0: Belgium
<f00b4r0> oh wow. I see, quite a jump.
<stintel> well 50% tax is pure theft
<stintel> so yeah, quite the jump from 50 to 10 :P
<f00b4r0> heh. I lived and worked in Belgium (BXL) for 6 months. Didn't like it one bit ;P
<stintel> bxl is horrible
<f00b4r0> but yeah, I thought France had a brain damaged tax system; that was until I went to Belgium ;P
<stintel> hahaha
<Namidairo> > he also has a rather neat fix for the 4K_SECTORS nightmare
<Namidairo> but I love spending 10 minutes waiting for the kernel to flash
<f00b4r0> heh
<f00b4r0> I wish he'd get some feedback from linux-mtd. If any one of you knows someone there, it'd be a nice help to raise awareness to his posts
<xback> I can ping Boris
<f00b4r0> xback: https://github.com/openwrt/openwrt/pull/3271 is where it happened; he posted links to his mailing lists messages toward the bottom of the conversation
<f00b4r0> xback: actually I htink he's about to resend. Maybe tell him he should CC someone?
feriman has joined #openwrt-devel
<nick[m]> damex: then I have to extract the devicetree frist ;) what do u mean with uboot? never heard of that
<nick[m]> u can extract the values from there
<damex> nick[m]: does device have uboot?
<damex> how does it boot and what kind of device is it?
<nick[m]> damex: yes it has uboot
<damex> uboot can help with extracting device tree and it might be different from what your OS sees
<xback> f00b4r0: just resend. I can pickup and ping from there
<nick[m]> damex: it is a ar9342 soc (nanstation ac loco)
<nick[m]> damex: okay, nice :) so I just google a bit? :D
<f00b4r0> xback: don't tell *me* :)
<damex> nick[m]: i think `fdt print /` is the one you're looking for
<damex> in uboot
<nick[m]> nice I will try! thanks :D
<damex> varies so might be just `fdt print`
<Borromini> good luck and congrats f00b4r0 :)
<f00b4r0> thx :)
Skeleswant has quit [Remote host closed the connection]
Swant has joined #openwrt-devel
<nitroshift> nbd, ping
<nick[m]> damex: my uboot on the device does not have fdt :/
Swant is now known as Skeleswant
<damex> nick[m]: you can try to dump uboot binary and do binwalk/extract-dtb
<damex> uboot binary partition*
<damex> nick[m]: if it boots - you can extract dt from running system if it runs with dt
<nick[m]> damex: the device tree is in the uboot partition? I always thought that it is the firmware section
<nick[m]> damex: I have a working openwrt on the current device. but I have rgmii-id, and I would like to switch to rmii ;)
<damex> nick[m]: depends. some devices have device tree embedded with uboot. that way you have uboot initalize device using dt
<nick[m]> damex: okay, I will boot and make dumps of the uboot partition. and try to find a dts there :) and I will flash airos again and try to dumb the flash there, too
<nick[m]> thanks! :)
<damex> nick[m]: you can try to use binwalk on airos firmware
<nick[m]> ahh okay :O
<damex> might find (and extract?) what you're looking for (or not~)
dedeckeh has joined #openwrt-devel
<nick[m]> damex: should there popup something like "device tree image (dtb)"? Cause it does not xD
grift has joined #openwrt-devel
<damex> nick[m]: yeah, should be
<nitroshift> i've brought mvebu to 5.9
<nick[m]> damex: tried "extract-dtb" and nothing useful :/
<nick[m]> I will try duming uboot :D
<nick[m]> damex: or is there some source there u can find datasheets for ar9342 socs?
<damex> nick[m]: not sure about that one. you need info about your mdio? ag71xx as in AR8216/AR8236/AR8316 ?
<rsalvaterra> nick[m]: I have for 9331 and 9344, but not for 9342… :/
<damex> or something else?
<dengqf6> I think 5.10 will be the next LTS
grift has quit [Ping timeout: 260 seconds]
<nick[m]> damex: isn't the mdio between MAC and PHY? so u mean that tx and rx delays are for the mdio and not the the actual phy?
<nick[m]> rsalvaterra: same xD
grift has joined #openwrt-devel
<nick[m]> damex: I need Atheros AR8035
<nick[m]> I found a datasheet, not sure which is the correct value, I would believe it is "tmdelay" "MDC to MDIO output delay", that is min 0 and max 4ns...
Redfoxmoon has quit [Ping timeout: 260 seconds]
<blocktrron> nick[m]: see which registers at803x.c touches depending on the phy mode
<blocktrron> The AR934x and subsequent chips are also capable of introducing delays on the mac side
MichaelOF has joined #openwrt-devel
andi- has quit [Remote host closed the connection]
andi- has joined #openwrt-devel
<nick[m]> blocktrron: thanks for the tipp! :) Just locking at the driver and on the datasheet damex linked on page 48 "rgmii rx clock delay control". so the driver just sets this to enabled if rgmii-id or a different delay mode is configured
victhor has joined #openwrt-devel
<nick[m]> so this is only phy mode delays, and I wanted what blocktrrron describes, the delays on the mac side :)
<nick[m]> or am I compltely wrong? if I set the mode to rgmii on a ar9342 soc, they don't work anymore. So I thought I have to set the delays manually to the correct value?
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has joined #openwrt-devel
Redfoxmoon has quit [Changing host]
<nick[m]> I read something like ""rgmii" should be the preferred mode, which allows the mac layer to turn off the dealys completely if they are not needed." ?
<nick[m]> MAC (add delays "rgmii") <-> Phy (add delays "rgmii-id")
<nitroshift> stintel, ping
stintel has quit [Remote host closed the connection]
stintel has joined #openwrt-devel
muhaha has joined #openwrt-devel
grift has quit [Ping timeout: 260 seconds]
<xback> f00b4r0: it seems latest master has issues with RB922 (nand ..)
grift has joined #openwrt-devel
<xback> will need to sort that out first
<f00b4r0> xback: as I said, we don't do badblocks management. From that, anything goes.
<f00b4r0> xback: if you want to rule out storage in your wifi tests, you can always netboot :)
<xback> got it running now
<f00b4r0> i'm curious if my patch will fix it for you, that would suggests they're deploying the new scheme in existing devices
<xback> well. I want to test it right away. as I got various revisions laying around now
<f00b4r0> s/existing/old/
<xback> made 2 builds. one without and one with your latest patch
<xback> currently running without the patch
<f00b4r0> note that the patch is a NOP on old-style hardware
<f00b4r0> i tried to be thorough in the commit message, let me know if it needs improvement
<xback> interesting .. on master even without the patch. the radio's are recognized.
<xback> on 19.07 they are not. only on this board
<xback> other boards behave well
madwoota has quit [Ping timeout: 244 seconds]
<xback> I've already made some backporting efforts in my staging. but I guess it's still lacking some more ports
<xback> probably the extraction script
<zorun> f00b4r0: thanks, I missed that patch. I had to apply the previous one to 18.06, and that was enough for the newer revisions I got
<f00b4r0> zorun: no worries, the new patch isn't in master yet, i wouldn't be comfortable backporting somethign that hasn't lived at least a few weeks in master
<f00b4r0> i don't quite remember what has and hasn't been backported
<zorun> yes, sure, it's just that if newer hardware doesn't work as expected, I know where to look ;)
<zorun> mostly everything you sent has been backported to 19.07
<zorun> 18.06 has less changes, but this is to be expected
<f00b4r0> sure. 18.06 is EOL, right?
<f00b4r0> xback: in any case, if master works for you, that means my work is done :D
<xback> very true
<xback> thanks for being a listening ear ;-)
<zorun> more or less, a last 18.06 release has been planned for months (but nobody got the time to push it through :/ Hauke did some work on it recently)
<f00b4r0> :D
daniele- has joined #openwrt-devel
madwoota has joined #openwrt-devel
madwoota has quit [Changing host]
madwoota has joined #openwrt-devel
<zorun> f00b4r0: in your patch, you mention the need for adaptation in hotplug scripts, did you send such a patch already?
<f00b4r0> zorun: no; because so far no supported device use that new scheme. This patch is needed by ipq4019 devices which are still in PR
<f00b4r0> the PRs have that change.
muhaha has quit [Ping timeout: 260 seconds]
grift has quit [Ping timeout: 260 seconds]
<zorun> ah, right, that makes sense
madwoota has quit [Read error: Connection reset by peer]
madwoota has joined #openwrt-devel
madwoota has quit [Changing host]
madwoota has joined #openwrt-devel
<damex> https://github.com/openwrt/openwrt/pull/3519 only issue that i have had with that one is naming. any idea if something else needs to be done before it could be merged ? it is a pretty simple upstream supported board
<damex> so i named it exactly as uboot and kernel upstream expects it to be
grift has joined #openwrt-devel
valku has joined #openwrt-devel
samantaz_ has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
grift_ has joined #openwrt-devel
grift has quit [Read error: Connection reset by peer]
grift_ has quit [Client Quit]
grift has joined #openwrt-devel
<grift> ok so i have it do dns over tls using the google servers
<grift> wrong chan
danitool has joined #openwrt-devel
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #openwrt-devel
Borromini has quit [Ping timeout: 260 seconds]
Borromini has joined #openwrt-devel
heffer has quit [Quit: heffer]
fonix232 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
heffer has joined #openwrt-devel
fonix232 has joined #openwrt-devel
<rsalvaterra> Awww, yiss!
Borromini has quit [Quit: Lost terminal]
MichaelOF has quit [Quit: Konversation terminated!]
f00b4r0 has quit [Quit: Quitte]
daniele- has quit [Quit: daniele-]
<grift> yes its some uci issue, the same with the verbosity earlier
<grift> wrong chan
<grift> but yes for this chan, the unbound package could use some attention. its pretty ugly
<grift> thing is so overengineered though that aside from whoever did that no one probably knows if and how it works
gch981213 has quit [Quit: The Lounge - https://thelounge.chat]
gch981213 has joined #openwrt-devel
<Hauke> zorun: I am waiting for one security fix and would push it then
Rene__ has joined #openwrt-devel
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
jg_ has joined #openwrt-devel
<blogic> this bkpepe dude on github is weird
<stintel> is bkpepe not a core dev? :P
<stintel> (one doesn't invalidate the other)
Night-Shade has joined #openwrt-devel
Night-Shade has quit [Client Quit]
<blogic> stintel: nutter, my cellphone just ping'ed
<blogic> bad and ugly are simply not words you wanna use
<stintel> you can, but not if you've agreed to "be nice ot eachother"
<blogic> I actually dont care, still seems odd
<blogic> but then again I had my own share of ranting in the past so who am I to complain
adrianschmutzler has joined #openwrt-devel
<olmari> Courtesy usually goes long way indeed, even if shouting it out straight would not be wrong in content
<adrianschmutzler> Hi, I find a lot of Image/mkfs/... definitions in image.mk, but don't see them used anywhere.
Night-Shade has joined #openwrt-devel
<adrianschmutzler> Is this legacy and may be removed?
<adrianschmutzler> The recipes were touched during the various selinux patches, but I still don't see any users...
daniele- has joined #openwrt-devel
grift has quit [Ping timeout: 272 seconds]
grift has joined #openwrt-devel
grift has quit [Ping timeout: 244 seconds]
grift has joined #openwrt-devel
daniele- has quit [Quit: daniele-]
grift has quit [Quit: Bye]
grift has joined #openwrt-devel
<aparcar[m]> adrianschmutzler: do you have an example line?
<aparcar[m]> also thanks for all the metadata comments
<adrianschmutzler> This will take long enough anyway.
<adrianschmutzler> mkfs stuff is starting there
<adrianschmutzler> however, I do not find anything beyond the definitions when grepping for mkfs ...
<grift> i would argue that it should probably be unbound.root 0775
<grift> so that hotplugcall doesnt need cap_dac_override to create that time stamp in there
nickname_ has quit [Ping timeout: 272 seconds]
goliath has joined #openwrt-devel
nickname_ has joined #openwrt-devel
daniele- has joined #openwrt-devel
<aparcar[m]> adrianschmutzler: these are target features
<aparcar[m]> these are resolved to actual calls in image.mk
<aparcar[m]> grift: sounds simple enough
<adrianschmutzler> ah, I've just found it; it's in image.mk line 343
<grift> aparcar[m]: i will file an issue on github as this isnt the only issue with that package
<aparcar[m]> adrianschmutzler: should we use label or function for ethernet ports?
<adrianschmutzler> for what?
<adrianschmutzler> the function of ethernet ports is "lan", the label is "lan1"
<adrianschmutzler> so, depending on what you want to tell
<adrianschmutzler> the question is whether we want to make that distinction between lan and wan at all
MarioH has quit [Read error: Connection reset by peer]
MarioH has joined #openwrt-devel
<aparcar[m]> adrianschmutzler: yea I don't know how much details we want here, but I think it'd be handy to have such information
<adrianschmutzler> I also weakly tend to provide such a function property
<aparcar[m]> ethernet port mapping?
<adrianschmutzler> The question is whether we then have an additional "type" for rj45 vs. sfp or whether we just make sfp one of the function options
<aparcar[m]> flash layout?
<adrianschmutzler> no to both
<grift> too worn out to fork, took me the whole day to get unbound running
<aparcar[m]> ok
<adrianschmutzler> flash layout is in DTS; we should try to prevent redundancy here
<adrianschmutzler> The idea is to provide complementary information
<adrianschmutzler> or at least information that is general but cannot be extracted by a general approach
<adrianschmutzler> like flash size
<aparcar[m]> yep
<adrianschmutzler> therefore, also leds/buttons are a bit redundant for my taste
<aparcar[m]> wow the amount of usb standards is awkward
<aparcar[m]> yea a parser could extract that automatically
<adrianschmutzler> while e.g. narrowing down usb ports to just mode and size might actually create a benefit
<aparcar[m]> agree
<adrianschmutzler> LEDs/Buttons could be something worth keeping optionally ...
<adrianschmutzler> But personally I would not add that to yaml file when adding a device
aszeszo has quit [Quit: aszeszo]
<adrianschmutzler> btw I still have the old version of your size_compare.sh in my staging
<adrianschmutzler> do you plan working on this again?
<aparcar[m]> adrianschmutzler: yea I could give it another spin
<aparcar[m]> is plural of usb "USBs"?
<adrianschmutzler> busses?
<aparcar[m]> nevermind
<adrianschmutzler> I would then add a noun, e.g. usb_ports, usb_adapters, ...
Slimey has quit [Read error: Connection reset by peer]
<aparcar[m]> I just go ith usb now
Slimey has joined #openwrt-devel
<aparcar[m]> adrianschmutzler: btw thomas just joined the github PR discussion. I hope we find a compromise that keeps bloat out of the files but is valuable for wiki maintainers
daniele-_ has joined #openwrt-devel
daniele- has quit [Ping timeout: 240 seconds]
daniele-_ is now known as daniele-
Ycarus has quit [Quit: Ycarus]
n4gi0s has quit [Ping timeout: 246 seconds]
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
n4gi0s has joined #openwrt-devel
<rsalvaterra> I had forgotten what "fun" it is to create/edit patches with quilt…
<rsalvaterra> "Oh, you edited a file and didn't notice it wasn't being tracked? <nelson> Ha, ha! </nelson>"
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
Misanthropos has quit [Ping timeout: 260 seconds]
Misanthropos has joined #openwrt-devel
Borromini has joined #openwrt-devel
daniele- has quit [Ping timeout: 240 seconds]
daniele- has joined #openwrt-devel
grift has quit [*.net *.split]
nick[m] has quit [*.net *.split]
quark_ has quit [*.net *.split]
zx2c4 has quit [*.net *.split]
Strykar has quit [*.net *.split]
Dave has quit [*.net *.split]
dissonant has quit [*.net *.split]
AUser has quit [*.net *.split]
[florian] has quit [*.net *.split]
Dave has joined #openwrt-devel
[florian] has joined #openwrt-devel
[florian] has quit [Changing host]
[florian] has joined #openwrt-devel
quark_ has joined #openwrt-devel
dissonant has joined #openwrt-devel
AUser has joined #openwrt-devel
Strykar has joined #openwrt-devel
zx2c4 has joined #openwrt-devel
grift has joined #openwrt-devel
Tapper has joined #openwrt-devel
Floppe has quit [Remote host closed the connection]
Floppe has joined #openwrt-devel
nick[m] has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
feriman has quit [Ping timeout: 260 seconds]
Borromini has quit [Quit: Lost terminal]
Night-Shade has joined #openwrt-devel
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Night-Shade has joined #openwrt-devel
Night-Shade has quit [Client Quit]
ivanich has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
ds_shadof has quit [Ping timeout: 260 seconds]
ds_shadof has joined #openwrt-devel
indy has joined #openwrt-devel
slh64 has quit [Read error: Connection reset by peer]
ivanich has quit [Quit: Konversation terminated!]
<aparcar[m]> anyone ever looked into squashfs + zstd?
<rsalvaterra> aparcar[m]: Only zram + zstd.
slh64 has joined #openwrt-devel
<philipp64|work> Anyone seen Kaloz recently?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
danitool has joined #openwrt-devel
kubrickdave has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
kubrickdave has joined #openwrt-devel
black_ant has quit [Ping timeout: 260 seconds]
Redfoxmoon_ has joined #openwrt-devel
Redfoxmoon has quit [Read error: Connection reset by peer]
kubrickdave has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
kubrickdave has joined #openwrt-devel
<Hauke> aparcar[m]: zstd could be betetr then lzma, but this probably needs more compression time: https://etbe.coker.com.au/2020/06/06/comparing-compression/
Redfoxmoon_ has quit [Changing host]
Redfoxmoon_ has joined #openwrt-devel
Redfoxmoon_ is now known as Redfoxmoon
<rsalvaterra> Hauke: But with squashfs you only have to compress once. If the decompression speed is still the highest at the highest compression ratios, it could be an interesting choice.
<rsalvaterra> The buildbot won't be happy, though. :P
<Hauke> yes, it could improve the situation
<Hauke> the compression also depends on the content
<Hauke> here is some other paper with lzma:9 and brotli: https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf
<Hauke> it alos depends on the decompression speed and ram usage
<Hauke> someone has to try it and do some mesurements
Night-Shade has joined #openwrt-devel
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<pkgadd> in the grand scheme of things, zstd support is still very recent, while lzma and xz are well known. it'll take a bit until someone really tries getting it working as well
<pkgadd> hard enough to find bootloaders that can read xz - and not pre-mainline squashfs lzma (yes, I know, only the kernel needs to be readable, but still)
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]> Kernel allows zstd file systems since 4.14 I think. So that should be a problem. I don't mean to change kernel compression itself
lemmi has quit [Ping timeout: 256 seconds]
<rsalvaterra> pkgadd: And there's a forthcoming update to upstream zstd, as soon as an agreement is reached… https://marc.info/?l=linux-crypto-vger&m=160090069502641&w=4
goliath has quit [Quit: SIGSEGV]
danitool has quit [Ping timeout: 240 seconds]
goliath has joined #openwrt-devel