**** BEGIN LOGGING AT Tue Mar 01 02:59:58 2016 Mar 01 05:32:31 stintel: ack Mar 01 09:17:21 hello guys Mar 01 09:18:44 I came here to ask about what happened to svn, but I got an answer, thank you guys Mar 01 09:22:40 mrkiko: we've been suggesting people to move over to the git interface for about a year now, and the server change ended up being an opportunity to do so Mar 01 09:23:21 mrkiko: later git.o.o will be on the same box so syncronization will happen in the post commit hook immediately Mar 01 09:24:07 mrkiko: the reason is that git lowers server load, like if you are looking into older changes, your client does it locally instead of poking at the server all the time Mar 01 09:24:25 mrkiko: also provides you with bisecting, so it's easier to track down regressions Mar 01 09:32:13 thank you Kaloz Mar 01 09:32:31 Kaloz: Oh, I relaly liked svn because of the "svn log" thing only, more or less Mar 01 09:32:50 mrkiko: git log will be way faster, beleive me ;) Mar 01 09:33:01 But this may be due to the fact that I am not so good in using git; I would like to use git log and have an effect similar to what you could have obtained with "svn -v log" Mar 01 09:33:10 and looking up user provided revisions will be a joy Mar 01 09:33:11 Kaloz: that for sure Mar 01 09:33:17 finally I have a reason to keep two svn clones Mar 01 09:33:23 or two git clones rather Mar 01 09:33:31 jow_laptop ;) Mar 01 09:33:53 I am already annoyied by "sghasgasfgafasffoobarabcdef" broke bla Mar 01 09:34:08 I usually resort to google sghasgasfgafasffoobarabcdef Mar 01 09:34:19 in order to figure out the repo they might have used Mar 01 09:34:57 oh, I would like to create no debate on this, for me it was a matter of "reading the log confortably" Mar 01 09:34:59 oh and no idea if 071f5442178e57fe2ed84a86ccc602467e3dc622 is newer than 6473fdca06d2199eaca33e3abaee1cbd6fca25e4 Mar 01 09:35:35 mrkiko: its fine ;) git log will provide you with the same info as svn log does and some more goodies like git log --grep=blah Mar 01 09:36:16 its also faster and defaults to page itself through less, so rather comfortable to read Mar 01 09:37:08 :D thank you Mar 01 12:48:56 hrm, that pidfile writing I was trying yesterday is having some issues with writing pids early, I get "Resource temporarily unavailable" and "INterrupted syscall" on the write calls :| Mar 01 12:49:29 write calls to where? Mar 01 12:49:31 and in->proc.pid is 0. Mar 01 12:49:32 to a socket? Mar 01 12:49:39 to /var/run/some.pid.file Mar 01 12:50:52 after it's up, in->proc.pid contains the correct pid and the writes succeed and have the right content, but it fails to write the pidfile when it's booting up. Mar 01 12:50:58 and what do you mean with write pids early? Mar 01 12:51:23 like, etc/rc.d/S60myprocess timeframe. Mar 01 12:51:36 works fine after it's running if I do /etc/init.d/myprocess restart Mar 01 12:51:46 can you paste your current modifications again? Mar 01 12:52:44 yeah sure, https://github.com/karlp/procd/blob/pidfiles/service/instance.c#L323 is where I get a in->proc.pid of 0 while we're still booting up and running init scripts, Mar 01 12:52:54 but a valid pid afterwards. Mar 01 12:53:53 and https://paste.fedoraproject.org/331645/45683682/ for the procd debug log from boot time... Mar 01 12:54:14 Kaloz: yes, conceptional problem Mar 01 12:54:18 sorry, karlp ^ Mar 01 12:54:36 hrm, one of my apps gets the right pid, one of them doesn't Mar 01 12:54:45 karlp: instance_run() is the child-after-fork code path Mar 01 12:54:53 that one always has a pid of zero Mar 01 12:55:28 hrm,if I have respawn set, the second one has the pid there. Mar 01 12:55:32 but yeah, ok. Mar 01 12:55:36 you want to do the pid writing somewhere in line 408 onwards (and not in instance_run as this is essentially just an exec* wrapper) Mar 01 12:56:17 fair enough, Mar 01 12:56:27 see line 400 Mar 01 12:56:28 the other place was jsut where most of the other paramets seemed to be handled. Mar 01 12:56:31 and then line 404 Mar 01 12:57:05 yeah, my bad, I added the pid output on lin 408, didn't really notice the fork in the wrong place. Mar 01 12:57:36 I suggest to move line 315-338 into a static utility function Mar 01 12:57:48 something like instance_writepid() Mar 01 12:58:01 then call that in line 422 Mar 01 12:58:15 sure. Mar 01 12:58:19 give it the entire struct service_instance * as argument Mar 01 12:58:36 what's teh difference between instance_stop and instance_restart then? I'd like to remove the pid on stop, but both those methods are the same at present. Mar 01 12:59:41 do the unlink on both Mar 01 13:02:27 or rather write another static instance_removepid() utility function which cheks whether (in->pidfile) is set, then unlinks based on that, with a log warning if the pid file cannot be unlinked or if its content does not match the expected pid Mar 01 13:03:33 reall need to check the content? is there any use in that? Mar 01 13:04:02 I just thought that more integrity checks are better as the entire concept of pid files is racy Mar 01 13:04:34 plus you do not want to delete files which are not really pid ones Mar 01 13:04:57 it only deletes the one that was specified, thatð's surely useer error if they use that file for soemthign else while the service is running. Mar 01 13:05:52 karlp: then skip the check, we can still add it later Mar 01 13:44:38 ok, movign the create to the right place all works now once it's booted, during boot though I still get thigns like https://paste.fedoraproject.org/331662/14568397/ or https://paste.fedoraproject.org/331664/83987214/ Mar 01 13:44:55 stop/restart nicely create new pids and remove them, Mar 01 13:47:56 karlp: write() returns the number of bytes written and you do if (write(...)) Mar 01 13:48:12 so you basically report an error where there is none and errno is undefined Mar 01 13:48:36 oh bah, carry over from when I was tryign tow rite the pid_t directly, which was creating empty files due to some flush or something Mar 01 13:48:38 karlp: use if (write(...) <= 0) Mar 01 13:48:55 why would it work ok post boot though? Mar 01 13:48:58 or even better use fprintf to avoid the need for intermeidate buffers Mar 01 13:49:47 oh yeah, I can fopen instead of open I guess. Mar 01 14:33:48 why is berkley-db stuck with 4.7 version released in 2008, any technical reason it's not updated? Mar 01 14:35:42 noone cares Mar 01 14:37:34 maintaining those packages takes time and even currently many maintainers in github have open pull requests or broken packages in some corner cases Mar 01 14:38:46 I have been learning openwrt on and off these years, openwrt is _the_ choice for many iot platforms these days in addition to the router devices Mar 01 14:39:12 I honestly feel Linux Foundation should sponsor openwrt and push this platform to the front page Mar 01 14:39:39 so the resource issues can be addressed much better Mar 01 14:41:00 or set up a fund that some device vendors can donate, e.g tp-link, netgear,etc Mar 01 14:41:22 most device vendors do not like openwrt that much Mar 01 14:42:08 It cuts into their business model. Why would you buy a new crappy router when you can put OpenWRT on it and have better stability and lots of extra features? Mar 01 14:42:20 exactly Mar 01 14:43:05 that is, unless they profit-generating model is software-based. as long as they can sell hardware, be it replaced by openwrt or not, it does not really matter Mar 01 14:43:07 see Asus - their advertisement for their new routers and bad security even backfired for them with 20years "forced" behaviour in security/review Mar 01 14:43:22 in fact openwrt-capable may sell more of their routers, sounds like a win-win Mar 01 14:44:04 It might make people buy more of their routers initially, but I think a lot of OpenWRT users aren't the type to go buying new routers a lot. Mar 01 14:44:18 ausjke: its difficult to sell such device because most consumer ask for "apps" or so for their routers apparently Mar 01 14:44:51 apps, cloud integration etc. even if its bad (privacy wise) or does not make sense Mar 01 14:45:30 In my opinion, a router should handle only network stuff. Routing, NAT, DNS, DHCP, maybe NTP, but nothing else. Mar 01 14:45:30 the UI is a big part of "sell to customers", talking about UI, I was trying Juci yesterday Mar 01 14:46:16 it uses lighttpd with websocket for two-way packets, and rewrite ubus/rpcd/etc, basically can not coexist with luci Mar 01 14:47:09 it also copied apache 2.0 code and put it into a gplv3 package Mar 01 14:47:29 yeah those damn lawyer trouble Mar 01 14:47:29 and when pointing out some stylistic issues in theu hhtpd changes of them I was told to fuck off and die Mar 01 14:47:57 which greatly reduced my willigness to even look into it :) Mar 01 14:48:11 jow_laptop: really? Martin does answer a few of my questions nicely Mar 01 14:49:02 allegeldy I'm too stupid to write proper C code, yet my stuff is good enough to take and republish under gplv3 Mar 01 14:49:10 with the usual amount of nih adjustments Mar 01 14:49:23 but I would hope it can co-exist with openwrt better, e.g. merge the changes back to openwrt, make luci/juci work "together", etc Mar 01 14:49:41 rather looks like gargoyle v2 to me Mar 01 14:49:47 my wqay or the highway Mar 01 14:49:55 upstream is stupid etc. yadda yadda Mar 01 14:50:26 I wish them luck Mar 01 14:50:37 maybe they'll too open a shop to sell preflashed routers Mar 01 14:50:40 it's sad to see this indeed Mar 01 14:51:23 also gplv3 with exception for signed firmare images Mar 01 14:51:26 wtf Mar 01 14:52:00 will the signed firmware images "kill" openwrt? Mar 01 14:52:18 the new thing from FCC and is pending for enforcement Mar 01 14:52:29 in USA only though Mar 01 14:53:19 as far as I know, not all chips can do "secure boot", but if it does, it's pretty hard to break Mar 01 14:54:43 ausjke: dunno - there are things like "market fragmentation" to consider - several models/companies are only active in certain regions Mar 01 14:55:50 for smaller companies it might be viable to have one single model thats working on all markets - ex: there is only worldwide Raspberry Pi variants Mar 01 14:56:03 jow_laptop: do you want to look at this again, or shoudl I just send it to openwrt-devel now? https://github.com/karlp/procd/commit/f1adca2e18cc56ddec67a7f86f26a585212056ed Mar 01 14:56:14 it's working properly for all the cases I can test with. Mar 01 15:15:19 karlp: looks well enough for an rfc ml post Mar 01 15:15:35 I have minor nitpicks but I'd like to discuss those in a wider audioence Mar 01 15:15:40 *audience Mar 01 15:15:55 for example personally I'd move the removepid right after the kill Mar 01 15:16:35 and you can likely reduce the two in->pidfile vs. in_new->pidfile checks into a single != one Mar 01 15:17:01 and the if (tb[INSTANCE_ATTR_PIDFILE]) block should have a blank line before and after Mar 01 16:40:12 jow_laptop: yeah, I considered whether the unlink should be before or after the kill, but the kill was unconditional, so seemed sane. will send, probably have to be tomorrow mornign though back in the office Mar 01 16:40:21 thanks for the last checkover Mar 01 19:50:53 jow_laptop: thanks for the merge Mar 01 22:43:34 nbd: have the mac80211 antenna gain patches ever been discussed for upstream inclusion? Mar 01 22:58:55 Also, I don't see the antenna gain ever being set by default. Wouldn't it make sense to set this to the txpower offset from the iwinfo hardware database by default? (Maybe factoring out the db to avoid depending on iwinfo for this?) Mar 01 22:59:32 neoraider: such info should probably go into board.json Mar 01 23:00:08 maybe it would make even more sense to encode such "quirks" into ath9k itself Mar 01 23:01:45 but then any kind of shared db sucks Mar 01 23:02:31 jow_laptop, yes... or finally getting device tree support for ar71xx and encoding it there (which is just another project I'd like to tackle, but don't have time for...) Mar 01 23:05:44 there's still a number of odd minipcie radios Mar 01 23:06:05 but I guess the 5 or so well known ones can be indeed added as quirk array to ath9k, based on their pci ids Mar 01 23:06:41 thinking of candidates like the sr-71 Mar 01 23:09:50 jow_laptop, do you know if there are also radios with negative offset, or are these things usually driver bugs (not reading the calibration data right or something)? Thinking of https://dev.openwrt.org/ticket/19402 Mar 01 23:10:59 never heard of ones Mar 01 23:11:16 the limits quoted in the ticket do not look that unreasonable Mar 01 23:12:27 the claimed 27dbm in stock firmware are suspiciously close to the usual 30dbm legal limit minus the standard 3db antenna gain factor Mar 01 23:12:54 = probably theoretical limit clamped down by the hw Mar 01 23:13:47 am too lazy to dig out the fcc test reports though Mar 01 23:14:50 I think dangole is spot on with his last comment Mar 01 23:15:04 likely not a tx power issue but related to rx filters Mar 01 23:15:22 Hmm, I'm not sure what the people in the ticket even claim, but we've had some reports that the TX power of the CPE510 is unusably low. But I haven't tested it myself, so maybe these were just people with wrong expectations Mar 02 02:02:22 hmm, dangole "bricks" my pogoplug and then promptly disappears! ;-) Mar 02 02:05:21 * russell-- still thrashing around trying to recover with tftp without a complete erase/reinstall, used to be able to netboot an initrd image and flash from there, /me missing the right incantation **** ENDING LOGGING AT Wed Mar 02 02:59:58 2016