**** BEGIN LOGGING AT Wed Feb 17 02:59:56 2021 Feb 17 03:23:27 build #1 of lantiq/xway is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/lantiq%2Fxway/builds/1 Feb 17 03:36:52 system prerequisite question: we already require libelf-dev on Linux. What's involved in also adding lbdw-dev, from the the same elfutils source? How to ensure buildbots are updated? Feb 17 03:38:35 I'm looking into alternatives to adding elfutils host pkg build in support of a PR (https://github.com/openwrt/openwrt/pull/3855) Feb 17 03:39:45 guidosarducci: the easy way out would be building it from source as a host package. requiring additional build dependencies on the buildbots is a mostly manual process with lots of pain (builds failing on buildbots not updated yet, a lot of user complaints) involved Feb 17 03:42:24 pkgadd: yeah, I took the easy way out in my PR, but didn't know relative effort of changing build dependencies. Sounds as messy as I imagined. Feb 17 03:43:08 pkgadd: one benefit of adding a host build is we can remove an existing libelf-dev dependency. That's probably easier to roll out! :) Feb 17 03:44:38 guidosarducci: the last addition to host side build dependencies was GNU time (instead of 'just' the shell builtin), it was painful, very painful (and has been changed to no longer require it again) Feb 17 03:48:04 also consider that that several developers are using MacOS as host OS, which does complicate things as well (and there are occasional attempts to get OpenWrt to build on FreeBSD, although they rarely get anywhere) Feb 17 03:48:17 pkgadd: heh, the irony stings I'm sure. Thanks for the insight, I'll leave my PR as is. Just need to get some members to review, with an interest in BPF support. Feb 17 03:49:14 pkgadd: yeah, I've already gone done the rabbit hole of OSX/BSD support and ensuring not to break things. Feb 17 03:50:47 pkgadd: nbd also helped to confirm a few things. Unfortunately, build kernel support for BPF/BTF doesn't seem likely for OSX. Feb 17 03:56:02 pkgadd: BTW who are the main OSX devs besides ldir and nbd? Would be good to know going forward... Feb 17 03:58:10 guidosarducci: I was thinking about them Feb 17 03:59:08 Does anyone know offhand the $() shortcut for ./staging_dir/target-/? Feb 17 04:01:11 rules.mk: STAGING_DIR:=$(TOPDIR)/staging_dir/$(TARGET_DIR_NAME) ? Feb 17 04:02:29 So just $(STAGING_DIR)? Thanks! Feb 17 04:02:43 I really should make a cheatsheet, I find them, then forget, then end up here Feb 17 04:03:26 I recently had the same prob... rules.mk is my cheatsheet now Feb 17 04:03:55 I usually grep in ./include, butg yeah, rules is in the root dir so I forget about it Feb 17 04:04:52 build #640 of x86/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2F64/builds/640 Feb 17 04:31:39 guidosarducci: ping Feb 17 04:34:44 mangix: Hey Rosen, what's new. Feb 17 04:36:10 build #1 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ramips%2Fmt76x8/builds/1 Feb 17 04:38:02 guidosarducci: httpstorm on github is also running on macOS. Feb 17 04:41:49 mangix: ah thanks, good to know Feb 17 04:46:29 build #1 of armvirt/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/armvirt%2F64/builds/1 Feb 17 05:46:12 is it better to submit a large patchset (enable port mt7621 patches to 5.10 and other 5.10 enablement changes) via github PR rather than email or doesn't matter? Feb 17 05:55:15 I think what I'll do is a PR and a short email to the list to make people aware Feb 17 05:57:34 lipnitsk: huh? Feb 17 05:58:08 https://github.com/openwrt/openwrt/pull/3693 Feb 17 05:59:57 that stuff is pretty stale, but yeah maybe some duplicate work. I did a bunch of work on some core modules, like wireguard Feb 17 06:00:08 it runs well on my ER-X Feb 17 06:01:27 build #605 of bcm27xx/bcm2711 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/605 Feb 17 06:03:09 mangix: I will link to that PR in my PR, probably won't send an email then and let folks decide which one to take, or maybe we can merge the two somehow Feb 17 06:07:16 although I used a longer form for .ko version deps, may need to fix that ($(if $(CONFIG_LINUX_5_4)) vs @lt5.10 Feb 17 06:07:32 https://github.com/openwrt/openwrt/pull/3876 Feb 17 06:13:03 build #1 of zynq/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/zynq%2Fgeneric/builds/1 Feb 17 06:15:46 aparcar[m]: i don't think that gettext 0.21 should have been merged. nevertheless, let's wait until people complain. BUILD_NLS is not default anyway Feb 17 06:17:02 blogic: does e8450 have only 1 x USB 2.0? Feb 17 06:29:27 rmilecki: many ipq807x 802.11ax devices don't even expose any USB ports at all Feb 17 06:29:39 oh Feb 17 06:32:34 hmm, ltq-tapi and ltq-vdsl-mei compilation seem to have been broken by 5ed1e5140a80558ab47fd70410ae3242bed5becf (build: build kernel image before building modules/packages), https://paste.debian.net/1185775/ Feb 17 06:33:03 mangix: with 5.10 gettext failed to build Feb 17 06:33:28 Why wouldn't you have merged it? Feb 17 06:37:51 I mentioned why in the initial PR. I also set it to draft. In any case, it's see why complains :) Feb 17 06:37:54 *who Feb 17 06:46:27 mangix: strange it worked for me Feb 17 06:50:01 morning! Feb 17 06:50:31 what e-mail should i use to send some patches upstream from git? Feb 17 06:50:39 aparcar[m]: yeah I don't remember which package I noticed issues with Feb 17 06:50:56 we'll see soon when the Turris people find out Feb 17 06:51:02 they build with BUILD_NLS Feb 17 06:51:24 in other news, master does not build with CentOS 7 Feb 17 06:51:27 the end of an era Feb 17 06:53:52 mangix: well thanks for the heads up Feb 17 06:54:54 build #1 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/archs38%2Fgeneric/builds/1 Feb 17 07:03:04 build #723 of lantiq/xway is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/723 blamelist: Rosen Penev , Adrian Schmutzler , Felix Fietkau , David Bauer Feb 17 07:03:29 ah, the buildbots are encountering that lantiq build failures as well, http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/686/steps/pkgbuild/logs/stdio - reverting 5ed1e5140a80558ab47fd70410ae3242bed5becf helps Feb 17 07:03:49 i've just sent am e-mail to openwrt-devel@lists.openwrt.org, anyone with access to that mailbox can confirm it was received, please? Feb 17 07:04:05 subject is mvebu: add linux 5.10 support Feb 17 07:04:08 thanks! Feb 17 07:04:10 mangix: is it because of make 4.1? Feb 17 07:04:51 nitroshift: it's on list, Message-ID: Feb 17 07:05:27 a bit hidden because of DMARC Reject/Quarantine policy clobbering Feb 17 07:05:50 but there it is http://lists.infradead.org/pipermail/openwrt-devel/2021-February/033830.html Feb 17 07:06:04 aparcar[m]: yeah Feb 17 07:06:09 pkgadd, found it, thanks! \0/ Feb 17 07:06:48 mangix: oops Feb 17 07:21:31 nitroshift: russell king's branch has http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=clearfog&id=6362626c710393dec3ab7c83a28aa6821c1d36ea http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=clearfog&id=6362626c710393dec3ab7c83a28aa6821c1d36ea . opinion? Feb 17 07:22:43 actually that branch has a bunch of mvebu stuff Feb 17 07:25:41 russell--: do you have any other mt7621 devices or just the dir-860l? Feb 17 07:30:01 huh. centOS is just like fedora Feb 17 07:31:11 mangix, gonna build afresh with russell's patches included, patches look ok Feb 17 07:32:08 on a different note, i included a patch by mistake in my message, anyone can scrap the message so i can send a new patchset? Feb 17 07:32:32 you can supersede the patch on patchwork Feb 17 07:32:47 mangix, so i send a new message? Feb 17 07:39:03 done Feb 17 08:10:13 mangix: comments on https://github.com/immortalwrt/openwrt-tmate ? I'd like to seee that upstream Feb 17 08:15:01 Is it much smaller than Screen? Feb 17 08:18:16 Borromini: did you find some POE APs with mt76 supported wifi? Feb 17 08:23:47 rmilecki: yes, EAP235-Wall e.g. Feb 17 08:24:31 Borromini: i only tried the affected versions on the dir-860l Feb 17 08:24:40 rmilecki: https://patchwork.ozlabs.org/project/openwrt/patch/20210214100322.246853-1-sander@svanheule.net/ Feb 17 08:24:43 russell--: ok Feb 17 08:24:51 but it went away in the next kernel bump Feb 17 08:25:18 rmilecki: been test driving it for weeks, the mt7613 doesn't do dfs for now with mt76 though Feb 17 08:25:22 i got feedback from the author of the upstream kernel commit that more "dependent" patches went into the later stable kernel Feb 17 08:25:34 russell--: cool. Feb 17 08:25:36 which might explain it Feb 17 08:25:58 Borromini: thanks! Feb 17 08:26:03 i tried an erx after the problem went away and it didn't have a problem, but that doesn't really tell us anything Feb 17 08:26:24 i am happy to pretend it never happened Feb 17 08:26:34 at least until it comes back Feb 17 08:26:42 rmilecki: looking for some? :) Feb 17 08:26:53 russell--: hehe. Feb 17 08:27:06 Borromini: yeah, i may want one Feb 17 08:27:13 :^) Feb 17 08:27:40 it's one of the few wall mounted ones on the market i think (Ubiquiti has one as well i thought but more expensive) Feb 17 08:28:17 i was looking for such AP about a year ago and couldn't find anything affordable Feb 17 08:28:21 nice there are som options now Feb 17 08:28:34 yeah i know what you mean. this one goes for ~75 EUR Feb 17 08:29:03 which isn't too bad i'd say given you get PoE as well Feb 17 08:29:05 rmilecki: I believe Ubnt's nanoHD is also PoE. Feb 17 08:29:20 MT7603 and MT7615. Feb 17 08:29:49 * russell-- just pulled apart a netgear gs108e-v3 switch after seeing the support for gs108t-v3, but a) flash is only 2MB (16Mbits) and soc covered by a heatsink and no obvious serial console, so i put it back together. i did just buy some gs108t-v3's which should arrive tomorrow. Feb 17 08:29:57 rsalvaterra: nice! Feb 17 08:30:41 Yep! It is: https://unifi-nanohd.ui.com/ Feb 17 08:30:44 russell--: never hurts to try eh :) Feb 17 08:31:20 * russell-- misses the old vigorous wikidevi Feb 17 08:31:48 i added the eap235 to wikidevi.cat-ru something and i have to say its admin is *very* precise Feb 17 08:31:56 * rsalvaterra misses wikidevi too… :( Feb 17 08:32:35 Borromini: but the URL is not exactly easy to remember… :P Feb 17 08:32:46 deviwiki.com is also a thing Feb 17 08:33:28 russell--: nope :P Feb 17 08:33:35 i wonder if they sync between one another Feb 17 08:33:50 since there's devices on one and not another... gets kinda clumsy with all those clones Feb 17 08:33:59 I wonder why they don't join efforts… Feb 17 08:34:49 rmilecki: the UniFi AP AC In-Wall HD (UBNT should really fix its naming) is Mediatek too Feb 17 08:34:59 but another price range than the eap235. Feb 17 08:36:24 rmilecki: MT7615 (EAP is MT7613) and MT7603 Feb 17 08:37:01 Heh… Ubnt is the Apple of networking equipment. :P Feb 17 08:38:03 and the Intel when it comes to model names? :P Feb 17 08:38:26 Pretty much, yes. :) Feb 17 08:38:36 =) Feb 17 08:39:23 * rsalvaterra is trying to figure out how in blazes his mvebu build broke so spectacularly… Feb 17 08:40:02 * Borromini is gonna try his hand at another MT7613 DFS hack Feb 17 08:41:14 Oh, is your MT7613 already working? Feb 17 08:41:42 it is yes Feb 17 08:41:52 and with the latest mt76 bump it seems a bit more stable Feb 17 08:42:07 it was already working, just crapping out when idle somehow. Feb 17 08:42:27 I'm still running with the GTK rekeying hack… Feb 17 08:42:29 both APs up 30h+ now Feb 17 08:42:38 rsalvaterra: doesn't fully solve the mt7615 issue? Feb 17 08:43:27 Yes, the hack completely "solves" the problem, but it would be nice if GTK offloading worked as it should… Feb 17 08:45:55 rsalvaterra: who says the hardware is not broken :) Feb 17 08:45:57 Borromini: so I can drop the "borks out when idling" notice from the EAP235 commit message? :-) Feb 17 08:47:02 mangix: That's why I wrote "it would be nice", but I'll remorsefully settle with "the hardware is broken", of course. :P Feb 17 08:47:48 mediatek went interesting with mt79xx Feb 17 08:48:34 rate control in hardware Feb 17 08:48:36 wonder why Feb 17 08:48:36 Really interesting? Or Terry Pratchett interesting? Feb 17 08:49:31 svanheule: i'd err on the side of caution. maybe rephrase and say it can do so occasionally? Feb 17 08:49:37 s/can/might/ Feb 17 08:52:18 * Borromini has learned to be cautious. sometimes. Feb 17 08:52:25 :-) Feb 17 09:01:08 Is there anyway to tell dnsmasq something like "hey, please solve all DNS request to /host.domain/ through the DNS servers supplied by DHCP to this interface"? Feb 17 09:02:48 Right now I have the DNS servers hardcoded (option server '/host.domain/'), but feels rather inelegant and brittle. Feb 17 09:03:02 you had me up until the last 6 words Feb 17 09:03:48 Huh? :P Feb 17 09:04:34 "supplied by DHCP to this interface" Feb 17 09:05:35 * russell-- uses the static solution you noted Feb 17 09:05:41 Well, yes… Imagine a triple-play ISP, which provides you three upstream connections (internet, IPTV and VoIP). Feb 17 09:07:44 I just worry for some crazy reason the DNS addresses might change, but maybe I'm overthinking… Feb 17 09:08:08 every five minutes, in cronjob, snarf the servers, uci set the thing you want, and reload dnsmasq, OR read the dnsmasq manpage until your eyes cross ;-) Feb 17 09:09:40 I… no. That's horrid. And yes, I thought about it. :P Feb 17 09:10:14 :P Feb 17 09:10:25 * rsalvaterra read the whole dnsmasq man page way too many times… :D Feb 17 09:12:01 I believe the main problem is dnsmasq assuming all DNS servers are functionally equivalent. Feb 17 09:12:42 It just gobbles up whatever gets pushed into resolv.conf. Feb 17 09:17:51 philipp64: honestly with your PR storm I don't know what to look at first. ping me in the weekend Feb 17 09:25:45 Hauke: https://github.com/openwrt/packages/issues/14771 <-- is this an issue? Feb 17 09:26:29 rsalvaterra: it's interesting because every manufacturer does rate control in hardware badly Feb 17 09:27:01 the reason they do it is for power savings, mostly for phones Feb 17 09:27:30 mangix: If only they did minstrel_ht in hardware… :) Feb 17 09:29:28 I was now about to ask how to set the 802.11Q PCP on a DSA VLAN in UCI, but I think I know the answer already… Feb 17 09:29:29 * mangix wonders if he should replace Fedora with CentOS Feb 17 09:29:41 *802.1Q Feb 17 09:31:00 build #1 of mpc85xx/p1020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mpc85xx%2Fp1020/builds/1 Feb 17 09:32:04 Grommish: you got octeon stuff right? is your timezone reporting correctly? both my EdgeRouter 4 and EdgeRouter Lite stubbornly stick to UTC, whatever I try Feb 17 09:34:13 # uci show system | grep timezone Feb 17 09:34:13 system.@system[0].timezone='PST8PDT,M3.2.0,M11.1.0' Feb 17 09:34:45 russell--: that's all good here. it's a uci preset on all my devices. it just refuses on the octeon ones for some reason. Feb 17 09:35:03 weird Feb 17 09:35:05 uci show system|grep timezone Feb 17 09:35:10 system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3' Feb 17 09:35:10 yeah very uch so. Feb 17 09:35:14 * much Feb 17 09:36:03 already tried a lot of things (had tzdata on my devices but one doesn't need that, so it's gone now) but no dice. Feb 17 09:43:27 Borromini: do you have /etc/TZ symlink there and does it point to /tmp/TZ with that string inside? Feb 17 09:43:44 PaulFertser: yes Feb 17 09:43:59 Borromini: and yet when you type "date" it prints UTC? Feb 17 09:44:03 yeah Feb 17 09:44:13 shows in LuCI as well Feb 17 09:44:37 it's a local uci defaults preset. works on all my targets. except for octeon which keeps showing utc somehow. Feb 17 09:44:53 i checked, no hardware clock on either of those octeon devices i have Feb 17 09:45:19 Borromini: I just tried echo CET-1CEST,M3.5.0,M10.5.0/3 > /tmp/TZ; date , works as expected Feb 17 09:46:00 Borromini: there must be something special in your build so that musl doesn't honour /etc/TZ and instead expects something else if that doesn't work. Feb 17 09:46:04 PaulFertser: thanks. like i said: it all looks good. it's identical to what i have on ramips/ath79/... devices. except it doesn't work Feb 17 09:47:13 Borromini: is "echo $TZ" empty? Feb 17 09:47:48 PaulFertser: it is Feb 17 09:48:08 Borromini: is that build on octeon using musl? Feb 17 09:48:09 also is on a functional mt7621 device Feb 17 09:48:11 yeah Feb 17 09:48:36 https://paste.debian.net/1185787/ < that's my diffconfig for octeon Feb 17 09:49:16 i'm not seeing anything wonky there Feb 17 09:49:39 A rather odd issue. Feb 17 09:50:06 yep. Feb 17 09:50:23 Does "TZ=CET-1CEST,M3.5.0,M10.5.0/3 date" work? Feb 17 09:51:24 build #1 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ramips%2Frt305x/builds/1 Feb 17 09:51:38 PaulFertser: yeah that works Feb 17 09:56:15 Borromini: do you by any chance have strace there? Feb 17 09:56:25 no Feb 17 09:56:37 It's pretty clear from toolchain/musl/patches/110-read_timezone_from_fs.patch that if TZ is unset then the file is read. Feb 17 09:56:38 i can build that though and install Feb 17 09:56:49 Hm, I'd try to do explitic "unset TZ" Feb 17 09:56:56 Probably it's there but empty Feb 17 09:57:08 yes it seems so Feb 17 09:57:12 Hm, that should still lead to file, I just checked. Feb 17 09:57:24 i did unset TZ and now date prints CET just fine :-/ Feb 17 09:57:29 Borromini: comment or revert https://github.com/openwrt/openwrt/commit/157cd0bd97bcfec8a34d4ebb558f37bee4f0515f Feb 17 09:57:32 Borromini: aha! Feb 17 09:57:51 Borromini: echo $TZ | hexdump -C Feb 17 09:58:07 mangix: it's been going on before that, that's 3 days old, so i don't think it's that? Feb 17 09:58:14 (before unset of course) Feb 17 09:58:35 PaulFertser: sec Feb 17 09:59:49 PaulFertser: sorry, false alarm. was on a mips device in the meantime Feb 17 10:00:07 unsetting TZ doesn't change anything on the octeon Feb 17 10:01:06 https://paste.debian.net/plain/1185790 Feb 17 10:04:59 aparcar[m]: is 'macbot' still useful to you? Feb 17 10:05:42 ldir: semi, it's been offline lately Feb 17 10:06:49 Borromini: it should certainly be looking into /etc/TZ then, you see the musl patch... Feb 17 10:07:09 aparcar[m]: I don't know how to restart the buildbot processes so can't kick it when apple do an auto update/restart. Feb 17 10:07:10 ldir: is online again but I get this: zsh: /Volumes/CaseSense/aparcar/worker/.direnv/bin/buildbot-worker: bad interpreter: /Volumes/CaseSense/aparcar/worker/.direnv/bin/python3: no such file or directory Feb 17 10:07:42 ldir: I think long term I'd switch back to gitlab workers again, I really don't want to spend to much time on buildbots Feb 17 10:08:17 if you can spare the resources, I'm happy to use them, if not, I'll find another bored mac Feb 17 10:10:17 I think it would be better to find another genuinely spare/bored mac.... there are occasions when this one becomes un-spare - hmmm. But the error is curious. Feb 17 10:10:20 what is this macbot? Feb 17 10:10:27 PaulFertser: yeah... if setting the full TZ works, does that say anything? Feb 17 10:10:44 mangix: build testing on a mac via buildbot/ci Feb 17 10:11:06 do all packages build on macOS? Feb 17 10:11:44 and yes the network isn't the most stable 'cos it's my home net...and I regularly rebuild openwrt on the home router for obvious reasons Feb 17 10:11:47 mangix: never dared to try, only all targets Feb 17 10:12:05 mangix: No. They do not. Feb 17 10:12:45 Is macOS officially supported? Feb 17 10:12:51 mangix: no Feb 17 10:12:55 mangix: it's a semi-spare/idle mac mini I have in the office room. Feb 17 10:12:59 it's a hobby project within this hobby project Feb 17 10:13:04 Borromini: what do you mean by "setting the full TZ"? Feb 17 10:13:21 PaulFertser: what is this /etc/TZ ? google doesn't reveal much Feb 17 10:14:03 mangix: uclibc reads that file when TZ env variable is not present. So OpenWrt counted on that, and when musl was added, a patch for musl to do the same was committed. Feb 17 10:14:22 Is it needed? Feb 17 10:15:16 my reading of musl code is that if no TZ env, it ready /etc/localtime Feb 17 10:15:27 which is currently a dead symlink Feb 17 10:15:38 mangix: some devs use macos and some users (me) build on it too - it's useful to know that at least 'core' openwrt builds under alternate, non-mono culture OSs Feb 17 10:15:39 to /tmp/localtime Feb 17 10:15:39 mangix: I'm talking about toolchain/musl/patches/110-read_timezone_from_fs.patch Feb 17 10:15:53 i am too Feb 17 10:16:11 mangix: do you have a spare mac for me? Feb 17 10:16:28 i do not Feb 17 10:16:40 And package/base-files/files/etc/init.d/system Feb 17 10:17:02 i tried setting up openwrt on a jailbroken iphone. no C compiler though Feb 17 10:17:05 I'm thinking to request some github sponsoring to buy a mac mini for ci testing... mhh Feb 17 10:17:30 mangix: /etc/localtime is used when you specify a zonename and you have the tzinfo database I think Feb 17 10:17:47 mangix: mhh sad that would be a nice cluster Feb 17 10:18:12 PaulFertser: yeah but instead of using /etc/TZ , why not use /etc/localtime ? Feb 17 10:18:38 mangix: because TZ contains full timezone definition while localtime only a timezone name Feb 17 10:18:52 aparcar[m]: I read recently but can't remember where that someone had mac mini M1s in a data centre for hire.... wish I could remember the story Feb 17 10:20:05 am so busy at the moment with sound work that the brain context switches between 'sound/openwrt' are failing Feb 17 10:20:28 PaulFertser: you mean the other way around Feb 17 10:20:40 ldir: well keep me posted :) Feb 17 10:20:45 * ldir needs a brain upgrade Feb 17 10:21:23 don't use opkg for that Feb 17 10:21:33 use pacman for that Feb 17 10:21:38 mangix: no, e.g. TZ=CET-1CEST,M3.5.0,M10.5.0/3 date works without any timezone names. Same if you put that value in /etc/TZ. Feb 17 10:21:53 aparcar: https://www.theregister.com/2021/02/02/m1_as_a_service/ Feb 17 10:22:15 While /etc/localtime on my Debian is a symlink to a file inside /usr/share/zoneinfo/ Feb 17 10:24:50 ldir: thanks. I'll check that out Feb 17 10:25:11 PaulFertser: I don't think you understand.https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/system#L25 sets up everything. why not use the value of /tmp/TZ as /tmp/localtime ? Feb 17 10:26:00 afair /etc/localtime is only used by glibc Feb 17 10:26:16 aparcar[m]: I was quite tempted to hire one myself to see how quick the M1s are but then life went (even more) mental. Feb 17 10:26:45 jow: https://git.musl-libc.org/cgit/musl/tree/src/time/__tz.c#n135 Feb 17 10:27:14 mangix: ah right, that was uclibc knowledge. musl has limited tzdb handling Feb 17 10:27:35 I was ordering an ARM Mac Mini for similar purposes but in Eastern Europe it was going to take several months to get it Feb 17 10:27:36 morning Feb 17 10:27:40 so I said f* that Feb 17 10:28:08 are/were there plans to move './scripts/feeds update/install -a' to be kind of 'make feeds_update' and then mentioned in 'make help'? Feb 17 10:28:27 stintel: you don't just buy a Mac, that would be too ordinary Feb 17 10:28:36 jow: =) Feb 17 10:28:56 hrw: no Feb 17 10:29:00 ldir: I'll write them may e they give me one for testing ;) Feb 17 10:29:04 jow: thx Feb 17 10:30:01 jow: my question is what's wrong with this? https://gist.github.com/neheb/7356492f2733272d6b837ddcd5bcc097 Feb 17 10:30:08 aparcar[m]: fingers crossed Feb 17 10:30:48 mangix: /tmp/TZ is a OpenWrt specific replacement for the $TZ env var which in turn is supposed to contain a POSIX timezone spec Feb 17 10:31:13 mangix: /tmp/localtime (symlinked to by /etc/localtime) is supposed to be a symlink to a tzdb Feb 17 10:31:41 writing a POSIX tz rule string into a file supposed to be a binary compiled tzdb makes no sense Feb 17 10:33:10 it's beasically two unrelated mechanisms to specify the timezone Feb 17 10:33:34 right. with strings on Debian's /etc/localtime , the last line is identical to what OpenWrt writes to /tmp/TZ Feb 17 10:33:34 the former encodes all the required changeover info directly in the rule spec (like TZ=CET-1CEST,M3.5.0,M10.5.0/3) Feb 17 10:33:54 the latter is a compiled database of historical and current DST rules Feb 17 10:34:13 yes, some tzdb files contain a posix rule spec equivalent at the end Feb 17 10:34:23 but not all Feb 17 10:35:12 might be that musl's implementation is even able to parse a tzdb generated from `echo CET-1CEST,M3.5.0,M10.5.0/3 > /tmp/localtime) Feb 17 10:35:24 but not sure if that is correct Feb 17 10:35:32 if e.g. glibs is able to handle it Feb 17 10:35:38 or other tzdb parsers Feb 17 10:35:49 I'd expect it to need at least some framing or a special header Feb 17 10:36:05 interesting Feb 17 10:36:12 i wonder how alpine handles this Feb 17 10:36:30 https://git.musl-libc.org/cgit/musl/tree/src/time/__tz.c#n179 Feb 17 10:36:45 even musl seems to bail out if no magic `TZif` header is present Feb 17 10:36:57 and if the file is smaller than 44 bytes Feb 17 10:38:38 on an unrelated note, what's wrong with this sed line? https://github.com/openwrt/openwrt/pull/3763#issuecomment-757620163 Feb 17 10:39:10 mangix: maybe the version number is not on the first line anymore? Feb 17 10:39:14 PaulFertser: prefixing date with the full TZ value like you suggested for testing Feb 17 10:39:26 jow: no it is Feb 17 10:39:26 mangix: what's the exact output of `./gettext -V` ? Feb 17 10:39:32 0.21 Feb 17 10:39:38 erm my bad Feb 17 10:40:05 the sed pattern expects a three digit version Feb 17 10:40:07 gettext (GNU gettext-runtime) 0.21 Feb 17 10:40:55 use sed -rne '1s/.*([0-9]\.[0-9]{2}(\.[0-9])?).*/\1/p' Feb 17 10:42:38 or even better sed -rne '1s/.*\b([0-9]\.[0-9]+(\.[0-9]+)?)\b.*/\1/p' Feb 17 10:44:19 is there a way to build one package? I got "ERROR: package/feeds/packages/mc failed to build." and would love to build only that one as doing 'make -j1 V=s' tries to build a bunch of stuff and finally gets to failed one Feb 17 10:44:47 hrw: make package/mc/{clean,compile} V=s Feb 17 10:44:53 jow: thanks Feb 17 10:44:53 jow gave you an answer Feb 17 10:45:13 edit include/autotools.mk with that sed line Feb 17 10:50:06 nbd: ping. 5ed1e5140a80558ab47fd70410ae3242bed5becf broke my mvebu build (Turris Omnia), reverting fixes it. Feb 17 10:50:24 hrw, mangix: can you try this patch? http://sprunge.us/Xoz107 Feb 17 10:51:18 jow: will check. Feb 17 10:52:03 jow: as I read this I sent a patch to the mailing list Feb 17 10:52:10 mangix: ah okay Feb 17 10:52:56 guys, i am seeing a single package fail with opkg... Feb 17 10:52:59 https://paste.debian.net/plain/1185801 Feb 17 10:53:17 out of six kmod-mt76* package this one package errors out ^^ Feb 17 10:53:37 (this is on a running master firmware not during image compilation in the buildroot) Feb 17 10:54:50 Borromini: failures as a result of the ABI stuff I think Feb 17 10:55:06 mangix: yeah looks like it Feb 17 10:55:47 rsalvaterra: can you give me some details? Feb 17 10:56:02 Borromini: can you pastebin the result of tar -Oxzf /tmp/kmod-mt76_5.4.98\+2021-02-14-289cd780-5_mipsel_24kc.ipk ./control.tar.gz | tar -Oxz ./control Feb 17 10:56:33 interesting Feb 17 10:56:43 alpine does not use /etc/localtime Feb 17 10:56:49 but does set $TZ Feb 17 10:57:13 nbd: I don't have many… with that commit, the kernel is the first thing to be built (after the toolchain), apparently, but it fails. Feb 17 10:57:34 ah. they use zoneinfo Feb 17 10:57:47 nbd: cc1: fatal error: symtab.h: No such file or directory Feb 17 10:58:45 jow: https://paste.debian.net/plain/1185804 Feb 17 10:58:52 it's a metapackage Feb 17 11:00:18 nbd: I can provide you with my configs (OpenWrt and kernel), but this happens on a pristine master, so I'm quite sure it's unrealted. Feb 17 11:00:30 *unrelated Feb 17 11:01:02 jow: from 'make clean' to 'build me mc for aarch64-a53' without issues Feb 17 11:01:48 hrw: so the patch worked? Feb 17 11:02:19 rsalvaterra: please try this patch: https://termbin.com/4wulx Feb 17 11:02:31 rsalvaterra: i think it's related to kernel symbol export stripping Feb 17 11:02:53 nbd: will do, thanks! Feb 17 11:02:54 which is not turned on by default Feb 17 11:03:14 jow: yes Feb 17 11:03:38 nbd: oh, I *always* enable stripping, as it reduces the size quite a bit. Feb 17 11:05:15 rsalvaterra: which config option is that? Feb 17 11:05:24 * Borromini gets a bit lost in the stripping options in the buildroot Feb 17 11:06:34 Borromini: CONFIG_STRIP_KERNEL_EXPORTS. I actually fixed it a while ago, it was completely broken on 64-bit kernels. Feb 17 11:07:28 ok :) Feb 17 11:07:33 why are changes like this required? https://github.com/openwrt/openwrt/pull/3875/files Feb 17 11:07:43 does it mean that manual abi versions are broken now? Feb 17 11:08:08 rsalvaterra: turns out i already have that enabled on small flash Feb 17 11:08:22 jow: it shouldn't be required. maybe it was based on the previous patches that got reverted Feb 17 11:08:43 nbd: ah okay Feb 17 11:10:15 the only place in the build system core that uses PKG_ABI_VERSION is when you set PKG_FIXUP = libtool-abiver Feb 17 11:10:26 which i used for wolfssl Feb 17 11:19:26 nbd: still building, but it seems happier with your patch… fingers crossed. :) Feb 17 11:22:17 hm. Feb 17 11:22:22 * pkg_hash_fetch_best_installation_candidate: Packages for libreadline8 found, but incompatible with the architectures configured Feb 17 11:22:24 * opkg_install_cmd: Cannot install package libreadline8. Feb 17 11:22:33 while './bin/packages/aarch64_cortex-a53/base/libreadline8_8.1-1_aarch64_cortex-a53.ipk' exists Feb 17 11:26:41 ok, tracked last user of it and now have finally image for ebin Feb 17 11:29:29 jow are u okay if I take care of owipcalc maintenance? Feb 17 11:30:05 build #1 of x86/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/x86%2F64/builds/1 Feb 17 11:32:15 nbd: my build problem appears to have gone away... I have no idea what caused the problem in 1st place. Feb 17 11:47:18 build #1 of sunxi/cortexa7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/sunxi%2Fcortexa7/builds/1 Feb 17 11:59:52 nbd: good news, your patch fixed my build. Thanks! :) Feb 17 12:03:05 * rsalvaterra can finally test his device tree backport… :P Feb 17 12:24:13 Hi all! Feb 17 12:25:57 Where can I contact someone regarding Archer C7 v5 last build ? Just bricked my router using the last 19.07.7 sysupgrade Feb 17 12:26:17 Upgrading from 19.07.6* Feb 17 12:28:21 SecT0uch: more details needed. Do you have a serial log? Feb 17 12:29:31 SecT0uch: or are you able to enter generic failsafe? Feb 17 12:32:35 PaulFertser: Unfortunately I don't have serial cable :'(. However, I can say that: I did have a warning saying the image is not compatible, but I doubled check everything and everything was OK. (Version, hardware, sha256sum) Feb 17 12:35:41 SecT0uch: did you probably save the log with that sign visible? Feb 17 12:36:20 PaulFertser: I'll connect via cable and read about failsafe mode. and come back to you. Feb 17 12:36:36 SecT0uch: you do not need serial to use generic failsafe. Feb 17 12:36:58 SecT0uch: I mean probably the configs are incompatible though it shouldn't happen. You can't retrive the old log unfortunately. Feb 17 12:37:09 SecT0uch: do you probably happen to remember what exactly the mismatch was? Feb 17 12:37:25 I did did not save any log. I feel so stupid. Feb 17 12:37:43 SecT0uch: btw, were you using ar71xx or ath79 before the upgrade? And what image did you upgrade to? Feb 17 12:38:25 PaulFertser: I upgraded via Luci and couldn't see what was the mismatch, everything seemed OK. But yeah, I did keep the configuration Feb 17 12:39:04 PaulFertser: ar71xx, upgraded to openwrt-19.07.7-ar71xx-generic-archer-c7-v5-squashfs-sysupgrade.bin Feb 17 12:40:26 SecT0uch: hm, that shouldn't have been problematic. But ar71xx receives really little attention lately. Guess you just need to use some TFTP recovery method and flash current ath79 release now, and forget about the unsuccessful upgrade. Unless you want to try to reproduce it. Feb 17 12:40:46 SecT0uch: did you try generic failsafe already? Or generic reset? Feb 17 12:49:34 nbd: I believe your ABI rework somehow broke abstract provided packages Feb 17 12:49:49 nbd: specifically, libncursesw6 appears to be not available Feb 17 12:50:31 i will look into it Feb 17 12:50:32 libncursesw is provided by libncurses Feb 17 12:50:38 through PROVIDES Feb 17 12:51:40 just to clarify, you mean it broke adding the ABI suffix to dependencies on libncursesw, right? Feb 17 12:51:54 no, ncursesw does not appear at all in the feeds Feb 17 12:52:03 (opkg list | grep cursesw is empty) Feb 17 12:52:15 in my test, the package has 'Provides: libncursesw, libncurses, libncursesw6' Feb 17 12:53:03 right, seeing it Feb 17 12:53:08 for me it is: "Provides: libncursesw, libncurses, libncursesw Feb 17 12:53:09 " Feb 17 12:53:13 PaulFertser: Never mind after connecting via cable everything works fine, only the router's wireless device is not active and wireless not associated (via luci). I have no idea why Feb 17 12:53:41 jow: does it work for you if you explicitly rebuild libncurses? Feb 17 12:54:07 I am testing the snapshot repo Feb 17 12:54:14 to reproduce bug reports Feb 17 12:54:22 Is Linux 5.10 going to be the target for ipq40xx in the 21.02 branch? Feb 17 12:54:35 barhom: 21.02 is going to use whats used right now Feb 17 12:54:39 so, no Feb 17 12:54:59 (unless the policy changed recently) Feb 17 12:56:51 nbd: hm, package repo is ~70 hours old, so likely predating whatever fixes you made Feb 17 12:58:10 jow: then 7d6a636918bccf68b49324729759e7c569105f71 should probably fix this Feb 17 12:58:10 need to revisit this after the next rebuild Feb 17 12:59:34 SecT0uch: probably you didn't keep the settings then. Probably forcing implies that. Feb 17 13:01:17 barhom: 5.4. 5.10 is next master kernel, after the 21.02 branching Feb 17 13:01:55 Borromini, I must have misread the commits. I thought some targets got 5.10 already in 21.02 Feb 17 13:05:19 PaulFertser: I can still see my config (SSID, passphrase, etc..). As recommended, I will start by upgrading to ath79. Shouldn't it be the default image offered by the firmware selector ? Feb 17 13:08:45 SecT0uch: it should be but I have no idea what firmware selector is :) Feb 17 13:10:32 barhom: oh, no. any reason you'd need it? Feb 17 13:10:43 PaulFertser: After checking on the Archer C7 page I do see ath79 as the default image proposed. I were right I must have flashed ar71xx on an ath79! The firmware selector confused me. Thanks a lot Feb 17 13:11:18 Borromini, not really. Would just be nice to have wireguard included in the kernel in the next stable openwrt. But no real reason! Ive been tracking master for a while now and its time to track 21.02 instead for my projects Feb 17 13:11:23 SecT0uch: that explains it! Feb 17 13:11:51 SecT0uch: upgrade to ath79 keeping configs and you'll have wireless back without changes I guess. Feb 17 13:12:38 PaulFertser: https://firmware-selector.openwrt.org , advertised here: https://openwrt.org/releases/19.07/notes-19.07.7 Feb 17 13:13:22 Backuped this time, let's flash it! :) Feb 17 13:14:41 SecT0uch: guess aparcar[m] might be interested in your story. Feb 17 13:15:18 barhom: yeah feel the same :P time to switch and hopefully the dust settles quickly. Feb 17 13:21:00 PaulFertser, aparcar[m]: Of course! There is no build yet for my target in 19.07.7. If I select 19.07.6 I have the choice between both ar71xx and ath79. Guess I will have to wait a few days. I feel so stupid! Again, thanks for your help Feb 17 13:21:48 And thanks all of you who work on that project, you're awesome! Feb 17 13:51:14 nbd: ryder lee has been explaining to me how to simulate a radar event, but i'm not sure how to proceed https://forum.openwrt.org/t/can-open-source-drivers-ever-be-as-good-as-proprietary-ones/72832/71 Feb 17 13:52:18 i did an echo "1" > /sys/kernel/debug/ieee80211/phy1/mt76/radar_trigger and that sure triggers stuff but it's unclear to me how (and into which files in debugfs) i should feed the pulse_start_time-pulse_width-pulse_power command and the radar pulse pattern? Feb 17 14:23:39 build #1 of ramips/mt7620 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ramips%2Fmt7620/builds/1 Feb 17 14:24:51 build #100 of realtek/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/100 Feb 17 14:33:27 grrrrrr and now I have the build problem back, this time on 'macbot'....and I have to go to work so no time to investigate. arrrghhhh Feb 17 14:43:54 Is there something I can do so that it builds more quickly if all I did was add some files into /files ? Right now, rebuilding takes me at least 15 minutes Feb 17 14:50:59 barhom: make -j$(nproc) Feb 17 14:53:11 SecT0uch: Often the compat message has to do with changes in partitioning Feb 17 14:53:20 ah, but they're gone Feb 17 14:54:23 mangix: ping Feb 17 15:00:23 Borromini, I learned something with $(nproc). Thanks for that. But yes, I already do -j8. Feb 17 15:02:19 ok. you could use ccache Feb 17 15:02:37 that will speed up subsequent builds, but ccache can occasionally cause problems Feb 17 15:02:51 what hardware are you on? Feb 17 15:05:40 barhom: the most selective make command for your use case is "make target/linux/install V=s" Feb 17 15:05:59 if that takes 15m as well then there's not much you can do unfortunately Feb 17 15:06:17 unless you're building dozens of images (e.g. on ar71xx with the generic profile) Feb 17 15:06:28 in this case it might make sense to only build for your particular device Feb 17 15:09:57 Im just building one target on ipq40xx, Ill give that a try. Thanks jow Feb 17 15:12:06 build #1 of ramips/mt7621 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ramips%2Fmt7621/builds/1 Feb 17 15:12:31 Ok, guys… anyone with a Turris Omnia in production? Feb 17 15:33:54 nbd: please check https://github.com/openwrt/openwrt/pull/3875#issuecomment-780636478 (PKG_ABI_VERSION) Feb 17 15:37:10 just commented Feb 17 16:01:05 kab-el: ping :) Feb 17 16:54:05 stintel: at this point, it's really only PR #14708 and #14711 (minor). there's some minor cleanup from #14028 that I can salvage and move into smaller PR's for manageability, but that's less pressing. Feb 17 18:01:38 mangix: which packages fail? Feb 17 18:03:05 barhom: did you activate all packages from the feeds? Feb 17 18:03:15 this increases the build time from my experinece Feb 17 18:49:11 build #237 of armvirt/64 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F64/builds/237 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:16 build #271 of ramips/rt3883 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/271 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:21 build #272 of ar71xx/mikrotik is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/272 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:26 build #276 of mvebu/cortexa72 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/276 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:31 build #277 of armvirt/32 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/277 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:36 build #271 of mediatek/mt7622 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7622/builds/271 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:41 build #266 of mediatek/mt7623 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7623/builds/266 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:46 build #296 of mvebu/cortexa9 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa9/builds/296 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:51 build #292 of mvebu/cortexa53 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/292 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:49:56 build #281 of archs38/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/281 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:01 build #269 of x86/geode is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/269 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:06 build #277 of kirkwood/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/kirkwood%2Fgeneric/builds/277 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:10 build #232 of lantiq/falcon is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/232 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:16 build #217 of ipq40xx/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/217 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:21 build #215 of lantiq/xway_legacy is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway_legacy/builds/215 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:26 build #215 of sunxi/cortexa8 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa8/builds/215 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:31 build #229 of x86/legacy is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/229 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:36 build #232 of mxs/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/232 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:41 build #230 of lantiq/xrx200 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/230 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:46 build #221 of brcm2708/bcm2709 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/221 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:51 build #230 of brcm2708/bcm2708 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2708/builds/230 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:50:56 build #235 of octeon/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/octeon%2Fgeneric/builds/235 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:01 build #218 of x86/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeneric/builds/218 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:06 build #216 of at91/sama5 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsama5/builds/216 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:11 build #217 of ath79/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fgeneric/builds/217 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:15 build #214 of samsung/s5pv210 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/samsung%2Fs5pv210/builds/214 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:21 build #209 of mpc85xx/p2020 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fp2020/builds/209 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:26 build #216 of brcm63xx/smp is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm63xx%2Fsmp/builds/216 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:31 build #219 of ramips/mt7620 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7620/builds/219 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:36 build #212 of ramips/mt7621 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7621/builds/212 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:41 build #233 of layerscape/armv7 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv7/builds/233 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:46 build #209 of ath79/tiny is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Ftiny/builds/209 blamelist: Eneas U de Queiroz , Hauke Mehrtens Feb 17 18:51:51 build #238 of brcm47xx/legacy is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm47xx%2Flegacy/builds/238 blamelist: Eneas U de Queiroz Feb 17 18:51:55 build #243 of zynq/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/243 blamelist: Eneas U de Queiroz Feb 17 18:52:00 build #247 of bcm53xx/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/bcm53xx%2Fgeneric/builds/247 blamelist: Eneas U de Queiroz Feb 17 18:52:05 build #243 of brcm2708/bcm2710 is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2710/builds/243 blamelist: Eneas U de Queiroz Feb 17 18:52:10 build #243 of omap/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/omap%2Fgeneric/builds/243 blamelist: Eneas U de Queiroz Feb 17 18:52:15 build #275 of mpc85xx/generic is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fgeneric/builds/275 blamelist: Eneas U de Queiroz Feb 17 18:52:20 build #271 of layerscape/armv8_64b is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/271 blamelist: Eneas U de Queiroz Feb 17 18:52:25 build #228 of apm821xx/nand is complete: Failure [failed gitcheckout] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/apm821xx%2Fnand/builds/228 blamelist: Eneas U de Queiroz Feb 17 19:43:44 What happened here? Feb 17 19:50:55 that was because you had 30 in /etc/selinux/semanage.conf which was not the latest avialable version Feb 17 19:51:07 ignore wrong chan Feb 17 20:08:00 bye all Feb 17 20:16:51 Is it now normal that OpenWrt builds all kernel objects already in the beginning where it previously only build the modules? Feb 17 20:18:25 just saw this: https://git.openwrt.org/5ed1e5140a80558ab47fd70410ae3242bed5becf Feb 17 20:44:16 ah, it looks like the missing builders went back online (but broken) Feb 17 20:46:26 blocktrron: are you around? Feb 17 20:51:46 should be fixed Feb 17 20:55:14 barhom: build the image-builder SDK and build on top of that. Feb 17 20:55:22 Much of the build time is building the toolchain. Feb 17 20:57:29 mkresin: sure Feb 17 21:00:13 Hauke: can you check that the release build went well anyway? Feb 17 21:04:19 blocktrron: noticed that you are about merge/pick https://github.com/openwrt/openwrt/commit/ebba9fbe5d6b96e52475a924129b339aa97bdcb4 Feb 17 21:05:11 blocktrron: the "if $(CONFIG_LINUX_5_4 .." syntax in the changes is uterly wrong Feb 17 21:05:36 blocktrron: we habe lt5.4 or ge5.10 for that purpose Feb 17 21:07:29 blocktrron: have a look at https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=019d8733eb2c1f0cc0a7277cddf4573e8fae8628 for illustration Feb 17 21:07:36 rsalvaterra: hello Feb 17 21:08:32 zorun: yes everything went well Feb 17 21:08:37 at lest I do not see any error message Feb 17 21:08:56 mkresin: i've dropped that one for now, because it's also incomplete Feb 17 21:09:11 cool, thanks! Feb 17 21:09:14 it went pretty fast Feb 17 21:09:38 there is a problem with ksmbd from the package feed Feb 17 21:09:58 mangix linked a github issues, it has a wrong dependecy Feb 17 21:11:17 kab-el: Hey! Thanks for the review! :) I forgot to ask, would the patch warrant a cc:stable? It's technically a bug fix. Feb 17 21:22:03 rsalvaterra: it would be picked automatically for stable since it contains a Fixes: tag Feb 17 21:22:35 rsalvaterra: stable maintainers have bots that search for upstream commits containing Fixes tags Feb 17 22:03:00 kab-el: Ok, great! Feb 17 22:15:34 zorun: the release notes are looking good Feb 17 22:15:40 do you want to publish them? Feb 17 22:16:06 mangix: we should add the problem with ksmbd to the regressions list of the release notes Feb 17 22:27:29 Hauke: ok, I don't have the details about this ksmbd issue, but yes you should add it to the regression section Feb 17 22:30:59 let's use 18 february as release date (I'm going to sleep now ;) ) Feb 17 22:39:39 zorun: have a good night Feb 17 22:52:21 Hauke: which problem? Feb 17 22:52:26 mangix: zorun: is this ok: https://openwrt.org/releases/19.07/notes-19.07.7#regressions Feb 17 22:52:50 mangix: https://github.com/openwrt/packages/issues/14771 Feb 17 22:52:55 mangix: this problem: https://github.com/openwrt/packages/issues/14771 Feb 17 22:53:42 I merged a commit fixing it Feb 17 22:53:42 . Is it still valid? Feb 17 22:54:16 I think this will not be rebuild for the 19.07.7 release Feb 17 22:54:24 the kmod should only be build with the 19.07.8 Feb 17 22:54:38 the fix is correct Feb 17 23:10:59 nbd: it looks like this broke the symvers for lantiq kernel modules: https://git.openwrt.org/5ed1e5140a80558ab47fd70410ae3242bed5becf Feb 17 23:11:18 this file is empty for me: build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/symvers/lib_ifxos.symvers Feb 17 23:11:40 Hauke: unfortunate. at least the workaround is easy Feb 17 23:11:42 then the DSL driver is not buidling becasue it can not find the symbols exported by ifxos Feb 17 23:12:13 rc4 is a soft dependency anyway Feb 17 23:17:52 Hauke: nbd: I've a fix in the ltq 5.10 branch of my staging tree. havn't realised it isn't related to the k5.10 bump. not sure if proper fix Feb 17 23:26:04 Hauke: Would it still be possible to get this into 21.02? It would be really nice to have. :) https://patchwork.ozlabs.org/project/openwrt/patch/20210217155819.1068661-1-rsalvaterra@gmail.com/ Feb 17 23:27:57 HBM has been broken on the Omnia since basically forever… :/ Feb 17 23:30:05 (And 5.10 on the master branch will most likely get the fix through the usual stable kernel updates.) Feb 17 23:31:44 rsalvaterra: I thought you use snapshot OpenWrt. Feb 17 23:57:28 build #855 of sunxi/cortexa53 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/855 blamelist: ?lvaro Fern?ndez Rojas , Felix Fietkau , Daniel Golle Feb 18 00:09:16 mangix: I run my own builds from master, yes. But normal users don't… :) Feb 18 00:13:33 rsalvaterra: guess i'm a normal user... Feb 18 00:15:00 mangix: See? I care about you! XD Feb 18 00:17:27 Wait, how do you develop without running master? O_o Feb 18 00:20:19 rsalvaterra: malta Feb 18 00:21:14 my comment above is related to the Turris Omnia. I hsve multiple devices Feb 18 00:21:33 Archer C7v2 is running a custom build Feb 18 00:21:59 because I hate LEDs Feb 18 00:22:16 Oh, malta… I don't really fancy virtual machines… Feb 18 00:24:37 rsalvaterra: I had this in my tree https://github.com/neheb/openwrt/commit/5f3de1171cd9ce9679acd6c5cc490803aaa7beda Feb 18 00:24:38 Heh… LEDs are the bane of my existence, especially since I have the router in my bedroom. Feb 18 00:25:14 no LED patch: https://github.com/neheb/openwrt/commit/44715307fadded961beed35169f2fedd551da1af Feb 18 00:25:18 it's a hack of course Feb 18 00:25:53 mangix: Good, but not enough. The MBus window reservation is still missing, so mvneta_bm will fail to allocate memory and bail out. Feb 18 00:25:56 wait a minute...what's LED_CTRL3 Feb 18 00:27:51 mangix: Besides the patch I sent, I also have this in my tree: https://gitlab.com/rsalvaterra/openwrt/-/commit/56b2e99e786bcb975b716d0277941929bcf4a7e0 Feb 18 00:30:52 that patch seems specific to sfp, no? Feb 18 00:31:24 also sounds like a new uboot is needed. my omnia is the original Feb 18 00:31:57 Well, it's basically a patch generated from a squashed commit of all changes after the hardware buffer management enablement, up until 5.11-rc7. Feb 18 00:33:09 Yeah, I'm looking forward to that u-boot update… My Omnia is also the model from the Indiegogo campaign. Feb 18 00:34:50 But that Archer C7 v2 LED patch is nice, I wonder if I could do something similar on my TL-WDR3600…? The switch LEDs can't be controlled with sysctl… Feb 18 00:36:27 … and turns out I can! https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi;h=21fd079e1a06225d985f08de5853344bc908b740;hb=HEAD Feb 18 01:14:14 rsalvaterra: yeah someone needs to write code for the driver to make it controllable Feb 18 01:24:39 mangix: The switch LEDs on my Archer C6 v2 are controllable (port_mask). I wonder if its driver could be used as a reference… Feb 18 01:26:02 they're controllable under ar71xx but not ath79 Feb 18 01:26:16 all because of code **** ENDING LOGGING AT Thu Feb 18 02:59:56 2021