**** BEGIN LOGGING AT Thu Nov 01 03:00:00 2018 Nov 01 05:35:13 * Katana_Steel is running r8392-3dba852 on linksys EA6500v2 Nov 01 05:46:24 build #1090 of brcm2708/bcm2710 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2710/builds/1090 Nov 01 08:47:18 jow: rewrote the code to auto-create a partiton after the rootfs{data}, occupying the rest of the space on the block device. Doesn't do anything more with it, so users can choose which fs to use Nov 01 08:48:19 but the existence of the partition means that with a proper fstab taken over with sysupgrade, the partition can get automounted again Nov 01 08:48:41 (as long as you don't flash an image with a different sized rootfs) Nov 01 08:48:58 s/rootfs/root partition/ Nov 01 08:49:38 nbd: ^ does this match what you were thinking? Nov 01 08:58:31 yes Nov 01 09:11:20 russell--: i've tested ubifs patch Nov 01 09:11:23 works for me as well Nov 01 09:11:30 should we pick it for master at least? Nov 01 09:11:41 Richard said he still wants to do some testing Nov 01 09:15:50 [10:15] no, please wait until i merged it Nov 01 09:15:52 [10:15] i need to run more tests Nov 01 09:17:14 russell--: so i'm going to wait until Richard is done with his extra tests Nov 01 10:05:37 rmilecki: sounds fine Nov 01 10:15:18 as a general question about IRC - which do people understand more for a direct person-to-person chat request 'PM' or 'query'? Nov 01 10:16:21 or perhaps a better question... which form are you less confused by? :-) Nov 01 10:18:09 PM afaik Nov 01 10:18:22 query is the command in Irssi and probably other clients Nov 01 10:18:28 e.g. /query ldir Nov 01 10:19:33 yeah I know *how* to do it, it's how to word the polite request before you do it :-) Nov 01 10:20:02 Morning people! :-) Nov 01 10:20:16 Up late today because you know beer! Nov 01 10:20:24 ldir: PM? Nov 01 10:20:28 ^^ Nov 01 10:21:47 hasn't actually *had* beer but feels like death warmed up anyway :-/ Nov 01 10:22:36 how was lisbon? Nov 01 10:22:38 Borromini: ok, PM it is. I've had some people say 'query' at me...and I became confused :-) Nov 01 10:22:38 Borromini: query is the term for _IRC_ not for any client in particular. Nov 01 10:23:19 ldir I think it just depeneds what their background is, irccers from way back will know query, people who came to irc for a particular community like this might prefer PM from other communication forums Nov 01 10:23:33 PM is definitely broader understanding I'd say :) Nov 01 10:23:53 karlp: i've never seen someone ask 'query?' to someone else. Nov 01 10:24:11 is the openwrt summit done? Nov 01 10:24:12 I shall stick with PM then - it certainly confuses me less Nov 01 10:24:30 Borromini: well, ldir has :) Nov 01 10:24:49 Borromini: yeah the opelwrt summit is done. Nov 01 10:25:00 karlp: but he's a bit weird, between us ;) Nov 01 10:25:02 ldir: and? Nov 01 10:25:24 * ldir lols Nov 01 10:25:51 actually I'm offended....only a *bit* weird? ldir tries harder Nov 01 10:26:38 ldir: popelwrt Nov 01 10:27:01 ldir: :D :D Nov 01 10:27:18 yeah I was being a bit more subtle with my spelling 'mistakes' - was attacking it a different letter at a time. Nov 01 10:27:28 to see if anyone noticed :-) Nov 01 10:28:43 i was trying hard not to say anything! Nov 01 10:29:06 Borromini: from my pov: it was nice to meet people on the summit Nov 01 10:29:25 probably a lot of people you'd only talked to on irc before? Nov 01 10:29:30 did any one record the summit? Nov 01 10:29:34 Borromini: ... but the impression remains that this a summit where non-openwrt orgs talk *about* openwrt, not people talking *to* openwrt Nov 01 10:30:05 jow: /me got that vibe from the schedule of talks Nov 01 10:30:11 Borromini: jow puts that very diplomatically. Nov 01 10:30:29 jow: gotcha. that's sad Nov 01 10:31:25 Is that because OpenWrt does not have a figurehead? Nov 01 10:31:35 for me the best bit was meeting face-to-face the other developers and contributors. Nov 01 10:31:40 jow: ... #some# orgs talk about openwrt Nov 01 10:31:48 was the weather at least nice? Nov 01 10:31:49 and others about mozilla and their products Nov 01 10:32:00 russell--: lisbon was a lovely city Nov 01 10:32:30 noted! Nov 01 10:32:36 Tapper: probably, maybe also because there's slightly diverging interests Nov 01 10:33:07 the worst bit was a number of organisations saying how wonderfully open they were.... Nov 01 10:33:27 So jow for you what was the most intresting thing? Nov 01 10:33:33 talk Nov 01 10:34:04 one takeaway for us was that we urgently need to organize a more devloper oriented openwrt summit/gathering where one can actually discuss openwrt architecture, development etc. Nov 01 10:34:06 ldir: lip service eh Nov 01 10:34:26 ldir :-) Nov 01 10:37:34 agrees with jow Nov 01 10:39:41 jow: so there was no room for the openwrt people to get their heads together ? Nov 01 10:39:46 surely not enough time i presume. Nov 01 10:40:00 jow: how about a community fundraiser for an openwrt centred summit? Nov 01 10:40:06 i'd happily contribute. Nov 01 10:40:47 is an openwrt/coding idiot but wishes to improve - I was hoping the conference would have a 'bunch of geeks - here's how we debug a package' etc etc feel but alas no. Nov 01 10:41:18 we *did* identify the need for such a thing as jow has already explained. Nov 01 10:41:21 * russell-- has been dying for a walk-through of the makefile hackery Nov 01 10:41:45 * Borromini votes fundraiser Nov 01 10:43:25 So I won't be going to another openwrt conference in its current form BUT I would gladly contribute to & attend a 'hacker meet' Nov 01 10:44:23 * russell-- has been wanting to make it to a battlemesh since at least the one in catalonia, N years ago. Nov 01 10:44:44 A number of 'devs' got together at the summit and had some good discussions about direction etc - I expressed myself at those discussions :-) Nov 01 10:45:32 in the past we never had a OpenWrt conference organized by OpenWrt people because no one wanted to take the work of organizing one Nov 01 10:45:44 It was nice meeting you all Nov 01 10:47:18 russell--: yeah a 'battlemesh' type event...or happening around such an event is desirable..... and the need is noted. Nov 01 10:47:56 if we have someone to coordinate organization + community suggesting sessions I think we can have a hackery summit Nov 01 10:48:05 questions / suggestions are important probably Nov 01 10:48:23 it could be there are some topics I cover, but not idea what people really want to know about Nov 01 10:48:32 could be same for other devs Nov 01 10:50:01 whelp what did i miss. Nov 01 10:50:11 rmilecki If the talks were put up on youtube like befor people can learn from them to. Nov 01 10:50:26 there was this (not fully thought out) idea of having a multi-day meetup before the wireless community weekend in berlin Nov 01 10:50:30 Tapper: sure, recording sounds find Nov 01 10:50:35 Tapper: *fine Nov 01 10:51:02 bradley kuhn is living here in portland, i could have stowed away in his luggage! Nov 01 10:51:02 haha my spelling is rubbing off again! :-D Nov 01 10:52:02 I think it fair to say there are a couple of openwrt 'admin' tasks that need to be done first and then we'll be able to focus on 'wireless community weekend' or whatever that turns out to be. Nov 01 10:53:07 russell--: only if your legs poked through the bags and you could walk yourself - Bradley was quite ill a few days before the conference... he wouldn't have been able to lift you :-) Nov 01 10:53:29 I am glad Halloween is dun! Nov 01 10:53:58 Tapper: PM ? Nov 01 10:54:19 My wife dressed me up by macking it look like I had my face smashed in! Nov 01 10:57:09 It was quite the talking point people at the partty liked the fact that I have glass eyes lol and took one out! Nov 01 11:00:51 jow: pm ? Nov 01 11:01:35 sure Nov 01 11:09:46 the talks from the openwrt sumit this week wrere recorded and they should be uploaded to youtube next week Nov 01 11:11:25 Isn't the battelmesh normaly before the wireles community weekend? Nov 01 11:15:46 Hauke cool Nov 01 11:16:05 Hauke: I think it varies Nov 01 11:16:41 ok Nov 01 11:17:05 Hauke: we can even do it before that, that it'd be like two weeks straight :P Nov 01 11:17:28 jow: pm? Nov 01 11:17:29 yes I think there was some doodle for the battlemesh in most years Nov 01 11:17:32 ldir: witness ^^ Nov 01 11:18:03 jow: 2 weeks straight is a little bit long in my opineon ;-) Nov 01 11:19:09 Borromini: sure Nov 01 14:26:02 dedeckeh: you forgot to annotate the fixed CVEs in the curl bump Nov 01 14:26:20 or were they fixed in previous patch releases already Nov 01 14:27:27 doesn't look like it. could you do a commit like 2375e279a7cb462d62fd6028cb3fbd56217222de ? Nov 01 14:27:55 apparently 2018-0500 fixed in 7.61.0 wasn't mentioned either Nov 01 14:28:29 nor 2018-14618 fixed in 7.61.1 Nov 01 14:28:50 stintel: if a version bump "implicitely" fixes CVE it should be fine (at least in the future) Nov 01 14:29:11 now that we have more or less reliable CPE IDs we can map vulnerabilities to the specific version vectors Nov 01 14:29:28 our changelog generator cannot do that yet but I planned to add that soon Nov 01 14:29:39 ah, so we don't need to add fixed CVEs anymore ? Nov 01 14:29:43 been toying a bit with the various CVE lookup libraries Nov 01 14:30:15 stintel: I'd say if a package has a PKG_CPE_ID then likely not Nov 01 14:30:16 or maybe we could have a git hook or something that looks up things and auto-adds the fixed CVEs during commit Nov 01 14:30:26 it's nice to have it in the changelog Nov 01 14:30:39 actually it depends on whether the NVD feed properly maps a CVE to affected versions Nov 01 14:30:40 but ok, it's probably most important to have it in the release notes/changelog Nov 01 14:31:19 so to be on the safe side, it probably makes sense to always attempt to mention the CVEs, but it should be less problematic in the future if it is forgotten while bumping a version Nov 01 14:53:40 build #1029 of lantiq/falcon is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Ffalcon/builds/1029 Nov 01 14:58:14 hey guys, why my router spam my logs with martians packets? http://sprunge.us/aTZWRs Nov 01 14:58:40 ssh connections spam my logs too Nov 01 14:59:43 please paste on pastebin Nov 01 15:01:11 pastebin ban tor connections Nov 01 15:04:56 what's wrong with that pastebin blogic? Nov 01 15:05:51 am0rphis: something in your network is causing it Nov 01 15:07:59 does someone know why all the Ubiquiti firmwares have ubnt- as a prefix? (I know UBNT is how they trade on Nasdaq etc.) Nov 01 15:08:22 other devices don't seem to have their brand name prefixed in firmware image names (like tp-link, netgear, d-link) Nov 01 15:10:50 perhaps a better question is why don't the others have a brand prefix, so people have a chance of finding the right one amongst the alphabet soup Nov 01 15:11:03 true enough Nov 01 15:11:29 karlp, how to disable it? any options to compile or some flags for dropbear? Nov 01 15:11:32 it just struck me while optimising my unattended upgrade script, Ubiquiti stuff is the only stuff to have a vendor prefix Nov 01 15:12:55 "disable" what? Nov 01 15:16:17 martians packets from router Nov 01 15:19:53 disable this:Nov 1 17:16:48 slack kernel: [95075.359287] local martians packet: IN=eth0 OUT= MAC=mac SRC=192.168.0.1 DST=192.168.0.111 LEN=132 TOS=0x10 PREC=0x00 TTL=64 ID=42547 DF PROTO=TCP SPT=22 DPT=46038 WINDOW=9404 RES=0x00 ACK PSH URGP=0 Nov 01 15:35:45 martians on your network! Can you speak to them? Did they get that car we fired at them yet? Nov 01 15:38:07 am0rphis: this could be caused by nat loopback and the like. I'm afraid its not easier to answer without knowning some more about your network topology Nov 01 15:40:56 jow, router, computer and some wireless devices Nov 01 15:42:26 copmputer wire connected to router(TP-Link TL-WR841N/ND v8) Nov 01 15:49:31 Tapper: I've seen the film and they run around your network going 'Aaaack', 'Aaack', 'Ack' a lot - and this one is no different..see... "ACK PSH URGP=0" slight dialect difference I guess. Nov 01 15:49:48 * ldir fetches coat and leaves Nov 01 15:50:05 am0rphis: do you have any firewall rules related to ssh / port 22 ? Nov 01 15:50:24 am0rphis: do you do things like wds, bridges etc? Nov 01 15:53:11 jow, no firewall rules to ssh, bridge between ethernet and wireless Nov 01 16:55:43 so, with regard to r7800, anyone have any ideas on how to make poweroff work (ie, keep the system down instead of it rebooting)? Nov 01 16:56:18 I'll trade you shiny new ath10k-ct firmware :) Nov 01 16:59:43 greearb_: is this conceptually possible at all? I always thought that such SoC boards simply lack the circuitry to actually power off Nov 01 17:00:15 you can basically trigger a SoC reset or halt the system in a while (1) spinning loop Nov 01 17:00:21 but not power off Nov 01 17:00:28 I might be wrong though Nov 01 17:03:20 someone yesterday said it used to work but then stopped. I myself don't know much at all about it. Nov 01 17:06:41 jow: It depends on the SoC, really. I know next to nothing about the part in question, but many larger ones have complex power requirements and certainly do have the option of completely halting and turning off their supplies. Nov 01 17:07:18 Monkeh: yeah, I guess for mobile phones and such. But e.g. an old brcm47xx mips soc certainly has none Nov 01 17:07:36 maybe such power circuitry is common on arm based designs nowadays Nov 01 17:07:40 jow: No, those really basic chips generally don't - things like an i.MX6 do. Nov 01 17:08:12 How far the.. these are IPQ8xxx or something? go, I don't know Nov 01 17:19:23 hmm still a lot to do to make openwrt work with kernel 4.19 Nov 01 17:20:32 Hauke, like what, out of curiosity? I'm porting forward my own patches to 4.19 now...at least my stuff is mostly applying OK Nov 01 17:22:14 there is already this pull request: https://github.com/openwrt/openwrt/pull/1386/commits Nov 01 17:22:26 but the config-4.19 files is not adapted and a lot more is missing Nov 01 17:22:39 it also reverts some cahnges done for kernel 4.14 some weeks ago Nov 01 17:26:41 I wonder if it would be easier to have an openwrt-linux-kernel repo that is the full kernel with openwrt patches applied. Then pull that in instead of stock kerne plus local patches? Nov 01 17:27:06 you could slap backports into it as well perhaps Nov 01 17:28:20 I find it tricky to deal with patches that won't apply in openwrt (like when I tried to use my 4.16 kernel as a backports source)...using normal 'git' tools would be easier I think. Nov 01 17:30:05 Upon moving to a new kernel, do a rebase so that openwrt patches always float to the top...better chance of being able to get them upstream that way Nov 01 17:30:47 we've been considering scripting such a work flow Nov 01 17:31:04 what needs scripting? Nov 01 17:32:13 upstream kernels should make it easy to flip between different releases too, I'd think. Nov 01 17:32:14 replacing the quilt based workflow by some git based one without having to maintain an actual kernel fork Nov 01 17:32:44 what is downside of forking the kernel...you have effectively already done that anyway, just w/out using git? Nov 01 17:33:15 the idea was (as I understood it) to have a vanilla kernel clone, git-am'ing our patchset on top, leverage Git's history tracking/3-way-merge/conflict resolution abilities to rebase the am-ed commits on top of the next version, then result the existing patchset again Nov 01 17:33:19 instead of quilt refresh Nov 01 17:34:01 jow, ok, that is how I rebase. But then you push that kernel to github and tell openwrt to download it. No local patches Nov 01 17:34:36 so far the consensus has been that we rather prefer patch files over "hiding" kernel customization in an own tree Nov 01 17:34:36 then if I want to run openwrt kernel on Fedora OS, easy as pie Nov 01 17:34:57 if you rebase like that, openwrt patches are always on top, not that hidden at all. Nov 01 17:35:45 and you can 'git diff' and such against latest upstream commit to see full changes, etc. Nov 01 17:36:38 problem is that it would also force our users to clone huge trees Nov 01 17:37:13 you mean instead of download a .tgz? Nov 01 17:37:17 or do shallow clones (negating the git history advantages) or force us to provide customized kernel source tarballs (which would be confusing and messy) Nov 01 17:37:33 correct Nov 01 17:38:14 it is trivial to create a tgz, so normal users could use that. Developers can use full tree, we have gobs of stuff on our disk already Nov 01 17:38:32 why would we default to wpad-basic for RPi ?! Nov 01 17:38:58 I have difficulties finding microsd cards < 32GB :P Nov 01 17:39:12 I know it is trivial to create tar.gz, what is not trivial is explaining why linux-4.14.36.tar.xz is not the same as linux-4.15.36-owrt-123.tar.gz Nov 01 17:39:56 who would you need to explain that to? Already OpenWRT has confusion of 'uname -a' showing a kernel, but really the bulk is hidden in some backports logic Nov 01 17:40:36 and local patches that most users could never find even if you told them they existed Nov 01 17:41:06 the thing is, right now openwrt bundles its customization along with its repo Nov 01 17:41:13 in the form of patch files Nov 01 17:41:35 moving changes to upstream software into separate repos would fundamentally change that Nov 01 17:41:53 ok, that is true...but I still think for the better Nov 01 17:42:02 at least for stuff as complex as the kernel Nov 01 17:42:47 if it is really important, then still use the upstream kernel as the developer base, but have a script that does the 'git am' for you and package those 'am' scripts into openwrt repo Nov 01 17:42:59 Never develop from that though, always the upstream kernel(s) Nov 01 17:43:02 installing findutils-find results in the error "check_data_file_clashes: Package findutils-find wants to install file /usr/bin/find ; But that file is already provided by package * busybox" Nov 01 17:43:03 I still think that the vast majority of openwrt users (those that do not do porting or driver development), there's only downsides to the kernel fork approach Nov 01 17:43:28 all other packages, which 'override' some busybox tools install just fine. Nov 01 17:43:28 for those that need it, a "make kernel-tree" (which would do the patch apply thing) would probably do fine Nov 01 17:43:35 rmilecki: ping Nov 01 17:43:43 https://forum.openwrt.org/t/brcmfmac-failed-on-pi3-and-pi-zero/24058 Nov 01 17:43:47 I'm seeing it too Nov 01 17:43:55 I'll bet you a no-name chinese AP sitting beside me on the floor that users would never even notice :) Nov 01 17:44:30 hm, last time I cloned a kernel tree it took me roughly half an hour vs. fetching the tarball in 5-10s Nov 01 17:44:33 I think I would notice Nov 01 17:44:40 jow, but making a local tree doesn't make it easy for users to share development of the upstream tree Nov 01 17:45:19 jow, you clone a local pristine tree you keep around, and then tell git to use that as basis of the new upstream clone...I forget the exact syntax. Nov 01 17:45:34 greearb_: we do not want people to develop on the openwrt kernel fork, they should use kernel.org instead Nov 01 17:45:44 and if you create tarballs for users to use anyway, then no need to download git tree for users Nov 01 17:46:00 in fact we do not want to have a kernel fork at all, at least this is my latest knowledge of the situation :) Nov 01 17:46:15 and have to deal with conflicts with backports and local openwrt trees? Seems a major pain. Nov 01 17:47:07 stintel: thanks for a ping, I've to check that wiphy_register() WARN Nov 01 17:47:09 what is that about Nov 01 17:47:26 anyway, that is my opinion. Nov 01 17:47:42 nbd: ping Nov 01 17:47:53 stintel: i'll debug that tomorrow Nov 01 17:48:46 rmilecki: I'm reverting some stuff to see if I can get working wifi, I'll let you know if I found the commit that breaks stuff Nov 01 17:49:19 Borromini: pong Nov 01 17:59:07 nbd: hi. i'm running 18.06 head and i've been experiencing reboots with the previous mt76 update and lockups with the last one Nov 01 17:59:54 on the last version wireless dies, at which point i can't ping the router, doesn't matter wireless or wired clients Nov 01 18:03:12 what kind of device Nov 01 18:03:14 device is a dir-860l b1, only using the 5 GHz wireless Nov 01 18:04:01 and it was only the last two mt76 commits that were triggering these issues? Nov 01 18:04:07 did you test them individually? Nov 01 18:04:57 i had unexpected reboots with the previous commit Nov 01 18:05:02 multiple a day Nov 01 18:05:14 with the latest commit, it just seems to hang Nov 01 18:05:54 no ssh access anymore, no ping, not from my desktop (wired) or from laptop/mobile/... Nov 01 18:10:02 Borromini: what about commit before the previous? was it stable? Nov 01 18:10:28 rmilecki: no issues with that Nov 01 18:11:06 stintel: that WARNING seems to be coming from the Nov 01 18:11:09 if (WARN_ON(!(rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_FW_ROAM) && Nov 01 18:11:10 rdev->ops->update_connect_params)) Nov 01 18:24:37 Borromini: does openwrt HEAD have the same issue? Nov 01 18:24:45 also, is there an easy way to trigger this more reliably? Nov 01 18:28:23 nbd: it feels seemingly random. I will run a master build and report back Nov 01 18:28:54 is there a way to force persistent logging on the internal flash? so crash info gets saved? now i have to powercycle and everything is lost Nov 01 18:30:39 greearb_: jow: when we put the mainline kernel with our changes into a reposetory the constant updates to more recent minor stable kernel versions gets much more messy Nov 01 18:31:54 Hauke, just pull with rebase? Nov 01 18:32:21 I have been doing this for years, I have about 400 patches out-of-tree in my local repo at any given time. Nov 01 18:32:31 stable kernels normally rebase w/out any manual intervention Nov 01 18:33:13 and taking me about 8 hours to go from 4.16 to 4.19 Nov 01 18:34:42 greearb_: using a git reposetory with multiple pepole which gets often rebased is not nice Nov 01 18:35:31 seems fundamentally similar to what you have currently...you just have to know that you will be rebasing a lot Nov 01 18:35:31 brb Nov 01 18:36:46 I actually looked in the packages/kernel dir to try to find current openwrt patch set and to see how many committers there were to it..but I guess it must be somewhere else? Nov 01 18:39:01 target/linux/generic/*-4.14/ && the target specific ones, e.g.target/linux/ipq806x/patches-4.14/ Nov 01 18:39:51 greearb_: the major kernel version upgrade is done once in a year, the minor stable version rebase is done multiple times a month Nov 01 18:40:36 this is effectively a rebase, right? ca88f4153f8f3f857451a1705f08e19fffa287fd Nov 01 18:41:22 greearb_: yes Nov 01 18:41:51 so it seems similar drawback to rebasing upstream kernels to me Nov 01 18:42:28 greearb_: we had such discussions over and over Nov 01 18:42:36 every few months someone comes with the same idea Nov 01 18:42:49 heh, ok Nov 01 18:43:00 greearb_: i'd just say, that it works and people what are mostly involved with it, are OK with this solution Nov 01 18:43:23 we definitely can't have fork repository for all packages we use to patch Nov 01 18:43:48 fair enough, and I only propose this for the kernel Nov 01 18:43:49 and we don't see any real reason why kernel would benefit from exception Nov 01 18:44:03 we know quilt anyway, have to know it anyway Nov 01 18:44:30 I don't know quilt, maybe that is why it is all such a mystery to me Nov 01 18:44:46 git and stg and git am and rebase is my preferred toolbox Nov 01 18:56:40 greearb_: what complicates "just creating a git tree" is that we also have files that get copied into the tree directly (see generic/files/* and /files), which might also get modified by patches Nov 01 18:57:19 greearb_: but feel free to create such a tree to see how much work it is ;) Nov 01 18:58:02 that seems awful, for sure. Seems like you could have exactly one kernel and use build options and #ifdef, but, if you all like the current way, then that is fine. I don't think I'll have much need to hack on it anyway Nov 01 18:58:48 nbd: you were right about the lzma_addr, i was testing the wrong symlinked img Nov 01 18:58:55 nbd: soz about the noise Nov 01 19:00:47 ah Nov 01 19:00:49 that explains it Nov 01 19:00:51 no problem Nov 01 19:01:27 now its blowing up inside the cmdline code, but i am debugging that just now Nov 01 19:01:53 disabling the cmdline code / fw_args loop makes the image boot Nov 01 19:02:24 maybe because the boot loader passes a board=* value? Nov 01 19:02:45 or is the mach code entirely compiled out? Nov 01 19:02:46 it passes 0x4 as the addr Nov 01 19:02:48 oh Nov 01 19:02:49 weird Nov 01 19:03:01 printk("%s:%s[%d]%p\n", __FILE__, __func__, __LINE__, fw_argv(i)); Nov 01 19:03:06 [ 0.000000] arch/mips/fw/lib/cmdline.c:debug_foo[57]00000004 Nov 01 19:04:02 anyhow, off to read equestrian stories Nov 01 19:04:09 and prolly fall asleep while doing so Nov 01 19:04:13 cza in the morning Nov 01 19:06:02 greearb_: one kernel and ifdef'ery has the problem that you can't really separate patches for a given target anymore, meaning that you no longer see how close a target is to mainline and that orphaned patches will linger around if a target gets dropped Nov 01 19:06:47 quith quilt the patches are pretty much in your face, rather than hidden Nov 01 19:06:51 with* Nov 01 19:07:12 we were talking about doing a git init on a vanilla kernel, then git am all our patches instead of quilting them Nov 01 19:07:46 this would make sure all patches are git am'able aswell ass giving you git as a tool for playing inside the kernel rather than quilt Nov 01 19:21:24 blogic, but you still commit the individual patches into openwrt? Nov 01 19:28:41 pkgadd, seems like not having individual patches might make it easier to have common code, but maybe there is too much cruft that can never make it upstream or play nice with other platforms? Nov 01 19:33:23 if anyone is feeling adventurous, completely un-tested ath10k-ct 4.19 driver is now pushed to ath10k-ct repo Nov 01 19:48:36 is there an equivalent of "Working with patches" in the new wiki? i leave that in a tab all the time. Nov 01 19:49:18 found it: https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem Nov 01 19:57:03 Hi. I'm building openwrt master. I wanted to customize kernel options, so I edited target/linux/ar71xx/generic/config-default (I'm building for TARGET_ar71xx). That seems to do what I want. But then I thought I'd add CONFIG_LOCALVERSION to the kernel, to mark the kernel as custom. I did it by editing target/linux/generic/config-4.14 (there was CONFIG_LOCALVERSION="", so I changed that to "-something") but when I do "uname -a" on the target, I don't get Nov 01 19:58:02 I looked in build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.14.78/.config, and the LOCALVERSION is there Nov 01 19:58:43 I don't understand how does the openwrt build system assemble the resulting .config, but the localversion seems to reach the dir. where the kernel is built, so that seems OK Nov 01 19:58:49 I have notes that this should update the PKG_MIRROR_HASH, but it doesn't seem to be working? Nov 01 19:58:53 make package/kernel/ath10k-ct/check FIXUP=1 Nov 01 19:59:08 Any idea why am I not seeing the localversion? Nov 01 20:03:09 guys is there a way to do persistent logging on internal flash? Nov 01 20:03:11 I guess I have to DL first Nov 01 20:07:11 karlp: just merged your uhttpd help patch. Nov 01 20:14:21 Borromini: why would you do that? Nov 01 20:16:35 russell--: to debug, temporarily. Nov 01 20:16:54 my router hangs and all i can do is powercycle, stops accepting any connections whatsoever Nov 01 20:16:57 karlp: of course you need to bump the uhttpd package to use it Nov 01 20:17:09 ldir: yeah, no stress on that, just so it happens next time. Nov 01 20:17:25 it's not a CVE ;) Nov 01 20:17:35 lol Nov 01 20:25:39 zub: maybe you have enabled LOCALVERSION_AUTO as well? Nov 01 20:27:12 greearb_: try make package/ath10k-ct/check FIXUP=1 instead Nov 01 20:28:29 ldir, I just needed to download first it seems Nov 01 20:29:08 I notice that 'cubic' is being used instead of RENO...in the past, CUBIC has sucked very badly with ath10k, at least... Nov 01 20:32:36 * blogic notes that hannu is the 8th most active dev of owrt and has not voting voice Nov 01 20:32:49 seems wrong Nov 01 20:33:54 greearb_: hmmm, turns out both forms apparently do the same thing. Nov 01 20:34:59 blogic: :) Nov 01 20:41:50 night gents. Nov 01 20:46:32 greearb_: I tried compiling OpenWRT with ath10k-ct 4.19 (including forward-porting the applicable patches against 4.16) and it initially seems to work fine. (The interface comes up and clients associate. I haven't done any performance testing or anything.) Nov 01 20:47:28 mamarley, thanks for testing. What patches needed forward porting? Nov 01 20:48:11 201 and 202. The rest seem to have been upstreamed already in 4.19. Nov 01 20:48:36 greearb_: ^ Nov 01 20:49:32 I'll try to add those to my tree when I get a chance Nov 01 20:49:48 Besides changing 4.16 to 4.19, 201 needs a tiny change to apply and 202 doesn't need anything. Both have lots of offsets though that I didn't bother to fix. Nov 01 20:55:22 blogic: how is this fixed? Does it need someone to propose him in some way? Nov 01 21:22:04 so if I have what is hopefully a generic kernel patch for 4.14, where does it go in the openwrt tree? Nov 01 21:25:46 I think this page is not accurate w/regard to this question: https://oldwiki.archive.openwrt.org/doc/devel/patches Nov 01 21:28:02 maybe in the generic/backport-4.14 dir? Nov 01 21:32:06 generic/backport-4.14 is for patches accepted upstream (mainline), generic/pending-4.14 for those submitted upstream/ under consideration, but not merged yet - stuff without a chance for mainline would go into generic/hack-4.14 Nov 01 21:32:38 I'll be spending time in the hack dir I think :) Nov 01 21:34:42 can someone explain to me the function/purpose/difference of usign v ucert ? Nov 01 21:36:20 ok partly answered https://gitlab.com/mrhso/openwrt/commit/1b8f3d9c2ec3dd89dda524c37e4d69c3d213918e Nov 01 21:37:31 pkgadd, so then I would do quilt things in this dir? ./build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x/linux-4.14.78 Nov 01 21:38:12 is there a better help page than the one I mentioned above? Nov 01 21:39:43 greearb_: https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem probably the most interesting part would be "quilt pop -a" and "while quilt push; do quilt refresh -p ab; done" Nov 01 21:40:38 maybe also https://wiki.debian.org/UsingQuilt for general info about quilt Nov 01 21:46:12 assuming I have done quilt push -a, and now things look very weird, how do I get back to initial settings? Nov 01 21:46:38 ahh, pop -a Nov 01 21:52:56 yep, particularly stubborn cases might need -f, in combination with push it force applies a patch (leaving foo.orig and foo.rej, so you can fix up the real file manually - and refresh later on), with pop it aborts trying this fixing up and force unapplies the patch Nov 01 21:54:15 you know if net/ipv4* is from backports or from 4.14-ish? Nov 01 21:55:12 those parts of the stack are... difficult. I pretty much always make the wrong call there ;) Nov 01 22:00:39 too bad quilt can't 'am' a git patch Nov 01 22:06:27 so, how do you show the contents of a quilt patch? Nov 01 22:08:46 seems like quilt diff should do it, but no joy Nov 01 22:10:03 quilt diff shows the contents of the current head of the applied patches Nov 01 22:10:13 so, I did quilt new ... Nov 01 22:10:21 then patch -p1 < /tmp/foo.patch Nov 01 22:10:45 then quilt add for the files the patch changed Nov 01 22:10:50 I'm guessing that is not right Nov 01 22:11:10 quilt add the changed files and quilt refresh afterwards Nov 01 22:11:27 you have to add before you change maybe? Nov 01 22:16:21 since we are talking about kernel/git/quilt Nov 01 22:16:34 is there any reason that the patches are copied into the kernel (it applies to packages as well) build directory "patches" instead of making a symlink? Nov 01 22:17:02 I know of make /update, but sometimes I forgot and end-up losing the patches :( Nov 01 22:17:40 probably easier to deal with in terms of adding/ removing patches Nov 01 22:18:27 symlinks would work nicely for patches you edit, but patch removals or additions wouldn't be helped that way Nov 01 22:18:59 But, the thing is, unless you do a make /update, the changes don't show-up in git status, which confuse my workflow Nov 01 22:21:11 Sometimes I even forgot to call make with QUILT=1, is there a reason for QUILT=1? What if the patches were always copied/symlinked to the build directory? Nov 01 22:22:26 if you have a patch from upstream kernel that you want to apply with quilt, what is the best work-flow? Only thing I can think of is very clunky Nov 01 22:22:27 using QUILT=1 is probably easier to check from within make Nov 01 22:23:18 greearb_: There are at least to options Nov 01 22:24:25 s/to/two Nov 01 22:24:40 1) copy the patch to target/linux// and do a make/target/kernel/prepare QUILT=1 Nov 01 22:24:43 greearb_: I usually start by just dumping it in the patches-* directory (there are some conventions about the leading numbers) and then checking with "make package/example/{clean,prepare} V=s QUILT=1" and "while quilt push; do quilt refresh -p ab; done" Nov 01 22:25:14 so, my patch will not apply cleanly Nov 01 22:25:48 likely I need to do patch -p1 --merge < /tmp/foo.patch or similar and then fixup the merge problems, for each of my patches Nov 01 22:26:06 that's for "while quilt push; do quilt refresh -p ab; done" to figure out - and to be fixed using quilt push -f and quilt edit ./file ; quilt refresh Nov 01 22:27:13 patches create with 'git am' are good candidates for this? As in, will quilt import the patch description? Nov 01 22:27:58 2) If you already did the make/target/kernel/prepare QUILT=1, you can cd into the kernel build directory, and into the patches directory. Copy the patch to the desired sub-directory, and manually add the patch to quilt's index ("series" file) Nov 01 22:28:06 quilt will leave text above the actual patches alone, which includes the typical git am style header Nov 01 22:28:37 2) yes Nov 01 22:30:09 In any case, if you apply your patch before other patches, you probably want to refresh them because some of them may change the same files Nov 01 22:30:31 I'll put mine on the top Nov 01 22:30:52 for your very own patches that aren't supposed to be submitted, it usually makes more sense to add them to the back of the queue Nov 01 22:31:05 that is what I mean Nov 01 22:31:06 so 999-*.patch or simila Nov 01 22:31:07 r Nov 01 22:31:10 Then you only have to add the patch and make sure it applies correctly Nov 01 22:31:43 pkgadd (IRC): That is usually what I do Nov 01 22:32:20 Unless I'm working on something I'll submit to OpenWRT later Nov 01 22:35:00 quilt edit does something magic, iirc, so applying a patch manually might be missing some of that magic Nov 01 22:35:16 it totally ignores it if you add it before doing an 'add' Nov 01 22:35:36 er, before doing a patch apply action Nov 01 22:36:52 the reason for that is because if doesn't keep an a/ b/ directory structure, which would be very, very painful with larger source trees (e.g. horrifying examples of which would be dpatch of dbs) Nov 01 22:37:29 after using stg, quilt is very painful in my opinion Nov 01 22:37:47 but, stg sucked at first too, so learning curve... Nov 01 22:37:51 it's mostly a matter of getting used to it Nov 01 22:38:18 e.g. I'm not very good of resolving conflicts using git, quilt is more obvious to me in that regard Nov 01 22:39:41 but like anything else, it needs a bit of practice to get to know it Nov 01 22:41:17 ...or to muster up enough of hate to bomb it from orbit Nov 01 22:41:23 ;) Nov 01 22:44:10 The only thing I miss from quilt is the ability to handle binary patches. I had to use OpenWRT's "files" approach when copying some ipq40xx board data Nov 01 22:45:37 yep, binary patches are a problem with quilt (or technically speaking with the underlying GNU patch) Nov 01 22:48:18 greearb_: Don't know if this will help you at all, but when I've been kernel hacking I do cd build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/linux-4.14.77/ ; git init && git add -A && git commit -m "init" - then hack away on source files, git commit squash whatever, and finally export my commits back out as patches with git format-patch Nov 01 22:48:51 heh, that is tempting Nov 01 22:49:43 then you can just copy them into the patches/*/ dir after renaming them to have the right prefix, and assume they all apply cleanly so no need to use quilt? Nov 01 22:51:32 jow: I think that's disabled, but I'll double check. Thanks for the hint. Nov 01 22:51:47 yeah you copy them into the source package's patch directory, so when you do a make package/foo/prepare or whatever they get included/applied by quilt for you. Nov 01 22:52:35 ldir, you first do a quilt push -a before the 'git add' ? Nov 01 22:53:22 if you do a make package/foo/{clean,prepare} then the quilt push -a will have been done for you. Nov 01 22:53:52 running 'make kernel_menuconfig' should start from the config openwrt would normally use? and any changes I make there are kept and used for the next make? Nov 01 22:54:17 you're working on a patched source....which is now in git as an initial commit, so you could git am and fixup Nov 01 22:54:51 ldir, for now, I have a big series of stuff in 'quilt series', how to get to the {clean,prepare} state from this? Nov 01 22:55:43 I guess that *is* the starting place Nov 01 22:56:32 yes, the {clean,prepare} gives you the package in the prepared (ie post quilt push -a) state. Nov 01 22:58:17 just beware that the build system does occasionally like to blow away your package and start again...which will lose you your local git dbase. Which can be erm, disappointing ;-) Nov 01 22:59:36 that's something you can disable though Nov 01 22:59:42 I guess I'll clone it and use another few GB of HD space :P Nov 01 22:59:53 how? Nov 01 23:00:46 lemme check what the option was called ... Nov 01 23:02:19 I can't take credit for this technique, it was handed to me after I screamed 'there has to be a better way to do this' by mkresin - and I think he got it from someone else - all I do know is it made some kernel bug hunting a lot easier to do :-) Nov 01 23:02:53 greearb_: [*] Advanced configuration options (for developers) -> [ ] Automatic rebuild of packages Nov 01 23:03:01 (AUTOREBUILD) Nov 01 23:03:29 * ldir makes a note Nov 01 23:04:47 not sure if this applies to the kernel though, but IIRC automatic rebuild of the kernel (except for version changes) on file changes is disabled once you use QUILT=1 Nov 01 23:06:13 oh right so you prepare with QUILT=1, quilt push -a, create your initial local git of the patch applied tree and hack away :-) **** BEGIN LOGGING AT Thu Nov 01 23:09:43 2018 Nov 02 00:10:23 Hi any one know about a release of openwrt? Nov 02 00:11:09 people are saying about a new build put out at the Summit! Nov 02 00:15:04 I wondered about that remark earlier as well Nov 02 00:15:20 I have seen it on twitter to! Nov 02 00:16:08 no habla twitter ;) Nov 02 00:21:33 ldir do you know anything about a new release? Nov 02 00:25:27 Am I missing somthing? http://openwrtsummit.org/ Nov 02 00:26:35 if you'd miss anything, so do I Nov 02 00:27:12 :-) Nov 02 01:01:24 For a release te be made, it first needs to be tagged, and the last 18.06 tag on the git repo is v18.06.1 from 2018-08-16 Nov 02 01:01:25 https://git.openwrt.org/?p=openwrt/openwrt.git;a=tags Nov 02 01:11:13 luaraneda: when hearing those earlier remarks, my gut feeling wasn't that positive (like yet-another-prpl-backed-vendor-sdk...) **** ENDING LOGGING AT Fri Nov 02 02:59:58 2018