**** BEGIN LOGGING AT Wed Jan 15 02:59:57 2020
Jan 15 04:27:17 <owrt-snap-builds> build #239 of omap/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/239
Jan 15 06:45:21 <jow> mangix: lgtm!
Jan 15 07:42:48 <mangix> hrm bricked my wr710n
Jan 15 07:45:27 <mangix> wiki says latest version that runs in 17.01. bah
Jan 15 07:52:22 <mangix> looks like bootloader has no tftp functionality. another brick in the wall.
Jan 15 07:55:57 <PaulFertser> mangix: even old tplinks had tftp client, was usually easy to activate via serial (after typing "tpl" fast enough to get a prompt).
Jan 15 07:56:46 <mangix> PaulFertser: I was thinking more along the lines of holding the reset button :P
Jan 15 07:57:19 <mangix> In any case, the wise thing to have done was replace the bootloader
Jan 15 07:58:23 <mangix> All my other Atheros units run breed
Jan 15 08:08:18 <PaulFertser> breed? Is it not an odd proprietary unmanageable thing?
Jan 15 08:24:18 <xback> Hauke: I'm planning to "release" the generic 5.4 stuff as soon as all build tests succeed on x86 and the remaining issues (mentioned in the WIP patch) get fixed.  I could post it to mailing, but looking at the patch content size, it will get rejected/blocked by the mailinglist
Jan 15 08:59:53 <mangix> PaulFertser: it's just in chinese. No big deal.
Jan 15 09:07:09 <PaulFertser> mangix: no big deal about not having source code for a bootloader? And not being able to communicate with its developer?
Jan 15 09:23:43 <mangix> it's a bootloader, not an OS
Jan 15 09:23:56 <mangix> it works perfectly fine.
Jan 15 10:41:33 <Pepe> mangix:  We need to be more strict which pull requests are merging in packages repository. There is a pull request template and someone does not care about it, so they removed it and you still merging those pull requests even there is no indication about compile/run tested.
Jan 15 10:44:22 <stintel> +1
Jan 15 10:56:24 <jow> but but.. its github, we suck if we don't merge there
Jan 15 10:56:53 <stintel> auto-mark-unmergeable-if-template-missing?
Jan 15 10:57:05 <stintel> wishful thinking probably
Jan 15 10:57:23 <jow> no, then we're dicks and fuck around contributors for no reason
Jan 15 10:57:44 <stintel> pff :)
Jan 15 10:58:19 <stintel> so we just accept that the packages feed is basically a trash container ?
Jan 15 10:58:51 <jow> sorry about the sarcasm. More serious: I wondered whether we already emply that S-o-b checker bot in the openwrt github mirror?
Jan 15 10:59:04 <jow> I added that to LuCI and it helps weeding out the most obvious problems
Jan 15 10:59:27 <Pepe> Yes, there is SoB checker in packages feed.
Jan 15 10:59:39 <jow> yaeh but is it in openwrt/openwrt too?
Jan 15 10:59:46 <jow> or just openwrt/packages?
Jan 15 11:00:55 <Pepe> In openwrt/openwrt there are no checks at all.
Jan 15 11:00:57 <Pepe> https://github.com/openwrt/openwrt/pull/2694/checks / https://github.com/openwrt/packages/pull/11029/checks
Jan 15 11:02:13 <ynezz> correct, we don't want to integrate tightly with that platform, until the decision is made
Jan 15 11:03:00 <jow> fair enough
Jan 15 11:03:27 <jow> I thought I couldn't hurt since this mechanism is easily replicable on gitlab
Jan 15 11:03:37 <jow> compared to e.g. codeload urls
Jan 15 11:04:17 <ynezz> yep, it was mainly reply to the Pepe's message, now I've read the backlog
Jan 15 11:04:20 <stintel> I recall there being an issue with it, that it doesn't check all SoB's or something
Jan 15 11:04:41 <stintel> but that's a while ago. maybe it improved, in that case sob checking wouldn't hurt?
Jan 15 11:04:47 <jow> stintel: well we still have a post receive hook on git.o.o to reject faulty sobs
Jan 15 11:04:58 <ynezz> I had custom patchwork/github bot in my mind
Jan 15 11:05:02 <jow> but as a "first line of defense" it would be good to give immediatze feedback whether
Jan 15 11:05:11 <stintel> indeed. it avoid manual labor
Jan 15 11:05:11 <jow> *any* well formed S-o-b is present
Jan 15 11:05:44 <stintel> ynezz: I've experimented a bit with writing a github integration but never got very far
Jan 15 11:06:03 <jow> ynezz: yeah, I was also thinking about external bot solutions
Jan 15 11:06:23 <stintel> I was doing something with django and https://github.com/sheppard/django-github-hook
Jan 15 11:06:23 <jow> this way we can (with some adjustment work) switch from github rest to gitlab rest apis without too much hassle
Jan 15 11:07:11 <stintel> I would even go as far to reject PRs that don't have the proper prefix in the subject etc
Jan 15 11:07:43 <ynezz> stintel: I would rather fix that automatically
Jan 15 11:08:00 <stintel> I wouldn't, educate contributors so they don't make the same mistake again
Jan 15 11:08:10 <jow> ynezz: well... think of that S-o-b drame in netifd.git
Jan 15 11:08:15 <jow> I'd rather not fix anything automatically
Jan 15 11:08:27 <ynezz> stintel: you can educate them in the comment about that missing subject prefix
Jan 15 11:08:37 <jow> I've also seen contributors in the past getting really angry when you changed aspects about their commits/patches
Jan 15 11:08:53 <ynezz> jow: subject prefix, you're going to do that work anyway to get proper labels
Jan 15 11:08:56 <stintel> if a bot does that automatically I don't need to get frustrated over joe random not even caring to read the contribution guidelines :)
Jan 15 11:09:17 <ynezz> bot should help people, not to depress them
Jan 15 11:09:25 <ynezz> rejecting PR is rude
Jan 15 11:09:39 <stintel> no, not caring about reading contribution guidelines is rude
Jan 15 11:09:41 <jow> eventually you will have to reject PRs
Jan 15 11:09:55 <ynezz> yep, after some timeout
Jan 15 11:10:00 <stintel> and s/reject/mark failed - needs work../
Jan 15 11:10:03 <jow> or is the goal to mergey anything that compiles?
Jan 15 11:10:31 <ynezz> nope, but on one hand we want new/1st time contributors
Jan 15 11:10:52 <ynezz> on the other we're going to reject those contributions?
Jan 15 11:11:25 <jow> I'm undecided
Jan 15 11:11:46 <stintel> we want to give them feedback for basic mistakes without actually having to do that manually
Jan 15 11:11:53 <ynezz> yep
Jan 15 11:11:55 <jow> thats my take on it too
Jan 15 11:11:57 <stintel> because that takes away time, focus, ...
Jan 15 11:12:08 <stintel> and it's frustrating if you look at 3 PRs in a row and they all have the same basic mistakes
Jan 15 11:12:18 <stintel> and you close github and go watch tv or play a game
Jan 15 11:12:56 <ynezz> bot comments about the issues, adds "needs changes" "first contribution" labels
Jan 15 11:13:20 <ynezz> once something is changed in the PR, do it again until fixed or timeout (close it)
Jan 15 11:13:40 <stintel> that sounds acceptable, excuse my poor choice of "reject" wording
Jan 15 11:14:15 <jow> I agree. Sounds perfectly acceptable
Jan 15 11:14:26 <jow> is this just your plan or did you do any actual work on that yet?
Jan 15 11:14:33 <ynezz> or do it vice versa, just label those "bot check passed" or such
Jan 15 11:14:45 <stintel> could even have a mechanism like @ping that would make it post a message on IRC as a reminder to us (rate-limited of course)
Jan 15 11:14:47 <jow> at least I see no reason not do it now already, even when against github
Jan 15 11:15:13 <ynezz> sure, it's just different python class
Jan 15 11:15:35 * stintel goes back to day job
Jan 15 11:15:43 <stintel> I wish it was more openwrt related :(
Jan 15 11:17:15 <ynezz> jow: just did the initial research and actually planned to do that for GitLab
Jan 15 11:18:16 <ynezz> and my next todo item currently in the works is runtime testing in QEMU
Jan 15 11:19:21 <ynezz> in order to do be able to do some more work on services like procd, ubusd etc.
Jan 15 11:19:49 <ynezz> where it's not that easy to do regression testing as for example in libubox
Jan 15 11:22:40 <ynezz> so now it's evaluation of Avocado, then I plan to look at LAVA/BoardFarm
Jan 15 11:30:53 <ynezz> makes me wonder if someone has some experience with any of those
Jan 15 11:31:13 <ynezz> lynxis: are you using LAVA or BoardFarm for your testing?
Jan 15 11:31:56 <lynxis> ynezz: yes
Jan 15 11:32:03 <lynxis> ynezz: https://lava.fe80.eu/
Jan 15 11:33:54 <ynezz> lynxis: have you looked at the BoardFarm as well?
Jan 15 11:34:08 <lynxis> ynezz: only looked. but never used it.
Jan 15 11:34:23 <lynxis> ynezz: intel has a "fork" or a double the size extended boardfarm as well.
Jan 15 11:34:55 <lynxis> ynezz: I also have received recommendation towards labgrid (pengotronix).
Jan 15 11:39:01 <ynezz> lynxis: what do you use for DUT control? To power cycle/reset the board?
Jan 15 11:42:38 <lynxis> ynezz: because I'm lazy, I'm using 230V controllable powerplugs. i've 3 different producs in use. e.g. EnerGenie EG-PM2 (usb)
Jan 15 11:43:02 <karlp> doesn't sound lazy at all :)
Jan 15 11:43:21 <lynxis> ynezz: low voltage relais with a raspi also works and is cheaper. but you have to cut the power cable
Jan 15 11:44:45 <ynezz> lynxis: yep, but that will result in the cable hell with more then a few devices
Jan 15 11:44:50 <lynxis> ynezz: my argument against boardfarm was, it's not distributed. lava is quite complex and distributed. labgrid is easier to use for direct control (interactive use) as well it's scriptable. $company from the openwrt community is also using labgrid.
Jan 15 11:44:51 <ynezz> this powerplugs looks good
Jan 15 11:46:21 <lynxis> ynezz: I'm using euroboxes to place the boxes in there.
Jan 15 11:49:18 <ynezz> lynxis: one usually needs a power (reset), serial, ethernet which means a lot of cables for one device
Jan 15 11:50:18 <ynezz> so I was thinking about switch with PoE and some custom PoE injector, with UART over ethernet
Jan 15 11:53:03 <ynezz> that PoE injector would have ethernet switch, one for the DUT and second one for the MCU doing the UART/ethernet - thus having all-in-one (power/ethernet/uart) in one device
Jan 15 11:53:21 <karlp> you've just moved the cable squid closer to the device?
Jan 15 11:53:30 <karlp> and now you've added a custom controller?
Jan 15 11:54:46 <ynezz> how would you do it?
Jan 15 11:55:46 <ynezz> having everything in one cable from switch to device looks appealing to me
Jan 15 11:58:05 <ynezz> UART<->USB cable length is limited, couldn't find some 3V3 UART<->Ethernet devices with more then one port
Jan 15 11:59:26 <ynezz> just dont want to have +2-3 more devices/cables for every device in test
Jan 15 12:05:58 <xback> ynezz: I'm using a moxa device for that
Jan 15 12:06:09 <karlp> ynezz: , no PoE requirement
Jan 15 12:06:17 <karlp> ynezz: https://privatebin.net/?05f446b778c69457#8NGCachLzo4kc8aQ7xaKBg8pQsWUwF933xhwsv5Fr4Cc sorry bad paste
Jan 15 12:06:21 <xback> 16 serial ports over ethernet, all loaded as ttyUSB's in my ubuntu dev machine
Jan 15 12:06:49 <xback> power for the testing boards is a simple UBNT PoE switch with PoE+
Jan 15 12:07:04 <karlp> you only have test boards that are poe capable then?
Jan 15 12:07:50 <xback> yeah, most of them are.  I do have boards without, but we've create a "PoE exporter board" for that
Jan 15 12:08:19 <xback> it strips power from PoE and serves it through a Barrel jack or a screw terminal block
Jan 15 12:08:25 <karlp> yeah, teh poe-de-injector I mention on that paste :)
Jan 15 12:09:13 <karlp> a terminal server and a poe siwtch/poe de-injector is way less work than building a single ethernet->uart+power+ethernet switch controller device IMO
Jan 15 12:09:28 <xback> but it's fun.  I can connect 16 serial ports to devices, and monitor them all at once scanning for dumps
Jan 15 12:10:05 <ynezz> xback: moxa is rs232, or do they have a 3V3 UART option as well?
Jan 15 12:10:35 <xback> No. there are plenty of cheap devices which strip a little bit of power from a RS232 handshake pin to power to converter
Jan 15 12:10:39 <xback> Blackbox has these
Jan 15 12:10:58 <ynezz> ok, didn't think about this option :)
Jan 15 12:11:14 <xback> ynezz: https://etronixcenter.com/nl/rs-232-rs232-adapters/8161018-ww81009611-nedro-passive-rs232-to-ttl-converter-hxsp-106-grey-7110216442389.html?gmc_currency=1&gclid=EAIaIQobChMImM6fz8mF5wIVFMayCh1kcgBvEAQYCSABEgIYUPD_BwE
Jan 15 12:11:38 <xback> it only strips a few milli amps from a pin, to the serial port can handle it
Jan 15 12:12:14 <karlp> a rack terminal server+rs232->ttl is ~simlar in wiring to usb hubs really, unless you're in love with rack mounting things :)
Jan 15 12:13:44 <xback> ynezz: if you want to be sure, it's always better to power the TTL convert directly. which can be done easily with this:  https://www.banggood.com/nl/5Pcs-Built-in-MAX232CPE-Chip-RS232-TTL-Converter-Module-With-Cables-p-948140.html?gmcCountry=BE&currency=EUR&createTmp=1&utm_source=googleshopping&utm_medium=cpc_bgs&utm_content=xibei&utm_campaign=xibei-pla-brand-elc2-be&gclid=EAIaIQobChMImM6fz8mF5wIVFMayCh1kcgBvEAQYBSABEgK6jvD_BwE&cur_
Jan 15 12:13:46 <xback> warehouse=CN
Jan 15 12:14:01 <xback> a simple powered USB hub can be used to power them all
Jan 15 12:14:59 <karlp> xback: if you're going to use a usb hub, just use usb2ttl up front?
Jan 15 12:15:08 <karlp> why bother with the rs232 terminal server at all?
Jan 15 12:15:50 <xback> well. those passive converters do work fine
Jan 15 12:16:10 <xback> but it depends on the host rs232 port mostly
Jan 15 12:16:24 <xback> it should have a normal fair drive strength
Jan 15 12:17:00 <xback> karlp: the main advantage here is that the testing boards do not need to be near the dev pc
Jan 15 12:17:37 <xback> I'm running all tests here to boards laying in another room.  as I don't have enough desk space to lay them all ;-)
Jan 15 12:17:58 <karlp> I would only consider having the usb2uarts exposed on the network anyway, I'd never be planning on having them attached to _my_ computer or anything.
Jan 15 12:32:28 <lynxis> xback: do you just use screen/tmux or do you use also labgrid or similiar tool?
Jan 15 12:38:21 <xback> lynxis: I just use Terminator to have nice scaled terminals, and just run minicom or picocom to view live + log to file
Jan 15 12:42:28 <ynezz> karlp: nice ASCII art :)
Jan 15 12:42:47 <ynezz> saved this tips for later, thanks
Jan 15 13:45:45 <cotequeiroz> I've received a report, in https://github.com/openwrt/packages/issues/10987, that the kmod-cryptodev package is not in the repo.
Jan 15 13:48:29 <cotequeiroz> I've searched for it all the way back to 17.01, when it was still in the packages repo, and couldn't find it anywhere.  The package is getting built, apparently, as we can see faillogs from time to time, such as here: http://logs.nslu2-linux.org/livelogs/openwrt-devel/openwrt-devel.20190718.txt
Jan 15 13:50:45 <cotequeiroz> It builds locally, and I don't really know how the buildbots work.  Can anyone help me with this?
Jan 15 13:52:57 <jow> phase1 buildbots build each target, its images, IB and SDK
Jan 15 13:53:28 <jow> phase2 buildbots pick the SDK from one of the target providing the pkgarch and build all packages with it
Jan 15 14:02:46 <jow> mipsel_24kc (mentioned in the linked ticket) is provided by ramips/mt7620, ramips/mt7621, ramips/mt76x8, ramips/rt288x, ramips/rt305x
Jan 15 14:04:05 <jow> the phase2 builder uses the SDK of mt7620 to build mipsel_24kc packages (e.g. http://buildbot.openwrt.org/master/packages/builders/mipsel_24kc/builds/133/steps/downloadsdk/logs/stdio)
Jan 15 14:07:11 <jow> none of the ramips subtargets appears to provide a kmod-cryptodev
Jan 15 14:07:34 <jow> yet, when building openssl using their SDK, it appears to start to depend on kmod-cryptodev
Jan 15 14:07:40 <cotequeiroz> jow: Thanks for the explanation.  The failure is across all targets, apparently.  AFAIK, mips does not have hw-crypto in the kernel (I may be wrong), but I know mvebu does, and I cant find it there at all.
Jan 15 14:07:54 <jow> the issue seems with the SDK
Jan 15 14:08:23 <jow> I suggest zo try building libopenssl with https://downloads.openwrt.org/snapshots/targets/ramips/mt7620/openwrt-sdk-ramips-mt7620_gcc-8.3.0_musl.Linux-x86_64.tar.xz
Jan 15 14:08:30 <cotequeiroz> kmod-cryptodev is from outside the kernel, it lives in `package/kernel/cryptodev-linux`.
Jan 15 14:09:11 <cotequeiroz> I'll give that a try.
Jan 15 14:09:54 <jow> I suppose the issue boils down to `DEFAULT:=m if ALL` in package/kernel/cryptodev-linux/Makefile
Jan 15 14:10:05 <cotequeiroz> What does it do, btw?
Jan 15 14:10:13 <jow> it overwrites the default `DEFAULT` selection logic, so it fails to build in the phase1 builders
Jan 15 14:10:28 <cotequeiroz> Is it necessary?
Jan 15 14:10:55 <jow> I honestly have no idea about the intent of this change. It says "Enable package as <m> when CONFIG_ALL=y" but that already is the default for CONFIG_ALL
Jan 15 14:12:01 <jow> problem is that phase1 uses CONFIG_ALL_KMODS=y and CONFIG_ALL_NONSHARED=y
Jan 15 14:12:34 <jow> which fail to select kmod-cryptodev since it overwrites the default `DEFAULT` kconfig select expression
Jan 15 14:12:47 <cotequeiroz> That's what I thought, and it makes no sense.   I'll try to build it locally, to see if it breaks anything, then I'll send a patch.  I can only imagine that the intent would be to make the package source-only, perhaps.
Jan 15 14:13:52 <cotequeiroz> It would make sense before the openssl engine was built as a separate package, since one would have to compile openssl with non-default options to enable it.  However, this is not the case anymore.
Jan 15 14:14:16 <jow> which is something like  `default m if ALL||ALL_NONSHARED||ALL_KMODS`
Jan 15 14:15:10 <cotequeiroz> I was thinking of just dropping it.
Jan 15 14:16:09 <jow> the default expression or the package (dependency) ?
Jan 15 14:16:21 <cotequeiroz> the default expression
Jan 15 14:16:35 <jow> yeah, I'd gree
Jan 15 14:16:38 <jow> *agree
Jan 15 14:16:57 <cotequeiroz> I'll give it a test, and send a patch.  Thanks.
Jan 15 16:12:12 <ynezz> karlp: "USB/USB-PD, or USB-A/C to barrel jacks, you can use a hub with per port power switching" any recommendations for such hub?
Jan 15 16:13:12 <karlp> any of the ones here: https://github.com/mvp/uhubctl
Jan 15 16:13:26 <ynezz> ooh, thanks!
Jan 15 16:13:33 <karlp> you can use lsusb to see if you already have one, but it's not a common feature unfortunately.
Jan 15 16:13:48 <karlp> if you're ok with turning off more than one device at a time, ganged might still be fine for you.
Jan 15 16:14:35 <karlp> I'm building a hub atm to get the form factor I want and including per port control for board regresion testing too, but I don't need uart+ethernet, so it's just 2 usb per dut.
Jan 15 16:15:38 <ynezz> I want to power-off the boards if theres no work for them
Jan 15 16:16:02 <ynezz> so it shouldn't be "ganged"
Jan 15 16:16:08 <karlp> so _most_ hubs just have no power control at all,
Jan 15 16:16:41 <karlp> ganged is sometimes available, but still not real common, and actual per port control is increasingly rare
Jan 15 16:18:21 <ynezz> I'm puzzled, that page says "Compatible USB hubs" = per-port power control?
Jan 15 16:18:52 <ynezz> as that table doesn't have such option, so I assume, that the list has only per-port power hubs
Jan 15 16:19:06 <karlp> yeah, that's a page for a tool that sends the hub commands for port power switching
Jan 15 16:19:15 <karlp> so they're only including ones that they know of that do it.
Jan 15 16:21:08 <karlp> (I'm only talking about usb 2.0 hub features here, usb pd should be doing it on any compatible sinks but I'm not as well versed there.)
Jan 15 17:35:08 <kristrev> they are a bit on the price side, but I have good experience with Yepkit
Jan 15 17:35:41 <kristrev> they have a hub where the main feature is per-port power control, and the datasheet is publically available
Jan 15 17:35:55 <kristrev> they also provide a utility for controlling the ports, but I havent tried that one. I ended up making my own instead
Jan 15 17:36:22 <kristrev> (utility for Linux, that is)
Jan 15 17:37:43 <kristrev> here is their website: https://www.yepkit.com/home. I see they have also made a usb3.0 hub now
Jan 15 17:39:19 <karlp> heh, that's so weird.
Jan 15 17:39:51 <karlp> they used a perfectly suitable port controller switch, and instead of connecting it to the port controller pins, they used a hub port to drop a pic, to listen to _custom_ commands, to drive the same pins.
Jan 15 17:41:19 <kristrev> yeah, the design is a bit weird, but at least they work and are readily available. Things might have changed, but when I was looking for a per-port hub I was not able to find any of the ones on the list you linked to (I also found it some time ago)
Jan 15 17:41:59 <kristrev> at least in Norway there seemed to always be a new revisions of the hubs that I could find, without per-port
Jan 15 17:42:01 <karlp> the rev 1.0 used the port power pins from the hub, but then passed it to the pic anyway.
Jan 15 17:42:03 <karlp> weirddddd
Jan 15 18:36:04 <Hauke> blogic: we could do a meeting in hamburg again now we know how it works and it should be easier or we wait for battlemesh
Jan 15 18:36:31 <thagabe> How about San Francisco? :3
Jan 15 18:37:46 <stintel> thagabe: if you pay :P
Jan 15 18:38:12 <reiffert> I'm in for SF when thagabe pays for the flight.
Jan 15 18:38:27 <thagabe> I got $20, take it or leave it
Jan 15 18:38:32 * stintel leaves
Jan 15 18:38:37 <stintel> ;)
Jan 15 18:39:49 <reiffert> 20 bucks wont even get me to the airport
Jan 15 18:39:51 <thagabe> bruhhhhh I've been to hamburg in 2018 and stayed at the reeperbahn because of a  mix up in my itinerary, man was that a weird stay hahahaha
Jan 15 18:40:06 <reiffert> :-)
Jan 15 18:40:51 <thagabe> Where would it be in hamburg? at the University?
Jan 15 18:41:19 <reiffert> Amsterdam is close - try that for weird. Let's have the meeting there!
Jan 15 18:42:41 <thagabe> lol
Jan 15 18:43:26 <aparcar[m]> OpenWrt meeting 2020?
Jan 15 18:43:36 <Hauke> last time we stayed at dock europe in Hamburg
Jan 15 18:43:51 <ynezz> that was nice place
Jan 15 18:48:01 <Hauke> there is a longer German article about OpenWrt on heise: https://heise.de/-4638479
Jan 15 18:48:48 <Hauke> xback: ok, I normally tried to post the diff between the old and the new kernel
Jan 15 18:48:54 <Hauke> but it gets big
Jan 15 18:49:12 <thagabe> Y'all got any suggestions for a decent setup for openwrt? I got the WRT line because of the legendary WRT54G but alas the new ones are hot garbage. Any suggestions are  appreciated
Jan 15 18:50:58 <ynezz> check forum
Jan 15 18:51:57 <ynezz> or ask on #openwrt, where I always get good recommendations (dont forget to define "decent" in your context)
Jan 15 18:52:13 <thagabe> gotcha
Jan 15 19:21:26 <blogic> Hauke: works for me
Jan 15 19:26:43 <blogic> https://patchwork.ozlabs.org/patch/1214777/
Jan 15 19:26:48 <blogic> will this break sysupgrade ?
Jan 15 19:53:05 <tmn505> blogic: it shouldn't, but I wouldn't lay my head for it. The size seems to be calculated on the fly Ref: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/upgrade/nand.sh;hb=HEAD#l245
Jan 15 19:53:40 <blogic> tmn505: i actually concluded the same 5 minutes ago
Jan 15 19:53:45 <blogic> thanks for confirming
Jan 15 19:56:20 <blogic> can I just note that i love my new uplink
Jan 15 19:56:27 <blogic> fianlly native ipv6
Jan 15 19:56:46 <blogic> however I am only getting ~220mbit and not the promised 250
Jan 15 19:56:54 <blogic> still time travel to the previous 7
Jan 15 19:57:05 <stintel> blogic: enjoy :)
Jan 15 19:57:16 <stintel> and welcome in the 1st world :P
Jan 15 19:57:19 <blogic> stintel: and really low pings
Jan 15 19:57:34 <blogic> stintel: i was not expecting that to ever happen in germany
Jan 15 19:57:51 <blogic> now they need to fix the cellphone coverage and I'll be a happy camper
Jan 15 19:58:01 <stintel> is it that bad?
Jan 15 19:58:11 <ynezz> yes
Jan 15 19:58:14 <blogic> yes
Jan 15 19:58:16 <blogic> worse
Jan 15 19:58:44 <mamarley> I wasn't really expecting https://www.speedtest.net/result/8941637901 to ever happen to me either, but it really is awesome.
Jan 15 19:59:05 <blogic> mamarley: god mode :-)
Jan 15 19:59:09 <owrt-snap-builds> build #251 of pistachio/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/251  blamelist: Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij <linus.walleij@linaro.org>, Felix Fietkau
Jan 15 19:59:09 <owrt-snap-builds> <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>
Jan 15 19:59:46 <blogic> bet that was me, lets see
Jan 15 19:59:57 <stintel> contacted an ISP that offers 1000/1000 in Sofia, they can connect me on my location, but I'm considering finding another apartment so I might stick with my 200/120 for now
Jan 15 20:00:11 <stintel> but neither my current nor that other one offer IPv6 :(
Jan 15 20:00:42 <stintel> current silently ignores inqueries about it, the 2nd one is aware but has no ETA
Jan 15 20:00:59 <mamarley> Yeah, that sucks.  The other ISP offering fiber in my area doesn't have (native) IPv6 either, and they force you to use their crappy router.
Jan 15 20:01:33 <stintel> with the new one I can just stick the fiber directly in my own equipment
Jan 15 20:01:38 <stintel> so that's definitely a +
Jan 15 20:02:12 <stintel> so I'm on the lookout for OpenWrt-able hardware with working SFP and possibility to route gigE with sqm enabled
Jan 15 20:02:19 <stintel> am I asking for too much? =)
Jan 15 20:02:29 <mamarley> I just plug my server/router straight into the ONT and do DHCP/DHCPv6.  Some older deployments of this service require some VLAN and CoS trickery, but mine doesn't.
Jan 15 20:02:29 <stintel> I was actually looking at macchiatobin but can't find it in Europe
Jan 15 20:03:27 <mamarley> I ran OpenWRT on x86_64 for quite a while, but I got tired of dealing with compiling myself and the monolithic updates, so I ended up switching to a homebrew setup on a general purpose distro.
Jan 15 20:03:34 <ynezz> stintel: check farnell
Jan 15 20:03:40 <Slimey> :)
Jan 15 20:04:48 <mamarley> Oh, and there isn't any bufferbloat either.  In fact, the already-low latency seems to tick down 1ms or so under heavy load.
Jan 15 20:05:51 <ynezz> stintel: they claim 30pcs of stock in UK, considering it as well :]
Jan 15 20:06:49 <stintel> ynezz: ooooh
Jan 15 20:08:13 <stintel> ynezz: 479 for the double shot, I could live with that I thinkj
Jan 15 20:08:32 <stintel> keep my apu2 as backup router, replacing the ERL
Jan 15 20:08:51 <stintel> but do they have an enclosure for it
Jan 15 20:08:57 <stintel> there was this cloud something something version of it
Jan 15 20:09:05 <Slimey> i have a few Mini PCIe (oversized) Senao PCE5503BN, Senao PCE5503AN, QCA9984 4x4:4 ac wave2 cards i want to use for a x64 router in a pc
Jan 15 20:09:15 <stintel> clearcloud 8k
Jan 15 20:12:39 <Slimey> whats the correct name for these connectors, http://images.shoutwiki.com/en.techinfodepot/9/90/Bsap-1800v2_24ghz_wifi.jpg Hirose U.FL right?
Jan 15 20:13:09 <blogic> U.fl
Jan 15 20:13:17 <blogic> there is ufel for the m2 cards
Jan 15 20:13:26 <blogic> but mini pci/e is without the e
Jan 15 20:14:57 <ynezz> latest build news: install: cannot create directory './files/dropbear.failsafe': File exists
Jan 15 20:15:00 <ynezz> :)
Jan 15 20:16:42 <owrt-snap-builds> build #244 of tegra/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/244  blamelist: Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij <linus.walleij@linaro.org>, Rosen Penev
Jan 15 20:16:43 <owrt-snap-builds> <rosenp@gmail.com>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 20:24:19 <blogic> ffs
Jan 15 20:24:27 <blogic> I need my build server back
Jan 15 20:24:59 <blogic> $ find package/ -name dropbear.failsafe
Jan 15 20:24:59 <blogic> package/network/services/dropbear/files/dropbear.failsafe
Jan 15 20:28:34 <ynezz> http://paste.ubuntu.com/p/J8Sg3DV9f2/
Jan 15 20:30:07 <blogic> ynezz: yup, figured
Jan 15 20:30:45 <owrt-snap-builds> build #243 of ath79/nand is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/243  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij
Jan 15 20:30:45 <owrt-snap-builds> <linus.walleij@linaro.org>, Rosen Penev <rosenp@gmail.com>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 20:30:47 <stintel> ynezz: oh, that macchiatobin fits in a mini ITX case. sweet
Jan 15 20:31:19 <stintel> I happen to have one left, even with a display on it (old HTPC case)
Jan 15 20:31:33 <stintel> could be nice to display some info on it
Jan 15 20:32:28 <stintel> but just ordered a new case for my home server. my chenbro es34069 psu became flakey recently. waiting for a silverstone cs381 now
Jan 15 20:33:30 <stintel> and some upgrades on my car too. I should stop spending for a while now
Jan 15 20:33:49 <stintel> but my >4y old xps13 needs replacing too
Jan 15 20:33:53 <stintel> ugh :P
Jan 15 20:34:46 <mamarley> I just replaced my desktop in order to downsize and save electricity, but when I sold the old one, the guy to whom I sold it couldn't get it running stably, so I had to give him a refund.  Now I'm stuck with a useless PC that I can't sell…
Jan 15 20:35:10 <Slimey> https://imgur.com/zqKcWMD these appear to be U.fl also
Jan 15 20:35:34 <stintel> that sucks. i messed up my workstation recently too, so did an emergency buy of something a friend wanted to get rid of
Jan 15 20:35:54 <stintel> so now I'm on a HP z840 with 2x E5-2673 v4 and 256GB RAM :P
Jan 15 20:36:46 <stintel> so I still plan to do new router with SFP and 10gigE support, upgrade my switch to 10gigE, probably an 11ax AP and a laptop, and then should be good for a couple of years lol
Jan 15 20:38:01 <owrt-snap-builds> build #239 of at91/sama5 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/239  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij
Jan 15 20:38:01 <owrt-snap-builds> <linus.walleij@linaro.org>, Rosen Penev <rosenp@gmail.com>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 20:38:46 <Slimey> just need to find me a pcie card that lets me put them into a desktop
Jan 15 20:39:37 <owrt-snap-builds> build #241 of apm821xx/sata is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fsata/builds/241  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij
Jan 15 20:39:37 <owrt-snap-builds> <linus.walleij@linaro.org>, Rosen Penev <rosenp@gmail.com>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 20:48:17 <owrt-snap-builds> build #232 of mpc85xx/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/232  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Linus Walleij
Jan 15 20:48:17 <owrt-snap-builds> <linus.walleij@linaro.org>, Rosen Penev <rosenp@gmail.com>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 21:03:21 <owrt-snap-builds> build #232 of layerscape/armv8_64b is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/232  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, John Crispin <john@phrozen.org>, Florian
Jan 15 21:03:21 <owrt-snap-builds> Eckert <fe@dev.tdt.de>, Linus Walleij <linus.walleij@linaro.org>, Rosen Penev <rosenp@gmail.com>, Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>, Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 15 21:10:27 <mangix> Pepe: which PR?
Jan 15 22:35:58 <owrt-1907-builds> build #84 of ramips/rt305x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt305x/builds/84
Jan 15 23:34:58 <owrt-1907-builds> build #78 of samsung/s5pv210 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/samsung%2Fs5pv210/builds/78  blamelist: Felix Fietkau <nbd@nbd.name>, Eneas U de Queiroz <cotequeiroz@gmail.com>
Jan 16 00:22:17 <xdarklight> Hauke: mostly off-topic to your OpenWrt 20.x release email: have you also discussed how to proceed with kernel patch submissions? I believe that I read that kernel patches should be upstreamed by their authors whenever possible. is this policy still relevant and how to communicate this to developers? (for example: I replied to https://github.com/openwrt/openwrt/pull/2662 today but I kept this as my personal opinion since I don't know
Jan 16 00:22:18 <xdarklight> where there's a rule about this)
Jan 16 00:23:29 <xdarklight> to me this is an important topic for every kernel update (which I've done twice now I think for the lantiq target. deleting backports during an update was very easy, but updating the old out-of-tree patches wasn't always straight forward)
Jan 16 00:26:01 <xdarklight> take the lantiq example: I see a realistic chance to have an upstream PCIe driver at some point. that requires migrating the PCI driver to some newer framework as well, which will break fixup-lantiq.c (PCI fixups). it's easy to drop fixup-lantiq.c in mainline since nothing uses it, but OpenWrt has ath5k EEPROM patches which rely on that
Jan 16 00:28:17 <xdarklight> long story short: personally I believe it's a good idea to make people contribute their patches upstream first, then backport them to OpenWrt. however, I don't know if OpenWrt developers are interested in this as well and how to transition from "the patch flow that we have right now" to "the new thing"
**** ENDING LOGGING AT Thu Jan 16 02:59:59 2020