**** BEGIN LOGGING AT Sun Dec 29 03:00:00 2019 **** BEGIN LOGGING AT Sun Dec 29 06:22:59 2019 Dec 29 09:34:35 build #66 of sunxi/cortexa8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa8/builds/66 Dec 29 13:34:04 nbd: FYI, someone else reporting similar behaviour on the forum. for me, AP was visible, but clients can't connect, nor does logread print any of the connection attempts. Forum report: https://forum.openwrt.org/t/mt7615-not-working-at-all/51357 Dec 29 13:42:22 (i might just have adjusted PKG_SOURCE_DATE myself in earlier builds but not the hash, so it seems i was running 2019-10-10 all along) Dec 29 13:49:04 why releasing a 19.7 when the year 19 is nearly over now? Dec 29 13:53:17 19.07 is year/month when branch was forked. Dec 29 13:53:41 SOP for release numbering Dec 29 13:54:36 Borromini: but this is not reproducable by the normal user that 19.07 is the new release which has been released in 2020 Dec 29 14:06:08 normal users are not interested in internal code branching Dec 29 14:08:14 i just gave you the rationale, i have no say in it; so no point in arguing about it with me Dec 29 14:47:04 build #88 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/88 Dec 29 18:09:52 build #77 of ath79/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fnand/builds/77 Dec 29 18:11:42 build #81 of arc770/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/arc770%2Fgeneric/builds/81 Dec 29 21:27:07 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Dec 29 21:32:00 build #71 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt305x/builds/71 Dec 29 22:02:38 I'm having problems with my git history - of late I'm seeing merges in the luci repository saying 'merge commit foo' but I don't see any diff output of what was actually merged. Dec 29 22:02:43 what am I doing wrong? Dec 29 22:03:54 and a similar behaviour exists on the web interface https://git.openwrt.org/?p=project/luci.git;a=commit;h=359379078e8ea786610d9dc1520f14f35239409c Dec 29 22:05:14 this is horrible because it obscures the actual code changes from being displayed in the history. Dec 29 22:10:06 ldir: these are empty merge commits Dec 29 22:10:27 ldir: the actual diff is in the commit that was part of the branch that got merged Dec 29 22:10:50 I usually do git log --no-merges to filter out the useless empty commits Dec 29 22:12:01 in the specific link you posted, the second "parent" link points to the actual merged commit Dec 29 22:12:16 1f84f268cc647d3469864fd9b04b97d4cd2f984c Dec 29 22:12:21 which contains the actual diff Dec 29 22:15:47 if I do git log --no-merges I don't see Florian's merge commit. I'm completely unaware that anything has been changed. Dec 29 22:16:53 ldir: sure Dec 29 22:17:05 if I run "git log --no-merges" I see "luci.mk: move indexcache delete into postinst" Dec 29 22:17:16 which is the commit that got merged Dec 29 22:17:38 it just was authored a while before it got merged, hence its far down in the history Dec 29 22:18:14 * ynezz wonders why it's not possible to enable `--no-merges` in the web UIs Dec 29 22:19:05 I'm having a WTF moment with this. Dec 29 22:19:48 So history is chronological of the commit, not of when it was actually merged into the tree. Dec 29 22:20:27 yes Dec 29 22:22:01 ok, so before I have a meltdown, is there a convenient way of showing what a merge commit actually merged at the time the merge took place? Dec 29 22:26:11 so I could have a commit authored 2 years ago, that I finally submit a PR for, gets merged, and then appears in the history as if it was committed 2 years ago. Dec 29 22:26:49 * ldir no longer trusts git log and has a meltdown Dec 29 22:27:10 that's the 'beauty' of distributed version control Dec 29 22:32:19 ldir: git alias: lgb = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset%n' --abbrev-commit --date=relative --branches Dec 29 22:35:05 (not exactly what you ask for but still useful in similar situations) Dec 29 22:36:38 kernel history must look like tokyo subway map with this alias :p Dec 29 22:37:09 git log --graph --decorate --abbrev-commit -p Dec 29 22:38:30 And regarding git log specifically, I'm looking at luci log, seeing "Merge: c508dec8 1f84f268", and I see c508dec8 is right before that so I'm interested in 1f84f268, I double-click with mouse on it, press / , middle-click (or Shift-Insert) to paste and I see the other part of the merge even if it was two years ago. Dec 29 22:42:52 jow: IMHO talking (and thinking!) about "empty merge commits" and "the actual diff" is confusing because by definition Git doesn't store any diffs, each commit is a full snapshot of all the tracked files. With that in mind, merge commits are no longer "confusing". Dec 29 22:43:18 is logread remote logging supposed to be rfc5424 compliant? I'm having issues with piping logs into grafana-loki … caller=syslogtarget.go:174 msg="error parsing syslog stream" err="expecting a version value in the range 1-999 [col 4]" Dec 29 22:56:20 PaulFertser: I am not the one being confused here Dec 29 22:56:40 jow: I know, but your wording looked kind of odd. Dec 29 22:58:06 I think it had potential to confuse the others :) Dec 29 22:58:16 *shrug* Dec 29 22:58:20 * jow is afk Dec 29 23:07:04 hm ok, logread seems to be rfc3164 (bsd syslog) compliant instead **** ENDING LOGGING AT Mon Dec 30 02:59:57 2019