**** BEGIN LOGGING AT Thu Apr 14 02:59:58 2016 Apr 14 05:54:21 rmilecki 49166 trunk/target/linux/bcm53xx/patches-4.4/ (9 files) bcm53xx: backport BCM5301X earlycon and USB VCC patches Apr 14 08:39:51 build #220 of ramips.mt7620 is complete: Failure [failed shell_7] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/220 Apr 14 12:07:54 build #216 of at91 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/216 Apr 14 13:47:31 build #228 of brcm63xx.smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/228 Apr 14 13:54:41 build #273 of bcm53xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/273 Apr 14 14:58:02 build #276 of ramips.mt7621 is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/276 Apr 14 15:36:08 build #221 of ramips.mt7620 is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/221 Apr 14 15:49:10 build #270 of oxnas is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/270 Apr 14 16:27:11 build #199 of ar71xx.mikrotik is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/199 Apr 14 16:28:21 build #265 of imx6 is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/265 Apr 14 17:27:49 I just did a trunk update for openwrt packages feeds and noticed the python3 package has reverted back to using $(STAGING_DIR_HOST) from $(STAGING_DIR)/host in this commit 57d94bbd44ceba023af46d88261fc79bea88180a. Is there any reason? Apr 14 17:59:05 build #258 of malta is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/258 Apr 14 20:28:17 what do you guys think of the patch series [RFC PATCH 00/10] make symlink /var to /tmp optional ? Apr 14 20:30:20 stintel: sounds resonable? Apr 14 20:30:49 That might cause comfusion however Apr 14 20:31:10 default is to keep it a symlink Apr 14 20:31:32 and except for some paths the behavior stays the same as it is now Apr 14 20:31:46 having /var be a tmpfs violates FHS Apr 14 20:32:19 /var is specifically for stuff that stays around after a reboot Apr 14 20:33:00 stintel: pretty sure most stuff is adapted to use /tmp on OpenWRT however Apr 14 20:33:27 DonkeyHotei: I wonder what apps on OpenWRT actually work that way Apr 14 20:33:43 since /var would be flash memory Apr 14 20:33:56 this is why various distros created /run Apr 14 20:33:59 that's the reason it's symlinked to /tmp right now Apr 14 20:34:24 well I had been thinking of making /run tmpfs too Apr 14 20:34:41 but that's probably a change for procd Apr 14 20:34:54 isn't more or less more common to usr /var/run ? Apr 14 20:35:00 use* Apr 14 20:35:15 nowadays most distros mount /run as tmpfs early on boot and symlink /var/run to /run Apr 14 20:35:27 that's ugly imho Apr 14 20:35:34 /var/run has been abolished by most distros in favor of /run Apr 14 20:35:45 the idea is to avoid too many differents tmpfs filesystems Apr 14 20:35:57 That said, I'm usually in bsd-land :) Apr 14 20:37:08 if the single tmpfs is /run then /tmp can be a symlink to /run/tmp, which at least debian optionally does Apr 14 20:38:04 but afaik /run is not in FHS either Apr 14 20:38:06 or not yet Apr 14 20:38:38 it was proposed for fhs in 2011 i think Apr 14 20:38:54 I don't really think we need a /run Apr 14 20:39:23 but oh well Apr 14 20:39:25 so in my series I decided to not add /run, just optionally not symlink /var to /tmp so that if someone wants, he can keep /var/lib/dhcp.leases (e.g.) saved over reboot Apr 14 20:40:02 like stintel said, the point of /run is to have one tmpfs to rule them all Apr 14 20:40:13 DonkeyHotei: use /tmp Apr 14 20:40:15 but just change path for some config files that are now genrated in /var/etc and change it to /tmp/etc to keep them generated in tmpfs Apr 14 20:41:19 neither /var/etc nor /tmp/etc make much sense Apr 14 20:42:00 well putting configs generated from uci just in /tmp would make it chaotic Apr 14 20:42:14 so I think /tmp/etc does make some sense in our case Apr 14 20:44:12 they should really be in /run/packagename since etc is for persistent config Apr 14 20:45:04 heh... chanbw seems to work. iwlwifi cannot lock it anymore *g* Apr 14 20:45:58 also, as packages get updated upstream, we will start to see them use /run out of the box Apr 14 20:47:12 so you suggest to introduce /run (mounted early in procd) and symlink /tmp to /run/tmp ? Apr 14 20:47:35 and configs generated by init scripts in /run/packagename/blah.conf ? Apr 14 20:48:11 yes Apr 14 20:48:37 so there is a single tmpfs (or 2, another for /dev), and we avoid potential oom by having too many tmpfs around Apr 14 20:49:06 s/avoid/reduce/ Apr 14 20:49:47 leave /var for non-config data that has to live in flash Apr 14 20:50:11 and by default have nothing write to /var Apr 14 20:50:37 and leave it up to the user to move $whatever to /var by changing /etc/config/* Apr 14 20:52:34 configs themselves should stay in /etc Apr 14 20:53:11 well many programs have /etc/config/packagename, and from the values in there, a config is generated every time the init script is run Apr 14 20:53:38 having both /etc/config/something and /etc/something.conf and both on flash, is bad for erase cycles Apr 14 20:56:42 and disk space too although mostly minimal Apr 14 21:00:46 no, that's for /run/packagename Apr 14 21:01:53 /run/packagename/something.conf Apr 14 21:35:33 I just updated my OpenWRT local trunk again and it looks like python3/host is set to install in $(STAGING_DIR_HOST) instead of $(STAGING_DIR)/host . Is this finalized? Apr 14 21:38:32 https://github.com/openwrt/packages/pull/2596 Apr 14 21:39:32 Is it final or just temporarily? Apr 14 21:41:26 everythign's temporary or everything's final, what's the problem exactly? Apr 14 21:42:02 I don't find the message very self explanatory in that pull my self, but I have no interest in this, was jsut remembering the pull from my emails Apr 14 21:43:27 I just compiled python3/host and my $(STAGING_DIR_HOST)/bin still has python3.2 linked to the python3.2 on my computer (host). Isn't the new version supposed to produce a new python3 binary file, i.e. $(STAGING_DIR_HOST)/bin/python3.5 ? Apr 14 21:46:20 how about posting that question then, instead of just askign whether a path change in a makefile is "permanent" or not? Apr 14 21:47:54 I will let others do that. Thanks. Apr 15 00:19:13 build #189 of adm5120 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/189 **** ENDING LOGGING AT Fri Apr 15 02:59:58 2016