**** BEGIN LOGGING AT Mon Jan 11 03:00:17 2021
Jan 11 03:27:48 <aparcar[m]> mangix: ping
Jan 11 03:36:23 <mangix> aparcar[m]: pong
Jan 11 03:36:50 <aparcar[m]> mangix: any trivial way to test this? I pushed it to my buildbot but that usually takes a little time to build
Jan 11 03:37:04 <mangix> test what?
Jan 11 03:51:02 <mangix> for the ccache commit, you'd really want to test locally and run ldd on staging_dir/host/bin/ccache
Jan 11 03:51:50 <mangix> I think every modern Linux OS has libzstd installed as a dependency of systemd
Jan 11 03:52:06 <mangix> CentOS 7 seems to be old enough for it not to be the case
Jan 11 05:30:57 <aparcar[m]> mangix: shouldn't we bump the release?
Jan 11 05:44:34 <owrt-snap-builds> build #40 of realtek/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/40  blamelist: David Bauer <mail@david-bauer.net>, Daniel Golle <daniel@makrotopia.org>, Paul Spooren <mail@aparcar.org>
Jan 11 06:08:22 <mangix> aparcar[m]: what release?
Jan 11 06:09:59 <Strykar> is the new nmap license going to affect Openwrt too? https://bugzilla.redhat.com/show_bug.cgi?id=1914445
Jan 11 06:21:20 <Namidairo> Strykar: the current version in packages is 7.80, so for the moment that isn't an issue
Jan 11 06:22:53 <Namidairo> as for whether the license is compatible with openwrt for 7.90+... IANAL.
Jan 11 06:32:40 <Strykar> welp, I've created an issue and tagged the maintainer
Jan 11 06:33:54 <Strykar> jow: any opinions on https://github.com/openwrt/packages/issues/14246
Jan 11 07:32:53 <aparcar[m]> mangix: of ccache
Jan 11 07:42:33 <mangix> aparcar[m]: tools don't have releases
Jan 11 07:42:34 <mangix> they
Jan 11 07:42:38 <mangix> 're not normal packages
Jan 11 07:42:56 <aparcar[m]> mhh I htink some do but nevermind
Jan 11 07:45:28 <mangix> I tried checking other tools for problems like these
Jan 11 07:45:30 <mangix> didn't find much
Jan 11 07:49:22 <aparcar[m]> mangix: I merged your patch it worked locally
Jan 11 07:49:45 <mangix> my patch?
Jan 11 07:49:54 <aparcar[m]> mangix: the patch you asked me to review
Jan 11 07:50:35 <mangix> ok
Jan 11 07:52:14 <mangix> hmm, forgot how awfully slow WSL was. Or maybe spectre mitigations are slowing it down further.
Jan 11 08:18:56 <ynezz> dedeckeh: russell--: BTW that realtek/generic build breakage is related to the iproute2 http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/40
Jan 11 08:19:17 <ynezz> dedeckeh: russell--: relevant build log error http://sprunge.us/nhpJyJ
Jan 11 08:22:35 <Namidairo> no, WSL is really just that slow
Jan 11 08:23:50 <Namidairo> especially if you're trying to do something like build off something that lives in ntfs
Jan 11 08:25:47 <russell--> ynezz: what is the corresponding .config?
Jan 11 08:33:46 <rsalvaterra> 'morning
Jan 11 08:34:42 <rsalvaterra> nbd: ping
Jan 11 08:38:35 <rsalvaterra> I'm seeing some weird mt76 behaviour…
Jan 11 08:42:00 <ynezz> russell--: https://downloads.openwrt.org/snapshots/targets/realtek/generic/config.buildinfo
Jan 11 08:43:20 * russell-- tries to reproduce
Jan 11 08:43:42 <ynezz> dedeckeh: russell--: if you look at the builds http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric you will notice few green builds before this faulty one
Jan 11 08:44:26 <ynezz> this probably hints to some issue with the iproute2 build system and might be harder to reproduce
Jan 11 08:45:32 <ynezz> perhaps it would be better to look at the failing step, whether it was changed in the bumped version etc.
Jan 11 09:08:24 <russell--> ynezz: there are 5 commits between success (build #39) and failure (build #40) and none of them seem related to iproute2
Jan 11 09:11:03 <ynezz> russell--: yep, another hint which points to the issue in the iproute2 package build system
Jan 11 09:11:52 <ynezz> dynsyms.list:0: syntax error in dynamic list
Jan 11 09:12:05 <ynezz> that file dynsyms.list is generated by the build system
Jan 11 09:13:30 <russell--> this looks vaguely similar on first blush: https://github.com/openwrt/packages/issues/7728
Jan 11 09:14:05 <ynezz> and https://bugs.openwrt.org/index.php?do=details&task_id=3353
Jan 11 09:14:18 * russell-- needs to Zzzzz ... will look harder tomorrow
Jan 11 09:43:08 <mangix> Namidairo: I remember it being slightly faster. I think some spectre update slowed it down.
Jan 11 09:43:49 <mangix> aparcar[m]: speaking of WSL, I forgot I put apk on here. Doesn't compile without deprecated OpenSSL APIs
Jan 11 10:11:06 <rmilecki> jow: could you take a quick look at the [PATCH] bcm4908: initial work on the Broadcom BCM4908 target https://patchwork.ozlabs.org/project/openwrt/patch/20210108135232.31360-1-zajec5@gmail.com/ please?
Jan 11 10:11:15 <rmilecki> any objections to that new target?
Jan 11 10:11:43 <rmilecki> patch is trivial, simple Makefile-s, few backports, it's mostly about a new target I think
Jan 11 10:22:32 <ynezz> I'm just wondering why do you include it as source-only
Jan 11 10:22:41 <rmilecki> ynezz: because it's not ready
Jan 11 10:22:51 <rmilecki> I want to have place to work on it with more developers
Jan 11 10:22:51 <ynezz> so why not include it when it's ready? :)
Jan 11 10:23:01 <rmilecki> so I don't develop it behind the door
Jan 11 12:25:50 <numero53> Hello everyone!
Jan 11 12:26:26 <numero53> Is someone using a router or board with mt7622? I am trying to add support for a new router (Belkin RT3200/Linksys E8450) but I have a problem with the flash and the bad block management table when jffs2 tries to erase rootfs_data ...
Jan 11 13:34:12 <blogic> numero53: there is a patch in felix's staging tre for that
Jan 11 13:34:41 <blogic> numero53: https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commit;h=10d32b98d76350caede3c2f5b483f3c8186c1588
Jan 11 14:02:35 <numero53> blogic: Thanks for the answer! I am already using that one, but it get recreated every boot because it conflicts with the one in the bootloader... I managed to fix most of the problems changing the define BB_TABLE_MAX from 0x2000U to 0x1000U... But I don't don't know if it's right
Jan 11 14:32:57 <mrkiko> rmilecki: have you seen my mails recarding bcm63xx target - netgear d6400
Jan 11 15:13:41 <rmilecki> mrkiko: that one I assume? [bcm63xx] help in adding Netgear D6400 support
Jan 11 15:17:46 <rmilecki> mrkiko: it seems you generated & flashed image that CFE can't understand
Jan 11 15:17:55 <rmilecki> I don't know bcm63xx's CFE enough to help with that
Jan 11 16:13:01 <mrkiko> rmilecki: well, it flashes the image, while otherwise saying it's invalid when I try to flash e.g.: the vendor .chk image or a dump of the partition
Jan 11 16:13:30 <mrkiko> but yes, definitely can't find the jffs2 entry for vmlinux.lz
Jan 11 16:13:49 <mrkiko> I hoped in some answer, but not been lucky so far
Jan 11 16:22:42 <rmilecki> mrkiko: just because firmware format is OK, it doesn't mean firmware is totally valid
Jan 11 16:22:59 <rmilecki> mrkiko: format validation is usually some basic check to make sure you don't flash random garbage
Jan 11 16:23:39 <mrkiko> rmilecki: yeah. What I meant - was I don't have a clear term of comparison or a way to go on since I don't have a "totally" valid firmware then
Jan 11 16:24:00 <mrkiko> I tried looking at the gpldump for my device as well.
Jan 11 16:24:40 <mrkiko> In the ky SR102 port I seen noltari replaced CFE with a generic one, but maybe it's late for me to try that? The "w" - wholeimage, command doesn't seem to work.
Jan 11 16:24:53 <mrkiko> CFE also fails to start any elf application I pass it
Jan 11 16:25:28 <mrkiko> I wanted to avoid replacing the bootloader if possible ... to make it easier for an user to install openwrt without risking too much and to keep nvram values.
Jan 11 16:26:24 <mrkiko> but in the end I'll happily do so if i can understand how without bricking the device.
Jan 11 16:35:55 * mrkiko misses u-boot
Jan 11 17:34:52 <nlowe> I spent some time to clean up and add descriptions for wireless config in LuCI - can somebody check https://github.com/openwrt/luci/pull/4713 ?
Jan 11 17:35:39 <jow> I don't like the camel case change
Jan 11 17:37:10 <nlowe> jow: That's for the option names only, where most were already upper camel case and not descriptions
Jan 11 17:37:34 <jow> "Associated Clients" is also not entirely correct
Jan 11 17:37:41 <jow> that list shows all associations
Jan 11 17:37:56 <jow> in case of ad-hoc it shows the peers, in case of a client the PAI associated to, in case of an AP the stations
Jan 11 17:38:28 <jow> s/PAI/AP/
Jan 11 17:39:17 <nlowe> Associations would be more accurate then, not associated stations
Jan 11 17:40:00 <jow> also please use … and not three dots
Jan 11 17:40:37 <jow> also after this change, all translations need to be resynced
Jan 11 17:40:57 <jow> preferably in a way that does not invalidate all existing langauges
Jan 11 17:41:24 <jow> for that the existing english strings need to be substituted by the new ones while keeping the translation
Jan 11 17:41:40 <jow> in the various *.po files
Jan 11 17:42:05 <nlowe> Gotcha, for ... I changed that for consistency with others already in the file - can change all the other way
Jan 11 17:46:45 <dorf> &hellip; is your friend.
Jan 11 17:47:46 <dorf> or maybe not, depends on context :)
Jan 11 17:51:59 <nlowe> jow: Re: upper camel case for names (not descriptions), to me it genuinely looks a lot better when seen in a browser, not just in a commit diff. Happy to switch all around for consistency though if that's desired. I don't think a mix of the two is good.
Jan 11 17:53:23 <jow> just remeber some native speaker complaining here a while ago that all camel case is not the proper thing to do
Jan 11 17:53:52 <jow> and that randomly sprinkling uppercase chars throughout labels is a rather german thing
Jan 11 17:56:56 <nlowe> Either way, perhaps a guideline or style guide could be helpful for the future to work towards?
Jan 11 18:15:00 <jow> nlowe: I am not a native english speaker myself, idealler a native and/or someone with technical writing or documentation background should weigh in
Jan 11 18:15:05 <jow> *ideally
Jan 11 18:15:45 <jow> I agree that camel-casing produces a more esthetically pleasing appearance in many cases
Jan 11 18:16:07 <jow> but it feels weird to captialize almost all words
Jan 11 18:18:04 <nlowe> I agree it would be weird and wrong if in descriptions, but for names and titles only, I personally think it is preferable
Jan 11 18:21:07 <ldir> CamelCase German nouns :-)
Jan 11 18:22:05 <owrt-snap-builds> build #41 of realtek/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/41
Jan 11 18:22:05 <nlowe> I'm a native English speaker from the UK FWIW, I would love to know what the objection is/was
Jan 11 18:22:13 <Slimey> Hi
Jan 11 18:23:46 <jow> mansy people seem to think that the Microsoft ui text capitalization guidelines are a sane thing to follow: https://docs.microsoft.com/en-us/windows/win32/uxguide/text-ui?redirectedfrom=MSDN#capitalization
Jan 11 18:23:58 <nlowe> https://www.grammarly.com/blog/capitalization-in-the-titles/
Jan 11 18:25:36 <nlowe> Okay, I will cycle through and make consistent to that as best I can
Jan 11 18:28:24 <aparcar[m]> mangix: i paused apk involvement until their next release
Jan 11 21:48:05 <mrkiko> aparcar[m]: hi! I seen your upx PRs
Jan 11 21:48:20 <aparcar[m]> upx?
Jan 11 22:14:24 <mangix> he
Jan 11 22:14:31 <mangix> 's talking about https://github.com/openwrt/openwrt/pull/3771
Jan 11 22:15:50 <mangix> aparcar[m]: can you look into https://patchwork.ozlabs.org/project/openwrt/patch/20210107011431.1412261-1-rosenp@gmail.com/ ?
Jan 11 22:16:49 <mangix> it's for ubox.git
Jan 11 22:18:02 <ynezz> it's wrong
Jan 11 22:18:08 <ynezz> it should be ${uci}
Jan 11 22:18:36 <ynezz> it wont compile correctly when compiled out of the tree for example
Jan 11 22:19:45 <ynezz> I've following in my tree http://sprunge.us/NjbO77
Jan 11 22:19:53 <ynezz> didn't had time to finalize it yet
Jan 11 22:20:36 <mangix> OK
Jan 11 22:20:41 <mangix> I'll remove from patchwork then
Jan 11 22:30:45 <mangix> ynezz: how about this one? https://patchwork.ozlabs.org/project/openwrt/patch/20201225011158.35592-1-rosenp@gmail.com/
Jan 12 00:14:58 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.2% images and 98.4% packages reproducible in our current test framework.)
Jan 12 00:34:35 <russell--> ynezz: using the .config you pointed me at, the build went uneventfully for me.
Jan 12 00:35:19 <russell--> how clean does the buildbot start?
Jan 12 02:40:34 <mrkiko> noltari: ping
**** ENDING LOGGING AT Tue Jan 12 02:59:57 2021