**** BEGIN LOGGING AT Mon Oct 26 02:59:57 2020
Oct 26 03:18:26 <mangix> pkgadd: i asked as gch981213 added an mt7621 unit with ax
Oct 26 03:19:22 <mangix> that specific unit seems to have pretty little RAM though...
Oct 26 04:03:06 <pkgadd> mangix: hmm, which device?
Oct 26 05:01:47 <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)
Oct 26 05:07:06 <pkgadd> e.g. Xiaomi Mi AX1800, IPQ6000, 4*1.2 GHz, 128 MB flash, 256 MB RAM
Oct 26 05:30:18 >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.)
Oct 26 05:32:38 <mangix> maybe ath10k devices need more RAM because of the firmware. who knows.
Oct 26 05:34:54 <mangix> erm eth11k
Oct 26 05:38:28 <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)
Oct 26 05:38:43 <pkgadd> using xiaomi's OEM firmware
Oct 26 07:27:07 <russell--> blogic: in netifd's system-dummy.c, shouldn't line 60 be "bridge" instead of "brctl"?
Oct 26 07:27:10 <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",
Oct 26 08:26:27 <rsalvaterra> Morns!
Oct 26 08:32:27 <blogic> russell--: russell-- that is just debug code for the dummy handler
Oct 26 08:32:42 <blogic> russell--: but yeah, I beleive felix added that when he merged the commit
Oct 26 08:33:30 <rsalvaterra> nick[m]: I guess 4.19 on ath79 can now die peacefully. :)
Oct 26 08:34:13 <Borromini> the jffs2 issue got solved huh? :)
Oct 26 08:34:25 <rsalvaterra> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b
Oct 26 08:34:47 <rsalvaterra> And it was indeed related to the protection bits.
Oct 26 08:35:44 <Borromini> :)
Oct 26 08:36:02 <Borromini> so now we can have 20.10? 0:-)
Oct 26 08:38:06 <rsalvaterra> That's for the "upper management" to decide. :P
Oct 26 08:38:36 <Borromini> :P :P
Oct 26 08:39:55 <rsalvaterra> Ooh, Linux 5.10-rc1 is out. Imma checkin' out the new toys.
Oct 26 08:42:51 * enyc meows
Oct 26 08:47:13 <nitroshift> rsalvaterra, so 5.9 is the next lts?
Oct 26 08:48:08 <grift> when you install a package, say unbound-server , then what exactly adds the unbound group to /etc/group?
Oct 26 08:48:48 <grift> aparcar[m]: know?
Oct 26 08:49:11 <grift> trying to find that code dunno where to look
Oct 26 08:50:22 <rsalvaterra> nitroshift: I don't know. Has gregkh already "blessed" the new LTS?
Oct 26 08:50:59 <nitroshift> rsalvaterra, i have no idea, that's why i asked
Oct 26 08:53:51 <rsalvaterra> Nope, the LTS is stil at 5.4.
Oct 26 08:53:54 <rsalvaterra> *still
Oct 26 08:55:24 <PaulFertser> grift: opkg itself I guess, following Require-User attribute added to the package metadata.
Oct 26 08:55:48 <nitroshift> rsalvaterra, yeah, that's what kernel.org says too, thought you might have some other undisclosed news ;)
Oct 26 08:57:36 <rsalvaterra> nitroshift: This is free software, hopefully there are no undisclosed news. :P
Oct 26 09:03:00 <PaulFertser> grift: I see, it's not opkg, package/base-files/files/lib/functions.sh processes that metadata in add_group_and_user()
Oct 26 09:04:55 <PaulFertser> In default postinst script.
Oct 26 09:07:03 <grift> thanks ill have a look
Oct 26 09:07:40 <PaulFertser> grift: if you have issues understanding shell scripting I can try to help
Oct 26 09:08:01 <PaulFertser> grift: why is that you're interested in this topic?
Oct 26 09:08:33 <grift> essentially i just want to know how it "replaces" files like /etc/group
Oct 26 09:08:53 <grift> it seems it creates a file and then mv's it to /etc/group
Oct 26 09:09:25 <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
Oct 26 09:11:06 <grift> echo "${name}:x:${gid}:" >> ${IPKG_INSTROOT}/etc/group
Oct 26 09:11:24 <grift> make me wonder ..
Oct 26 09:11:43 <Borromini> >> just tacks it onto the contents of the file
Oct 26 09:12:10 <Borromini> IPKG_INSTROOT by default points to / unless you use extroot, i guess
Oct 26 09:13:44 <grift> yes strange though...
Oct 26 09:14:09 <Borromini> how so? :)
Oct 26 09:14:57 <grift> ill have to dig into this a bit and if i can't explain it table that issue for a while
Oct 26 09:15:28 <grift> editing /etc/group in that scenario seems to mess with its label, but it also edits /etc/passwd and that label is fine
Oct 26 09:16:10 <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 :/
Oct 26 09:16:31 <rsalvaterra> Oh… :/
Oct 26 09:17:44 <nick[m]> https://github.com/openwrt/openwrt/pull/3540
Oct 26 09:18:01 <nick[m]> https://github.com/openwrt/openwrt/pull/3540/commits/ca53872369aed9b3174713d126eef43188fedf75
Oct 26 09:20:30 <Borromini> grift: you mean with selinux?
Oct 26 09:21:23 <grift> yes
Oct 26 09:21:44 <grift> anyway i guess i will hit it again and deal with it later
Oct 26 09:22:16 <grift> might be sed
Oct 26 09:22:39 <grift> i suppose in some cases it uses sed and i guess sed creates a backup file with a random suffix
Oct 26 09:23:03 <grift> and i cant anticipate files with random names
Oct 26 09:23:08 <Borromini> sed for post-removal, i suppose
Oct 26 09:25:52 <grift> o right might have been my removal of the dnsmasq package...
Oct 26 09:28:01 <grift> where is that function for "post-removal"?
Oct 26 09:31:34 <Borromini> in a postinstall script, probably
Oct 26 09:31:38 <grift> but yes if thats what is cuasing it then specifying a fixed extension would solve it ie sed -i ".bak" ...
Oct 26 09:35:54 <grift> no its not any removal, because the dnsmasq user/group isnt removed on removal of the dnsmasq package
Oct 26 09:36:03 <grift> anyway i will table this and move on
Oct 26 09:36:29 <Borromini> grift: dnsmasq is different, it's a base package
Oct 26 09:36:36 <Borromini> that might influence things.
Oct 26 09:36:42 <Borromini> unbound is completely optional
Oct 26 10:32:15 <xback> ping f00b4r0
Oct 26 10:32:32 <f00b4r0> xback: pong
Oct 26 10:32:36 <xback> good morning
Oct 26 10:32:43 <xback> Quick question
Oct 26 10:32:59 <xback> We've just received a new batch of RB922 today which seems to be yet another revision.
Oct 26 10:33:09 <xback> although the board serials dont indicate it
Oct 26 10:33:17 <xback> but they have big yellow capacitors now
Oct 26 10:33:28 <f00b4r0> heh
Oct 26 10:33:29 <xback> We've just flashed them .. and wifi is again not detected
Oct 26 10:33:38 <f00b4r0> sweeet
Oct 26 10:33:53 <f00b4r0> I'm tempted to bet this is related to https://patchwork.ozlabs.org/project/openwrt/patch/20200824103840.38920-1-hacks@slashdirt.org/
Oct 26 10:33:56 <xback> the boards contain a onboard ath10k  and we've placed a ath9k 2x2 in the pcie slot
Oct 26 10:35:28 <xback> ps. I;m running latest 19.07
Oct 26 10:40:31 <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
Oct 26 10:40:53 <xback> drop Mikrotik?
Oct 26 10:41:03 <f00b4r0> drop support for their devices
Oct 26 10:41:18 <f00b4r0> to boot, the NAND-based device support is completely broken-by-design.
Oct 26 10:42:01 <xback> I'm more than willing to aid in keeping them alive
Oct 26 10:42:12 <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
Oct 26 10:42:28 <f00b4r0> believing*
Oct 26 10:43:45 <f00b4r0> xback: those 922 are NAND-based, right?
Oct 26 10:43:46 <damex> f00b4r0: there is really interesting devices from mikrotik...
Oct 26 10:44:15 <f00b4r0> damex: sure, but nobody really cares and mikrotik is (actively or passively) making it very hard for us to deal with their stuff
Oct 26 10:44:29 <damex> hEX PoE (RB960PGS) is quite unique
Oct 26 10:45:02 <damex> f00b4r0: hmm... i thought people still use them and add support for their boards (from time to time?)
Oct 26 10:45:19 <damex> what kind of support do you need for it to be justified? :)
Oct 26 10:45:35 <f00b4r0> damex: it's commit and forget, and most of the time it's "commit garbage and forget"
Oct 26 10:48:25 <zorun> there definitely is interest to keeping them supported
Oct 26 10:48:38 <f00b4r0> good to hear
Oct 26 10:48:47 <karlp> are you saying that only mikrotik support is "garbage and forget"? that seems particularly prejudiced.
Oct 26 10:48:54 <zorun> but I agree these revision changes are really annoying (we are considering changing vendor just because of this)
Oct 26 10:48:59 <f00b4r0> karlp: lol; touché
Oct 26 10:49:10 <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
Oct 26 10:49:33 <zorun> damex: that's a sensitive discussion :)
Oct 26 10:49:54 <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
Oct 26 10:50:05 <damex> maybe if we (or someone) pay more attention to each device in question - quality of the outcome might be better
Oct 26 10:50:15 <f00b4r0> ...
Oct 26 10:50:19 <damex> f00b4r0: uh... okay :(
Oct 26 10:50:43 <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
Oct 26 10:50:45 <xback> f00b4r0: yes. they are NAND
Oct 26 10:51:23 <xback> we currently roughly have about 100 of them running in the field offshore
Oct 26 10:51:28 <f00b4r0> ugh
Oct 26 10:51:36 <f00b4r0> don't update them too often then :P
Oct 26 10:51:41 <xback> the only issue ever seen so far is that sysupgrade sometimes fails
Oct 26 10:51:49 <xback> something appeared to be changed in nand
Oct 26 10:52:02 <xback> and I need to set sysupgrade executable bit again at that point
Oct 26 10:52:10 <f00b4r0> well
Oct 26 10:52:29 <xback> I did not encounter that with rb912 (also nand)
Oct 26 10:52:38 <f00b4r0> that sounds pretty harmless in comparison to what can (and will) happen
Oct 26 10:52:56 <f00b4r0> the kernel partition will eventually die abruptly. We do not manage badblocks _at all_ on that partition.
Oct 26 10:53:20 <f00b4r0> thanks to the extremely stupid kernel2minor "workaround"
Oct 26 10:53:55 <xback> is that patch backportable to 19.07?
Oct 26 10:54:12 <f00b4r0> the one I linked?
Oct 26 10:54:14 <f00b4r0> I suppose so
Oct 26 10:54:29 <xback> just tried and didn't apply.  checking now
Oct 26 10:55:02 <xback> ah.  19.07 is at v0.3 still :-)
Oct 26 10:55:08 <f00b4r0> heh
Oct 26 10:55:15 <f00b4r0> note that this is still not in master
Oct 26 10:55:23 <f00b4r0> not sure why it's not so.
Oct 26 10:55:47 <xback> no worries. I'll take care of it
Oct 26 10:56:04 <xback> I've been absent for quite some time due to other tasks
Oct 26 10:56:19 <f00b4r0> i can't guarantee this'll fix your woes, it's possible mikrotik once again did something clever ;P
Oct 26 10:56:40 <f00b4r0> no worries, I'm currently rather busy setting up shop (I quit my job and am going full freelance ;)
Oct 26 10:57:08 <f00b4r0> john-tho has been extremely helpful in the meantime, btw
Oct 26 10:57:19 <stintel> f00b4r0: congrats!
Oct 26 10:57:28 <f00b4r0> stintel: heh, we'll see how that pans out :)
Oct 26 10:57:31 <f00b4r0> but thanks
Oct 26 10:57:50 <xback> I followed the discussion from a distance with john-tho
Oct 26 10:57:55 <xback> very interesting stuff
Oct 26 10:58:04 <xback> and congratz with your shop :-)
Oct 26 10:58:10 <stintel> going full freelance + moving to Bulgaria (10% tax) were some of the best decisions I ever made
Oct 26 10:58:11 <f00b4r0> he basically implemented everything I was looking forward.
Oct 26 10:58:37 <f00b4r0> native compressed elf boot, and he also has a rather neat fix for the 4K_SECTORS nightmare
Oct 26 10:58:39 <nick[m]> is there an example how to findout the correct settings for rgmii ethernet interface?
Oct 26 10:59:34 <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 :)
Oct 26 10:59:48 <damex> nick[m]: maybe stock will have it in device tree? or uboot?
Oct 26 11:00:19 <f00b4r0> stintel: out of curiosity, you moved to Bulgaria from ?
Oct 26 11:00:25 <stintel> f00b4r0: Belgium
Oct 26 11:00:33 <f00b4r0> oh wow. I see, quite a jump.
Oct 26 11:00:45 <stintel> well 50% tax is pure theft
Oct 26 11:00:58 <stintel> so yeah, quite the jump from 50 to 10 :P
Oct 26 11:01:01 <f00b4r0> heh. I lived and worked in Belgium (BXL) for 6 months. Didn't like it one bit ;P
Oct 26 11:01:06 <stintel> bxl is horrible
Oct 26 11:02:05 <f00b4r0> but yeah, I thought France had a brain damaged tax system; that was until I went to Belgium ;P
Oct 26 11:03:06 <stintel> hahaha
Oct 26 11:03:28 <Namidairo> > he also has a rather neat fix for the 4K_SECTORS nightmare
Oct 26 11:04:12 <Namidairo> but I love spending 10 minutes waiting for the kernel to flash
Oct 26 11:04:23 <f00b4r0> heh
Oct 26 11:04:51 <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
Oct 26 11:06:16 <xback> I can ping Boris
Oct 26 11:07:34 <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
Oct 26 11:09:30 <f00b4r0> xback: actually I htink he's about to resend. Maybe tell him he should CC someone?
Oct 26 11:17:05 <nick[m]> damex: then I have to extract the devicetree frist ;) what do u mean with uboot? never heard of that
Oct 26 11:17:14 <nick[m]> u can extract the values from there
Oct 26 11:18:04 <damex> nick[m]: does device have uboot?
Oct 26 11:18:10 <damex> how does it boot and what kind of device is it?
Oct 26 11:18:16 <nick[m]> damex: yes it has uboot
Oct 26 11:18:36 <damex> uboot can help with extracting device tree and it might be different from what your OS sees
Oct 26 11:18:38 <xback> f00b4r0: just resend. I can pickup and ping from there
Oct 26 11:18:40 <nick[m]> damex: it is a ar9342 soc (nanstation ac loco)
Oct 26 11:18:54 <nick[m]> damex: okay, nice :) so I just google a bit? :D
Oct 26 11:18:59 <f00b4r0> xback: don't tell *me* :)
Oct 26 11:19:32 <damex> nick[m]: i think `fdt print /` is the one you're looking for
Oct 26 11:19:35 <damex> in uboot
Oct 26 11:19:48 <nick[m]> nice I will try! thanks :D
Oct 26 11:19:49 <damex> varies so might be just `fdt print`
Oct 26 11:20:43 <Borromini> good luck and congrats f00b4r0 :)
Oct 26 11:20:59 <f00b4r0> thx :)
Oct 26 11:26:36 <nitroshift> nbd, ping
Oct 26 11:28:14 <nick[m]> damex: my uboot on the device does not have fdt :/
Oct 26 11:29:14 <damex> nick[m]: you can try to dump uboot binary and do binwalk/extract-dtb
Oct 26 11:29:39 <damex> uboot binary partition*
Oct 26 11:31:58 <damex> nick[m]: if it boots - you can extract dt from running system if it runs with dt
Oct 26 11:32:34 <nick[m]> damex: the device tree is in the uboot partition? I always thought that it is the firmware section
Oct 26 11:33:09 <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 ;)
Oct 26 11:33:10 <damex> nick[m]: depends. some devices have device tree embedded with uboot. that way you have uboot initalize device using dt
Oct 26 11:34:55 <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
Oct 26 11:35:08 <nick[m]> thanks! :)
Oct 26 11:35:16 <damex> nick[m]: you can try to use binwalk on airos firmware
Oct 26 11:35:32 <nick[m]> ahh okay :O
Oct 26 11:35:41 <damex> might find (and extract?) what you're looking for (or not~)
Oct 26 11:40:23 <nick[m]> damex: should there popup something like "device tree image (dtb)"? Cause it does not xD
Oct 26 11:40:57 <damex> nick[m]: yeah, should be
Oct 26 11:41:37 <nitroshift> i've brought mvebu to 5.9
Oct 26 11:41:38 <nick[m]> damex: tried "extract-dtb" and nothing useful :/
Oct 26 11:42:01 <nick[m]> I will try duming uboot :D
Oct 26 11:42:58 <nick[m]> damex: or is there some source there u can find datasheets for ar9342 socs?
Oct 26 11:46:00 <damex> nick[m]: not sure about that one. you need info about your mdio? ag71xx as in AR8216/AR8236/AR8316 ?
Oct 26 11:46:01 <rsalvaterra> nick[m]: I have for 9331 and 9344, but not for 9342… :/
Oct 26 11:46:11 <damex> or something else?
Oct 26 11:46:40 <dengqf6> I think 5.10 will be the next LTS
Oct 26 11:50:45 <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?
Oct 26 11:50:53 <nick[m]> rsalvaterra: same xD
Oct 26 11:53:16 <nick[m]> damex: I need Atheros AR8035
Oct 26 12:00:24 <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...
Oct 26 12:05:27 <blocktrron> nick[m]: see which registers at803x.c touches depending on the phy mode
Oct 26 12:07:34 <blocktrron> The AR934x and subsequent chips are also capable of introducing delays on the mac side
Oct 26 12:12:15 <damex> nick[m]: sure it is ar8035 ? https://media.digikey.com/pdf/data%20sheets/csr%20pdfs/ar8035_ds_(atheros)_mar2011.pdf
Oct 26 12:13:57 <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
Oct 26 12:14:37 <nick[m]> so this is only phy mode delays, and I wanted what blocktrrron describes, the delays on the mac side :)
Oct 26 12:16:55 <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?
Oct 26 12:29:32 <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." ?
Oct 26 12:33:48 <nick[m]> MAC (add delays "rgmii") <-> Phy (add delays "rgmii-id")
Oct 26 12:34:16 <nitroshift> stintel, ping
Oct 26 13:03:05 <xback> f00b4r0: it seems latest master has issues with RB922 (nand ..)
Oct 26 13:03:21 <xback> will need to sort that out first
Oct 26 13:05:40 <f00b4r0> xback: as I said, we don't do badblocks management. From that, anything goes.
Oct 26 13:06:10 <f00b4r0> xback: if you want to rule out storage in your wifi tests, you can always netboot :)
Oct 26 13:06:46 <xback> got it running now
Oct 26 13:06:52 <f00b4r0> i'm curious if my patch will fix it for you, that would suggests they're deploying the new scheme in existing devices
Oct 26 13:07:12 <xback> well. I want to test it right away.  as I got various revisions laying around now
Oct 26 13:07:14 <f00b4r0> s/existing/old/
Oct 26 13:07:37 <xback> made 2 builds.   one without  and one with your latest patch
Oct 26 13:07:43 <xback> currently running without the patch
Oct 26 13:08:03 <f00b4r0> note that the patch is a NOP on old-style hardware
Oct 26 13:09:23 <f00b4r0> i tried to be thorough in the commit message, let me know if it needs improvement
Oct 26 13:11:27 <xback> interesting ..  on master even without the patch.   the radio's are recognized.
Oct 26 13:11:33 <xback> on 19.07 they are not.   only on this board
Oct 26 13:11:48 <xback> other boards behave well
Oct 26 13:12:07 <xback> I've already made some backporting efforts in my staging. but I guess it's still lacking some more ports
Oct 26 13:12:22 <xback> probably the extraction script
Oct 26 13:15:00 <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
Oct 26 13:16:01 <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
Oct 26 13:16:02 <zorun> https://git.openwrt.org/ac56d253618c8c607944
Oct 26 13:16:28 <f00b4r0> i don't quite remember what has and hasn't been backported
Oct 26 13:16:39 <zorun> yes, sure, it's just that if newer hardware doesn't work as expected, I know where to look ;)
Oct 26 13:16:56 <zorun> mostly everything you sent has been backported to 19.07
Oct 26 13:17:10 <zorun> 18.06 has less changes, but this is to be expected
Oct 26 13:18:03 <f00b4r0> sure. 18.06 is EOL, right?
Oct 26 13:18:40 <f00b4r0> xback: in any case, if master works for you, that means my work is done :D
Oct 26 13:18:59 <xback> very true
Oct 26 13:19:11 <xback> thanks for being a listening ear ;-)
Oct 26 13:19:41 <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)
Oct 26 13:19:44 <f00b4r0> :D
Oct 26 13:26:39 <zorun> f00b4r0: in your patch, you mention the need for adaptation in hotplug scripts, did you send such a patch already?
Oct 26 13:29:27 <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
Oct 26 13:29:35 <f00b4r0> the PRs have that change.
Oct 26 13:47:10 <zorun> ah, right, that makes sense
Oct 26 13:51:13 <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
Oct 26 13:51:41 <damex> so i named it exactly as uboot and kernel upstream expects it to be
Oct 26 15:08:56 <grift> ok so i have it do dns over tls using the google servers
Oct 26 15:09:02 <grift> wrong chan
Oct 26 16:17:13 <svanheule[m]> 5.10 will be the next LTS https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-LTS-Kernel
Oct 26 16:18:28 <rsalvaterra> Awww, yiss!
Oct 26 17:26:02 <grift> yes its some uci issue, the same with the verbosity earlier
Oct 26 17:26:13 <grift> wrong chan
Oct 26 17:28:46 <grift> but yes for this chan, the unbound package could use some attention. its pretty ugly
Oct 26 17:30:03 <grift> thing is so overengineered though that aside from whoever did that no one probably knows if and how it works
Oct 26 17:41:08 <Hauke> zorun: I am waiting for one security fix and would push it then
Oct 26 17:57:36 >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.)
Oct 26 18:06:56 <blogic> this bkpepe dude on github is weird
Oct 26 18:14:27 <stintel> is bkpepe not a core dev? :P
Oct 26 18:14:39 <stintel> (one doesn't invalidate the other)
Oct 26 18:19:59 <blogic> stintel: nutter, my cellphone just ping'ed
Oct 26 18:20:12 <blogic> anyhow, https://github.com/openwrt/packages/pull/13770
Oct 26 18:20:26 <blogic> bad and ugly are simply not words you wanna use
Oct 26 18:20:43 <stintel> you can, but not if you've agreed to "be nice ot eachother"
Oct 26 18:24:57 <blogic> I actually dont care, still seems odd
Oct 26 18:25:13 <blogic> but then again I had my own share of ranting in the past so who am I to complain
Oct 26 18:26:55 <olmari> Courtesy usually goes long way  indeed, even if shouting it out straight would not be wrong in content
Oct 26 18:27:15 <adrianschmutzler> Hi, I find a lot of Image/mkfs/... definitions in image.mk, but don't see them used anywhere.
Oct 26 18:27:31 <adrianschmutzler> Is this legacy and may be removed?
Oct 26 18:28:11 <adrianschmutzler> The recipes were touched during the various selinux patches, but I still don't see any users...
Oct 26 18:59:04 <aparcar[m]> adrianschmutzler: do you have an example line?
Oct 26 18:59:23 <aparcar[m]> also thanks for all the metadata comments
Oct 26 18:59:48 <adrianschmutzler> This will take long enough anyway.
Oct 26 19:00:03 <adrianschmutzler> https://github.com/openwrt/openwrt/blob/master/include/image.mk#L237
Oct 26 19:00:10 <adrianschmutzler> mkfs stuff is starting there
Oct 26 19:00:51 <adrianschmutzler> however, I do not find anything beyond the definitions when grepping for mkfs ...
Oct 26 19:03:44 <grift> aparcar[m]: https://github.com/openwrt/packages/blob/master/net/unbound/files/unbound.sh#L263 and line 264 are problematic because of this https://github.com/openwrt/packages/blob/master/net/unbound/files/unbound.ntpd#L21
Oct 26 19:04:14 <grift> i would argue that it should probably be unbound.root 0775
Oct 26 19:04:36 <grift> so that hotplugcall doesnt need cap_dac_override to create that time stamp in there
Oct 26 19:10:43 <aparcar[m]> adrianschmutzler: these are target features
Oct 26 19:11:59 <aparcar[m]> at least I think that's it https://github.com/openwrt/openwrt/blob/master/target/linux/armvirt/Makefile#L12
Oct 26 19:12:07 <aparcar[m]> these are resolved to actual calls in image.mk
Oct 26 19:14:16 <aparcar[m]> grift: sounds simple enough
Oct 26 19:17:45 <adrianschmutzler> ah, I've just found it; it's in image.mk line 343
Oct 26 19:18:51 <grift> aparcar[m]: i will file an issue on github as this isnt the only issue with that package
Oct 26 19:19:31 <aparcar[m]> adrianschmutzler: should we use label or function for ethernet ports?
Oct 26 19:26:08 <adrianschmutzler> for what?
Oct 26 19:26:34 <adrianschmutzler> the function of ethernet ports is "lan", the label is "lan1"
Oct 26 19:26:58 <adrianschmutzler> so, depending on what you want to tell
Oct 26 19:27:42 <adrianschmutzler> the question is whether we want to make that distinction between lan and wan at all
Oct 26 19:30:15 <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
Oct 26 19:31:26 <adrianschmutzler> I also weakly tend to provide such a function property
Oct 26 19:31:49 <grift> added issue: https://github.com/openwrt/packages/issues/13778
Oct 26 19:31:52 <aparcar[m]> ethernet port mapping?
Oct 26 19:31:56 <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
Oct 26 19:32:04 <aparcar[m]> flash layout?
Oct 26 19:32:05 <aparcar[m]> https://aparcar.github.io/openwrt-devices/devices/tp-link_archer_c7_v5/
Oct 26 19:32:11 <adrianschmutzler> no to both
Oct 26 19:32:18 <grift> too worn out to fork, took me the whole day to get unbound running
Oct 26 19:32:18 <aparcar[m]> ok
Oct 26 19:33:06 <adrianschmutzler> flash layout is in DTS; we should try to prevent redundancy here
Oct 26 19:33:19 <adrianschmutzler> The idea is to provide complementary information
Oct 26 19:34:06 <adrianschmutzler> or at least information that is general but cannot be extracted by a general approach
Oct 26 19:34:10 <adrianschmutzler> like flash size
Oct 26 19:34:20 <aparcar[m]> yep
Oct 26 19:35:06 <adrianschmutzler> therefore, also leds/buttons are a bit redundant for my taste
Oct 26 19:35:15 <aparcar[m]> wow the amount of usb standards is awkward
Oct 26 19:35:48 <aparcar[m]> yea a parser could extract that automatically
Oct 26 19:36:48 <adrianschmutzler> while e.g. narrowing down usb ports to just mode and size might actually create a benefit
Oct 26 19:37:22 <aparcar[m]> agree
Oct 26 19:38:28 <adrianschmutzler> LEDs/Buttons could be something worth keeping optionally ...
Oct 26 19:38:53 <adrianschmutzler> But personally I would not add that to yaml file when adding a device
Oct 26 19:41:53 <adrianschmutzler> btw I still have the old version of your size_compare.sh in my staging
Oct 26 19:42:00 <adrianschmutzler> do you plan working on this again?
Oct 26 19:43:07 <aparcar[m]> adrianschmutzler: yea I could give it another spin
Oct 26 19:43:29 <aparcar[m]> is plural of usb "USBs"?
Oct 26 19:44:36 <adrianschmutzler> busses?
Oct 26 19:44:37 <aparcar[m]> nevermind
Oct 26 19:44:59 <adrianschmutzler> I would then add a noun, e.g. usb_ports, usb_adapters, ...
Oct 26 19:45:55 <aparcar[m]> I just go ith usb now
Oct 26 19:51:44 <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
Oct 26 20:01:34 <aparcar[m]> adrianschmutzler: https://github.com/openwrt/openwrt/pull/3534#discussion_r512232951
Oct 26 20:23:43 <rsalvaterra> I had forgotten what "fun" it is to create/edit patches with quilt…
Oct 26 20:26:03 <rsalvaterra> "Oh, you edited a file and didn't notice it wasn't being tracked? <nelson> Ha, ha! </nelson>"
Oct 26 22:11:29 <aparcar[m]> anyone ever looked into squashfs + zstd?
Oct 26 22:14:33 <rsalvaterra> aparcar[m]: Only zram + zstd.
Oct 26 22:25:39 <philipp64|work> Anyone seen Kaloz recently?
Oct 26 22:44:09 <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/
Oct 26 22:48:37 <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.
Oct 26 22:49:19 <rsalvaterra> The buildbot won't be happy, though. :P
Oct 26 22:49:22 <Hauke> yes, it could improve the situation
Oct 26 22:49:38 <Hauke> the compression also depends on the content
Oct 26 22:50:01 <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
Oct 26 22:50:19 <Hauke> it alos depends on the decompression speed and ram usage
Oct 26 22:50:38 <Hauke> someone has to try it and do some mesurements
Oct 26 23:08:18 <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
Oct 26 23:09:19 <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)
Oct 26 23:13:46 <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
Oct 26 23:18:59 <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
Oct 27 01:00:56 <biangbiangmian> I am on IPQ4019, and every time I reset the device the MAC addresses for WAN and LAN change.  Is that a known issue?
Oct 27 01:01:19 <biangbiangmian> I am running git master
Oct 27 02:18:30 <pkgadd> that shouldn't happen, but is probably more device specific than generic for ipq4019 (my ipq4019/ map-ac2200 does not have that issue)
Oct 27 02:18:49 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
Oct 27 02:19:38 <pkgadd> correct MAC address assignments are easily missed during development for a new device
Oct 27 02:26:29 <biangbia_> I will double check it
Oct 27 02:26:41 <biangbia_> thanks @pkgadd
**** ENDING LOGGING AT Tue Oct 27 02:59:57 2020