**** BEGIN LOGGING AT Mon Jul 30 03:00:00 2018 Jul 30 04:45:52 DonkeyHotei: Hauke wrote "Why not add a autoprobe section for them?" Jul 30 04:46:09 DonkeyHotei: is the "Tested only with insmod, on both x86 and x86_64. The modules still do not have an autoload, so the included dependencies must be manually loaded in the correct order, which is not shown here." Jul 30 04:46:21 a valid explanation why autoprobe can't be used? Jul 30 04:47:12 rmilecki: commit message was edited, but not the pr message Jul 30 04:48:20 Hauke and philipp64 requested the autoload, so i added it Jul 30 04:48:45 DonkeyHotei: Hauke asked: "Why not add a autoprobe section for them?" Jul 30 04:48:49 do you need autload? Jul 30 04:48:55 can't you use autoprobe? Jul 30 04:49:22 the modules probe as they load, so that would be superfluous Jul 30 04:50:06 in fact, the only one that doesn't is the one that was already packaged Jul 30 04:50:08 i'm not sure if we're talking about the same thing Jul 30 04:50:53 DonkeyHotei: have you tried "call AutoProbe" instead of "call AutoLoad"? Jul 30 04:51:16 that's an option? Jul 30 04:51:41 not sure what do you mean by "option" Jul 30 04:51:49 it's an alternative way of loading modules Jul 30 04:51:56 it doesn't require you to care about order Jul 30 04:52:08 and if that happens to work, I believe it's preferred Jul 30 04:52:25 look e.g. at package/kernel/mt76/Makefile Jul 30 04:52:36 it's just about sth like: Jul 30 04:52:38 AUTOLOAD:=$(call AutoProbe,mt76x2e) Jul 30 04:54:07 the potential problem i see with doing it that way in this case is that if you probe a module that won't load due to lack of hardware support, you might end up not loading a dependency that does Jul 30 04:54:26 however, that could be worked around Jul 30 04:54:26 good morning Jul 30 04:54:33 jow: morning Jul 30 04:54:54 jow: since you revealed youself... can you check above AutoProve vs. AutoLoad discussion? ;) Jul 30 04:55:07 i was not aware the AutoProbe thing had been added to the buildroot until now Jul 30 04:55:15 it's about https://github.com/openwrt/openwrt/pull/679 Jul 30 04:55:51 took a cursory look Jul 30 04:55:55 it's certainly an improvement Jul 30 04:56:03 yes AutoProbe is definitely preferred Jul 30 04:56:04 autoprobe, that is Jul 30 04:56:13 but DonkeyHotei's argument has merit Jul 30 04:56:31 however I wonder how trtaditional distros using modprobe handle this, then Jul 30 04:57:10 on the other hand I don't want to do even more bikeshedding Jul 30 04:57:12 traditional distros use aliases to autoprobe instead of autoprobing by name Jul 30 04:57:30 so either way is fine for me Jul 30 04:57:31 agreed Jul 30 04:58:16 blogic: any more concerns about https://github.com/openwrt/openwrt/pull/679 ? Jul 30 04:58:58 that concatination of multiple $(call AutoLoad,...) macro results has been tested at runtime? The generated postinst shell code is fine? Jul 30 04:59:21 runtime-tested, yes Jul 30 04:59:27 allright then Jul 30 04:59:49 functionality of the modules themselves not tested, though Jul 30 04:59:53 but they do load Jul 30 05:00:14 (except the ones that the hardware does not support) Jul 30 05:06:28 it should be noted that with the changes requested, whether autoload or autoprobe, the results will be sad if anyone should attempt this on a 486 Jul 30 05:07:45 but people aren't likely to do crypto on a 486 in 2018 Jul 30 05:16:18 since people are beginning to appear on a monday morning, i should bring up the matter of an edimax board somebody in this channel requested support for a week or two ago Jul 30 05:17:31 i do not have this board, but i took the liberty of contacting the openwrt forum participants who were working on it at the time of the forum's demise by e-mail directly Jul 30 05:18:33 but there is a problem with code blogic added to work around an issue with a different board in 2014 Jul 30 05:19:14 the commit msg at https://dev.archive.openwrt.org/changeset/43200 is a summary of what led up to it Jul 30 05:19:43 ping mkresin Jul 30 05:21:07 the linksys e1700 has an mt7620a with its internal switch, and a separate mt7530 switch chip Jul 30 05:21:10 * rmilecki is back Jul 30 05:23:03 the "ephy1 fixup" alluded to in that commit msg is apparently intended to apply only to the mt7620's internal switch core, but on the e1700, it was clobbering the separate switch chip Jul 30 05:25:27 it does the same thing on the edimax board, but the solution that was settled on for the e1700, setting the PHY_DIS bits on the internal switch core, somehow also goes to the switch chip on the edimax board Jul 30 05:34:01 i'm hoping blogic might be able to shed a bit more light on what may be going on Jul 30 05:50:50 rmilecki: ping Jul 30 05:58:41 jow: pong Jul 30 05:59:50 rmilecki: I wonder if we should include kmod-brcm-wl by default for the e3000 and wrt610n devices Jul 30 06:00:02 currently it comes up without any wireless support by default Jul 30 06:00:17 but the good news is that tg3 is included by default in this release so finally no soft-brick by default anymore Jul 30 06:00:46 tg3 was already included in 17.01 builds I think Jul 30 06:00:57 ah right yes Jul 30 06:01:07 since the per-device rootfs Jul 30 06:01:39 possibly even in 15.05 since we got "generic" subtarget back then Jul 30 06:02:00 i'm not sure about wl... Jul 30 06:02:18 it's closed source, I'd prefer to not include it by default Jul 30 06:02:25 also not sure when was it tested last time Jul 30 06:02:35 testing it right now Jul 30 06:02:38 and I'm sure people were complaining about not working eaps/nas Jul 30 06:02:46 oh, nice Jul 30 06:02:50 well better than no wireless at all :D Jul 30 06:03:09 wpa2-psk in client mode appears to work well Jul 30 06:03:27 AP mode will be more interesting :) Jul 30 06:03:32 I'm fine with not including wl by default if you prefer that Jul 30 06:03:44 Hauke: whats your opinion? Jul 30 06:04:37 i think I prefer to have users do "opkg install wl", but if more people want to have it included by default, I'm OK Jul 30 06:07:16 ap-sta seems broken, need to check that later Jul 30 06:07:36 I guess nobody ever tested it after the wireless/netifd integration Jul 30 06:12:41 jow: pong Jul 30 06:14:31 mkresin: about https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=78cf5eed6edaa38561e9c9c3ff14a36c1eedfadd Jul 30 06:14:57 mkresin: this causes a (cosmetical) regression on brcm47xx since you set the sysinfo modelname forcibly to "unknown" Jul 30 06:15:38 mkresin: on these boards, the cpuinfo machine field contains the human readable model name, e.g. "Linksys E3000 V1" Jul 30 06:16:05 mkresin: so I wonder if we should simply duplicate the value in board_name into model Jul 30 06:17:03 usually board_name is supposed to contain some identifier, like a DT compatible string or a board id Jul 30 06:17:29 rmilecki: no real blockers Jul 30 06:17:29 mkresin: ah sorry missing context.... "these boards" is brcm47xx/generic Jul 30 06:17:50 i always wonder why people add such big "to be maintained" features that they dont runtime test as they dont use them Jul 30 06:18:21 blogic: ? Jul 30 06:19:01 jow: it's about https://github.com/openwrt/openwrt/pull/679 Jul 30 06:20:18 jow: DonkeyHotei says, he load tested the modules Jul 30 06:20:32 [06:59] functionality of the modules themselves not tested, though Jul 30 06:20:34 [06:59] but they do load Jul 30 06:20:39 now this patch adds lots of crypto foo, which he does not actually use himself, making me wonder why he even created the patch Jul 30 06:20:53 so I am inclined to NAK Jul 30 06:21:04 there is no one using that featuyres so why add it Jul 30 06:24:16 jow: obviously I fail(ed) to see how the values where set before Jul 30 06:24:52 the package is not new, nor are any of the enabled hashes Jul 30 06:25:04 fine then Jul 30 06:26:28 now, about this mt7530 strangeness... Jul 30 06:26:40 context Jul 30 06:26:52 jow: yes board_name == model name is fine Jul 30 06:27:20 edimax board with mt7620a and mt7530wu chips Jul 30 06:27:44 mkresin: I've also a slightly different proposal Jul 30 06:27:52 mkresin: so the situation is: https://pastebin.com/CXHqcB4u Jul 30 06:28:15 same problem as described in the https://dev.archive.openwrt.org/changeset/43200 commit message, but not the same solution Jul 30 06:28:23 jow: I'm still suprised that the code target/linux/brcm47xx/base-files/etc/board.d/01_detect doesn't work any longer Jul 30 06:28:29 mkresin: and I'd suggest to change it like: https://pastebin.com/EgPEQc3h Jul 30 06:28:46 i described it in more detail in this channel 45 min ago Jul 30 06:28:47 mkresin: it does, but it happens after preinit Jul 30 06:29:01 mkresin: and therefor it never wrote to sysinfo Jul 30 06:29:16 it overlaps with 01_sysinfo in functionality Jul 30 06:29:22 but thats due to historical reasons Jul 30 06:29:44 yes, and the purpose of 01_sysinfo was to unify the board detection stuff accross targets Jul 30 06:30:16 see the suggested change, it would move the "detection" part into 01_sysinfo Jul 30 06:30:28 and only leave the case switches by model / board id in 01_detect Jul 30 06:30:58 jow: perfect. way to early for me. didn'T scrolled enough and saw only the change to 01_detect Jul 30 06:30:59 after that we could theoretically also drop the ucidef_set_board_id / ucidef_set_model_name part Jul 30 06:31:14 since that defaults to copy from /tmp/sysinfo Jul 30 06:31:22 more specifically, if the "ephy1 fixup" code is allowed to execute, port 1 on the mt7530 chip is pegged to 10/100 while the rest all allow gigabit links, and if the PHY_DIS bits are set, _all_ ports are pegged to 10/100 Jul 30 06:32:54 the linux is talking to the wrong phy Jul 30 06:33:05 that's what i figured Jul 30 06:33:31 so in short "my board has the mt7530 cascade, one of the poorts is not getting gbit but stays on 10/100, this is the ext_phy port" Jul 30 06:33:43 is that what you are trying to tell us ? Jul 30 06:33:58 no, port 5 on the internal switch is the cascade Jul 30 06:34:40 then try to create one such nice sentence as i just did Jul 30 06:34:54 your commit msg linked above talked about lan2 on the linksys device, which according to the portmap is also port 1 on the mt7530 chip Jul 30 06:35:37 so the problem is the same in theory Jul 30 06:36:11 but why does setting PHY_DIS affect only the internal switch on linksys but the external on edimax? Jul 30 06:37:02 jow: the brcm47xx looks like a mess and I would be glad if you can make it looking less ugly Jul 30 06:37:14 jow: *brcm47xx board detection Jul 30 06:38:08 DonkeyHotei: setting it correctly ? Jul 30 06:38:18 one chips is mmio the other mdio Jul 30 06:38:32 so all changes to the internal one need to go via mmio others via mdio Jul 30 06:38:47 if your settings apply to the wrong chip then the wrong io routine is used Jul 30 06:39:38 i can see that, but both devices have all that in common, and bypassing the mmio code for ephy1 was your own solution Jul 30 06:41:57 well then fix it and make it dynamic Jul 30 06:42:10 you evidently already fully analyzed and understood the problem Jul 30 06:42:37 i understood _what_ is happening, but not _why_ Jul 30 06:43:51 it's as if the external chip responds to both mdio and mmio Jul 30 06:46:25 the per-device workaround is to simply remove the setting of the PHY_DIS bits, but there has to be a more generic way to handle the problem, since it's apparently inherited from a mediatek reference design Jul 30 06:49:28 mkresin: rmilecki: https://pastebin.com/vHZeA2it Jul 30 06:50:56 and sometime, in the far future we should straight out the sysinfo vs. board.json naming Jul 30 06:51:18 /tmp/sysinfo/board_name -> board/model ID, /tmp/sysinfo/model -> board/model Name Jul 30 06:54:09 jow: your patch failes to apply on top of master Jul 30 06:54:48 we should get rid of that board* detection... Jul 30 06:55:02 these devices are so old/unknonw I couldn't move that detection code into krenel Jul 30 06:55:36 github is awefully slow today Jul 30 06:55:42 mkresin: its probably whatespace broken Jul 30 06:56:03 blogic: they're probably busy replacing the infra with windows servers Jul 30 06:57:11 mkresin: try this one https://pastebin.com/raw/diH09FBF Jul 30 06:57:39 jow: is that correct? Jul 30 06:57:41 +boardtype="$(board_name)" Jul 30 06:57:42 rmilecki: I agree but right now I'd prefer to keep it as is and cleanup post-release Jul 30 06:57:45 rmilecki: yes Jul 30 06:57:53 thats the confusion I was talking about Jul 30 06:58:03 board_name reads /tmp/sysinfo/board_name Jul 30 06:58:36 which is isn't actually the board_name but rather some board_id, either a DT compatible string, some DMI data identifer, or a unique id number of some sort Jul 30 06:59:05 /tmp/sysinfo/model contains the actual human readable name, but has no generic accessor functions Jul 30 06:59:53 one more sec Jul 30 07:01:03 sure Jul 30 07:01:28 jow: Acked-by: Rafał Miłecki Jul 30 07:02:34 rmilecki: ideally the kernel would expose that somewhere, iirc there was that crappy /proc/diag in the past Jul 30 07:03:10 but I guess there is no choice other than switching to DT in the future so the situation will likely stay as is Jul 30 07:06:47 rmilecki: allright, will perform some runtime testing and merge + cherry-pick it later Jul 30 07:06:54 thx Jul 30 07:07:43 jow: thx Jul 30 07:28:43 hmm, apparently the hostapd build fails if only hostapd-common is selected Jul 30 07:29:47 https://pastebin.com/BVEbPUYy Jul 30 07:30:12 mkresin: :) Jul 30 07:30:21 you've touched it last it seems Jul 30 07:31:39 hehe, why should someone do something like that Jul 30 07:32:16 jow: but to be honest, doesn't really look related to the changes I've done Jul 30 07:32:30 https://github.com/openwrt/openwrt/pull/1193 Jul 30 07:32:33 looks correct Jul 30 07:32:45 but not sure if the fix is at the correct place Jul 30 07:32:58 will it break if hardening is on but LTO is not ? Jul 30 07:33:40 mkresin: only noticed it by accident while deslecting all the mac80211 related cruft manually Jul 30 07:33:48 mkresin: I overlooked hostapd-common and left it in place Jul 30 07:34:27 jow: yeah, it a dependency of hostapd*/wpad*/wpa-supplicant* and doesn't work/compile on it's own Jul 30 07:34:57 mkresin: I wonder if it should be converted into a HIDDEN:=1 package Jul 30 07:35:11 which is default n and simply selected by all of the hostapd utils Jul 30 07:35:23 but then there's more pressing things to do, just some idea Jul 30 07:35:41 jow: would make sense to me Jul 30 07:49:20 blogic: an additional data point: the ports do not go to 10/100 immediately upon setting the PHY_DIS bits, but some time later Jul 30 08:11:52 hello Jul 30 08:12:06 I have few problem with transmission on Lede, can anyone help me ? Jul 30 08:13:15 blogic: https://patchwork.ozlabs.org/patch/950549/ Jul 30 08:13:19 what change is requested there? Jul 30 08:13:31 f00b4r0: .... Jul 30 08:13:34 https://patchwork.ozlabs.org/patch/950547/ - same question Jul 30 08:13:36 no time sorry Jul 30 08:13:41 come back later Jul 30 08:13:54 blogic: these are two one-liners you dumped with the change you object to Jul 30 08:14:06 probably because you were too eager to slam it in my face Jul 30 08:14:08 fine i can merge the 2 patches Jul 30 08:14:09 f00b4r0: hey Jul 30 08:14:15 f00b4r0: ? Jul 30 08:14:27 f00b4r0: why so agro ? Jul 30 08:14:30 blogic: model name changes Jul 30 08:14:37 what can be wrong with those? Jul 30 08:14:47 i normally close whole series Jul 30 08:15:12 and not merge partial ones Jul 30 08:15:12 f00b4r0: try being a bit calmer, every time there is argue about your stuff ;) Jul 30 08:15:22 rmilecki: :-D Jul 30 08:15:23 f00b4r0: i've got my mtd patches accepted Jul 30 08:15:25 ok Jul 30 08:15:29 rmilecki: I saw that Jul 30 08:15:32 f00b4r0: i backported them to the OpenWrt master Jul 30 08:15:32 rmilecki: and find it very cool Jul 30 08:15:44 rmilecki: that's exactly what i used in v2 Jul 30 08:15:50 f00b4r0: you can use them and hopefully get your parser selected from DT Jul 30 08:15:58 oh, ok, let me check Jul 30 08:16:18 as for a parser I just tried to explain why i honestly believe it's a bad idea Jul 30 08:16:22 nobody available ? Jul 30 08:16:26 but maybe I'm wrong again Jul 30 08:16:56 i'm hypoglycemic, i need food. maybe that's why i'm edgy ;P Jul 30 08:17:01 bbiab Jul 30 08:18:47 nbd: the mac80211 is so far so good on mwlwifi Jul 30 08:19:09 f00b4r0: i'm looking at [PATCH v2 4/4] ramips: improve RBM11G partitioning Jul 30 08:19:21 f00b4r0: syntax is OK Jul 30 08:19:31 I have few problem with transmission on Lede, can anyone help me ? Jul 30 08:19:43 f00b4r0: but why do you have "RouterBoot" with "routerboot" and "routerboot2" subpartitions? Jul 30 08:19:54 this seems confusing... what is routerboot after all? Jul 30 08:19:56 rmilecki: "RouterBoot" is OEM name for the whole segment Jul 30 08:20:16 ok, then what about "routerboot" and "routerboot2"? Jul 30 08:20:23 routerboot and routerboot2 are carried over from ar71xx naming. I would personally prefer bootloader1 and bootloader2 or somesuch Jul 30 08:20:45 rmilecki: there is a ToC and there is no user for the new layout yet Jul 30 08:21:07 forget it, i wont beinvolved in this any longer, had my say Jul 30 08:21:28 the rbcfg tool calls them "regular" and "backup" Jul 30 08:21:40 naming is all over the place unfortunately Jul 30 08:22:40 f00b4r0: can we rename them to "bootloader1" and "bootloader2" or something like that? or would that break anything? Jul 30 08:23:15 rmilecki: i doubt it would break anything. This is purely decorative. The ones that aren't are "hard_config" and "soft_config", the latter being used by rbcfg in particular Jul 30 08:23:51 blogic: please ignore f00b4r0 if you have to ;) but try to answer me, just shortly Jul 30 08:24:01 blogic: can you see sth wrong with [PATCH v2 4/4] ramips: improve RBM11G partitioning Jul 30 08:24:27 except for maybe-confusing "RouterBoot" vs. "routerboot" vs. "routerboot2" names Jul 30 08:28:27 ok, I can see that blogic basically wanted mtd splitter to be used Jul 30 08:28:56 rmilecki: in my last email I explain why I think it's not a good idea Jul 30 08:29:13 i'm trying to follow :) Jul 30 08:29:16 ;) Jul 30 08:29:24 i'll go grab some food for real, bbiab Jul 30 08:35:24 f00b4r0: let me ask few questions to blogic and wait for his reply Jul 30 08:35:49 blogic: by using mtd splitter, did you mean it to handle "RouterBoot" partition? Jul 30 08:36:40 blogic: partitions inside "RouterBoot" seem like something static (bootloader + config + bootloader + config + bios), I don't think they can change Jul 30 08:37:20 blogic: so using fixed-partitions seems well justified Jul 30 08:38:10 blogic: also if it's just f00b4r0 said - that these partitions (bootlodaer, config, bios) don't have any magic header, it may be hard to detect them (assuming there is a reason for that in the first place) Jul 30 08:38:33 had my say Jul 30 08:38:40 spent too much time on this already Jul 30 08:38:55 and i am not getting into yet another discussion Jul 30 08:39:02 i naked it, mkresin naked it Jul 30 08:39:08 we explained over and over why Jul 30 08:39:11 end of story Jul 30 08:40:01 ok, I missed that discusion with explanation then Jul 30 08:40:24 in short, there are at least 2 layouts, one for ar71xx and one for ramips Jul 30 08:40:34 currently we use offsets and a userland tool Jul 30 08:40:39 so the magic is in userland Jul 30 08:40:48 this patch adds partitions that are not used Jul 30 08:40:52 err no Jul 30 08:40:56 magic is not in userland Jul 30 08:41:05 rbcfg looks for a partition named "soft_config" Jul 30 08:41:08 welcome to my ignore list Jul 30 08:41:08 there's no magic there Jul 30 08:41:17 * f00b4r0 shrugs Jul 30 08:41:19 so right now its a no-op Jul 30 08:41:24 and I'm the aggressive one Jul 30 08:41:31 rmilecki: if you feel its great, go ahead, you have commit access Jul 30 08:41:43 i can just say if i will merge it or not, cant stop you from doing so Jul 30 08:41:52 and frankly i dont really care Jul 30 08:42:32 f00b4r0: that's what happen when you step on blogic's toe once ;) Jul 30 08:42:40 *shrug* Jul 30 08:43:05 rmilecki: what gets me off is: I offer something that is correct to replace something that is not, and it seems it's still not good enough. Jul 30 08:43:40 ... to many Jul 30 08:43:50 f00b4r0: blogic: mkresin: anyone cares to e-mail/pastebin log from previous discussion regarding these partitiosn? Jul 30 08:43:55 rmilecki: also, I do not understand the "adds partitions that are not used" arguments. most of the partitions are not used anyway. no partition that defines the bootloader is used. The kernel partition itself is useless... So I'm not sure what's the argument here. Jul 30 08:44:16 blogic: ping - dnsmasq ubus question Jul 30 08:44:20 rmilecki: part is inside your beloved github Jul 30 08:44:24 ldir: sure Jul 30 08:44:32 DTS should be generic, not just OpenWrt specific. bootloader may use these partitions, so it's OK for me to have them defined in DTS Jul 30 08:44:57 f00b4r0: can you paste me a link to github discussion? Jul 30 08:44:57 oh I can tell you the bootloader does use these partitions Jul 30 08:45:04 I want to verify that Simon's upstreaming of your patch hasn't broken anything. Jul 30 08:45:10 rmilecki: moments Jul 30 08:45:14 ldir: it fixed something Jul 30 08:45:17 I can't work out what is the consumer of the stuff you added Jul 30 08:45:25 ldir: ustatusd Jul 30 08:45:36 rmilecki: https://github.com/openwrt/openwrt/pull/1185 Jul 30 08:45:47 ldir: its inside the packages feed Jul 30 08:45:51 rmilecki: please note that I initially thought a splitter could make sense, but now I have changed my mind Jul 30 08:46:02 ldir: i am using that for my band steering/load balancing daemon Jul 30 08:46:11 f00b4r0: ok, thanks, I've to get back to some work now, I'll try to lookat this today Jul 30 08:46:12 ... which is still needing a bit of final loving Jul 30 08:46:25 ah, ok Jul 30 08:46:26 i'm leaving tomorrow for holidays, so I hope I can find time today Jul 30 08:47:13 I'll go look :-) Jul 30 08:47:42 rmilecki: as for the bootloader use of the partitions: hard_config contains the model name, serial number, MAC address, and compressed ART. the bootloader uses that info (name, serial and MAC in particular) Jul 30 08:47:58 rmilecki: the soft_config part contains an equivalent of "uboot-env". Jul 30 08:48:10 ok, thx for the background Jul 30 08:48:13 np Jul 30 08:48:14 yw Jul 30 08:48:58 i have prepared a new patch with the bootloader sections renamed. let me know if I should submit it Jul 30 08:49:05 rmilecki: thanks for looking into this. Jul 30 08:58:09 KanjiMonster: thanks for the example about of compatible for RedBoot, worked like charm. Jul 30 08:58:33 rmilecki: hmm, it looks as if latest master does not initialize ethernet on the e3000 anymore Jul 30 08:58:44 rmilecki: still investigating whether its a problem with my own build Jul 30 08:59:04 rmilecki: thanks for 5e8b4be531778aa8b6783fa431e6dd3f2865c926, tested on routerstation. Jul 30 08:59:58 tmn505: np, I didn't actually know someone was looking for it :) Jul 30 09:00:27 tmn505: you may want to check https://patchwork.ozlabs.org/patch/950719/ Jul 30 09:00:35 but you probably already know how to use it Jul 30 09:00:52 rmilecki: false alarm, snapshot build works Jul 30 09:00:56 ok :) Jul 30 09:01:13 don't panic! :-) Jul 30 09:02:20 tmn505: yeah i did the same Jul 30 09:03:40 m4t: regarding interrupts, I'm also getting shared for all three interfaces. Jul 30 09:04:00 i spent like 12 hrs working on that crap yesterday Jul 30 09:04:08 i know what the issue(s) are, at least partly Jul 30 09:04:38 well the wifi works somehow. Jul 30 09:05:03 did You get any further with it? Jul 30 09:05:16 i tried replacing irq_domain_add_linear() with irq_domain_add_simple(), which lets you specify the base_irq (ATH79_PCI_IRQ_BASE aka 40). that just puts both ath9k cards at irq 41 instead of 40/41. i spent the majority of the time messing with the ar7100.dts trying to get interrupt-map to assign the correct irqs to the 3 pci slots (17, 18, 19). Jul 30 09:05:59 the openfirmware interrupt-controller parsing code in drivers/of/irq.c (of_irq_parse_raw) sees that pcie-controller@180c0000 node is itself an interrupt-controller, so it never attempts to parse the interrupt-map property :/ i tried lots of variations including a separate interrupt-controller node and subnode. no luck :( Jul 30 09:06:03 m4t: fun is it not ? :-) Jul 30 09:06:09 hahah Jul 30 09:06:09 rmilecki: for the sake of background: the reason why I'd like to see these DTSes fixed is: the original incorrect submission was made as the original author copy pasted code from RB750Gr3.dts (which is a board with bootloader reflashed to uboot), thinking it was canonical. I don't want that disease to spread further :) Jul 30 09:06:31 kind of. i took a video of me holding ctrl-z in my ar7100.dts editor... Jul 30 09:06:47 lol Jul 30 09:07:23 https://drive.google.com/file/d/197ARVShNCUf1db6Wdk01cqB9jU3tGg54/view?usp=sharing Jul 30 09:07:25 :( Jul 30 09:07:37 that was only a small section of what i tried Jul 30 09:07:53 i added debug printks to every part of the of/irq assignment code Jul 30 09:08:35 the last thing i tried was reverting int pcibios_map_irq() to something similar as ar71xx, where it just uses the static slot->irq mapping Jul 30 09:08:46 then got an oops about an ignored interrupt and went to sleep. lol Jul 30 09:09:09 meep Jul 30 09:09:26 so 4 hours of github and i managed to get from 138 -> 73 open PRs Jul 30 09:10:28 nice Jul 30 09:10:44 that's new kind of broom Jul 30 09:11:30 blogic: but yeah i held off on submitting that pr to "fix" the irq domains because i don't think that having both ath9k @ irq 12 (vs 40 + 41 in ar71xx) is correct... Jul 30 09:11:30 jow: for 18.06 if possible: e99f760235 and 5c2419b6f8. Thanks Jul 30 09:11:52 ermmm Jul 30 09:12:05 do the cards work ? Jul 30 09:12:12 coz this is an irq casacde on a cascade Jul 30 09:12:21 so mips IRQ maps to the intc Jul 30 09:12:24 yeah Jul 30 09:12:35 and a intc irq maps to the cascade inside the pci core Jul 30 09:12:37 do you think there's no difference? i didn't do any throughput tests Jul 30 09:12:50 so to be honest it might actually be correct Jul 30 09:13:04 irq mapping between static ar71xx and ath79 OF is very different Jul 30 09:13:19 good to know. hey well at least i gained some understand of interrupt-mapping and other devicetre fun Jul 30 09:13:19 the virtual -> physical numbers no longer correlate Jul 30 09:13:35 at least you see the benefit :-) Jul 30 09:13:51 trying to look on the bright side Jul 30 09:13:53 experience is what you get if you dont get what you set out to achieve :-D Jul 30 09:14:07 f00b4r0: picked Jul 30 09:14:15 jow: thanks! Jul 30 09:14:58 hmm. sysupgrade isn't working on a routerboard 493g. Jul 30 09:15:00 i'll do a fresh build based on that commit and some iperf tests to make sure there's not a regression then submit it then Jul 30 09:15:15 m4t: cool Jul 30 09:15:31 tmn505: oh i tested sysupgrade too. works fine w/the redboot parser patch Jul 30 09:15:44 tmn505: i think we should team up and get both boards supported in the same PR Jul 30 09:16:33 ubirmvol: error!: cannot find UBI volume "rootfs" Jul 30 09:16:33 error 19 (No such device) Jul 30 09:19:20 m4t: that's fine with me, will also do some test's, ping me tomorrow around same time about it. Jul 30 09:19:37 https://pastebin.com/WCmT1qrY Jul 30 09:22:00 rmilecki: applied ;) Jul 30 09:22:07 :) Jul 30 09:22:10 drivers/mtd/redboot.c:306:34: error: array type has incomplete element type 'struct of_device_id' Jul 30 09:22:20 from: http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/857/steps/images/logs/stdio Jul 30 09:22:25 oh my... Jul 30 09:22:33 i forgot 4.9 requites #include Jul 30 09:22:34 let me fix that Jul 30 09:22:37 ;) Jul 30 09:23:18 rmilecki: saw that in my mailbox, but that's not my target and device, I'm using it on ath79. Jul 30 09:24:04 tmn505: yeah if im awake ;/ Jul 30 09:25:23 m4t: what's Your tz? Jul 30 09:25:30 utc-4 Jul 30 09:26:56 idk if that should be redhat,redboot-partitions btw, i used { .compatible = "ecoscentric,redboot-fis-partitions" }, Jul 30 09:27:05 afaik redhat hasn't had anything to do with redboot for a while Jul 30 09:27:52 * ldir thinks it looks like rain/blogic merge bomb :-) Jul 30 09:27:52 idk tho Jul 30 09:28:43 recovered from a initramfs image Jul 30 09:29:34 Red Hat no longer maintain nor support RedBoot and have contributed both RedBoot and eCos to the stewardship of the Free Software Foundation (FSF). eCosCentric are now the sole commercial maintainers of both eCos and RedBoot. Jul 30 09:30:41 well, had similar thoughts, if rmilecki will send it upspstream then we'll see what mtd guys will think about it. Jul 30 09:31:10 m4t: tmn505: please send a patch for rename Jul 30 09:31:15 i'm ok with it Jul 30 09:31:21 rmilecki: ok is it in master? Jul 30 09:31:26 yes Jul 30 09:31:32 and should i include the missing header? Jul 30 09:31:36 rmilecki: sorry, I'm not going to be involved in that toxic discussion again. not for a patch that is at the moment a no op as there are no consumers for the partitions Jul 30 09:31:45 rmilecki: and especially not after all devs involved so far are either stupid, have no clue what they are talking or lack the iq to understand the brilliance of the contributors idea Jul 30 09:32:30 mkresin: i only asked you for a log ;) but I got a GitHub link now, which I think is what I need Jul 30 09:33:16 rmilecki: fyi - you are the fifth involved dev by now Jul 30 09:33:23 :D Jul 30 09:33:54 which wasn't meant as fun fact, considering the amount of wasted time Jul 30 09:35:42 rmilecki: okay i will rename the parser, add the header, and also rename target/linux/brcm63xx/dts/livebox-blue-5g.dts Jul 30 09:35:44 i was under the impression that the initial objection was mostly the syntax used. I thought that was solved by rmilecki's recent patch. Maybe I didn't understand. Jul 30 09:36:48 (i wouldn't have bothered resubmitting otherwise) Jul 30 09:46:15 is it okay to use my github email address? Jul 30 09:47:43 e.g. ...@users.noreply.github.com Jul 30 09:49:46 m4t: noreply? maybe not... ;) Jul 30 09:49:57 i think it's a forwarder Jul 30 09:50:07 why not just ust a proper e-mail? Jul 30 09:50:09 i'll use another e-mail. i just worry about spam Jul 30 09:50:11 *use Jul 30 09:50:33 yeah, in open source, your e-mail "leaks" easily Jul 30 09:52:20 i have a fancy new one i was intending to use for e.g. gpg keys, i'll use that Jul 30 10:00:34 m4t: sorry, had to rush out for something. I'll post here a link to my changes on top of master, after You'll send the rename to ecoscentric. Jul 30 10:00:54 ok, im working on that now Jul 30 10:09:27 blogic: thanks for your PR cleanup work. Jul 30 10:09:43 blogic: this one doesnt need the label "needs changes" anymore, does it ? https://github.com/openwrt/openwrt/pull/1054 Jul 30 10:11:17 hiho, anyone here uses samba4 + vfs_fruit for timemachine? If so what filesystem did you pick? Jul 30 10:14:11 m4t: using @noreply.... github.com emails is not possible, our repo server disallows pushing such commits Jul 30 10:14:18 jow: thx Jul 30 10:25:55 pogoplug v3 console dies, device is alive and reachable over network via ssh: https://pastebin.com/eMiFveGY Jul 30 10:30:43 rmilecki: okay i'm testing that it compiles on 4.9 then will submit the pr Jul 30 10:31:14 russell--: hm, the log you pasted looks complete? Jul 30 10:32:54 jow: it doesn't respond to the serial console Jul 30 10:33:04 ah, so no prompt after enter Jul 30 10:33:08 yeah Jul 30 10:35:16 i can force stuff to console from ssh-land Jul 30 10:35:44 that is, e.g. echo "HELLO IN THERE" > /dev/console Jul 30 10:35:54 comes out on the serial console Jul 30 10:36:30 [ 0.000000] console [tty0] enabled Jul 30 10:36:54 seems to be sending to a non-existent graphical console or something Jul 30 10:37:02 seems like i just don't have a shell Jul 30 10:37:14 oh Jul 30 10:37:22 i should dust off my pogoplug pro ;/ Jul 30 10:37:57 /dev/tty ? Jul 30 10:38:15 pidof ash gives me one pid, presumably attached to the ssh session Jul 30 10:38:59 jow: found a bug related to the 18.06 branch, the e2fsprogs change regarding libss/comerr was merged, but not the fixed krb5 package. Without the fixed krb5 package those libs will break and potentially any package using them. Jul 30 10:39:20 * russell-- is doing a dirclean world build, will try that before i get too excited Jul 30 10:41:11 i used it for a while back when it was stuck on 3.x without the new devicetree stuff. basically arch/arm/mach-oxnas or whatever compied from vendor kernel: https://app.box.com/v/squeezeplug Jul 30 10:41:25 copied* Jul 30 10:41:31 So 18.06 should pick the latest krb5/master version as well. Jul 30 10:44:51 andy2244: do you happen to have the missing sha? Jul 30 10:44:57 *missing commit sha# Jul 30 10:45:08 63ce209dea142c13ccdcc4feeec10eafe54a4d00 Jul 30 10:45:28 but wait a minute trying to build krb5 with 18.06 and get a error still Jul 30 10:45:46 even with master version, need to-do a clean rebuild Jul 30 10:46:03 -v Jul 30 10:47:42 no better Jul 30 10:47:57 * russell-- will file a bug Jul 30 10:58:48 jow: oki something is still bugged, if i recompile e2fsprogs before krb5 manually all works, but not for a normal make with my current config. It seems some other package might still break comerr, will try to find the bugger. Jul 30 11:18:53 jow:ping Jul 30 11:25:52 dedeckeh: pong Jul 30 11:26:51 jow:do you have any objection against backporting https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1bad852ff597fd0535e02703f0c4b83447aaff45 to 18.06 ? Jul 30 11:27:07 dedeckeh: I thought I already did Jul 30 11:27:11 but if not, feel free to Jul 30 11:27:51 jow:just checked it as the dnsmasq patch was backported but I was missing this patch Jul 30 11:29:19 jow:just pushed it Jul 30 11:33:36 * ldir has a nervous twitch every time dnsmasq is mentioned :-) Jul 30 11:36:33 ldir: i'll pick up my dhcp-tools work shortly Jul 30 11:39:19 jow: https://github.com/openwrt/luci/blob/63fbf5a805085f7ad99aebaaa116e3096fcf792d/modules/luci-base/Makefile#L46 needs a mkdir above it Jul 30 11:41:17 ldir:no reason to press the dnsmasq panic button :) Jul 30 11:42:14 blogic:I had a look to your netifd patch before my holidays Jul 30 11:42:43 blogic:I noticed it won't cover all scenarios Jul 30 11:43:34 blogic:therfore I staretd with an initial cleanup https://git.openwrt.org/?p=project/netifd.git;a=commit;h=263631ae5a22daa90743d9758f44f1df109dc990 Jul 30 11:43:40 *started Jul 30 11:45:22 blogic:the check should be moved to device_set_ifname Jul 30 11:46:10 and all functions calling device_set_ifname need to check the return code which is currenlty not the case Jul 30 11:46:42 when I find time I will rework this further Jul 30 11:48:54 jow: oki krb5 builds/installs now (had to correctly reinstall the package), so you can pick: https://git.openwrt.org/?p=feed/packages.git;a=commit;h=63ce209dea142c13ccdcc4feeec10eafe54a4d00 Jul 30 11:49:18 dedeckeh: appreciated Jul 30 11:50:10 rmilecki: just fyi, wl.ko still appears to work fine, even in ap/sta mode Jul 30 11:50:23 can't test more advanced stuff like wds due to lack of a 2nd device Jul 30 11:50:53 iwinfo needs some fixes to properly query info though Jul 30 12:07:39 https://github.com/openwrt/openwrt/pull/877 Jul 30 12:07:46 i am considering to tell him to add a target feed Jul 30 12:08:46 blogic: hm why? Jul 30 12:09:03 to me this target looks very lightweight, almost no kernel aptches, jsut DTSes etc. Jul 30 12:09:15 ok, fine with me, i'll merge it Jul 30 12:09:21 we had worse, even more obscure stuff in the past Jul 30 12:09:33 *cough* arc *cough* zynq *cough* Jul 30 12:09:34 if we dont get kernel bumps from him in future i'll drop it again Jul 30 12:10:16 yeah, sounds sane to me Jul 30 12:10:29 if this target does not meet the target kernel of the next stable, it'll become source only Jul 30 12:10:40 if it is still nto updated after that, we'll drop it Jul 30 12:16:07 oh wow, chinese "symbols" as the name of the last 3 18.06 commits :D Jul 30 12:16:12 *author name Jul 30 12:18:36 jow: takes on this one -> https://github.com/openwrt/openwrt/pull/622 Jul 30 12:19:18 blogic: personally I am strictly against such partial, arbitrary preconfig solutions Jul 30 12:19:29 either use uci-defaults / files overlay Jul 30 12:19:40 or supply a custom base-files fork with PROVIDES:=base-files Jul 30 12:19:52 thanks to neoraider's metadata rework this is now easily doable Jul 30 12:20:02 i was just looking at that one Jul 30 12:20:18 kimda pointless Jul 30 12:20:28 i'll paste that as my excuse to close the PR :-) Jul 30 12:20:37 please be gentle Jul 30 12:20:56 I can see why someone needs that but either completely or not at all Jul 30 12:21:31 please use either use uci-defaults / files overlay or supply a custom base-files fork with PROVIDES:=base-files ~ ~ Jul 30 12:21:37 Jul 30 12:21:40 i'll use that Jul 30 12:22:05 I /think/ the intention is to customize the default behaviour solely with .config Jul 30 12:22:10 provides huh Jul 30 12:23:37 jow: --> https://github.com/openwrt/openwrt/pull/1193 Jul 30 12:23:58 looks technically correct, but i know that part of the build system too little to know if is the right place/fix Jul 30 12:24:30 is hardeded pie specs from us or from upstream? Jul 30 12:24:47 blogic: no opinion on that. Whenever I see keywords like ASLR, LTO or other random cflag tuning I quickly run away, this usually results in random build breakage somewhere Jul 30 12:25:00 jow: correct Jul 30 12:25:17 karlp: you tell me Jul 30 12:25:21 * karlp shrugs Jul 30 12:25:33 blogic: but that specific change looks reasonable Jul 30 12:25:33 I can't even get lto to work well :) let alone aslr Jul 30 12:25:46 people merge this stuff and then disappear randomly and leave us to fix stuff up Jul 30 12:26:41 jow: i am expecting a little breakage from all the merges i am making right now Jul 30 12:26:42 rmilecki: heh i think i did it right https://github.com/openwrt/openwrt/pull/1220 Jul 30 12:26:56 * m4t 's first PR Jul 30 12:27:21 blogic: the PR is okay, had the "need -fPIC for ld" when building with -flto recently too when experiemnting with Lua and LTO Jul 30 12:27:57 worst case its a no-op Jul 30 12:31:32 [Sun 2018-07-29 11:41:57 PM PDT] well then fix it and make it dynamic <------ regarding the making it dynamic part, RFC: https://pastebin.com/dkV1Hdfu Jul 30 12:31:39 ok who busted redboot Jul 30 12:32:05 hmm samsung/s5pv210, interesting. i actually just dug my samsung epic 4g out of storage to play with the new upstream kernel support. was going to do postmarketos but maybe i'll do openwrt instead ;) Jul 30 12:32:26 OutBackDingo: my PR fixes the build error on 4.9 Jul 30 12:32:40 https://pastebin.com/5c5wrNWs Jul 30 12:33:01 just needs #include Jul 30 12:33:09 OutBackDingo: according to the ML, it's more "who busted ath10k-ct" Jul 30 12:33:12 in drivers/mtd/reboot.c Jul 30 12:33:25 right... just pulled will rebuild Jul 30 12:33:43 its not merged yet Jul 30 12:34:30 DonkeyHotei: Jul 30 12:34:42 change it to gsw->mdio_mode Jul 30 12:35:00 I busted ath10k-ct, will look into it Jul 30 12:35:01 no other comments? Jul 30 12:35:11 now I know again why I never merge PRs Jul 30 12:35:18 it always fails Jul 30 12:35:27 jow: tell me about it Jul 30 12:35:43 make them rebase and update pr Jul 30 12:35:57 jwh: "how do I rebase an update a PR" ? Jul 30 12:36:30 heh Jul 30 12:36:40 DonkeyHotei: and fully annotate it and send it as a patch on the ML Jul 30 12:36:52 to be fair it didn't occur to me that the ath10k patches would break ath10k-ct Jul 30 12:37:01 which is not overly surprising in hindsight Jul 30 12:37:50 blogic: i see two potentials for breakage here, one existing and one new, and i do not have the hardware to test (linksys e1700 and dovado tiny-ac) Jul 30 12:38:04 i have a e1700 Jul 30 12:39:36 blogic: on a current snapshot on the e1700, do all ports get a gigabit link out of the box? because the mdio phy entries 0-4 in the dts are what nuke things on the edimax when PHY_DIS are set Jul 30 12:40:19 no idea Jul 30 12:42:07 can I subdivide for example network config file in several files with something like "import" as seen in other config systems? Jul 30 12:42:19 for that device, it's a simple test. for the dovado board, idk why the mt7530 property is in the dts, since by all accounts, the chip is not present there Jul 30 12:42:21 guifipedro[m]: not right now Jul 30 12:42:27 hrm, quick question, so my PR has 2 commits, one for kernel: and one for brcm63xx:. should i edit the title of the PR to kernel: or does it matter? Jul 30 12:42:36 DonkeyHotei: copy pasta Jul 30 12:43:05 from my understanding the PR text doesn't wind up in git does it? just the individual commits? Jul 30 12:43:07 m4t: just use the ML and you wont have such an issue Jul 30 12:43:13 lol Jul 30 12:43:28 according to the trac archive, though, the copy pasta was from a dts that did not have the property Jul 30 12:44:09 idk there's no edit / preview button on the ML Jul 30 12:44:57 you can't force-push to amend a commit on the ML, either Jul 30 12:45:04 m4t: tbf You are missing only SoB line in commit messages, everything else looks okay. Jul 30 12:45:30 hmm Jul 30 12:45:52 i thought that was added during merge or something Jul 30 12:46:13 m4t: it's the -s option to git commit Jul 30 12:46:26 DonkeyHotei: oh ok Jul 30 12:47:16 can you just add it in the editor too? Jul 30 12:47:30 its just part of the commit message yeah? Jul 30 12:47:58 yeah, I just type it by hand Jul 30 12:48:28 ok i'll fix that, gotta figure out how though Jul 30 12:49:34 git commend --amend && git push -f Jul 30 12:52:21 since its 2 im doing rebase Jul 30 12:53:01 or that :) Jul 30 12:55:10 cool Jul 30 12:55:12 blogic: if the mdio-bus entries 0-4 in the e1700 dts turn out to cause all the ports on that device to be pegged to 10/100 on current master/18.06 also, then that's an existing regression Jul 30 12:55:19 it automatically changed the PR after i did the push --force Jul 30 12:55:27 fancy Jul 30 13:11:34 ok question, whats everyone using for DPI these days ? still nDPI ? Jul 30 13:26:03 blogic: can you quickly test a current snapshot or rc on the e1700 by plugging all ports into a gigabit switch and checking "swconfig dev switch1 show" output? Jul 30 13:26:11 nope Jul 30 13:27:08 then if the regression is there, it'll probably have to stay Jul 30 13:29:08 DonkeyHotei: i'll test it tomorrow Jul 30 13:29:35 jow: https://github.com/openwrt/openwrt/pull/1198 Jul 30 13:29:43 i'd remove the quotes Jul 30 13:32:38 blogic: OK, and if the ports are all 100Mb/s, try this https://pastebin.com/1fRSAzz8 Jul 30 13:32:53 blogic: had to write a response to the contact@ mail first Jul 30 13:33:22 jow: ? Jul 30 13:33:24 blogic: yeah Jul 30 13:33:28 ah ok Jul 30 13:33:33 i need to mail realtek Jul 30 13:33:37 blogic: "LEDE security question" Jul 30 13:34:00 we're insecure and underminded by state level cyber terrorists because we're democratic Jul 30 13:34:06 or something like that Jul 30 13:34:24 15.05 is secure because it only had a few comitters Jul 30 13:34:42 * jow blames the heat Jul 30 13:34:57 jow: chemtrails /// Jul 30 13:35:05 haarp Jul 30 13:35:15 mind control kittens Jul 30 13:35:18 flouride in the water Jul 30 13:35:41 microwave antennas on the cellphone network Jul 30 13:35:59 frequencies that make the water in our bodies oscilate Jul 30 13:37:44 precious bodily fluids... Jul 30 13:37:47 soooo Jul 30 13:37:50 tag time? Jul 30 13:38:14 * jow finally wants to get over with it and stop doing openwrt for a few days Jul 30 13:38:30 jow: where is that nice topic? Jul 30 13:38:56 jow: sounds like a plan Jul 30 13:40:36 jow: did you catch my notice or should i open a backport PR? https://git.openwrt.org/?p=feed/packages.git;a=commit;h=63ce209dea142c13ccdcc4feeec10eafe54a4d00 Jul 30 13:41:33 hmm. build fails at -j32 but not at -j1 Jul 30 13:42:26 wigyori: seems you aren't even part of the fun yet. There's this contact@ mail address which simply will forward to all committers Jul 30 13:42:31 wigyori: ill update the subscriber lsit Jul 30 13:42:38 jow: thanks :) Jul 30 13:42:51 wigyori: forwarded the mail in question Jul 30 13:45:42 thx Jul 30 13:45:52 ldir: ping Jul 30 13:46:46 huaracheguarache: pong Jul 30 13:48:03 I see a commit in your staging tree that switches archer to mips 74kc type. That's what it's supposed to be, right? Jul 30 13:49:05 the mips core in that soc is 74kc yes, but will happily run code for 24kc Jul 30 13:49:42 does it have much of an impact on performance? Jul 30 13:50:48 there was a commit AGES ago to rationalise the architecture types. Jul 30 13:52:17 I doubt it has that much difference. I've not measured. It's for my own personal OCD scratching ;-) Jul 30 13:52:28 heh, ok Jul 30 13:54:35 well, it was done to reduce the builders duplication of things that were being treated (at the time) identically by the compiler. Jul 30 13:54:51 wigyori: ldir: added you both to contact@lede-project.org Jul 30 13:55:01 so don't wonder if you see mails from that address Jul 30 13:55:05 :) Jul 30 13:55:28 added koen and kaloz too, they've been both missign as well Jul 30 13:55:48 when you respond, consider putting contact@ into Cc so that the others see it Jul 30 13:56:13 there's rarely useful mail there, jsut some "help I bricked my router" and random brazilian or chinese inquiries Jul 30 13:57:03 if you do not wish to receive mail from there anymore then tell me and I'll remove you Jul 30 13:57:47 karlp: understood Jul 30 13:58:15 * ldir dies laughing at the email just received. Jul 30 14:07:46 ldir: but only because you're the organized crome group! Jul 30 14:07:51 *crime Jul 30 14:08:30 andy2244: seen it, lookgin into it now Jul 30 14:10:34 andy2244: that referenced commit is just a minor version bump? Jul 30 14:11:17 yes the actual change was 1/2 commits before it, but we should grab the latest version as well. Jul 30 14:11:41 I'll pick and squash these: Jul 30 14:11:49 8256b9674 krb5: update to 1.16.1 Jul 30 14:11:49 536d55545 krb5: set replay cache directory to /tmp Jul 30 14:11:49 ebc41d575 krb5: update depends, adapt FS#1310 Jul 30 14:12:04 yup those 3 Jul 30 14:13:00 gninrom Jul 30 14:15:48 terrible hot outside today... Jul 30 14:16:40 andy2244: was too lazy to sqush, simply icked those three separately Jul 30 14:16:56 I hope new release will be soon :-) Jul 30 14:17:30 jow: thanks again Jul 30 14:34:22 my head is starting to hurt after processing 80+ PRs :-D Jul 30 14:36:53 jow: https://github.com/openwrt/openwrt/pull/864 Jul 30 14:37:07 jow: do you know how the metadata voodoo works ? Jul 30 14:38:19 blogic: Stop headbutting the PRs :) Jul 30 14:40:48 blogic: I know Jul 30 14:41:44 blogic: the hook is supposed to run a function which strips the metadata prior to writing it to flash Jul 30 14:42:14 mkresin: yes Jul 30 14:42:29 mkresin: i think i'll need to manually review the platform.sh code Jul 30 14:42:39 and then we might just want to risk it i guess Jul 30 14:42:41 blogic: but the image file isn't passed to the function, and the fwtool call misses the option to remove the metadata Jul 30 14:43:32 oh look shiny new feature Jul 30 14:43:43 long story short, never worked and a decission need to be made if we fix it or drop the code at all Jul 30 14:44:18 well, apparently it does not harm having the metadata as a random blob in flash Jul 30 14:44:28 i vote for just dropping the pre hook Jul 30 14:44:38 anyone wanna second that notion ? Jul 30 14:45:04 jow: question about best way to do things: do we always want to define the switch in 02_network when there is one, even if all ports are assigned to e.g. LAN? Jul 30 14:45:09 for reference: https://github.com/openwrt/openwrt/blob/5660c8fb20d056eac495647bb1116883f269ed8d/target/linux/ar71xx/base-files/etc/board.d/02_network#L187 Jul 30 14:45:42 a couple RB boards have been added like that, and this applies to a lot more, however I'm not sure it's such a good idea, performance-wise? Jul 30 14:47:16 blogic: drop it Jul 30 14:47:52 beside of image rootfs+kernel images, it will get purged on preparing the rootfs overlay anyway Jul 30 14:56:17 f00b4r0: if there is a switch which is fully supported and user configurable, then add it Jul 30 14:56:38 jow: even though it apparently forcefully turns on VLAN ? Jul 30 14:56:42 f00b4r0: if its one these "better don't touch" kind of switches that onyl work because the bootloader programmed them but no driver support exists, then don't Jul 30 14:56:53 oh no, it's of the working configurable variety Jul 30 14:57:33 is there any downside in forcefully turning on vlan ? Jul 30 14:57:51 If there's a performance impact I can't see it being large Jul 30 14:57:57 ok then Jul 30 14:58:02 if the eth0 vs. eth0.1 is bothering then consider making the cpu port untagged Jul 30 14:58:09 by default Jul 30 14:58:16 can this be done in 02_network? Jul 30 14:58:29 yeah, using the "u" suffix Jul 30 14:58:39 e.g. 0u@eth0 or 5u@eth1 Jul 30 14:59:00 ah nice Jul 30 14:59:03 will test Jul 30 14:59:06 right away Jul 30 15:00:53 /etc/board.json should then have a `want_untag: true` member for the cpu port and the generated /etc/config/network should be something like option ports "0 1 2 3 4 5" Jul 30 15:01:29 if that works I'll want to fix that line I highlighted and move a couple boards Jul 30 15:01:48 probably good to get that in 18.06 if possible since these boards are currently "snapshot only" Jul 30 15:02:00 modern luci is smart enough to promote this vlan to tagged (and to migrate eth0 to eth0.1) if a user adds another vlan in the gui Jul 30 15:02:01 (to avoid having network iface change across releases) Jul 30 15:02:09 cool! Jul 30 15:02:16 on the cli, the user has to take care of that manually Jul 30 15:02:23 makes sense Jul 30 15:03:00 that once was the reasoning for shipping tagged by default, even if there's only one vlan Jul 30 15:03:17 since it makes adding another one less error prone. Most people forget to change the lan netdev Jul 30 15:05:05 ok, testing now Jul 30 15:08:41 it appears to work Jul 30 15:09:00 "Enable VLAN functionality" is on by default in Luci Jul 30 15:09:04 and shows up in swconfig as well Jul 30 15:09:15 but the iface is eth1 (not eth1.1) Jul 30 15:09:59 "want_untag": true Jul 30 15:10:16 option ports '1 2 3 4 0' Jul 30 15:10:23 jow: looks like what you were expecting? Jul 30 15:10:40 config switch has "option enable_vlan '1'" Jul 30 15:11:13 yes, looks okay Jul 30 15:11:42 "option enable_vlan" can be read as "swconfig, parse me" Jul 30 15:12:05 ok Jul 30 15:12:18 i'll send you a quick 18.06-only fix Jul 30 15:14:16 jow: not moving any board for 18.06, just using "u", seems more prudent. Jul 30 15:16:30 jow: that pattern (ucidef_set_interfaces_lan_wan "eth1.1" "eth0") is found many times in 02_network. Do you want me to change all occurrences to untaged or just the ones for the routerboard I spotted? Jul 30 15:19:24 f00b4r0: tagged by default is to make it harder to lock yourself out when trying to use vlans to separate the ports (since you can't forget to switch lan to use the tagged interface) Jul 30 15:19:30 f00b4r0: hmm, I'd rather do the cleanup globally and defer it until after .0 - we can target .1. Its a little bit too last minute for my taste Jul 30 15:20:18 jow: sure. for the routerboards they aren't in any release yet. I'm concerned about the implications of changing the interface name for LAN across release points... Jul 30 15:20:29 i.e. won't it break anything? Jul 30 15:20:43 KanjiMonster: ack. jow just pointed out Luci got smarter about this :) Jul 30 15:21:51 f00b4r0: the implications for changing them 5 minutes before tagging are equally high. For a point release we at least have enough time to review and watch out for regressions Jul 30 15:22:26 f00b4r0: (ucidef_set_interfaces_lan_wan "eth1.1" "eth0") is (misused) a lot in the tree. it is expected that ucidef_add_switch sets the correct lan interface Jul 30 15:22:32 jow: oh I agree, that's why I asked if I should limit my change to that setup that matches the 4 RB devices Jul 30 15:22:49 f00b4r0: ucidef_add_switch + ucidef_set_interface_wan is way cleaner Jul 30 15:24:14 what's the command to re-parse etc/board.d ? Jul 30 15:24:31 rm /etc/config/network; config_generate Jul 30 15:25:56 f00b4r0: limiting it to only the RBs would add special cases I'd rather like to avoid - previous refactoring of that file for ar71xx commonly led to a handful of broken boards and it's not readily apparent to users who upgrade while keeping configs Jul 30 15:26:16 so my plan is: defer until .1 but do a full conversion Jul 30 15:26:18 reasoning: Jul 30 15:26:23 makes sense Jul 30 15:26:41 - changing netdev defaults is equally "bad" now or for a point release Jul 30 15:26:41 ucidef does seem to do the right thing indeed Jul 30 15:26:58 - but for a point release we do have time to do it properly (and its due in 3-4 weeks already) Jul 30 15:27:48 jow: a one-liner that moves a board from switch-undefined to switch defined, would that be ok? Jul 30 15:27:51 - with the additional time we can do a proper conversion, including set_lan_wan cleanup Jul 30 15:28:29 f00b4r0: can you pastebin it, quickly? Jul 30 15:28:34 sure, seconds Jul 30 15:30:00 https://pastebin.com/Mg2Cq5P6 Jul 30 15:30:22 I could probably move the rb-951ui-2hnd but I don't own the hw to test Jul 30 15:31:48 could live with that one for now Jul 30 15:31:52 ok :) Jul 30 15:32:04 sending it to m-l? Jul 30 15:32:29 yeah, will pick it from there. That'll be the last one, I'm going to tag Jul 30 15:32:38 thanks! Jul 30 15:32:49 rmilecki: you're through? Jul 30 15:38:01 jow: sent Jul 30 15:44:38 blogic: ping Jul 30 15:45:24 blogic: 5660c8fb20 ("ar71xx: TL-WR1043N v5: fix mapping of LAN ports to labels on housing.") looks wrong Jul 30 15:45:38 it renumbers the ports for all boards, not only the wr1043n v5 Jul 30 15:46:08 true Jul 30 15:46:10 let me fix it Jul 30 15:56:53 mkresin: so apparently with the current ucidef both eth1 and eth1.1 exists, and they're both assigned to the lan bridge. Dunno if that matches your expectation Jul 30 16:00:47 f00b4r0: looks wrong. should be eth1 XOR eth1.n Jul 30 16:01:40 f00b4r0: mind to link me to code we are talking about. might be some special case Jul 30 16:02:02 mkresin: https://github.com/openwrt/openwrt/blob/5660c8fb20d056eac495647bb1116883f269ed8d/target/linux/ar71xx/base-files/etc/board.d/02_network#L187 Jul 30 16:03:15 f00b4r0: to be honest, I fail to see where the eth1 on the bridge comes from Jul 30 16:03:32 i suppose it's anyone's guess Jul 30 16:06:04 f00b4r0: looks correct Jul 30 16:06:34 jow: ok. I suppose a positive side effect is that it should make the transition to untag easier Jul 30 16:06:49 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=73d923ed6baabe3f8844f13216c50a6383a79a46 Jul 30 16:06:52 since the untagged iface is already a member Jul 30 16:07:13 ucidev_add_switch only wants the base netdev Jul 30 16:07:20 vlan tags are added as needed Jul 30 16:08:11 i see the second "-" in that commit message works both ways :) Jul 30 16:08:31 no Jul 30 16:08:41 ? Jul 30 16:08:57 personally I think that migrating back to untagged by default will complicate additional vlan setup Jul 30 16:09:12 its simple for luci users, bot not for cli ones Jul 30 16:09:48 oh. So the cleanup we just discussed is not desired? Jul 30 16:10:01 * f00b4r0 is confused again Jul 30 16:10:18 *I* do not desire it Jul 30 16:10:32 but I can see that not taggin when having only one vlan is desired Jul 30 16:10:50 esepcailly since it unclutters the (default) configuration Jul 30 16:11:08 and since it was the default in the past and since luci can handle it nowadays, I personally do not care too much about it Jul 30 16:11:44 my only requirement is that it happens globally and coordinated Jul 30 16:12:29 sounds like another opportunity for me to step on someone's toes. I think it's fine the way it is ;P Jul 30 16:12:55 I'll just submit a patch moving the other rb devices to correctly defined switch Jul 30 16:13:14 its 50 / 50 anyway Jul 30 16:13:35 while that move to tagged by default cleaned up some boards, orther configurations started to look odd Jul 30 16:15:31 that can of works will get even larger in the future with the pending move to dsa Jul 30 16:15:38 *can of worms Jul 30 16:15:42 *nod* Jul 30 16:15:55 because does everything different, only worse :) Jul 30 16:22:13 dammit, just after I'd got pwclient installed to try out patchwork-apply..... someone goes and commits the patch anyway Jul 30 16:22:57 lols Jul 30 16:22:58 shall I send a patch adding some fancy ascii art to dnsmasq.init ? :) Jul 30 16:23:08 jow: please drop that 18.06 patch I sent. Device behavior seems erratic. I don't know if it's related but let's not take chances. Jul 30 16:23:52 f00b4r0: eth1 and eth1.1 on the lan bridge is impossible with https://github.com/openwrt/openwrt/blob/5660c8fb20d056eac495647bb1116883f269ed8d/target/linux/ar71xx/base-files/etc/board.d/02_network#L187 Jul 30 16:23:53 jow: no, 'cos that might be the thing that makes it sentient...and then we've Skynet. Jul 30 16:24:13 mkresin: sorry I was looking at a 17.01 device Jul 30 16:24:17 should have mentioned Jul 30 16:24:45 f00b4r0: ahh. that makes sense, as the commit mentioned by jow isn't included Jul 30 16:24:53 f00b4r0: 'k - I'll revert Jul 30 16:25:06 jow: thx. Sorry for the noise. Jul 30 16:30:00 mmm, guess I should send my other patches Jul 30 16:30:17 just in case anybody wants the Jul 30 16:30:19 m Jul 30 16:32:12 * [new tag] v18.06.0 -> v18.06.0 Jul 30 16:32:19 kicking the builders now Jul 30 16:32:28 yay Jul 30 16:32:41 oh nooos. just one more patch! ;-) Jul 30 16:32:42 'grats! Jul 30 16:32:58 ldir: ;^) Jul 30 16:32:59 I am sure we overlooked something very important, but I plan to be far away before anyone notices Jul 30 16:33:07 hehe Jul 30 16:33:14 lol Jul 30 16:33:49 I feel left out, my nice fw3 patch didn't make into release Jul 30 16:33:52 :d Jul 30 16:33:53 :D Jul 30 16:34:05 jwh: next time, I promise Jul 30 16:34:12 :D Jul 30 16:34:19 a number of pending uhttpd and iwinfo patches are on the list as well Jul 30 16:34:36 thats ok, you can do the follow up one(s) too :D Jul 30 16:35:59 tmn505: i added your tree to mine as a remote and cherry-pick'd that rspro commit. i was planning on submitting a pr to your branch or something that makes a generic routerstation entry in the generic-ubnt.mk that both rs and rspro can $(Device/ubnt_routerstation). reuses most stuff aside from model name and packages. Jul 30 16:36:17 that's actually what i've been using for a few days now Jul 30 16:37:57 or i can just show you what i did via pastebin or something, idc Jul 30 16:49:09 well that's new. dropbear won't start. What did I break again Jul 30 16:50:16 explicit listen address that doesn't exist due to ryou tagged/untagged fiddling? Jul 30 16:50:57 karlp: well I started from scratch (wiped device installed clean image). Odd thing is, nothing in the syslog Jul 30 16:51:20 was just an idea :) Jul 30 16:51:38 I must have gone fat fingered somewhere Jul 30 16:52:02 methinks I'm gonna wait for that official 18.06 sysupgrade image. And use that :) Jul 30 17:49:07 rmilecki: I think b43 will also work on e3000 and wrt610n devices but only in ieee80211g mode Jul 30 17:50:06 In my experience, this is correct. (Also, the 5gHz adapter is not supported.) Jul 30 17:52:04 doesn't 5GHz also work since some years? Jul 30 17:54:28 It didn't work when I tried it, but that has been several years now. I don't use the WiFi on those devices anymore. Jul 30 18:06:05 jow: ping Jul 30 18:08:02 Borromini: o/ Jul 30 18:08:59 stintel: hey Jul 30 18:09:45 how goes :) Jul 30 18:10:15 ldir: .59 bump fails again for me Jul 30 18:10:31 mangix: in what sense? Jul 30 18:10:52 CONFLICT in a ipq4440xx patch Jul 30 18:10:57 oh Jul 30 18:11:24 i am running .59 just fine so far on 18.06 but i assume you're talking about master Jul 30 18:11:30 i am Jul 30 18:11:37 blogic went on a rampage Jul 30 18:12:19 hehe Jul 30 18:12:29 doesn't surprise me, there was a conflict during a rebase.... fixing patches of patches is never easy. Jul 30 18:12:42 mangix: me what ? Jul 30 18:13:14 Borromini: back from holiday. so much work, so little time Jul 30 18:13:27 blogic: lots of stuff merged Jul 30 18:14:00 stintel: sounds familiar. where did you go off to? Jul 30 18:14:05 Borromini: Croatia Jul 30 18:14:11 nice :) not too busy? Jul 30 18:14:29 mangix: ah ok Jul 30 18:14:30 Borromini: could be worse :) Jul 30 18:14:45 anyway, need to run to the supermarket before it closes Jul 30 18:14:54 3x pizza in 24h would be too much :P Jul 30 18:15:27 :D :D Jul 30 18:16:38 I could do with a holiday Jul 30 18:16:50 this european weather is more work than holiday Jul 30 18:17:06 should have stayed in the UK this week :D Jul 30 18:17:33 isn't the uk having hot weather a s well? Jul 30 18:17:39 Not as hot Jul 30 18:17:42 dipped over the weekend Jul 30 18:17:46 (but still really hot for us) Jul 30 18:17:46 climbing end of the week though Jul 30 18:17:56 Monkeh: 33 here today, 35 tomorrow :( Jul 30 18:18:03 humid as fuck too Jul 30 18:18:05 jwh: Haw haw. Jul 30 18:18:05 well was supposedly like 26° C in Belgium as well, on saturday Jul 30 18:18:14 went to get a kfc, nearly died Jul 30 18:18:16 thirties again today, and humid as well Jul 30 18:18:26 jwh: that's what fast food gets you Jul 30 18:18:29 haha Jul 30 18:18:44 I'm not sure my stomach can handle the local cuisine after the horrific plane food Jul 30 18:18:47 :D Jul 30 18:18:50 (and all the beer0 Jul 30 18:18:51 lol Jul 30 18:18:51 ) Jul 30 18:19:16 soviet beer kicked my ass, should have stayed with the western european beer :D Jul 30 18:19:32 you mean wodka? ;) Jul 30 18:19:42 lol no, not in russia Jul 30 18:19:45 czechia Jul 30 18:20:54 blogic: okay i did some runtime testing and both cards worked simultaneously ;) https://github.com/openwrt/openwrt/pull/1225 Jul 30 18:21:20 get to upgrade the firmware on all my routers this week, gonna be fun Jul 30 18:21:32 OOB and ilo ftw :D Jul 30 18:21:38 coz its gonna go horribly wrong Jul 30 18:21:47 i switched my APU2 from one image type to another... now it doesn't remember its settings anymore >_> Jul 30 18:21:50 brother wasn't too happy Jul 30 18:21:56 heh Jul 30 18:22:06 luckily i had some uci presets so at least his VLANs kept going Jul 30 18:22:27 I've got uh, ~120 interfaces on one of them :D Jul 30 18:22:50 so it better remember its config, otherwise I'm gonna have to arse about typing some of them in via ilo Jul 30 18:22:52 well either it's something in 18.06 (but that doesn't seem to be the case since all my ar71xx and mt7621 devices upgrade just fine), or it's an issue stemming from the combined-ext4 -> combined-squashfs switch Jul 30 18:23:05 oh, that has never worked properly for me Jul 30 18:23:25 switching back and forth between those? Jul 30 18:23:33 from ext4 to squash Jul 30 18:23:42 I had the insane idea of using ext4 originally Jul 30 18:24:05 me too. Jul 30 18:24:13 blogic: thx! Jul 30 18:24:14 regretted that huh? Jul 30 18:24:46 jwh: i didn't have issues with the ext4 image, but i figured squashfs should be more resilient... Jul 30 18:24:51 yeah Jul 30 18:24:58 so i switched, wiping configs with sysupgrade Jul 30 18:25:03 restoring a config tarball Jul 30 18:25:07 easy peasy, i thought Jul 30 18:25:08 I mostly switched to squash so it would be the same on all platforms Jul 30 18:25:08 but nope. Jul 30 18:25:15 yeah that as well Jul 30 18:27:42 i pushed upgrades last week and everything went fine, except for my brother's APU2, so... that's that :P Jul 30 18:28:08 i use squashfs on x86_64 and sysupgrade preserves configs Jul 30 18:28:29 DonkeyHotei: i believe the fact i switched images makes it choke somehow. Jul 30 18:28:50 combined-ext4 kept configs just fine as well for me, it just stopped once i switched to combined-squashfs... Jul 30 18:29:39 I have awesome fun Jul 30 18:29:56 as the packages have changed to (bird 1.6 -> bird v2 as an example) Jul 30 18:30:13 :D Jul 30 18:30:17 with 17.01 -> 18.06? Jul 30 18:30:23 well Jul 30 18:30:27 master+local patches Jul 30 18:30:49 currently running version is just after 17.01 branch iirc Jul 30 18:30:50 oh Jul 30 18:31:34 i'm sticking with 18.06 until the current release kind of gets into the picture, then i'll switch my own devices to test drive master ahead of a new stable branch Jul 30 18:31:50 ah heh Jul 30 18:32:13 I figure its easier to just track master than cherry pick bits from master and backport to releases Jul 30 18:32:44 i don't cherry-pick too much, right now i just have the dropbear bump Jul 30 18:32:46 that's about it Jul 30 18:32:55 heh Jul 30 18:32:55 and kernel bumps :P Jul 30 18:32:58 I like new shinies :D Jul 30 18:33:05 i have learned to steer clear Jul 30 18:33:33 as much as i love tinkering, it gets frustrating quickly when you have to spend time on it you'd like to spend otherwise :-P Jul 30 18:33:47 I only really bump firmware versions once a year (or when i can be bothered) Jul 30 18:34:00 normally around release time as all the nice things have gone in by then Jul 30 18:34:16 heh I'm already maintaining a fork, so time is already wasted Jul 30 18:34:40 i have my own modest 'LTS' fork of 18.06 Jul 30 18:34:49 well, not really wasted as it does exactly what I want Jul 30 18:34:55 ;) Jul 30 18:35:05 my time went mostly into preconfiguring with UCI Jul 30 18:35:08 but recently I have learnt that I can achieve 90% of that by using .config symbols Jul 30 18:35:11 yeah Jul 30 18:35:15 hehe Jul 30 18:35:28 default configs are a large portion of my changes Jul 30 18:35:35 as the defaults just don't work for my uses Jul 30 18:35:53 plus some additions Jul 30 18:36:00 yeah Jul 30 18:41:58 ugh, oops, i opened a pr from my master then pushed more stuff to my master not realizing it'd update the pr with the new commits :( Jul 30 18:42:12 feature branches dude Jul 30 18:42:13 oh well, just merge them all, theyre wonderful Jul 30 18:42:20 yeah, i did for my second one Jul 30 18:44:23 heh Jul 30 18:44:34 rmilecki: did you reach a verdict eventually? :) Jul 30 18:44:35 lol Jul 30 18:44:46 * m4t scrambles to rebase Jul 30 18:44:51 then close the pr ;( Jul 30 18:45:54 which PR ? Jul 30 18:46:07 hmmm, unable to build toolchain/gcc/final Jul 30 18:46:22 stintel: out of space? Jul 30 18:46:23 stintel: welcome to my world :) Jul 30 18:46:36 DonkeyHotei: nope, 32GB available Jul 30 18:46:44 stintel: could you tell me what's up with ext4 exactly on 4.14? Jul 30 18:46:47 any issues? Jul 30 18:47:08 https://pastebin.com/tVgp2ExB Jul 30 18:47:25 Borromini: it simply freezes on boot Jul 30 18:47:40 well not freezes, but the boot process doesn't finish Jul 30 18:47:44 stintel: weird... what box are you testing it on? Jul 30 18:48:02 at least on 18.06 i'm on 4.14.57 now on my APU2 and that works fine afaict Jul 30 18:48:03 this rendered my APU2 broken, reproduced in qemu Jul 30 18:48:16 but a clean .config doesn't have the problem Jul 30 18:48:19 ouch Jul 30 18:48:20 ok Jul 30 18:48:29 I can send you my .config if you want to try and reproduce it Jul 30 18:49:03 sure, i assume diffconfig doesn't show any easy culprits? Jul 30 18:49:15 * blogic starts fixing build server fallout Jul 30 18:49:57 stintel: are you cross-compiling a cross-compiler? because x86_64-pc-linux-gnu-g++ to build a mips toolchain Jul 30 18:50:27 DonkeyHotei: I am just running make Jul 30 18:50:34 in the openwrt git clone Jul 30 18:50:48 Borromini: https://gist.github.com/4b3a17cd49e31c554ea0a12ac0ff3286 Jul 30 18:51:09 blogic: a different one for the new redboot dt parser https://github.com/openwrt/openwrt/pull/1220/commits Jul 30 18:51:50 stintel: y u no diffconfig? :'( Jul 30 18:51:52 i unfudged it and will just close, i need to rebase it anyhow because rmilecki added the missing header that i also added in my commits Jul 30 18:51:54 i'll diffconfig. Jul 30 18:52:07 i'm not doing 4k Jul 30 18:52:13 at least, that i know of Jul 30 18:52:18 4k? Jul 30 18:52:55 CONFIG_TARGET_EXT4_BLOCKSIZE_4K=y Jul 30 18:53:29 that's default Jul 30 18:53:37 oh Jul 30 18:53:42 nevermind me. Jul 30 18:53:44 here is diffconfig: https://gist.github.com/547a839c837dcbb167e2f28c3c0d98be Jul 30 18:53:52 much obliged ;) Jul 30 18:54:01 makes it easier to compare against mine Jul 30 18:54:06 blogic: did you manage to reproduce my problem with my .config ? Jul 30 18:54:37 stintel: not yet Jul 30 18:54:38 been afk for ~10d and my server crashed so IRC was dead for some time as well Jul 30 18:54:39 ok Jul 30 18:55:55 stintel: silly question, the ext4 kernel partition is big enough on x86/64 right? Jul 30 18:56:12 nm. shouldn't be an issue since you're using defaults for that. Jul 30 18:56:15 Borromini: 256M? default is 16 or so Jul 30 18:56:46 stintel: will test once i fixed the applied micro build error Jul 30 18:56:56 blogic: ok thanks Jul 30 18:57:08 meanwhile I try to figure out why toolchain/gcc/final doesn't build Jul 30 18:57:18 mangix: do you have the same problem with toolchain/gcc/final ? Jul 30 18:57:32 stintel: show me the error Jul 30 18:57:41 blogic: https://pastebin.com/tVgp2ExB Jul 30 18:58:04 stintel: yeah. i will look at this later, it's not just my eyes that are tired :( :( Jul 30 18:58:20 Borromini: :D Jul 30 18:58:28 stintel: no different one. Jul 30 18:58:39 ok Jul 30 18:59:19 guys, out of curiosity: the kernel bumps i sent in for 18.06, were they too late to make it to final or was there some other issue? Jul 30 18:59:57 stintel: reported ext4 breakage Jul 30 19:00:06 so everyone held their breath and did not dare Jul 30 19:00:22 blogic: yeah, i pointed to it too in my e-mail Jul 30 19:00:35 i fully understand :) Jul 30 19:00:52 perfect timing for holiday :P Jul 30 19:01:00 stintel: yeah Jul 30 19:01:18 throw a bomb, run like a motherfucker huh ;) Jul 30 19:02:19 Borromini: no, he didn't commit it to master Jul 30 19:03:33 ldir: true, but just spreading a rumour works equally well :^) Jul 30 19:03:44 hearsay can be more powerful than a git commit Jul 30 19:04:14 hmmm, and when changing my .config for my Unifi AP AC Pro to ath79, all other options get reset to default :/ Jul 30 19:04:48 stintel: too bad huh :( Jul 30 19:05:06 yeah, had hoped to get some things done today, but I guess not o Jul 30 19:05:17 any idea if the last round of ath10k updates made it suck less? Jul 30 19:05:33 or is https://bugs.openwrt.org/index.php?do=details&task_id=333 still making it near unusable Jul 30 19:06:37 epic fail Jul 30 19:06:55 google's git tarballs return a different hash everytime they're downloaded Jul 30 19:08:06 i have never seen this type of failure before Jul 30 19:08:58 stintel: I do not currently suffer any suckiness with a QCA9880 Jul 30 19:10:26 Let's just gloss over the one I just accidentally unplugged. Jul 30 19:11:52 ^_^ Jul 30 19:12:01 nothing worse than PEBKAC Jul 30 19:12:26 Let's just say the current arrangement of power strips sucks. Jul 30 19:14:02 trying to build toolchain again, now with correct .config Jul 30 19:14:09 let's hope it was .config related Jul 30 19:17:03 hmmm, the files it failed on point to my previous host gcc version Jul 30 19:17:57 but I did a make dirclean recently Jul 30 19:18:01 * stintel scratches head Jul 30 19:22:55 stintel: I've had instances of build strangeness not cured by dirclean, but an 'rm openwrthomedir/tmp' fixed Jul 30 19:23:47 yeah, did rm -rf tmp/ before my current build Jul 30 19:23:50 fingers crossed Jul 30 19:24:12 * blogic frags tmp/ regularly Jul 30 19:24:33 same here, but probably didn't think of it when I did the dirclean Jul 30 19:24:42 maybe we should add it somewhere Jul 30 19:25:09 looks like it's OK now, seeing ubusd being built means toolchain finished Jul 30 19:30:06 yep, built fine now Jul 30 19:31:35 sysupgrading my UAP AC Pro from ar71xx to ath79 - fingers crossed again Jul 30 19:32:04 Device unifiac-pro not supported by this image Jul 30 19:32:14 I did the same thing on my UAP-LR a while back and it worked fine. Jul 30 19:33:09 and when I edit /tmp/sysinfo/board_name -> Sysupgrade is not yet supported on ubnt-unifiac-pro Jul 30 19:33:10 hmmmz Jul 30 19:33:19 mamarley: do settings stick? or did you just wipe? Jul 30 19:33:45 Borromini: The settings stuck both on the initial upgrade to ath79 and subsequent upgrades. Jul 30 19:33:57 neat. Jul 30 19:34:06 maybe I need to upgrade it to a more recent ar71xx build first Jul 30 19:34:21 (Good thing too, because the WAP is attached to a trunk with VLANs and if it defaulted, it wouldn't get a network connection and I would have to pull it off the ceiling to fix it. Jul 30 19:34:45 https://github.com/openwrt/openwrt/pull/1166#issuecomment-408969098 Jul 30 19:34:47 i won't switch the unifis just yet, it's all remote stuff so if it breaks i get to go over. not to mention i like to stick to stable on that stuff Jul 30 19:34:48 charming fella Jul 30 19:34:57 blogic: ? Jul 30 19:35:08 blogic: oh nm missed your previous line :P Jul 30 19:35:25 wtf Jul 30 19:35:29 LOL Jul 30 19:35:39 i was not aware that blokes could get pregnant Jul 30 19:35:54 😂 Jul 30 19:37:12 blogic: you did miss schwarzenegger, obviously Jul 30 19:42:39 just gone on the block list Jul 30 19:42:55 ldir: where ? Jul 30 19:43:03 github? Jul 30 19:43:32 well that's where I've put him for me at least. Jul 30 19:43:41 github yes Jul 30 19:43:45 how do you do that ? Jul 30 19:44:19 ah cool Jul 30 19:44:23 /ignore for github Jul 30 19:44:41 amazing, ignore is the most mis underestimated feature evvaaa Jul 30 19:45:03 click on user's profile picture - when you get to their homepage, underneath picture is block/report button. Jul 30 19:45:08 yeah Jul 30 19:45:11 just found it Jul 30 19:45:41 hahaahah that dude is off his head! Jul 30 19:46:08 Tapper: i thinks its kinda funny Jul 30 19:46:27 Yeah! (chuckle) Jul 30 19:46:28 there's a blocklist on github? Jul 30 19:46:33 neat. Jul 30 19:46:54 the pic is funny but the namecalling... Jul 30 19:47:24 his profile picture is quite telling - for tapper's benefit a 'rapper' style dude in a 'pose' with 2 fingers up. Jul 30 19:47:35 ah. psyborg Jul 30 19:47:47 2 specific fingers :) Jul 30 19:48:06 blogic: doesn't the pop up on the mailing list sometimes as well? Jul 30 19:48:06 very specific fingers :-) Jul 30 19:48:13 he seemed better behaved on the ML, Jul 30 19:48:53 not sure whether Tapper "saw" the pic in the comment Jul 30 19:49:24 maybe it has an alt? probably not. Jul 30 19:49:59 same bloke who put up money baits to "fix bugs" on the FS Jul 30 19:50:18 Borromini: oooh we could have fun working out what the alt text would be! :-) Jul 30 19:50:55 lol Jul 30 19:53:05 ldir: midwest town depopulated after pregnancy billboard. Jul 30 19:53:59 ok so the ath79 image supports boardnames ubnt,unifiac-pro and ubnt-unifiac-pro Jul 30 19:54:14 but the ar71xx sysupgrade check doesn't recognize them Jul 30 19:54:26 so no sysupgrade from ar71xx to ath79 Jul 30 19:54:27 ath79 is wip Jul 30 19:54:32 ah yes Jul 30 19:54:41 sysupgrade -f Jul 30 19:54:56 ldir: ? :P Jul 30 19:54:56 that's how I migrated my archers Jul 30 19:55:01 ah, -F Jul 30 19:55:10 anyone know why christian schoenbeck is removing himself as maintainer ? Jul 30 19:55:58 ok, -F works for me Jul 30 19:56:13 do we want users to do that during migration, once ath79 is ready? Jul 30 20:01:12 ok, had to change the path for the 2.4GHz chip too (option path 'platform/ahb/ahb:apb/18100000.wmac') Jul 30 20:05:57 it's not ideal and I didn't expect it to work perfectly.... it didn't... as you've discovered wireless devices change Jul 30 20:06:48 well happy to finally be running at least 1 device with ath79 :) Jul 30 20:14:17 i wanted to flash my 1043 v1 but bricked it first :D :D Jul 30 20:14:41 jow: erratic behavior could well ahve been a PEBKAC. Better safe than sorry still. We'll see how that fares in master :) Jul 30 20:14:43 building an ancient modded uboot then force feeding it didn't work out too well :^ Jul 30 20:14:46 :^) Jul 30 20:14:58 doh Jul 30 20:14:58 * mamarley still needs to buy another serial adapter to debrick his other e3000. Jul 30 20:15:20 i'd like ath79 on my wndr3700 v1 but afaict there's still issues with those older devices Jul 30 20:15:37 Borromini: in a similar situation I noticed that a raspi makes for a convenient SPI flasher :) Jul 30 20:15:56 ra-SPI Jul 30 20:16:07 ;-) Jul 30 20:16:09 * ldir chuckles Jul 30 20:29:36 lol Jul 30 20:30:14 f00b4r0: unfortunately i'm not handy with that kind of stuff. i can't even get a serial cable right... Jul 30 20:30:38 keep trying, eventually you'll get it ;) Jul 30 20:30:42 You should see how nasty the soldering on my e3000 that does have the serial adapter is. Jul 30 20:31:04 * mamarley is surprised it works at all. Jul 30 20:31:25 :) Jul 30 20:40:01 jow: i have zero knowledge of target/linux/ar71xx/base-files/etc/board.d/02_network (you asked me about it hours ago) Jul 30 20:40:27 f00b4r0: i didn't sorry, this day became more crazy than I expected, I'm trying to buy everything I need for holidays Jul 30 20:40:58 rmilecki: enjoy Jul 30 20:41:06 KanjiMonster: what do you think about "ecoscentric,redboot-fis-partitions" istead of "redhat,redboot-partitions" Jul 30 20:41:09 KanjiMonster: https://github.com/openwrt/openwrt/pull/1220/files Jul 30 20:41:18 rmilecki: fine by me Jul 30 20:41:36 blogic: thanks Jul 30 20:41:56 m4t: i assume "ecoscentric" is better than "ecos"? Jul 30 20:42:10 yeah Jul 30 20:42:14 ok Jul 30 20:42:16 i had a pr but i closed it. it had the missing include Jul 30 20:42:29 m4t: one comment regarding your changes: you need to do that in a single commit Jul 30 20:42:33 i know two commits look nicer Jul 30 20:42:37 k Jul 30 20:42:43 theyre dependent i guess? Jul 30 20:42:45 but if you checkout the first commit & build - it won't work Jul 30 20:43:06 because you end up in the middle of changes. parser will already expect a new binding, but DT will contian old binding Jul 30 20:43:10 and resulting images won't work Jul 30 20:43:16 hah, exactly why I just pushed 50c5fdd54d5f189df0979f1255ec50b88c90a702 Jul 30 20:43:41 if I would add libcap-ng, and afterwards fix tcpdump Makefile, the first commit would also not build Jul 30 20:44:06 and that's really annoying when doing git bisect Jul 30 20:46:58 are there image available to download to test ath79 on archer c7 v4? Jul 30 20:47:26 the plan seems to be ath71xx=>ath79 according to https://lists.openwrt.org/pipermail/openwrt-devel/2018-February/011312.html Jul 30 20:49:59 guerby: ath79 is WIP - no support for c7 v4 yet afaict Jul 30 20:55:11 i think the only archer c7 with a dts file at this point is v2 Jul 30 20:55:22 guys, 18.06 x86/legacy sdk Jul 30 20:55:30 and reportedly it's not complete Jul 30 20:55:32 how to disable CONFIG_AUTOREMOVE? Jul 30 20:55:53 legawhat Jul 30 20:56:43 the sdk for the x86 legacy target Jul 30 20:57:04 i want to keep the build tree, but editing .config doesn't help Jul 30 20:57:40 CONFIG_AUTOREMOVE always gets set to 'y' when I run make Jul 30 20:57:42 prob selected ahaim, use menuconfig? Jul 30 20:57:49 again Jul 30 20:58:13 hm, didn't find option in there Jul 30 20:58:26 editing .config does not do what yoi think it does Jul 30 20:58:35 its uh, under global build i think Jul 30 20:59:46 i'm afraid not, there's just three options "select all" this or that, and one about crypto signatures Jul 30 20:59:48 domt have terminal to hand to check Jul 30 20:59:54 dont Jul 30 21:00:08 oh maybe toolchain thinger Jul 30 21:00:14 its there somewhere Jul 30 21:00:25 search for the symbol Jul 30 21:00:29 easier Jul 30 21:00:42 ah Jul 30 21:00:50 forgot about that Jul 30 21:01:32 "Defined at Config-build.in:749" Jul 30 21:01:43 so that's what I need to manually edit? Jul 30 21:02:09 ah i see, there's a default defined Jul 30 21:02:33 justvneed to unselect it Jul 30 21:03:12 i'm pretty sure there's no checkbox in 'menuconfig' Jul 30 21:03:22 there is Jul 30 21:03:27 ive seen it Jul 30 21:03:41 maybe not in the sdk tho? Jul 30 21:04:08 exactly Jul 30 21:04:17 the sdk comes with prebuilt toolchain Jul 30 21:04:29 and menuconfig is much reduced, as compared to the full tree Jul 30 21:04:37 ah hm Jul 30 21:04:56 that's alright, changing Config-build.in should do it Jul 30 21:05:03 yeah Jul 30 21:05:10 your 'search for it' hint presumably saved me Jul 30 21:05:16 so ... thanks a lot! Jul 30 21:06:04 heh Jul 30 21:06:42 it's about asterisk, and I want to keep some modules that are built but not included in any package Jul 30 21:06:46 meh, lldpd picks up libevent2, and at first look it doesn't seem possible to tell it not to Jul 30 21:07:32 need libev no? Jul 30 21:07:42 stintel, ok thx. found some proposed dts for v4 in this post: https://forum.lede-project.org/t/is-anybody-working-on-linux-4-14-for-ar71xx-platform-porting-guide-to-ath79/13013/420 Jul 30 21:07:44 since it uses events Jul 30 21:08:03 stintel, what is the process for approving those dts? Jul 30 21:08:16 guerby: submitting it either as a patch to the ML or as a PR on github Jul 30 21:08:20 patches in forum are not reviewed Jul 30 21:09:03 stintel: dont tell people about github Jul 30 21:09:08 guerby: use the ML Jul 30 21:09:10 lol Jul 30 21:09:10 :-D Jul 30 21:09:30 guerby: i review the ath79 patches Jul 30 21:09:36 blogic, ok :) I guess I'll have to figure out where to tell the builder I want c7 v4 in ath79 Jul 30 21:09:53 in addition to pasting the forum suggested dtsi Jul 30 21:10:41 blogic: :D Jul 30 21:10:52 guerby: https://openwrt.org/submitting-patches Jul 30 21:12:42 blogic, yep followed it once :) but didn't push (dropbear fix for bind on ipv6 address, shell scripting) Jul 30 21:14:35 ok seems to be where to add c7 v4 target/linux/ath79/image/generic-tp-link.mk Jul 30 21:15:18 hmmm wait a minute, DEPENDS:=+libevent2 Jul 30 21:15:21 wut Jul 30 21:15:30 then why is it complaining about the missing dependency Jul 30 21:15:35 *shrug* Jul 30 21:44:22 rmilecki: k here's the updated PR https://github.com/openwrt/openwrt/pull/1228 Jul 30 21:45:48 m4t: looks good to me! Jul 30 21:46:19 cool Jul 30 21:46:20 blogic: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9b47aa93c76ba87b7d84dacd2c881cef6334e3f5 Jul 30 21:46:33 m4t: is there an easy way to copy your repo's URL? Jul 30 21:46:37 when looking at github? Jul 30 21:46:43 blogic: jow already nodded on #-adm, but you were afk Jul 30 21:46:50 rmilecki: the .git? Jul 30 21:46:56 yes Jul 30 21:47:14 I see "from tofurky:redboot-dt-parser" only, but that isn't a link Jul 30 21:47:15 oooh. lots of action. exciting. Jul 30 21:47:35 https://github.com/tofurky/openwrt.git -b redboot-dt-parser 3201a47cddcfbce655963975909238580cf58524 Jul 30 21:47:44 or https://github.com/tofurky/openwrt/commit/3201a47cddcfbce655963975909238580cf58524.patch Jul 30 21:47:53 thank you! Jul 30 21:47:55 np Jul 30 21:48:01 stintel: and while at the "shiny new feature" kthxbye Jul 30 21:48:15 dedekh pushed a netifd update that now blows up Jul 30 21:48:51 blogic: in what way? Jul 30 21:49:10 package/Makefile:107: recipe for target 'package/network/config/netifd/compile' failed Jul 30 21:49:13 make[1]: *** [package/network/config/netifd/compile] Error 2 Jul 30 21:49:16 make[1]: *** Waiting for unfinished jobs.... Jul 30 21:49:22 I'm trying to reproduce my 4.14.56 issue meanwhile but keep running into various issues Jul 30 21:49:24 /var/lib/buildbot/slaves/slashdirt-03/MAIN/build/build_dir/target-arm_mpcore_musl_eabi/netifd-2018-07-30-75ee7905/interface-ip.c:724:11: error: unused variable 'macaddr' [-Werror=unused-variable] Jul 30 21:49:28 uint8_t *macaddr = iface->l3_dev.dev->settings.macaddr; Jul 30 21:49:41 blogic: revert the commit? Jul 30 21:52:08 can someone close https://github.com/openwrt/openwrt/pull/1228 for me, please? Jul 30 21:52:16 it seems I'm a Member Jul 30 21:52:22 but i don't see a close button Jul 30 21:52:26 done Jul 30 21:52:36 beat me to it :) Jul 30 21:52:44 :) Jul 30 21:52:53 gracias Jul 30 21:53:59 release day, github pr squashing day, nice... Jul 30 21:54:38 Merge it or burn it Jul 30 21:55:31 and another package complaining about a missing dependency while the dependency is actually there Jul 30 21:55:33 wtf is this shit Jul 30 21:56:32 hmm, dirclean does "rm -rf $(TMP_DIR)" Jul 30 21:58:05 fixed the netifd issue i hope Jul 30 21:59:24 hm, it looks like this PR's commits are already in master, blogic ? https://github.com/openwrt/openwrt/pull/1224 Jul 30 21:59:35 you commited but maybe forgot to close the PR Jul 30 22:10:47 as part of the 18.06 release celebration, can someone finally ban SpaceRat? lol Jul 30 22:11:11 Poor Rat Jul 30 22:12:10 never heard of spacerat Jul 30 22:12:16 who/where is that Jul 30 22:12:21 oh do you ignore join/parts? Jul 30 22:12:29 ha Jul 30 22:12:39 you'd be suprised how easy it is to get onto my ignore list Jul 30 22:12:49 It might be something to do with the #lede-dev redirect Jul 30 22:13:00 and its the same shell account i've been using for 10 years to connect here so the list if flipping long Jul 30 22:14:49 did some quick shell math: 222 2018-05, 2396 2018-06, 1912 2018-07 Jul 30 22:14:54 joins/parts Jul 30 22:15:28 it doesn't bother me that much, it's kind of funny actually, but i know some people here have screen readers Jul 30 22:15:40 blogic: sorry, I missed that 18.06.0 is already being built. disregard the merge request then, or postpone for a point release. it's already in master anyway. Jul 30 22:15:57 ? Jul 30 22:16:04 takimata: ah that forum thing Jul 30 22:16:08 yup. Jul 30 22:16:14 m4t: been away from pc for few hours. Just updated ubntrs branch on top of Your latest accepted commits. Jul 30 22:16:28 a few days ago I asked jow to cherry-pick it, but eh, moot now. Jul 30 22:16:34 tmn505: cool Jul 30 22:16:52 (and not in any way mission critical anyway.) Jul 30 22:17:14 * takimata does the happy release day dance. Jul 30 22:17:35 (bummer that we missed sysadmin day ... would have been a nice coinkidink.) Jul 30 22:17:54 everyone missed sysadmin day ;( Jul 30 22:18:29 yeah, the actual sysadmims were busy working ;) Jul 30 22:18:30 I didn't, my sysadmin got a chocolate stash. Jul 30 22:18:52 nice Jul 30 22:18:58 was there a vote or discussion i missed about ar71xx/ath79? it looks like PRs for ar71xx are deprecated although ath79 is full of bugs and a source only target Jul 30 22:19:02 (keep your friends close, your sysadmin closer.) Jul 30 22:19:11 actually i had someone in customer service mention it back in 2010 or so, i didn't even know it was a thing Jul 30 22:19:21 example PR for ar71xx which was closed : https://github.com/openwrt/openwrt/pull/1107 Jul 30 22:19:28 rotanid: what a pile of bollocks Jul 30 22:19:37 blogic: hm? Jul 30 22:19:44 rotanid: i recall merging ~25 ar71xx patches just today Jul 30 22:19:49 * takimata is thankful for the image of "a pile of bollocks" Jul 30 22:19:59 #fakenews Jul 30 22:20:17 blogic: ok, thanks, maybe not every openwrt maintainer has the same idea for the future of ar71xx then? Jul 30 22:20:27 see the PR i linked Jul 30 22:21:09 well it works fine on ath79 Jul 30 22:21:22 rotanid: if you want a stable, use 18.06 Jul 30 22:21:27 would be nice if there was some kind of common way forward so no one invests time for nothing Jul 30 22:21:44 rotanid: if you want to use current dev head then you gotta life with potential bugs Jul 30 22:21:52 blah blah blah Jul 30 22:22:29 ok, i guess my opinion is not in line with yours ^^ Jul 30 22:22:38 fine Jul 30 22:23:22 i think the correct syntax is /mode #openwrt-devel +b $a:SpaceRat$##fix_your_connection Jul 30 22:24:11 DonkeyHotei: yes Jul 30 22:24:11 DonkeyHotei: unfortunatley this channel is still under imres control :-) Jul 30 22:24:11 only? Jul 30 22:24:16 wigyori: did you have ops here ? if so please op me Jul 30 22:25:28 while you're at it, freenode imposes a requirement that public logs must be disclosed either in the /topic or in the onjoin msg, and this channel does neither Jul 30 22:25:42 are there public logs ? Jul 30 22:26:05 http://logs.nslu2-linux.org/livelogs/openwrt-devel/ Jul 30 22:26:19 who is that? Jul 30 22:26:43 if someone is logging without permission that needs to ne dealt with Jul 30 22:26:51 they log a BUNCH of channels Jul 30 22:26:53 DonkeyHotei: how would we know if any of the users here puts the logs out there? Jul 30 22:27:33 i think the permission to log this channel was granted back when the openwrt website also logged both this channel and #openwrt Jul 30 22:29:05 only the first six months of this channel are missing from the above logs, if archive.org's cache of the original log repo is any indication Jul 30 22:29:19 i think ka6sox owns it Jul 30 22:29:24 71 days idle ha Jul 30 22:29:27 nice uptime Jul 30 22:32:18 mmh ... I'm seriously considering _not_ updating one of my 17.01.0 machines, just to keep the uptime. :) Jul 30 22:32:30 I mean ... Jul 30 22:32:46 00:32:34 up 513 days, 5:22 Jul 30 22:33:10 nice Jul 30 22:33:27 yeah uptime is great and all but so are shiny new things Jul 30 22:33:28 uptimes above 2-3 months at most are just a sign of security issues, being an easy target Jul 30 22:33:32 when was 17.01.0 released? is it possible that this thing is up almost exactly since 17.01.0 came out? Jul 30 22:33:43 unless you're livepatching Jul 30 22:34:30 that only applies to a very, very limited set of case Jul 30 22:34:36 pkgadd: that thing is behind a firewall, behind a firewall, and it doesn't do anything at all ... I set it up to test 17.01 and ... forgot about it. ;) Jul 30 22:35:16 my pogoplug e02 running barrier breaker almost reached 1000 days. ups failure :( Jul 30 22:36:15 m4t: funny, that one is a pogoplug too. :) Jul 30 22:36:55 i think the ethernet on mine started to fail, kept flapping. tried turning off auto neg to no avail. setting it to 100mb fixed it, didn't flap once since then. Jul 30 22:37:13 also, no, 17.01.0 was 554 days ago. so my uptime is missing almost 2 months on the release date. Jul 30 22:40:12 /topic things you do on the internet may be monitored by the surveillance state(s) Jul 30 22:41:01 russell--: :-D Jul 30 22:42:19 rmilecki: no problem, we can do this later. Enjoy your vacation! :) Jul 30 22:49:12 DonkeyHotei: the nslu2 logging is pretty spotty Jul 30 22:49:27 at times Jul 30 22:50:45 but a public log of this channel was damn convenient as a live notepad when no one was around and i was doing the initial hardware investigation into what later became the first supported adm8668 device Jul 30 22:51:26 ahhh, nslu2, the good ol linksys slug Jul 30 22:52:22 with it's pain in the ass ARM BE build, when just about everything else used LE. Unslung fixed that. Jul 30 22:56:37 ah, good, the release dir is filling up with targets... Jul 30 22:56:55 * Kamilion watches the x86 target like a hawk Jul 30 23:08:06 is Chaos Calmer 15.05.1 still maintained ? Jul 30 23:08:12 no Jul 30 23:08:39 17.01 just got a maintenance bump, and 18.06 is now released Jul 30 23:08:59 in https://downloads.openwrt.org/ Chaos Calmer 15.05.1 is listed under The most recent OpenWrt/LEDE releases Jul 30 23:09:03 17.01.5 and 18.06.0, respectively Jul 30 23:09:15 15.05.1 hasn't been maintained at all for almost a year by now (and that's very generous, in practice it hasn't been maintained for well over 2 years) Jul 30 23:09:58 somebody should fix that page soon Jul 30 23:11:19 i'm wondering whether release names are to be resumed at any point Jul 30 23:11:51 I asked because gns3 source lists looks like a real mess. Jul 30 23:11:55 pkgadd: well yeah, most of the times when i wanted to push something into that branch in packages, i was told off that the branch is closed ;p Jul 30 23:12:07 I can make a PR to just delete them all Jul 30 23:12:09 it's a bit of an irony that Designated Driver was the release cycle that crashed Jul 30 23:12:11 https://github.com/GNS3/gns3-server/blob/master/gns3server/appliances/openwrt.gns3a Jul 30 23:12:17 https://github.com/GNS3/gns3-server/blob/master/gns3server/appliances/lede.gns3a Jul 30 23:12:58 DonkeyHotei: lol :P Jul 30 23:14:46 wigyori: I totally understand you, but also the package maintainers - it's very difficult to go back to a branch that hasn't seen much movements in the past, that's mentally written off already - and then trying to remember what other critical patches besides the proposed changes would be needed as well (even more so when the persons in question don't even run that codebase anymore, so testing Jul 30 23:14:52 becomes difficult) Jul 30 23:16:13 pkgadd: i'm not disagreeing at all with that :) Jul 30 23:16:18 e.g. I'm pretty good at remembering what I've done in software projects over the years, but putting it on a timescale is more difficult - and that's required to tick off the to-do list. and fixing one thing, while leaving $x equally critical ones unfixed isn't really of service to the user either Jul 30 23:16:58 creating a cc.2 never got too much traction, and after some time i also dropped the idea against working on more useful stuff Jul 30 23:17:39 i think cc got up to .4 or .5, no? Jul 30 23:17:51 no, there was only one maintenance release, cc.1 Jul 30 23:18:07 i.e. 15.05.1 Jul 30 23:21:08 the longer the timespan between maintenance releases, the harder it will be to get one done at all. because it means developers will lose the old branch out of sight, with pending changes stacking up to a point where it won't be done at all anymore Jul 30 23:43:43 yay Jul 30 23:43:45 found the problem Jul 30 23:43:48 was ext4 related after all Jul 30 23:45:59 ldir: ping Jul 31 00:00:05 ldir: I suspect you rejected your 4.14.59 bump on patchwork due to conflicts caused by blogic's rampage... just going to start over with update_kernel.sh and hopefully push 4.14.59 before going to bed Jul 31 02:12:46 blogic: ldir: pushed 4.14.59 + fix for ext4 issue Jul 31 02:13:13 shit Jul 31 02:13:58 false alarm - thought I forgot git add but should be ok Jul 31 02:14:15 nn **** ENDING LOGGING AT Tue Jul 31 03:00:00 2018