**** BEGIN LOGGING AT Mon Apr 20 02:59:57 2020
Apr 20 04:58:32 <owrt-1907-builds> build #143 of mediatek/mt7622 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7622/builds/143
Apr 20 06:17:26 <owrt-1907-builds> build #145 of mediatek/mt7623 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7623/builds/145
Apr 20 07:27:24 <owrt-1907-builds> build #142 of cns3xxx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/cns3xxx%2Fgeneric/builds/142
Apr 20 08:33:08 <owrt-1907-builds> build #142 of mvebu/cortexa9 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa9/builds/142
Apr 20 09:17:20 <Tapper> Switching to dsa in mvebu seems like a pane in the ass!
Apr 20 09:17:30 <Tapper> on mvebu
Apr 20 09:18:01 <Tapper> I don't understand what's better about it!
Apr 20 09:18:36 <mrkiko> Tapper: well, even in ramips hasn't been easy. Still, the device looks cleaner to me right now, and btw DS is upstream, swconfig is not.
Apr 20 09:19:17 <Tapper> But if you can onley get trfic to flow through 1 CPU core then what good is that?
Apr 20 09:19:33 <Tapper> traffic*
Apr 20 09:36:35 <mrkiko> Tapper: is that the case? don't think so
Apr 20 09:37:46 <mrkiko> Tapper: but I may very well be wrong
Apr 20 09:49:48 <owrt-1907-builds> build #142 of mvebu/cortexa53 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/142
Apr 20 10:06:00 <RobertP> could someone school me on how to add SYNPROXY support to kernel and iptables? Looks like source code is there, but no way with existing menuconfig to add this support - do I need to amend /include/netfilter.mk file?
Apr 20 10:37:30 <stintel> what was the name of the tool that uses netperf to do bufferbloat testing etc ?
Apr 20 10:37:41 <ldir> flent
Apr 20 10:37:45 <stintel> thanks!
Apr 20 10:38:15 <jow> RobertP: yes, you need to amend netfilter.mk and possibly package/kernel/linux/*
Apr 20 10:43:48 <stintel> interesting. netperf 2.7.0 doesn't build on Gentoo hardened musl, yet we carry no patches for it in packages feed
Apr 20 10:45:15 <xback> adrianschmutzler: ping
Apr 20 10:46:32 <xback> adrianschmutzler: is there a way in DTS to specify a random MAC address?
Apr 20 10:47:05 <xback> the main reason is so avoid this warning:  [    0.810274] ag71xx 19000000.eth: invalid MAC address, using random address
Apr 20 10:47:35 <dengqf6> xback: just supress this warning then
Apr 20 10:48:22 <xback> dengqf6: how exactly? (I'm not a DTS expert at all :-)  )
Apr 20 10:48:44 <dengqf6> xback: patch the kernel, not the dts ;)
Apr 20 10:48:46 <ynezz> dont have complete context, but to me it seems like you should just remove that MAC address source
Apr 20 10:48:58 <dengqf6> xback: btw https://github.com/openwrt/openwrt/pull/2936
Apr 20 10:49:06 <ynezz> as it looks like its probably invalid
Apr 20 10:50:16 <xback> The context in short is following:   DTS is parsed before a kernel mod which picks up the MAC (and sets it) is loaded
Apr 20 10:51:30 <ynezz> example please?
Apr 20 10:52:46 <dengqf6> Tapper: there is a multi-cpu patch in turris' code
Apr 20 10:55:05 <xback> ynezz: checking ..
Apr 20 10:55:20 <xback> dengqf6: I'll take a look at it. thanks
Apr 20 10:59:18 <adrianschmutzler> xback: pong
Apr 20 10:59:46 <xback> adrianschmutzler: ^^
Apr 20 10:59:58 <adrianschmutzler> I'm not aware of a way to "allow" a random MAC address
Apr 20 11:00:07 <adrianschmutzler> but that doesn't mean there is none
Apr 20 11:00:47 <adrianschmutzler> typically the workaround for providing an address in cases where the board.d stuff was too late were these preinit scripts
Apr 20 11:01:45 <adrianschmutzler> like here: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/base-files/lib/preinit/10_fix_eth_mac.sh
Apr 20 11:02:06 <adrianschmutzler> but that doesn't seem to be what you need exactly
Apr 20 11:02:21 <xback> I'm currently testing f00b4r0 's patches which use a kernel module to parse the Mikrotik data from eeprom
Apr 20 11:02:45 <xback> it's really clean and works really well.  but it only gets loaded after DTS parsing (even when embeded)
Apr 20 11:03:00 <xback> so the MAC is random at first, and then gets sets correctly afterwards
Apr 20 11:03:23 <adrianschmutzler> and what sets the correct address then?
Apr 20 11:03:24 <xback> this produces a warning in dmesg as the mtd-mac-address property is omitted now
Apr 20 11:03:43 <adrianschmutzler> if it isn't the mtd-mac-address?
Apr 20 11:04:27 <ynezz> then there is something missing in the patches
Apr 20 11:04:35 <xback> via sysfs
Apr 20 11:04:53 <xback> https://github.com/f00b4r0/openwrt/commit/a9c5ad3c07f7b2ef0823afe4dcad81b5dc39fc89
Apr 20 11:04:59 <adrianschmutzler> so it's done by f00b4r0's drivers?
Apr 20 11:05:14 <xback> see commit at the end
Apr 20 11:05:19 <f00b4r0> it's done by 02_network using setup_macs()
Apr 20 11:05:23 <f00b4r0> i have to run, bbiab
Apr 20 11:05:33 <ynezz> ugh
Apr 20 11:05:45 <adrianschmutzler> ah, that patch wasn't at the list yet, was it?
Apr 20 11:06:40 <xback> correct
Apr 20 11:06:52 <xback> This is potential V2 candidate which i'm checking early
Apr 20 11:07:00 <adrianschmutzler> anyway, xback: what exactly is the problem? just that you want to suppress the random-mac message or something else?
Apr 20 11:07:27 <RobertP> jow: Thanks - is there any documentation for netfilter.mk file? not sure what needs to be added to this file in order to work ...
Apr 20 11:07:27 <adrianschmutzler> didn't get that in the backlog ...
Apr 20 11:07:34 <xback> yeah, suppress the "invalid mac - generating random .."
Apr 20 11:08:12 <ynezz> then set it to some valid random mac yourself :p
Apr 20 11:08:33 <xback> hence the question if there was a property for that ;-)
Apr 20 11:08:36 <adrianschmutzler> Okay, then I have no idea. But that actually affect a lot of devices, at least all which use mtd_mac_from_ascii (or how it's called correctly)
Apr 20 11:08:39 <ynezz> mtd-mac-address:
Apr 20 11:08:43 <ynezz> thats the property
Apr 20 11:09:07 <ynezz> err, the other one
Apr 20 11:09:11 <ynezz> local-mac-address
Apr 20 11:09:26 <xback> I noticed others too:  local-mac-address     mac-address    etc
Apr 20 11:09:29 <adrianschmutzler> ynezz: but that would then be the same address for all
Apr 20 11:09:35 <adrianschmutzler> ... devices
Apr 20 11:09:40 <jow> RobertP: nope
Apr 20 11:09:48 <adrianschmutzler> which just doesn't matter as we overwrite it anyway
Apr 20 11:10:11 <ynezz> it's just another hack anyway, so why to bother?
Apr 20 11:10:30 <xback> adrianschmutzler: the rationale here is 2-fold:    1) avoid the warning    2)  if the module fails for whatever reason,  try to stay behind with a random valid mac
Apr 20 11:11:02 <adrianschmutzler> yeah, and I don't think you can get both
Apr 20 11:11:15 <ynezz> local-mac-address = [00 00 00 00 00 00];
Apr 20 11:11:31 <adrianschmutzler> this will trigger a random one?
Apr 20 11:12:28 <owrt-1907-builds> build #143 of archs38/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/143
Apr 20 11:13:28 <RobertP> jow: thanks ... looks like this is way above my head :)
Apr 20 11:14:51 <adrianschmutzler> because if there is a solution which is not too hacky, one should actually consider to use that on mtd_get_mac_ascii() devices as well
Apr 20 11:16:46 <ynezz> all zeroes = invalid MAC address
Apr 20 11:16:58 <ynezz> but you could check for this known address in that script
Apr 20 11:17:17 <ynezz> and generate random MAC address
Apr 20 11:18:23 <adrianschmutzler> okay, and if the script fails, one would be stuck with all zeros
Apr 20 11:19:48 <ynezz> nope
Apr 20 11:19:56 <ynezz> kernel would set random MAC address
Apr 20 11:20:14 <ynezz> but you can override it with another one later in userspace
Apr 20 11:20:46 <ynezz> kernel checks if it got valid MAC address, otherwise uses random
Apr 20 11:20:57 <ynezz> booting over network etc.
Apr 20 11:21:00 <adrianschmutzler> hmm, looks like I should just try it out at some point
Apr 20 11:21:49 <adrianschmutzler> anybody knows how mikrotik is dealing with that?
Apr 20 11:22:20 <adrianschmutzler> or is this not relevant because they probably don't use device tree
Apr 20 11:22:46 <adrianschmutzler> hmm, let's look up in ar71xx ...
Apr 20 11:32:43 <f00b4r0> they don't use DTS
Apr 20 11:32:56 <f00b4r0> in ar71xx we passed the correct mac via the routerboot routines
Apr 20 11:33:45 <f00b4r0> I think the only issue here is whether or not the dmesg output is considered a "problem". If it isn't, we can move forward. If it is, then I guess the only alternative is to used a fixed mac in DTS, same for all devices, and live with it
Apr 20 11:34:23 <f00b4r0> my preference goes to let the kernel issue the printk and generate a random address for us, that way if something breaks in userspace: 1) we have a random valid MAC and 2) people will know where to look at
Apr 20 11:38:01 <karlp> I'm getting "jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x0527 instead" on my spi flash image attempt on sunxi, so I _presume_ I've got padding or something wrong with the image creation.  I've tried following ath79's image makefiles with padding and appendning, but there's a _lot_ of combinations.
Apr 20 11:38:26 <karlp> is there any guideance on what I should be aiming for, rather than just trying different combinations? I feel a bit like a monkey poking it at the moment
Apr 20 11:38:41 <karlp> I've got "IMAGE/other2 := append-kernel | pad-to $$$$(BLOCKSIZE) | append-rootfs | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)" so far.
Apr 20 11:51:51 <adrianschmutzler> f00b4r0: So, we would effectively have the same situation as with the mtd_get_mac_ascii devices
Apr 20 11:52:15 <f00b4r0> adrianschmutzler: I'm not familiar with that situation, so I'll have to take your word for it :)
Apr 20 11:53:40 <adrianschmutzler> just meaning that you wouldn't be the first. It's sad that there is no way for a really satisfying solution with these devices
Apr 20 11:54:17 <f00b4r0> well, I guess this is us hitting the limitations of DTS. There's only so much one can "describe"
Apr 20 11:59:40 <xback> f00b4r0: screw it.  leave the warning in :-)
Apr 20 11:59:56 <xback> i'd rather have a random one that all the same mac
Apr 20 12:00:04 <f00b4r0> same here :)
Apr 20 12:00:17 <xback> usecase here is that some people (like me) tend to flash a batch of boards in 1 go
Apr 20 12:00:21 <ynezz> adrianschmutzler: there is solution, proper MAC address implementation
Apr 20 12:01:35 <ynezz> adrianschmutzler: in other words current upstream solution, using nvmem subsystem
Apr 20 12:02:02 <ynezz> everything else is just our downstream hack^Wsolution
Apr 20 12:02:07 <ynezz> :)
Apr 20 12:02:09 <adrianschmutzler> what happened to that, btw? IIRC, you had some patches for 4.14 more than a year ago ...
Apr 20 12:03:33 <ynezz> the usual answer, no time/interested :)
Apr 20 12:04:32 <adrianschmutzler> so, there is no actual blocker?
Apr 20 12:04:57 <ynezz> no, I'm not aware about such
Apr 20 12:05:39 <ynezz> those ascii variants are going to be fun, but IIRC upstream has suggested some possible solution to those use cases as well
Apr 20 12:05:40 <f00b4r0> nvmem doesn't seem to handle the specific case I'm dealing with
Apr 20 12:05:50 <f00b4r0> or I didn't fully understand the code. I did take a look.
Apr 20 12:07:21 <adrianschmutzler> looking into this is still on my whenever-I-have-more-time-than-just-a-little todo list
Apr 20 12:07:59 <adrianschmutzler> but most probably it's too much kernel for me anyway
Apr 20 12:14:01 <xback> God I miss board files already :-p
Apr 20 12:34:31 <owrt-1907-builds> build #143 of x86/geode is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/143
Apr 20 12:47:40 <Borromini> xback: lol.
Apr 20 12:47:46 <Borromini> i assume they were a lot easier than DTS?
Apr 20 12:56:22 <f00b4r0> adrianschmutzler: quick question if you have the time: https://github.com/f00b4r0/openwrt/commit/a7b5800e0f06820e5ae1db9abd22c6faad406fbb
Apr 20 12:56:38 <f00b4r0> the "status = "okay";" is necessary, correct?
Apr 20 12:56:49 <f00b4r0> the node can't be empty
Apr 20 12:57:24 <adrianschmutzler> depends on whether it was disabled before
Apr 20 12:57:29 <adrianschmutzler> let me looks
Apr 20 12:57:32 <adrianschmutzler> *look
Apr 20 12:57:50 <gch981213> f00b4r0: you could just remove the node completely.
Apr 20 12:58:02 <f00b4r0> gch981213: thanks
Apr 20 12:58:19 <adrianschmutzler> what gch981213 says
Apr 20 12:58:26 <f00b4r0> ;)
Apr 20 12:58:32 <adrianschmutzler> it's not disabled when it's created in mt7621.dtsi
Apr 20 12:59:19 <adrianschmutzler> btw, in 02_network, I wouldn't use cat three times, if you already have the label_mac variable
Apr 20 12:59:29 <f00b4r0> oh good point
Apr 20 12:59:35 <adrianschmutzler> lan_mac=$(macaddr_add $label_mac 1)
Apr 20 12:59:41 <f00b4r0> ACK
Apr 20 12:59:44 <f00b4r0> thanks!
Apr 20 12:59:57 <f00b4r0> sometimes I overlook the obvious
Apr 20 13:00:18 <adrianschmutzler> and (matter of taste) I'd not use mac_base at all, but directly use the path when calling cat for label_ma
Apr 20 13:00:41 <adrianschmutzler> that will spare us the discussion about the best name for it as well :-)
Apr 20 13:00:58 <f00b4r0> hehe ok, I'll edit away
Apr 20 13:01:05 <adrianschmutzler> so label_mac=$(cat /sys/firmware/mikrotik/hard_config/mac_base)
Apr 20 13:36:48 <Borromini> guys this might be silly but i don't want to fry my router - i have a usb ttl cable that has a single 5.5v wire, but no 3.3v wire (just tx, rx and gnd)
Apr 20 13:37:09 <Borromini> can i make do with just tx/rx/gnd? since the router needs 3.3v only, not 5v
Apr 20 13:39:21 <karlp> yes, just don't connect it.
Apr 20 13:39:54 <karlp> if you're super unlucky, your 5v tx line might be too high for the part, but hard to say out of the box
Apr 20 13:43:13 * f00b4r0 uses a raspi as a convenient RS232 interface for routers ;)
Apr 20 13:43:25 <f00b4r0> raspi IOs being 3.3v TTL
Apr 20 14:01:00 <Borromini> karlp: thanks
Apr 20 14:01:41 <Borromini> f00b4r0: yeah, my single RPi is gone. i might order one of those fancier switchable ttl connectors
Apr 20 14:03:40 <f00b4r0> adrianschmutzler: noted for label_mac, I was under the impression it wasn't used anywhere based on feedback I got here yesterday
Apr 20 14:07:22 <karlp> it's used in downstream ui's
Apr 20 14:08:25 <f00b4r0> ok
Apr 20 14:10:48 <karlp> (to create uis that match the sticker mac's on the devices themselves)
Apr 20 14:11:01 <ynezz> I use it for configuration as well
Apr 20 14:11:16 <ynezz> random token + mac = unique id
Apr 20 14:12:40 <karlp> why not just random token for that case?
Apr 20 14:13:44 <jow> to get a stable random id maybe?
Apr 20 14:14:41 <ynezz> sorry, that the mac is still used as device id since it's usually the only visible id for the user on the device
Apr 20 14:14:53 <ynezz> so the api call is api/mac/token/foo/bar
Apr 20 14:15:39 <f00b4r0> adrianschmutzler: $DEVPATH is set by the uevent call, like $FIRMWARE. There's no point in making an argument (imo), since you really can't load anywhere else but where the kernel is asking you to
Apr 20 14:15:45 <ynezz> either way, I was maintaining something like that mac label stuff locally for ages
Apr 20 14:19:36 <karlp> yeah, I had one too,
Apr 20 14:20:45 <karlp> so, any ideas or references on what I'm doing wrong constructing a squasfs+jffs2 image "like normal ath79" for sunxi?
Apr 20 14:23:17 <adrianschmutzler> f00b4r0: regarding label_mac: it's a fall-back for whenever it cannot be set via DT.
Apr 20 14:24:18 <f00b4r0> adrianschmutzler: ok, i couldn't quite find any hint as to how it was used by owrt and was told it wasn't. My understanding is that the actual setting is based on lan_mac/wan_mac and label_mac appears to be (for now) purely cosmetic?
Apr 20 14:24:22 <f00b4r0> anyway, that's fixed
Apr 20 14:24:47 <adrianschmutzler> regarding DEVPATH: thanks for the link via e-mail, keep your version then
Apr 20 14:25:08 <f00b4r0> np, yw
Apr 20 14:25:36 <f00b4r0> no change to your renaming suggestion?
Apr 20 14:26:03 <adrianschmutzler> label_mac in combination with ucidef_set_label_macaddr will store this in /etc/board.json, where it can be retrieved via get_mac_label
Apr 20 14:26:26 <adrianschmutzler> this is one of two ways to provide the MAC address on a device's label/sticker to the user
Apr 20 14:26:33 <adrianschmutzler> https://openwrt.org/docs/guide-developer/mac.address#label_mac_address
Apr 20 14:26:57 <adrianschmutzler> that's quite helpful for some network-building communities that identify devices by their printed-on MAC address
Apr 20 14:27:20 <f00b4r0> ah i see. it makes sense indeed!
Apr 20 14:27:25 <adrianschmutzler> which renaming suggestion are you referring to specifically
Apr 20 14:27:51 <f00b4r0> althought mikrotik devices typically have multiple MACs on their label (ETH/WLAN2G/WLAN5G)
Apr 20 14:28:03 <f00b4r0> so, dunno if that's not more confusing ;)
Apr 20 14:28:20 <adrianschmutzler> f00b4r0: that's one of the problems indeed.
Apr 20 14:28:22 <f00b4r0> adrianschmutzler: "Didn't get that at first. Maybe choose something like caldata_file_to_sysfs()?"
Apr 20 14:29:03 <adrianschmutzler> I'd do a rename like this. When reading this for the first time, I thought you wanted to _extract from_ sysfs.
Apr 20 14:30:21 <f00b4r0> ah ok
Apr 20 14:30:22 <f00b4r0> got it
Apr 20 14:30:23 <adrianschmutzler> Now it's clear to me how your name tells me the right thing as well
Apr 20 14:30:33 <adrianschmutzler> but I'm looking for something more obvious
Apr 20 14:31:06 <f00b4r0> i tried to merge within the existing naming scheme which puts emphasis on "from"
Apr 20 14:31:07 <adrianschmutzler> mine are just suggestions
Apr 20 14:31:22 <adrianschmutzler> I perfectly see your reasoning now
Apr 20 14:31:52 <adrianschmutzler> maybe someone else won't have that problem, and after all, it won't matter that much
Apr 20 14:32:09 <f00b4r0> ok so no change for now. Although I'd rather avoid patchbombing the m-l too often ;)
Apr 20 14:32:40 <f00b4r0> (I assume I must resend the complete series if I change some commits?)
Apr 20 14:32:41 <adrianschmutzler> maybe wait for additional review first, yes
Apr 20 14:32:59 <adrianschmutzler> most committers will prefer that
Apr 20 14:33:38 <f00b4r0> *nod*
Apr 20 14:33:53 <adrianschmutzler> despite, most of my other comments could be easily fixed afterwards as well, even if the patchset was picked as-is
Apr 20 14:34:36 <f00b4r0> true. but let's aim for bulletproof ;)
Apr 20 14:34:40 <adrianschmutzler> on the multiple label MAC issue: typically, we just picked the first one
Apr 20 14:35:29 <adrianschmutzler> for the Freifunk community networks where this is mostly used, each device needs to have _one_ MAC address as an identifier
Apr 20 14:35:34 <f00b4r0> ok. that's basically what is going to happen here: the mac_base contains the base MAC address for the device (usually assigned to ETH), the other ones being incremented from it
Apr 20 14:36:09 <adrianschmutzler> exactly, that's how this conflict typically resolves quite easily in practice
Apr 20 14:37:09 <adrianschmutzler> I'm just asking myself whether we should dare to put the label_mac into default case for mikrotik ath79 subtarget
Apr 20 14:37:32 <f00b4r0> it would make sense i suppose
Apr 20 14:38:22 <adrianschmutzler> this would assume that mikrotik will use that scheme on majority of devices
Apr 20 14:38:52 <f00b4r0> well the way they compute mac addresses is consistent across devices
Apr 20 14:39:09 <adrianschmutzler> Then go for it.
Apr 20 14:39:13 <f00b4r0> hard_config contains a base mac and a mac count, which is how many macs are assigned to that device, starting from the base
Apr 20 14:39:59 <adrianschmutzler> despite, FYI: if you want to define a base MAC address, which shouldn't become label_mac, they common use on the variable name has been base_mac so far.
Apr 20 14:40:31 <adrianschmutzler> Which is I suppose what you thought label_mac would be before we discussed it.
Apr 20 14:40:31 <f00b4r0> close call ;)
Apr 20 14:40:49 <f00b4r0> btw, I already set label_mac as the default in the current patch, unless you had something different in mind?
Apr 20 14:41:16 <f00b4r0>         case "$board" in
Apr 20 14:41:17 <f00b4r0>         *)
Apr 20 14:41:50 <adrianschmutzler> you didn't in 7/14
Apr 20 14:41:57 <adrianschmutzler> you did for ramips, I think
Apr 20 14:42:26 <adrianschmutzler> yes
Apr 20 14:43:04 <adrianschmutzler> don't forget the [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac for ath79/mikrotik as well :-)
Apr 20 14:44:13 <f00b4r0> oh it's there, it was already there in fact ;)
Apr 20 14:44:23 <f00b4r0> you can't tell from the patch alone, I see
Apr 20 14:46:40 <adrianschmutzler> ah, indeed. I was confused by the local variable declarations not including label_mac
Apr 20 14:47:38 <adrianschmutzler> anyway, I'm curious what happens to your main proposal, as my comments are only touching side-side-issues
Apr 20 14:48:47 <f00b4r0> well, I think xback likes it much ;)
Apr 20 14:49:47 <adrianschmutzler> will see. It's a pity anyway that still almost no RB devices have been ported to ath79
Apr 20 14:50:05 * xback is working on rb912 atm
Apr 20 14:50:09 <f00b4r0> i'd say it's a chance instead
Apr 20 14:50:15 <f00b4r0> the plumbing definitely wasn't ready
Apr 20 14:50:48 <f00b4r0> and i'm worried it will be hard, if not impossible, to preserve some of the nice features of the ar71xx target
Apr 20 14:50:55 <f00b4r0> starting with common image for all devices
Apr 20 14:52:16 <adrianschmutzler> well, that's we have completely different thoughts. for me, the biggest problem with ar71xx has always been this terrible mixture of boards and devices
Apr 20 14:52:53 <xback> I think the main reason for low Mikrotik target count is the amount of initial work which was required for converting the required base for these in ath79 (Thanks Roger)
Apr 20 14:53:09 <f00b4r0> my rationale is simple: 1) one-image-per device doesn't scale, and 2) in the case of mikrotik it's even worse because some products are in fact the exact same device with a different branding. Which is going to be a nightmare to handle.
Apr 20 14:53:39 <adrianschmutzler> xback: Indeed, I remember how much fun we had reviewing/discussing that
Apr 20 14:54:25 <adrianschmutzler> f00b4r0: yes, but then you will have to have a lot of script dealing with what's different between the devices which effectively aren't similar after all.
Apr 20 14:54:33 <adrianschmutzler> and those scripts will be different for each vendor.
Apr 20 14:54:56 <f00b4r0> adrianschmutzler: i'm not saying it makes sense for all vendors, but for mikrotik it certainly does
Apr 20 14:54:59 <adrianschmutzler> and then you will end up with a target full of specific scripts nobody can maintain anymore, like ar71xx was in my perception
Apr 20 14:55:44 <f00b4r0> adrianschmutzler: case in point: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1
Apr 20 14:55:47 <adrianschmutzler> and if I look at the mach files and the effort required to port each one to ath79, it does not look so unifyable to me
Apr 20 14:56:14 <f00b4r0> this device was added simply by adding detection support for it. it's a rebranded 911
Apr 20 14:56:33 <adrianschmutzler> there are always clones, have a look at how silly it is with ubiquiti
Apr 20 14:56:49 <f00b4r0> and don't discount how user-friendly a single image is
Apr 20 14:56:59 <adrianschmutzler> but just adding another devices definition and creating a DTSI is not so much effort as well.
Apr 20 14:57:15 <f00b4r0> for me it's exceptionally convenient: I can point all my RBs to the same image have them netboot it
Apr 20 14:57:39 <f00b4r0> adrianschmutzler: the problem is, are you going to have say 5 or 6 different images which are binary-identical?
Apr 20 14:57:57 <f00b4r0> do you see how that really doesn't scale and the maintenance nightmare it would be?
Apr 20 14:58:57 <adrianschmutzler> well, adding support is simple. and I'm not a big fan of the "just-pick-an-image-for-a-similar-device-and-flash-it" approach
Apr 20 14:58:59 <f00b4r0> for ath79 my feeling is the way around that is probably an intermediary loader, one that can parse hard_config and select the correct dtb
Apr 20 14:59:34 <f00b4r0> it shouldn't be particularly difficult to implement
Apr 20 14:59:52 <f00b4r0> but it certainly easier to do this when there aren't a gazillion images floating around ;)
Apr 20 15:00:25 <zorun> f00b4r0: how large is a dtb? i like this approach, but it means you will carry all dtb in the image, which might be an issue with small flash size
Apr 20 15:00:45 <zorun> although thankfully mikrotik is often generous with the flash size
Apr 20 15:00:53 <f00b4r0> zorun: mikrotiks SPI NOR all have 16MB flash. Compressed dtb is small
Apr 20 15:01:14 <f00b4r0> that's why we got away with common image for all in ar71xx to begin with ;)
Apr 20 15:01:40 <f00b4r0> and now that I'm freeing more space with the proposed sysfs caldata loader, I'm happy to reclaim these bytes to store multiple dtbs ;)
Apr 20 15:02:31 <adrianschmutzler> still, i don't think I like going that direction again
Apr 20 15:02:49 <reiffert> Hi. Any recommendations for: openwrt device, ADSL modem builtin, wifi: don't need it. 4 or 5 port LAN/WAN switch. Empty miniPCIE slot. Needs a LTE miniPCIE card. DECT would be nice for attaching my phones.
Apr 20 15:02:54 <adrianschmutzler> then you have to start with scripts for board name again as well
Apr 20 15:02:55 <f00b4r0> well, wait until you see what I have to offer? Don't judge a book by its cover maybe? :)
Apr 20 15:03:42 <f00b4r0> adrianschmutzler: if you're going to argue that wasting ~5MB per image just not to have to deal with a tiny script to load board name is sane, I'm afraid we're going to disagree here ;)
Apr 20 15:04:31 <zorun> don't we *already* have scripts that look at the board name? for things like number of ports, wan/lan, etc
Apr 20 15:05:02 <f00b4r0> in fact there shouldn't be much of achange needed, the board name is exposed in sysfs with my proposal
Apr 20 15:05:07 <zorun> I remember having issues because mikrotik is quite liberal in what they put in the hard_config
Apr 20 15:05:07 <adrianschmutzler> size doesn't matter, but we have finally reached a state where device and board names follow a system, and having board names besides them will destroy that again just for a little convenience of not having to choose a matching image
Apr 20 15:05:37 <f00b4r0> size doesn't matter?
Apr 20 15:05:46 <f00b4r0> you have infinite builder and webspace?
Apr 20 15:05:47 <adrianschmutzler> zorun: we have scripts looking up the board name, but this is about setting the board name
Apr 20 15:05:48 <f00b4r0> interesting concept.
Apr 20 15:06:09 <f00b4r0> adrianschmutzler: I think you didn't understand me
Apr 20 15:06:14 <f00b4r0> the board name will not be touched
Apr 20 15:06:17 <f00b4r0> it will be the dts one
Apr 20 15:06:32 <f00b4r0> the "display board name" if you want to call it that, the one e.g. Luci would show, can be scripted
Apr 20 15:06:32 <adrianschmutzler> then SUPPORTED_DEVICES won't work for upgrading
Apr 20 15:06:49 <f00b4r0> ofc it would. Why wouldn't it?
Apr 20 15:07:21 <f00b4r0> you have a combined image which supports multiple boards and the embedded secondary loader picks the correct dtb for your hardware
Apr 20 15:07:36 <f00b4r0> the board name used by the system is the one set in the dts
Apr 20 15:07:58 <adrianschmutzler> and then you add all of those to SUPPORTED_DEVICES for your merged image?
Apr 20 15:07:59 <f00b4r0> not some fancy schmuck set by the hardware itself :)
Apr 20 15:08:11 <f00b4r0> yes; exactly how it's done in ar71xx
Apr 20 15:08:21 <adrianschmutzler> and add scripts for the device names
Apr 20 15:08:25 <f00b4r0> that's what SUPPORTED_DEVICES (plural) is for, right?
Apr 20 15:08:25 <adrianschmutzler> no, please not
Apr 20 15:08:28 <f00b4r0> no
Apr 20 15:08:38 <f00b4r0> why would you need scripts for the device name?
Apr 20 15:08:55 <adrianschmutzler> the "display board name"
Apr 20 15:08:58 <f00b4r0> sysupgrade will look if the current device matches one in the SUPPORTED_DEVICES list
Apr 20 15:09:15 <f00b4r0> adrianschmutzler: this is cosmetic. You don't even have to do it if you don't want to
Apr 20 15:09:38 <f00b4r0> it's to allow eg the above mentioned SXT2 to be correctly displayed by Luci as SXT2, instead of rb911
Apr 20 15:09:53 <f00b4r0> it has no impact anywhere else and wouldn't be used by the OS
Apr 20 15:09:56 <adrianschmutzler> but I really like the concept of having image and compatible matching each other
Apr 20 15:10:24 <f00b4r0> adrianschmutzler: my understanding is that SUPPORTED_DEVICES was designed with the explicit goal of supporting multiple devices with one image
Apr 20 15:10:26 <f00b4r0> hence the plural
Apr 20 15:11:24 <f00b4r0> that's exactly why it worked very well on ar71xx, btw. (the sysupgrade part)
Apr 20 15:11:32 <adrianschmutzler> which is effectively mostly used for supporting older device names
Apr 20 15:11:52 <f00b4r0> that's a convenient side effect. That wasn't the (only) design goal, AIUI
Apr 20 15:12:19 <adrianschmutzler> that's were we have completely different views: for me, ar71xx always was script- and rename-hell, and I've desperately waited downstream for all of this additional work and circumstances to finally vanish with ath79
Apr 20 15:12:50 <f00b4r0> in an ideal world where the stock bootloader supports DTS loading, are you suggesting we should not use the facility and keep padding kernel+dtb and force the kernel to ignore the bootloader provided DTS?
Apr 20 15:12:59 <f00b4r0> that seems to be completely going against the intent of DTS
Apr 20 15:13:24 <f00b4r0> adrianschmutzler: as I'm saying, I understand that and that is not what I'm proposing
Apr 20 15:13:38 <f00b4r0> I'm saying it is perfectly possible to have a single-image system _WITHOUT_ the scripting hell.
Apr 20 15:13:56 <adrianschmutzler> but you cannot have image matching compatible
Apr 20 15:14:21 <f00b4r0> I don't know what that means
Apr 20 15:14:39 <f00b4r0> and I wish you'd give me an opportunity to demonstrate this before shooting down the proposal ;)
Apr 20 15:16:17 <adrianschmutzler> I won't hinder you, I just want you to prepare for me NAKing it then, as I believe the one image=one device=one board name is a significant benefit of ath79
Apr 20 15:17:13 <f00b4r0> well, let's agree to disagree on that ;)
Apr 20 15:17:27 <adrianschmutzler> just to prevent a you-have-to-take-it-since-I-put-so-much-effort-in-it argument then
Apr 20 15:18:08 <f00b4r0> i won't put too much effort. I'll try to see if an intermediary bootloader is feasible first, if it is I'll put a proposal to the m-l outlining what I said and I'll see if there's traction
Apr 20 15:18:22 <karlp> f00b4r0: I think adrians' just trying to say that there's a benefit for (across all of openwrt's iamges) that you can pick a file that _exactly_ matches your device, instead of _sometimes_ using an exact model, and _sometimes_ using a "generic" one.
Apr 20 15:18:43 <karlp> (even if a generic one would  be simpler/smaller/"better" for mikrotik)
Apr 20 15:18:50 <f00b4r0> karlp: i get that. The point is, in the case of the mikrotik hardware at least, that you won't get the sometimes/sometimes
Apr 20 15:18:58 <f00b4r0> the split typically is NAND vs NOR, period.
Apr 20 15:19:28 <adrianschmutzler> but why do they have more than two products then, if they are so similar
Apr 20 15:19:43 <f00b4r0> I think it's called "marketing" ;P
Apr 20 15:19:43 <karlp> yes, but you've now got the instructions being, "pick the exact model number of your device, unless you have mikrotik, then work out whether it's nand or nor, and us this other generic image"
Apr 20 15:19:52 <jow> until a third variant comes along that is a unicorn device which works differently from all the rest :)
Apr 20 15:20:02 <f00b4r0> karlp: err no. We have a mikrotik subtarget
Apr 20 15:20:21 <karlp> I'm not talking about people building their own images :)
Apr 20 15:20:24 <f00b4r0> an ath79/mikrotik subtarget, that is. Which imo makes the proposal much more acceptable
Apr 20 15:20:45 <f00b4r0> jow: why do you have to rain on my parade? :D
Apr 20 15:21:06 <jow> experience, been that way years ago with brcm47xx for example, or even ath25 iirc
Apr 20 15:21:17 <jow> just use that one generic image, execept for these three devixes
Apr 20 15:21:33 <jow> okay, lets make a subtarget
Apr 20 15:21:48 <jow> so pick the model specific file for this subtarget, execept for that other subtarget, there you can pick the generic one
Apr 20 15:21:55 <f00b4r0> jow: if you have unlimited storage and cpu power (and don't mind paying for it), then sure, why would I even care (not considering the user-side benefits)
Apr 20 15:22:07 <jow> unless its one of these, then you need to pick a specific one over a gneric one :D
Apr 20 15:22:14 <f00b4r0> personally I have a vested interest in reducing buildbots load ;)
Apr 20 15:23:09 <f00b4r0> jow: also so far, mikrotik has been very consistent. We have a backlog of dozens of devices to support the idea that it demonstrably works :)
Apr 20 15:24:20 <jow> okay, so we instruct people to look for their model in ath79/generic and just pick the generic image in ath97/mikrotic
Apr 20 15:24:46 <f00b4r0> yep
Apr 20 15:24:52 <jow> and if they ask if the gneric image works on $random_microtic_hw we say "most likely" ?
Apr 20 15:25:08 <f00b4r0> no. We have a supported list for that purpose
Apr 20 15:25:19 <jow> so we tell them to try flashing it?
Apr 20 15:25:32 <f00b4r0> jow: remember that install on mikrotik isn't a flash-first
Apr 20 15:25:36 <f00b4r0> you have to netboot first
Apr 20 15:25:45 <f00b4r0> so the failure mode is the safest you can get.
Apr 20 15:26:00 <Rich13> Hi all, as an alternative to going crazy I thought I'd ask a question about architecture here. About how modemmanager and the rest of OpenWrt fits together
Apr 20 15:26:09 <f00b4r0> if you can't netboot, clearly you can't brick the device.
Apr 20 15:26:23 <jow> Rich13: short answer: not well at all. dbus vs. ubus for starters
Apr 20 15:26:38 <Rich13> @jow Indeed!
Apr 20 15:26:41 <jow> Rich13: its like importing half of freedesktop on a router in order to drive an usb dongle
Apr 20 15:26:48 <adrianschmutzler> or just don't provide a support list and provide the matching images instead
Apr 20 15:27:18 <adrianschmutzler> then everyone will see whether his/her device is supported directly, and that's why per-device image are more user-friendly after all.
Apr 20 15:27:20 <f00b4r0> *sigh*
Apr 20 15:27:27 <jow> Rich13: however I believe some people made it working on master
Apr 20 15:27:53 <jow> Rich13: there's even luci support for it, so it should be just plug-play
Apr 20 15:28:11 <jow> (once required packages are installed)
Apr 20 15:28:21 <Rich13> But even given that, it's a space trade-off that we're willing to make rn :)  My question is this tho. I use mmcli to detect the modem, and successfully create a data bearer. This shows me the IPv4 address granted.
Apr 20 15:29:06 <f00b4r0> adrianschmutzler: and in 5 years time it'll take a week for the buildbots to build the target, and a day to upload the target images to the server.
Apr 20 15:29:13 <f00b4r0> big win.
Apr 20 15:29:15 <Rich13> The problem comes when I set the wwan interface in /e/c/n to take that ip, gateway and subnet mask. I simply cannot transfer traffic over the link. Every indication from MM and its logs are that it's working
Apr 20 15:29:35 <Rich13> I'm wondering if I'm missing something from the OpenWrt side. Something simple or stupid
Apr 20 15:29:54 <f00b4r0> by then I'll have shutdown my buildbots I guess
Apr 20 15:30:24 <Rich13> https://pastebin.com/t2WFK4jE seems A OK
Apr 20 15:30:27 <adrianschmutzler> that's where I prefer clarity over ressource consumption
Apr 20 15:30:53 <f00b4r0> you prefer infinite growth. I don't.
Apr 20 15:33:17 <ynezz> isnt ath79 finished? :p
Apr 20 15:33:18 <f00b4r0> also you seem to miss the point that this growth impacts both the number of images and the size of the individual images. When you have to add the multiple identical devices to e.g. 02_network, it grows for no reason.
Apr 20 15:33:50 <ynezz> I mean, is Mikrotik still producing new hardware with ath79?
Apr 20 15:33:54 <f00b4r0> yes
Apr 20 15:34:17 <adrianschmutzler> you have to add them anyway, as you have different DTSes with different compatible even with your approach
Apr 20 15:34:21 <karlp> here's where I've gotten to with squashfs,jffs2 rootfs, if anyone's got any bright ideas: https://paste.jvnv.net/view/AN32Y
Apr 20 15:34:26 <f00b4r0> adrianschmutzler: no
Apr 20 15:34:38 <f00b4r0> adrianschmutzler: for the sxt2/rb911 case above, you have one dts: the 911
Apr 20 15:34:45 <f00b4r0> when booted on sxt2, it's a 911
Apr 20 15:34:57 <zorun> let's not go into specious arguments... threatening to stop running buildbots if things don't go your way is not an honest argument
Apr 20 15:35:11 <f00b4r0> zorun: where did I make such an argument??
Apr 20 15:35:32 <f00b4r0> read again please, don't put words in my mouth.
Apr 20 15:35:34 <adrianschmutzler> and that's where you have real fun downstream when you start to draw a map with which DTS matches which board for which device
Apr 20 15:35:52 <f00b4r0> you don't have to
Apr 20 15:36:01 <adrianschmutzler> because then sxt2 will have 911 board and mikrotik_generic as the routername
Apr 20 15:36:06 <zorun> ah, I read "I'll have *to* shutdown my buildbots"
Apr 20 15:36:08 <f00b4r0> ok, either you don't understand how rb boards are made, or we're talking about different things.
Apr 20 15:36:21 <adrianschmutzler> I do not care how rb board are made
Apr 20 15:36:30 <adrianschmutzler> that's the point where we don't understand each other
Apr 20 15:36:31 <f00b4r0> adrianschmutzler: the sxt2 IS an 911
Apr 20 15:36:40 <ynezz> karlp: wild guess, wrong DTS?
Apr 20 15:36:48 <f00b4r0> the ONLY difference is a string in hard_config that says the PRODUCT NAME is SXT2
Apr 20 15:37:07 <f00b4r0> do you see the point now?
Apr 20 15:37:30 <adrianschmutzler> exactly, and the user will have bought an SXT2, and will look for info on the sxt2
Apr 20 15:37:35 <ynezz> karlp: IIRC you need that padding after kernel/rootfs for possible squashfs issues, not related to JFFS2
Apr 20 15:37:51 <adrianschmutzler> so I will provide him with an image for the sxt2
Apr 20 15:37:58 <ynezz> karlp: you need to tell mtd splitter in DTS what to do with your flash
Apr 20 15:38:09 <f00b4r0> adrianschmutzler: and you don't have to map which device match which DTS, you have only one DTS and the bootloader will select it automatically
Apr 20 15:38:25 <ynezz> karlp: then the magic is going to happen with rootfs/rootfs_data and jffs2
Apr 20 15:38:33 <karlp> ynezz: I've got the partitions added manually to dts, that' swhy you get the partitions listed at line 58 in that paste
Apr 20 15:38:37 <f00b4r0> i feel I'm going in circles here.
Apr 20 15:38:41 <karlp> they're marked as denx,uImage
Apr 20 15:38:49 <karlp> I had to do that to get it to even try and jffs mount
Apr 20 15:38:57 <karlp> so I _think_ that's going the right way
Apr 20 15:39:06 <karlp> https://openwrt.org/docs/guide-developer/defining-firmware-partitions
Apr 20 15:39:18 <ynezz> ok, then please provide complete boot and dts as well
Apr 20 15:39:40 <ynezz> maybe you're missing some kernel config option then in sunxi?
Apr 20 15:39:46 <ynezz> like the support for that splitter
Apr 20 15:40:28 <ynezz> s/boot/boot log/
Apr 20 15:40:52 <karlp> ynezz: full boot log: https://paste.jvnv.net/view/7eomh
Apr 20 15:41:16 <karlp> yeah, could be a splitter config missing, it wouldn't have been on sunxi before I guess?
Apr 20 15:41:21 <karlp> just gettign the dts
Apr 20 15:42:44 <karlp> dts is https://paste.centos.org/view/64688eb8 with the referenced base file from here: (it didn't make 5.4 in time for us, made it to 5.5) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
Apr 20 15:43:22 <karlp> https://openwrt.org/docs/guide-developer/defining-firmware-partitions implies that if you've got a denx,uImage compatible partition labelled "firmware" that you shouldn't need to set CONFIG_MTD_SPLIT_FIRMWARE ?
Apr 20 15:43:53 <ynezz> but you need CONFIG_MTD_SPLIT_UIMAGE_FW=y
Apr 20 15:44:16 * karlp runs kernel_menuconfig to check
Apr 20 15:44:43 <ynezz> target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c:      { .compatible = "denx,uimage" },
Apr 20 15:45:26 <karlp> correct! I didn't have the umage splitter enabled in kernel_menuconfig, it only had fit parser
Apr 20 15:45:38 <karlp> (should we really be using fit images anyway?)
Apr 20 15:47:38 <karlp> ynezz: is there any guidance on when/how the padding is required for squashfs?
Apr 20 15:47:39 <PaulFertser> karlp: btw, you do not need root= kernel command line argument, it's done with generic OpenWrt patch automatically when "rootfs" partition is present.
Apr 20 15:48:07 <karlp> there's no rootfs partition though,
Apr 20 15:48:12 <karlp> just "firmware" ?
Apr 20 15:48:22 <karlp> or is that being injected automatically by the splitter?
Apr 20 15:49:33 <f00b4r0> karlp: firmware is split by the splitter, yes
Apr 20 15:51:41 <karlp> PaulFertser: I still need the rootfstype though?
Apr 20 15:52:11 <karlp> yes, it worked! woo
Apr 20 15:52:18 * karlp tries to save a file and reboot...
Apr 20 15:52:30 <karlp> (no, didn't need rootfstype now that it has the uImage splitter included)
Apr 20 15:56:52 <karlp> ahhh, so nice having that finally working. knew it had to be somethign simple
Apr 20 15:57:13 <karlp> now just all the _other_ little bits :)
Apr 20 15:57:24 <ynezz> leds!!!
Apr 20 15:58:09 <karlp> heh, no, things like teh gadget giving me "cable unconnected" when it worked in initramfs, and "reboot" causing a stack trace in the u_serial gadget, and packaging it all up properly and all that boring stuff.
Apr 20 15:58:16 * karlp checks the leds though...
Apr 20 15:59:59 <karlp> yeah,. they both work
Apr 20 16:10:14 <karlp> ynezz: you'
Apr 20 16:10:53 <karlp> v poked sunxi, can we turn on CONFIG_MTD_SPLIT_UIMAGE_FW=y for all, (it already has CONFIG_MTR_SPI_NOR) or should I be tryign to get this all workign with FIT images instead of copyign ath79?
Apr 20 16:14:49 <owrt-1907-builds> build #138 of ath25/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath25%2Fgeneric/builds/138
Apr 20 16:15:01 <ynezz> karlp: just add it once you add support for that device
Apr 20 16:15:32 <xback> adrianschmutzler: ynezz: I've asked f00b4r0 to also post a PR version of the patch series for easier/quicker review
Apr 20 16:15:56 <karlp> well, that's the enxt fun bit :) it doesn't have spi flash out of the box, just a footprint, so not sure if it can ever really be added as is...
Apr 20 16:16:29 <ynezz> xback: poor f00b4r0 :p
Apr 20 16:16:40 <f00b4r0> yeah ;p
Apr 20 16:16:42 <xback> can we agree that the main scope of this series is to properly fix revision 2 support with lzo compressed data
Apr 20 16:16:52 <f00b4r0> i thought i was being a good boy by going m-l
Apr 20 16:17:16 <f00b4r0> and now I'm told I must PR. I'm going mad. Must be confinment. Need air. HALP! :}
Apr 20 16:17:19 <ynezz> now you'll get more comments as a bonus
Apr 20 16:17:34 <ynezz> dunno if valuable, but comments are nice :)
Apr 20 16:17:40 <xback> I didn't tell you,  I requested it nicely :-)
Apr 20 16:17:46 <f00b4r0> ;)
Apr 20 16:17:50 <karlp> ynezz: with those bl31bins, are they actualyl _different_ each time? like, is the aw ones any different from the rk ones?
Apr 20 16:17:53 <f00b4r0> ynezz: noiz, most of the time
Apr 20 16:17:55 * f00b4r0 hides
Apr 20 16:18:09 <adrianschmutzler> xback: I'm fine with what it says it does, and left my comments where I'm qualified to do so
Apr 20 16:18:09 <ynezz> karlp: like between releases?
Apr 20 16:18:09 <xback> this PR (at least for me) is a very important one which adds foundations for Mikrotik in ath79.  So I would prefer maximum exposure to reviewers
Apr 20 16:18:43 <karlp> ynezz: no, like isn't bl31.bin  actually different between parts?
Apr 20 16:18:54 <karlp> soryr, _is_ it actually different between parts?
Apr 20 16:19:21 <ynezz> https://github.com/atf-builds/atf/releases
Apr 20 16:19:45 <ynezz> see the hashes/sizes
Apr 20 16:20:38 <karlp> yeah, i looke da few days ago, it seemd to be just "build once, and call it rk3399" but it's all different now :)
Apr 20 16:20:59 <xback> adrianschmutzler: Thanks for your input so far on this series.  Highly appreciated as always.
Apr 20 16:21:14 <ynezz> karlp: https://github.com/atf-builds/atf/pull/1#issuecomment-616612983
Apr 20 16:21:22 <ynezz> mvebu is next
Apr 20 16:21:50 <ynezz> I'm then going (propose) to add it to U-Boot as well
Apr 20 16:22:14 <karlp> :+1:
Apr 20 16:22:51 <ynezz> but that's probably 2022 already :p
Apr 20 16:24:09 <adrianschmutzler> xback: you plan to backport to 19.07 then? and leave 18.06 alone?
Apr 20 16:24:21 <adrianschmutzler> (for ar71xx)
Apr 20 16:25:31 <xback> adrianschmutzler: 19.07 would be the first candidate to backport for sure.
Apr 20 16:25:52 <xback> this branch is currently the latest, and MikroTik is ramping up rev 2 version of the board
Apr 20 16:26:34 <xback> without a backport here .. a large amount of Mikrotik targets will lack proper wifi support without any warning/error
Apr 20 16:27:38 <xback> 18.06 is low prio
Apr 20 16:28:01 <adrianschmutzler> and ar71xx there is 4.9 ...
Apr 20 16:28:17 <xback> I would focus solely on the current latest branch
Apr 20 16:28:29 <adrianschmutzler> but till this is finished, 18.06 might be close to EOL
Apr 20 16:28:30 <adrianschmutzler> yes
Apr 20 16:28:37 <xback> in case of user complaints regarding 18.06,  it is possible to point users to 19.07
Apr 20 16:28:46 <adrianschmutzler> was just curious about your plans :-)
Apr 20 16:28:58 <xback> with lacking support in 19.07 .. it's not possible to point users elsewhere
Apr 20 16:29:37 <adrianschmutzler> makes sense to me
Apr 20 16:31:22 <adrianschmutzler> and I still don't believe 20.xx will have many mikrotik devices supported, even if the base support becomes better
Apr 20 16:32:05 <xback> blame the guy who made it source-only :-p  (ynezz)   ( kidding ;-) )
Apr 20 16:32:24 <adrianschmutzler> (depending on how long it will take until we have a 20.xx ..........)
Apr 20 16:32:45 <adrianschmutzler> if it was to me, ar71xx would have been deleted from master after 19.07 branch
Apr 20 16:33:05 <adrianschmutzler> and changes applied to 19.07 directly
Apr 20 16:33:45 <xback> I think the source-only is a nice balanced compromise for fading out
Apr 20 16:34:14 <adrianschmutzler> yes, of course
Apr 20 16:35:30 <f00b4r0> xback: #2943
Apr 20 16:35:35 * f00b4r0 runs away
Apr 20 16:35:39 <f00b4r0> (screaming)
Apr 20 16:41:32 <adrianschmutzler> won't have to read again if I've read the patchsets?
Apr 20 16:42:16 <f00b4r0> adrianschmutzler: I simply applied your suggestions so far; no other change
Apr 20 16:42:27 <adrianschmutzler> Nice, just saw it.
Apr 20 16:44:02 <ynezz> karlp: just buy (or pretend having) device with spi nor flash, like that a64-olinuxino
Apr 20 16:45:39 <adrianschmutzler> f00b4r0: is there a special reason why you test-extract in caldata_sysfsload_from_file(), which we don't do for the other functions?
Apr 20 16:46:02 <f00b4r0> adrianschmutzler: we actually do it, see || caldata_die
Apr 20 16:46:11 <f00b4r0> we can't caldata_die in the middle of a kernel load
Apr 20 16:46:43 <f00b4r0> hence testing first, and loading only when we're sure it can be done
Apr 20 16:47:33 <adrianschmutzler> okay. I wonder whether it's really necessary to read "everything" for the test
Apr 20 16:48:05 <adrianschmutzler> however, most probably anything else would just make it more complicated without substantial benefit
Apr 20 16:48:14 <f00b4r0> if you try to extract more than is available
Apr 20 16:48:22 <f00b4r0> that too :)
Apr 20 16:49:20 <adrianschmutzler> just interferes with my pedantic mind, but seems to be fine :-)
Apr 20 16:51:00 <adrianschmutzler> ah, and please no merge commits
Apr 20 16:51:23 <adrianschmutzler> just the patches rebased on top of master
Apr 20 16:51:34 <f00b4r0> these are purely for convenience, of course they won't be part of the final proposal
Apr 20 16:51:54 <f00b4r0> the PR groups 2 branches (the two sets i posted on the m-l)
Apr 20 16:52:26 <adrianschmutzler> I'm aware, I'll leave a comment in GH anyway just in case it's pulled from there at the end
Apr 20 16:52:48 <f00b4r0> sure
Apr 20 17:19:33 <greearb> hello, I could use some help putting openwrt on a linksys mr8300.  I think the hardware is likely very similar (maybe basically identical) to ea8300, but the web page won't let me install a custom image, so I'm trying to do it through the serial console.
Apr 20 17:19:56 <blogic> greearb: uboot access ?
Apr 20 17:19:59 <greearb> I have serial up, and am in the bootloader.  But, not sure of a safe step to do after that
Apr 20 17:20:15 <blogic> what silicon is that ?
Apr 20 17:20:21 <greearb> ipq4019
Apr 20 17:20:26 <blogic> oh
Apr 20 17:20:39 <blogic> you need the board files from the image on the system
Apr 20 17:20:55 <greearb> openwrt works on similar board: https://openwrt.org/toh/linksys/linksys_ea8300
Apr 20 17:20:57 <greearb> maybe identical
Apr 20 17:21:04 <blogic> *mazbe* (TM)
Apr 20 17:21:06 <greearb> but instructions are for web install
Apr 20 17:21:14 <greearb> I won't cry long if I brick it
Apr 20 17:21:18 <blogic> easiets way is to boot an initramfs
Apr 20 17:21:24 <blogic> then sysupgrade from that
Apr 20 17:21:27 <blogic> or even better
Apr 20 17:21:40 <blogic> initramfs boot, mount orig FS, extract board data files
Apr 20 17:21:47 <blogic> then flash an image with them integrated
Apr 20 17:22:03 <greearb> lets assume that if I can just install the images for ea8300, it will work fine and figure all of that out?
Apr 20 17:22:11 <blogic> flashing initramfs->sysupgrade is generally safer then uboot flashery
Apr 20 17:22:29 <blogic> greearb: and if not you order a new one on amazon
Apr 20 17:22:36 <blogic> ;)
Apr 20 17:22:54 <greearb> looks like it has a recovery partition as fallback
Apr 20 17:23:34 <greearb> so, there is an install *factory.bin and another sysupgrade.bin
Apr 20 17:23:56 <greearb> can you talk me through how to do it, or point me to some fairly specific instructions that would likely work?
Apr 20 17:25:32 <blogic> you need an initramfs image
Apr 20 17:25:48 <blogic> factory is what we use for flashing ODM->owrt
Apr 20 17:26:05 <blogic> sysupgrade owrt->owrt
Apr 20 17:33:19 <champtar> Anyone has some opinions / ideas how we should de hotplug over ubus (sent an email yesterday "ubus acls for params or hotplugd ?")
Apr 20 17:34:30 <greearb> blogic, linksys_ea8300-initramfs-fit-zImage.itb maybe?
Apr 20 17:35:16 <blogic> greearb: ah wait
Apr 20 17:35:19 <blogic> ipq4019
Apr 20 17:35:26 <blogic> initramfs wont know the mtd layout
Apr 20 17:36:04 <greearb> so can I use the factory image from uboot?
Apr 20 17:36:14 <jow> champtar: why do you want to do that?
Apr 20 17:36:15 <blogic> no
Apr 20 17:36:25 <jow> champtar: to broadcast hotplug over the network using ubus as transport?
Apr 20 17:36:37 <champtar> jow: to sandbox ntpd / udhcpc / ...
Apr 20 17:37:10 <champtar> just to drop privileges
Apr 20 17:37:20 <jow> I wouldn't trust the ubus blobmsg marhsalling/unmarshalling enough yet to see it as viable inter-sandbox communication method
Apr 20 17:37:31 <tmn505> blogic: initramfs image should know the flash layout since it has it specified in dts
Apr 20 17:37:47 <blogic> tmn505: is it on ipq4019 ?
Apr 20 17:38:02 <tmn505> it should
Apr 20 17:38:07 <blogic> did ipq4019 not have that smem stuff ?
Apr 20 17:38:11 <greearb> blogic, so I can log in as root once the AP boots, that help?
Apr 20 17:38:16 <blogic> ipq4019 is when they introduced smem
Apr 20 17:38:22 <champtar> jow: creating a second bus because we don't trust the first one seems crazy
Apr 20 17:38:26 <blogic> greearb: yeah
Apr 20 17:38:28 <jow> champtar: can you describe a slightly broader picture? How is hotplug preventing sandboxing now and how would ubus change it?
Apr 20 17:38:37 <blogic> and then just sysupgrade the sysuopgrade image
Apr 20 17:39:04 * tmn505 shearches what's smem
Apr 20 17:39:08 <blogic> champtar: do you want to inject or recieve events ?
Apr 20 17:39:11 <jow> champtar: you want to replace hotplug scripts invoking executables with ubus listeners reacting on event broadcasts?
Apr 20 17:39:25 <blogic> tmn505: its that FAT like thing they have on a MTD partition
Apr 20 17:39:32 <blogic> i think 0:RPM
Apr 20 17:39:42 <blogic> and then the smem parser will create the mtd partitions
Apr 20 17:39:43 <champtar> I want to run all daemon parsing stuff from the network as non root
Apr 20 17:39:48 <greearb> blogic, I'm booted into stock Linksys firmware....do I still try sysupgrade, or instead somehow install the factory image?
Apr 20 17:40:04 <blogic> champtar: and why do you need hotplug for that
Apr 20 17:40:17 <blogic> try sysupgrade
Apr 20 17:40:20 <champtar> right now ntpd trigger hotplug
Apr 20 17:40:22 <blogic> sysupgrade -n
Apr 20 17:40:29 <greearb> no sysupgrade in path
Apr 20 17:40:35 <blogic> so you want to inject hotplug
Apr 20 17:40:41 <champtar> yup
Apr 20 17:40:44 <blogic> greearb: mtd ?
Apr 20 17:40:56 <greearb> no
Apr 20 17:40:58 <blogic> champtar: hmmmm
Apr 20 17:41:03 <greearb> mtd_debug
Apr 20 17:41:06 <jow> I don't get it :(
Apr 20 17:41:08 <blogic> so you need a way to call hotplug trigger
Apr 20 17:41:18 <blogic> jow: its a corner case
Apr 20 17:41:24 <blogic> need to think about it
Apr 20 17:41:56 <blogic> greearb: you could try just writing the sysupgrade image into the firmware partition
Apr 20 17:42:02 <champtar> jow: you don't get why parsing untrusted network data shoudn't be done as root ?
Apr 20 17:42:16 <blogic> champtar: no he is dumb as shit
Apr 20 17:42:18 <blogic> silly question
Apr 20 17:42:23 <champtar> :P
Apr 20 17:42:25 <jow> champtar: that I do. I dont understand why hotplug is a problem and how using ubus would solve it
Apr 20 17:42:42 <jow> especially since relying on ubus would require a lot more C handling code to be written
Apr 20 17:42:50 <blogic> jow: its possible to trigger hotplug via the hotplug trigger
Apr 20 17:42:54 <blogic> that is how coldplug works
Apr 20 17:43:04 <blogic> appranetly ntp uses it for some reason
Apr 20 17:43:16 <blogic> and that relies on root
Apr 20 17:43:34 <blogic> the actual question is how will ntp open a port < 1024 if !root
Apr 20 17:43:46 <blogic> kernel aint gonna let you do that
Apr 20 17:44:10 <champtar> if ntpd run as 'ntp' user, the hotplug scripts will run as 'ntp' user
Apr 20 17:44:19 <champtar> blogic: ambient capabilities
Apr 20 17:44:31 <jow> ah, so you want to repalce the hotplug "bus"
Apr 20 17:44:55 <champtar> yes, right now there is no bus
Apr 20 17:45:06 <jow> well
Apr 20 17:45:54 <jow> so you need something subscribing to kernel uevents and broadcasting them to ubus
Apr 20 17:46:09 <champtar> nop
Apr 20 17:46:34 <champtar> I still want to have ntpd call a small script
Apr 20 17:46:37 <greearb> blogic, so, no idea how to do that unfortunately
Apr 20 17:46:39 <jow> and you need to modify hotplug-call xxx to invoke ubus send hotplug '{ "class": "xxx" }'
Apr 20 17:47:28 <greearb> maybe I can use the uboot recovery logic to flash an image?
Apr 20 17:47:29 <champtar> but have acl to allow only the type / class hotplug.ntp
Apr 20 17:47:31 <jow> and whatever process is hosting the ubus hotplug namespace then eeds to invoke the scrptlets in /etc/hotplug.d/
Apr 20 17:47:48 <champtar> jow: yes
Apr 20 17:48:10 <champtar> but it needs to also work for udhcpc
Apr 20 17:51:15 <jow> so in the end its a kind of suid + command filter mechanism
Apr 20 17:51:48 <champtar> I also want to be able to run ntpd in an almost empty ujail
Apr 20 17:52:22 <champtar> with a suid you would need the whole /etc/hotplug.d/ and many dependencies
Apr 20 17:52:56 <jow> why not simply let ntpd broadcast an event (something similar to ubus call service event, just more generalized) and have whatever is interested in it simply handle it?
Apr 20 17:53:07 <jow> e.g. a reload trigger for dnsamsq
Apr 20 17:53:53 <champtar> we need to filter the type of events that ntpd can generate
Apr 20 17:54:27 <jow> that should be doable already
Apr 20 17:54:31 <pkgadd> greearb: https://openwrt.org/toh/asus/asus_lyra_map-ac2200#oem_installation_using_the_tftp_method should be very similar for your device - and yes, the partitions are defined in the dtb and the initramfs image should just work (*if* ea8300 amd mr8300 are indeed similar enough)
Apr 20 17:54:46 <champtar> jow: we only filter on method, not params in the acls
Apr 20 17:54:49 <jow> iirc ubus supports acl's that can be tied to the remote socket user credentails (effective uid)
Apr 20 17:54:58 <jow> so the acl mechanism needs to be extended
Apr 20 17:55:37 <champtar> thus the title of my email "ubus acls for params or hotplugd ?" ;)
Apr 20 17:55:37 <jow> filter on param does not scale well imho, better break out the event type out of the param and make it part of the namespace / method or whatever
Apr 20 17:56:36 <jow> you would need to unmarshall the params blob just to apply potential acl rules on it
Apr 20 17:56:46 <jow> this will slow down the common path for anything using ubus
Apr 20 17:57:25 <pkgadd> greearb: this http://paste.debian.net/hidden/2d8f6d46/ would be a full serial log for booting an initramfs image on an ipq4019 device (map-ac2200), using the renamed "openwrt-ipq40xx-generic-XXX-initramfs-fit-uImage.itb" and then flashing it via sysupgrade
Apr 20 17:57:54 <greearb> thanks, reading
Apr 20 17:58:11 <pkgadd> greearb: I'd strongly recommend to just try the initramfs image first, and checking several times before flashing anything ;)
Apr 20 17:58:31 <champtar> jow: I would like to just drop an handler script, /etc/ubus-handler.d/hotplug.ntp
Apr 20 17:58:49 <jow> champtar: your proposed option 2 sounds like the way to go
Apr 20 17:59:01 <jow> publish one namespace per hotplug event class
Apr 20 17:59:12 <jow> apply ACLs on the per-class namespaces
Apr 20 17:59:20 <champtar> and have the hotplug.ntp namespace be usable
Apr 20 17:59:38 <champtar> yup but do I want another daemon for that
Apr 20 18:00:47 <jow> no, preferably it should go into procd / plugd or whatever sits on the kernel uevent socket atm
Apr 20 18:02:10 <greearb> pkgadd, do I need to so something special to get to the 'plesae choose the operation' prompt?
Apr 20 18:03:03 <jow> champtar: the ubus hotplug machinery would need to go into this part of procd: https://lxr.openwrt.org/source/procd/plug/hotplug.c
Apr 20 18:03:40 <jow> champtar: and it needs to be smart enough / provide a mechanism to update the namespaces at runtime
Apr 20 18:04:11 <jow> e.g. some /etc/hotplug.d/xxx class might not exist on boot but might be added later when an installed package stages stuff there
Apr 20 18:07:31 <m4t> can anyone confirm that the combined-squashfs x86_64 images boot for them under e.g. qemu? i'm pretty sure there's a race condition that among other things, causes overlay to not mount properly and logd doesn't start up. seeing this as far back as 18.06.0: https://imgur.com/a/2kezkK2
Apr 20 18:07:53 <jow> m4t: yeah, I use them all the time
Apr 20 18:08:02 <m4t> it also happens for me on real hardware w/the initramfs image. well, at least the logd not starting.
Apr 20 18:08:08 <m4t> the combined-ext4 or combined squashfs?
Apr 20 18:08:18 <jow> combined-squash
Apr 20 18:08:23 <m4t> hmm
Apr 20 18:09:18 <m4t> i wonder what's different about my environment then?
Apr 20 18:13:54 <m4t> i think it might be a race between ubus/logd and/or procd. i wish i'd saved the strace i had of what they were doing...
Apr 20 18:14:20 <m4t> https://drive.google.com/file/d/1sPZSmhVoE7pjLcSi2dio4qnhymzIkegv/view?usp=sharing is a screencast of it
Apr 20 18:14:25 <jow> m4t: https://pastebin.com/ZQWQrJdQ
Apr 20 18:19:34 <greearb> blogic, if nandwrite is on the oem file image, does that offer a safe-ish way to try the install?
Apr 20 18:27:54 <greearb> maybe I can dig through the oem webpage to see how it installs things..
Apr 20 18:29:00 <m4t> eh i know what it was heh. duh.
Apr 20 18:29:19 <m4t> need to truncate -s 256M openwrt.img
Apr 20 18:29:34 <jow> yeah
Apr 20 18:29:48 <m4t> i did oddly see a similar thing with initramfs, though
Apr 20 18:29:50 <jow> at some point we lost the default padding in x86 squash images, making them unusable
Apr 20 18:30:01 <jow> ... ootb as vm image
Apr 20 18:33:56 <m4t> i wonder why logd/logread doesn't work when that happens
Apr 20 18:35:41 <m4t> yeah, so it does, if you start it. the thing i was seeing on initramfs was different, then. tbh it may have had to do with a dirty build dir.
Apr 20 18:36:59 <philipp64> hi all… glad to see the x86_64 EFI stuff finally made it in… is that all now 100% functional, including sysupgrade?
Apr 20 18:39:45 <pkgadd> greearb: no, you just need to enter the number in time - I think that was a 3s timer
Apr 20 18:41:24 <greearb> I found the hidden web page that will let me update, thankfully
Apr 20 18:41:54 <pkgadd> even better
Apr 20 18:43:32 <greearb> you hit the url, which will redirect you a bit, then you backspace over 'ui' and everything following it, then type in fwupdate.html
Apr 20 18:43:55 <greearb> upload image from your system, click Update
Apr 20 18:45:58 <greearb> if someone can edit this page, please add that info around where it is talking about how to upload the image
Apr 20 18:46:04 <greearb> https://openwrt.org/toh/linksys/linksys_ea8300
Apr 20 18:53:09 <tmn505> philipp64: it should, personally never tested it.
Apr 20 18:54:54 <philipp64> sounds like I should make a raw image backup then…
Apr 20 19:02:42 <champtar> jow: we still need something to validate the params of the event, as it's untrusted, so what do you think of script handlers in /etc/ubus-handler.d/ ?
Apr 20 19:03:38 <champtar> with procd doing all the "publishing" work
Apr 20 19:12:49 <jow> champtar: not much
Apr 20 19:13:09 <jow> why do we need to validate params?
Apr 20 19:14:05 <jow> what is the thread model, what untrested input do we need to guard against?
Apr 20 19:14:16 <jow> I wouldn't expect even params to carry e.g. shell commands
Apr 20 19:14:39 <jow> *event params
Apr 20 19:21:23 <champtar> right now most hotplug params end up being environement variables
Apr 20 19:22:17 <champtar> we need to safely transform the data table in the event in the right command
Apr 20 19:23:01 <jow> you could apply generic constraints
Apr 20 19:23:31 <jow> like disallow nested / complex values in event args (so only u32, u8, string, bool, no object/array)
Apr 20 19:23:49 <jow> when transforming the fields into env vars, forcibly prefix them
Apr 20 19:23:56 <jow> to prevent things like overwriting $PATH
Apr 20 19:24:39 <jow> (and u8 == bool)
Apr 20 19:25:39 <jow> field names could be either transformed into valid shell identifiers doing something like s/[^a-zA-Z0-9_]+/_/g
Apr 20 19:25:43 <jow> or rejected outright
Apr 20 19:25:58 <champtar> I prefer to reject
Apr 20 19:26:03 <jow> fine with me
Apr 20 19:26:13 <champtar> and to prefix
Apr 20 19:26:39 <champtar> but then we need to change the hotplug
Apr 20 19:26:51 <champtar> hotplugs*
Apr 20 19:26:58 <jow> that is an acceptable tradeoff
Apr 20 19:28:19 <champtar> and the generic handler script seems to be the same amount of work that only handling hotplug
Apr 20 19:28:56 <jow> what is "the generic handler script" ?
Apr 20 19:29:32 <champtar> create /etc/ubus-handler.d/aaa
Apr 20 19:29:58 <champtar> you now have the aaa namespace
Apr 20 19:30:10 <champtar> with an event method
Apr 20 19:30:21 <philipp64> what’s the difference between the nft_* stuff and the nf_* modules? does one obsolete the other?
Apr 20 19:32:01 <jow> champtar: uhm, but you still need to apply all the security measures, you still need to rewrite all hotplug scripts
Apr 20 19:32:26 <jow> just that it will be a different directory than the one used since over a decade
Apr 20 19:33:02 <jow> or is "aaa" supposed to be a script itself? That sounds like a lot of duplicated logic
Apr 20 19:33:25 <jow> each hotplug class script bringit its own parameter parsing, with variying degrees of code quality
Apr 20 19:33:31 <jow> *bringing
Apr 20 19:34:08 <jow> and it still needs to subdispatch to something like /etc/hotplug.d/xxx/ to allow for user scripts
Apr 20 19:36:06 <jow> you could exempt a list of well known variables from the forced prefixing, like $ACTION
Apr 20 19:36:12 <jow> which seems the most important one
Apr 20 19:36:37 <jow> the things reading kernel uevents and putting them into ubus can be allowed to bypass prefixing
Apr 20 19:38:48 <jow> just stuff emitted from userspace (hypothetical  ubus send hotplug.ntp event '{ "action": "stratum", "foo": true, "evil": "rm -rf /" }')  would translate into an exec of /etc/hotplug.d/ntp/*.sh with ACTION=stratum EVENT_ARG_FOO=1 EVENT_ARG_EVIL="rm -rf /" env vars each
Apr 20 19:39:03 <jow> (ACTION not prefixed due to being well known whitelist item)
Apr 20 19:40:47 <champtar> jow: I agree on the duplication, I'm just worried about breaking hotplug for all OpenWrt derivative
Apr 20 19:44:19 <aparcar[m]> ynezz: https://github.com/openwrt/openwrt/pull/2911/files#r411643104
Apr 20 19:52:18 <hexa-> adrianschmutzler: predictive interface naming pretty please :D
Apr 20 19:52:49 <adrianschmutzler> what's predictive?
Apr 20 19:53:06 <adrianschmutzler> meating X's expectations?
Apr 20 19:53:13 <adrianschmutzler> but who is X :-)
Apr 20 19:54:07 <hexa-> predictable *doh*
Apr 20 19:54:12 <hexa-> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Apr 20 19:54:55 <hexa-> step 1) include systemd-udevd
Apr 20 19:54:59 <hexa-> step 2) ????
Apr 20 19:55:02 <hexa-> step 3) cry.
Apr 20 19:55:09 <hexa-> but predictable ifnames would be neat
Apr 20 19:57:10 <philipp64> aparcar: what’s the advantage of signify over usign?
Apr 20 19:58:09 <jow> hexa-: dsa0swp1deadb33f0 :P
Apr 20 19:58:35 <jow> philipp64: usign is a signify "fork"
Apr 20 19:58:37 <hexa-> amazing :P
Apr 20 19:58:57 <jow> philipp64: signify is better maintained, used upstream by BSD etc. so likely to be less buggy and better audited
Apr 20 19:59:22 <philipp64> and it’s ELF but not OS reliant?
Apr 20 20:00:46 <jow> philipp64: it has been ported ot linux and is available as package for at least Debian
Apr 20 20:01:10 <jow> and its compatible to using
Apr 20 20:01:13 <jow> *usign
Apr 20 20:01:23 <jow> signify and usign can verify each others signatures
Apr 20 20:02:19 <jow> functionality wise there is no up or downside, it is more an opportunity to get rid of custom code in favor to maintained upstream one
Apr 20 20:02:42 <philipp64> okay… looking at the PR… wondering why some of the patches are necessary…
Apr 20 20:03:15 <jow> usign added some fluff to signify, like the ability to print a ecda key fingerprint
Apr 20 20:03:24 <aparcar[m]> philipp64: the VERIFY_ONLY is not yet upstream supported
Apr 20 20:03:53 <philipp64> hm… seems like a fairly intrusive change.
Apr 20 20:04:34 <aparcar[m]> philipp64: the VERIFY_ONLY is upstream documented however currently broken, ynezz fixed it. I can imagine they like the patch
Apr 20 20:05:17 <philipp64> okay.
Apr 20 20:05:53 <philipp64> In that case, I’d have #ifdef’d stuff out rather than deleting it, but otherwise I guess it’s okay.
Apr 20 20:06:23 <jow> yeah, #ifdef +1
Apr 20 20:06:32 <jow> makes the patches way smaller and easier to rebase in the future
Apr 20 20:07:27 <aparcar[m]> philipp64: I'll look at it again but I think ynezz already used ifdefs als multiple places
Apr 20 20:07:58 <aparcar[m]> also he never said i's finished, I just took the stuff from his working tree and it worked and resulted in much (130kb) smaller working packages
Apr 20 20:09:25 <aparcar[m]> philipp64: I don't see any code deletion which are not afterward hidden in ifdef
Apr 20 20:10:28 <aparcar[m]> jow: do you have an opinion on the key name handling? currently key-build would be renamed to key-build.sec because signify introduces a "key name verification". I'd simply move key-build to key-build.sec if the latter does not yet exists. However maybe that's super insecure and breaks a lot of stuff?
Apr 20 20:11:55 <karlp> ynezz: yar, there's a variant for an olimex bord with optional emmc, so optional spi flash seems... reasonable at least :)
Apr 20 20:12:32 <jow> aparcar[m]: you could play it dumb and do something like  if [ -f key-build ]; then echo "ERROR: you need to migrate your keys... long technobabble" >&2; exit 1; fi
Apr 20 20:12:59 <jow> and leave it to the user to move things in place
Apr 20 20:13:12 <ynezz> karlp: A64-OLinuXino-1Gs16M with 1GB RAM, no NAND or eMMC flash, no WiFi/BLE, extra 16MB SPI flash
Apr 20 20:13:44 <jow> I don't think that any stuff is actively masking "key-build", imho the more likely breakage is that things are expecting "key-build" and chocking if it does not exist
Apr 20 20:14:03 <jow> (in reference to your "super insecure" remark)
Apr 20 20:15:35 <aparcar[m]> okay manual it is! My monthly build(bot) breaking patch
Apr 20 20:16:31 <philipp64> aparcar[m]: I’m saying I wouldn’t delete any code at all, I’d just hide it with #ifdef…
Apr 20 20:17:11 <ynezz> thats exactly what I'm trying to do
Apr 20 20:17:22 <aparcar[m]> philipp64: I think ynezz sorted some stuff to have less ifdefs
Apr 20 20:17:22 <ynezz> anyway, it's still wip, need to poke upstream first
Apr 20 20:18:03 <philipp64> reviewed…
Apr 20 20:20:15 <aparcar[m]> Do we ultimately need the fingerprint patch? signify seem to put the signing key name into signatures and requires private and public key to have the same stem. This would also make the opkg/keys folder more human readable
Apr 20 20:20:48 <jow> iirc you can easily derive the fingerprint with shell tools as well
Apr 20 20:20:55 <jow> let me dig out that code
Apr 20 20:23:32 <karlp> ynezz: ok, you added that just after I pulled my last branch.  I was looking at the olimex_a20-olinuxino-lime2-emmc and olimex_a20-olinuxino-lime2 versions
Apr 20 20:24:03 <karlp> is tehre any guidance on how DEVICE_VARIANT is meant to work?
Apr 20 20:34:54 <adrianschmutzler> DEVICE_VARIANT is just for the displayed name in make menuconfig
Apr 20 20:35:22 <adrianschmutzler> DEVICE_TITLE := $(DEVICE_VENDOR) $(DEVICE_MODEL) $(DEVICE_VARIANT) or something like that
Apr 20 20:36:34 <adrianschmutzler> it's designed for having a web-based image selector, DEVICE_VARIANT would be mainly stuff like v1/v2 or in your case might be "eMMC"
Apr 20 20:36:40 <adrianschmutzler> karlp: ^^
Apr 20 20:38:06 <jow> the more I think about, the more I like the idea of simply retaining the swconfig uci syntax for dsa
Apr 20 20:38:37 <jow> maybe with slight variations of using the actual port device names instead of port numbers
Apr 20 20:39:10 <adrianschmutzler> I'm still not sure what precisely you mean by the swconfig uci syntax?
Apr 20 20:42:13 <jow> adrianschmutzler: I mean this kind of syntax: https://pastebin.com/ynAmBaJw
Apr 20 20:42:47 <jow> though instead of programming a switch IC through swconfig we're creating a bridge "switch0" and set up the various vlans on top using bridge filtering
Apr 20 20:43:16 <jow> the port numers (0..5) get translated to DSA port numbers (or we use DSA port names directly)
Apr 20 20:43:49 <jow> the t vs. u suffix controls whether the vlan is egress tagged or untagged
Apr 20 20:44:12 <adrianschmutzler> okay, so you were mostly talking about the organization concept where my mind was still fixed to just names
Apr 20 20:44:26 <jow> one can then refer to switch0.1 vs. switch0.2 internally
Apr 20 20:44:44 <jow> ah yes, I'm a few steps ahead :)
Apr 20 20:45:08 <jow> for names I'd prefer something like swXpY e.g. sw0p1
Apr 20 20:45:13 <adrianschmutzler> I have to think about that, as on the first encounter it just looks to me like an additional layer of complexity
Apr 20 20:45:24 <jow> adrianschmutzler: well DSA config is complex
Apr 20 20:45:32 <jow> I'd say even more complax than swconfig
Apr 20 20:46:41 <adrianschmutzler> Actually, I haven't done much with it myself yet
Apr 20 20:47:42 <jow> https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-with-tagging-support
Apr 20 20:47:49 <adrianschmutzler> for the naming discussion, swXp1 would have the disadvantage that we had to change every port label
Apr 20 20:48:26 <jow> well I guess we have to live the reality of randomly made up names being wildly inconsistent between different targets and devices
Apr 20 20:49:00 <philipp64> been so long since I started a fresh cloning… once I’ve done a “script/env new” and copied over my .config and kernel-config into it, do I need to do anything else to get the kernel-config primed or is the rest automatic?
Apr 20 20:49:13 <adrianschmutzler> yes, but I tend to at least try to have them consistent where I can
Apr 20 20:49:14 <jow> as far as I understood, upstream already settled on inconsistent things... so it's a lost cause anyway
Apr 20 20:49:58 <adrianschmutzler> looks like that to me
Apr 20 20:50:47 <adrianschmutzler> though initially, I just wanted to answer the simple question whether I rename "ethernet1" label to "lan1" with local kernel patch or include the ugly "ethernet1" in 02_network
Apr 20 20:50:59 <jow> here's another example of how DSA config looks in practise: https://forum.openwrt.org/t/er-x-sfp-vlans-not-working-properly-with-kernel-5-4/60002/26
Apr 20 20:51:18 <jow> I believe adding some uci abstraction on top reduces compelxity
Apr 20 20:51:26 <jow> I mean that stuff begins to look like iptables
Apr 20 20:51:50 <karlp> adrianschmutzler: re device_variant, so here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/sunxi/image/cortex-a53.mk;h=7a70de4dfff3d0b0fac61c1d85e3387aa89da199;hb=HEAD#l53 _VENDOR, _MODEL and _PACKGES should all be removed?
Apr 20 20:52:05 <adrianschmutzler> jow: would be helpful indeed, particularly talking with my downstream hat on
Apr 20 20:53:42 <adrianschmutzler> karlp: No, the other way around. We once replaced the single DEVICE_TITLE by the three variables, so web-based image selectors wouldn't have to parse the whole name, but get some hierarchy out-of-the-box
Apr 20 20:54:08 <adrianschmutzler> karlp: what is your goal/task?
Apr 20 20:54:12 <karlp> is this a correct understanding of the methods of using it? https://paste.jvnv.net/view/OolM2
Apr 20 20:55:20 <adrianschmutzler> karlp: you could actually mix both ways
Apr 20 20:55:37 <karlp> clear as mud then :)
Apr 20 20:55:44 <adrianschmutzler> inheriting the definition and using DEVICE_VARIANT are not dependent on each other
Apr 20 20:56:07 <karlp> so is DEVICE_VARIANT then _just_ about adding extra text that's "not the model name" ?
Apr 20 20:56:15 <adrianschmutzler> yes
Apr 20 20:56:23 <karlp> well, that seems super useful.
Apr 20 20:56:24 <adrianschmutzler> functionally it does not matter for anything
Apr 20 20:56:44 <adrianschmutzler> it's sole purpose is splitting up the DEVICE_TITLE for parsing by other tools
Apr 20 20:56:52 <karlp> is there some downstream example of this?
Apr 20 20:57:02 <adrianschmutzler> you could even use DEVICE_TITLE and it would work
Apr 20 20:57:39 <adrianschmutzler> it's only in master so far, so I don't think downstream adopted it yet for anything
Apr 20 20:57:47 <adrianschmutzler> let me look for the initial PR
Apr 20 20:59:02 <adrianschmutzler> https://github.com/openwrt/openwrt/pull/2124
Apr 20 20:59:52 <karlp> ah, mor eof aparcers json stuff then.
Apr 20 21:00:19 <adrianschmutzler> karlp: OT: I wouldn't derive one device from another, but create a shared definition and then derive both devices from it
Apr 20 21:00:40 <adrianschmutzler> that's easier to maintain if there are changes to one of the devices
Apr 20 21:00:47 <karlp> even if one of them is actually available as a purchaseable item, and the other is a modification done by the end user?
Apr 20 21:01:30 <adrianschmutzler> yes, just for the matter of maintainability. But that's no hard rule, more something I've learned in the past
Apr 20 21:01:34 <karlp> I mean, if dt overlays were better, it might not even really need to even be a separate device at all.
Apr 20 21:02:00 <karlp> I'm more in the "don't add layers of indirection that aren't used" camp myself.
Apr 20 21:04:08 <adrianschmutzler> My argument is purely practical here: If someone is changing a device, he might not look for some other device inheriting from it, and thus will change that one unintentionally. if you have a shared definition, then it will be obvious that it affects multiple devices. For the same reason, I don't like deriving one DTS from another, but prefer to have shared code only in DTSI files.
Apr 20 21:05:36 <adrianschmutzler> I've seen stuff like this happening several times, and since it's quite easy to avoid it with these guidelines, I try to enforce them wherever I can :-)
Apr 20 21:05:37 <karlp> I understand it completely when people are doing ith with boards, but versions of the same board seems unnecessary
Apr 20 21:06:11 <adrianschmutzler> still, my version gives you extra security with no disadvantage.
Apr 20 21:07:01 <adrianschmutzler> I do understand your conceptional thinking though.
Apr 20 21:09:05 <adrianschmutzler> https://zerobin.fff.community/?5d3de9e3faf247cc#9EM8QcdMrL9LIxQktlsRKhaGjRbWTEVRiT3Tg3Mx9k8=
Apr 20 21:09:42 <adrianschmutzler> Despite, I'd actually add a DEVICE_VARIANT for the "standard" device, even if it's a trivial one.
Apr 20 21:10:13 <adrianschmutzler> If the mod is "SPI flash", there must be an identifier for the other version as well
Apr 20 21:11:25 <karlp> riught, and to me, IMO at least :) your version is _worse_  with no gain.  you've preloaded to "save the work of  the person who modifies the base target in the future, whether that happens or not"
Apr 20 21:11:49 <karlp> and I get that, I've seen that get messy when people are using whole different prodcuts as a base dts file for instance and trying rmeove nodes and add other nodes,
Apr 20 21:12:03 <karlp> it's gross, I agree.  So i've taken your considerations on board :)
Apr 20 21:13:42 <adrianschmutzler> Most of the comments are my personal opinion anyway, so other reviewers might see it differently. I just learned my lessons from having to deal with ar71xx for too long.
Apr 20 21:15:03 <adrianschmutzler> anyway, will be afk now
Apr 20 21:17:05 <adrianschmutzler> and please be forgiving if you receive the same comments as review in two weeks, just remind me of the discussion we had here :-)
Apr 20 21:21:16 <karlp> I would expect no less :)
Apr 20 21:53:51 <philipp64> ynezz: btw, the problem is either my .config or kernel-config… using only upstream master and no local edits, it still fails…
Apr 20 21:57:05 <philipp64> How does $(NFT_CORE-m) get generated?
Apr 20 22:24:45 <Tapper> Hi I had a update to ubuntu and now make menuconfig will not load.
Apr 20 22:25:19 <Tapper> Itsays somthing about libncursesw.so.5
Apr 20 22:26:50 <olmari> Tapper: try "make dirclean", if not working, maybe need to install some prereq
Apr 20 22:27:04 <Tapper> OK will see now thanks
Apr 20 22:27:22 <Tapper> I did install all the packages needed for building tho.
Apr 20 22:30:28 <owrt-1907-builds> build #130 of at91/sam9x is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsam9x/builds/130  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Tomasz Maciej
Apr 20 22:30:29 <owrt-1907-builds> Nowak <tomek_n@o2.pl>
Apr 20 22:39:56 <jgu> Hello. I accidentally posted some login credentials to the openwrt bug tracker. I have changed the credentials, but would like to get them removed from the bug report. How can I contact the admin of the bug tracker?
Apr 20 23:00:16 <owrt-snap-builds> build #352 of pistachio/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/352  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:00:16 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 20 23:03:51 <lynxis> Hauke: do you know how the dect is connected on the speedports/fritzbox/etc?
Apr 20 23:03:53 <owrt-snap-builds> build #325 of omap/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/325  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:03:53 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 20 23:04:36 <lynxis> build failures: "Failed to connect to git.openwrt.org port 443: Connection timed out"
Apr 20 23:09:57 <owrt-snap-builds> build #337 of ramips/rt288x is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/337  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:09:57 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 20 23:19:46 <Tapper> olmari my builds and make menuconfig work again now thanks.
Apr 20 23:32:48 <owrt-1907-builds> build #129 of ipq806x/generic is complete: Failure [failed fetchrefs]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq806x%2Fgeneric/builds/129  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>,
Apr 20 23:32:49 <owrt-1907-builds> Tomasz Maciej Nowak <tomek_n@o2.pl>
Apr 20 23:35:08 <owrt-1907-builds> build #129 of brcm47xx/mips74k is complete: Failure [failed fetchrefs]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm47xx%2Fmips74k/builds/129  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>,
Apr 20 23:35:08 <owrt-1907-builds> Tomasz Maciej Nowak <tomek_n@o2.pl>
Apr 20 23:38:36 <owrt-1907-builds> build #130 of arc770/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/arc770%2Fgeneric/builds/130  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>,
Apr 20 23:38:37 <owrt-1907-builds> Tomasz Maciej Nowak <tomek_n@o2.pl>
Apr 20 23:50:37 <owrt-snap-builds> build #294 of bcm53xx/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/294  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:50:37 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 20 23:55:44 <owrt-snap-builds> build #285 of octeon/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/285  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:55:44 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 20 23:59:04 <owrt-snap-builds> build #280 of malta/be is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/280  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 20 23:59:04 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:01:22 <owrt-snap-builds> build #278 of ath79/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/278  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:01:22 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:09:43 <owrt-snap-builds> build #275 of samsung/s5pv210 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/samsung%2Fs5pv210/builds/275  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:09:43 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:12:56 <owrt-snap-builds> build #269 of ramips/mt7620 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/269  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:12:56 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:16:36 <owrt-snap-builds> build #267 of ramips/mt7621 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/267  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:16:36 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:20:31 <owrt-snap-builds> build #264 of lantiq/falcon is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Ffalcon/builds/264  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:20:31 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:23:37 <owrt-snap-builds> build #280 of sunxi/cortexa7 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa7/builds/280  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 00:23:38 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 00:44:32 <russell--> KA_BOOM
Apr 21 01:22:51 <owrt-1907-builds> build #132 of tegra/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/tegra%2Fgeneric/builds/132  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Tomasz
Apr 21 01:22:51 <owrt-1907-builds> Maciej Nowak <tomek_n@o2.pl>
Apr 21 01:25:47 <owrt-snap-builds> build #295 of ramips/rt305x is complete: Failure [failed fetchrefs]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/295  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 01:25:47 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 01:41:27 <owrt-snap-builds> build #291 of ramips/mt76x8 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/291  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 01:41:27 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 01:44:24 <Monkeh> Who broke the universe this time?
Apr 21 01:46:26 <pkgadd> the good news, no one ;) fatal: unable to access 'https://git.openwrt.org/feed/routing.git/': Operation timed out after 300024 milliseconds with 0 out of 0 bytes received
Apr 21 01:47:02 <DonkeyHotei> and who broke that?
Apr 21 01:47:34 <owrt-snap-builds> build #289 of lantiq/xway is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/289  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 01:47:34 <owrt-snap-builds> <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 01:51:15 <owrt-snap-builds> build #345 of tegra/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/345  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 01:51:15 <owrt-snap-builds> <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:08:52 <owrt-snap-builds> build #341 of ath79/nand is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/341  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 02:08:53 <owrt-snap-builds> <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:09:12 <owrt-snap-builds> build #334 of at91/sama5 is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/334  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 02:09:12 <owrt-snap-builds> <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:11:50 <owrt-1907-builds> build #131 of ar71xx/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fgeneric/builds/131  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Tomasz Maciej
Apr 21 02:11:50 <owrt-1907-builds> Nowak <tomek_n@o2.pl>
Apr 21 02:15:00 <owrt-snap-builds> build #325 of mpc85xx/generic is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/325  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans
Apr 21 02:15:00 <owrt-snap-builds> Dedecker <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:18:01 <owrt-1907-builds> build #119 of x86/legacy is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/119  blamelist: Joel Johnson <mrjoel@lixil.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Magnus Kroken <mkroken@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Tomasz Maciej
Apr 21 02:18:01 <owrt-1907-builds> Nowak <tomek_n@o2.pl>
Apr 21 02:26:46 <owrt-snap-builds> build #326 of layerscape/armv8_64b is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/326  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>,
Apr 21 02:26:46 <owrt-snap-builds> Hans Dedecker <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:37:48 <owrt-snap-builds> build #319 of apm821xx/nand is complete: Exception [exception interrupted]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/319  blamelist: Tomasz Maciej Nowak <tomek_n@o2.pl>, Tobias M?del <t.maedel@alfeld.de>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker
Apr 21 02:37:48 <owrt-snap-builds> <dedeckeh@gmail.com>, Petr ?tetiar <ynezz@true.cz>, Alexander Couzens <lynxis@fe80.eu>, Pawel Dembicki <paweldembicki@gmail.com>
Apr 21 02:38:37 <lynxis> at least the snap-builds should be silenced.
Apr 21 02:41:58 <philipp64> jow: you still awake?  I doubt it… looking at how xt_MASQUERADE is built… and packaged… in include/netfilter.mk and it seems wrong.
Apr 21 02:43:33 <philipp64> it’s built with different CONFIG_* passed in depending on whether we’re building it for IPv4 or IPv6… but it lives in net/netfilter so it should be agnostic..  but of course it isn’t because it contains “#if IS_ENABLED(CONFIG_IPv6)” so it can’t be…
Apr 21 02:44:33 <philipp64> we could build it being IPV6 aware always and then package it into IPT_NAT_COMMON instead on IPT_NAT or IPT_NAT6 …
**** ENDING LOGGING AT Tue Apr 21 02:59:59 2020