**** BEGIN LOGGING AT Mon Jan 11 02:59:58 2016 Jan 11 08:44:27 jow r48197 branches/chaos_calmer/include/download.mk Jan 11 08:44:27 CC: build: add a variable pointing to the main openwrt git repositories (useful if we want to support using a mirror later) Jan 11 08:44:41 jow r48198 branches/barrier_breaker/include/download.mk Jan 11 08:44:41 BB: build: add a variable pointing to the main openwrt git repositories (useful if we want to support using a mirror later) Jan 11 11:58:11 jow r48199 branches/barrier_breaker/package/ network/services/samba36/patches/012-patch-cve-2015-5299.patch network/services/samba36/patches/010-patch-cve-2015-5252.patch network/services/samba36/patches/011-patch-cve-2015-5296.patch network/services/samba36/Makefile * BB: samba36: add three CVE patches from 2015-12-16 Jan 11 12:30:33 nbd r48200 trunk/package/system/uci/Makefile * uci: update to the latest version, adds a small optimization to uci commit Jan 11 13:54:16 is there any sane way of having patches for an existing feed? I've got a BB/1407 tree that has an older luci, and I want to cherry pick some patches from newer luci, but as it allcomes in from a feed, I don't have any obvious "patches" dir to drop things in? Jan 11 13:54:33 I can fork and make my feeds.conf point to a patched version of luci, but that seems kinda gross too. Jan 11 13:55:20 karlp: is your olderl uci already the modularized version? Jan 11 13:55:34 where each component is its own package Jan 11 13:55:49 what does "modularized" mean? it's the 0.12 tree from "https://github.com/openwrt/luci.git;luci-0.1" Jan 11 13:57:29 so, hm, no, I don't think so if I compare it to the current master stuff Jan 11 13:58:01 karlp: in this case you should be able to drop local patches into contrib/package/luci/patches/ Jan 11 13:59:42 but everything inside the /feeds/luci directory gets trashed if you clean and install feeds right? Jan 11 14:00:31 I mean, I can just edit the files directly and make sure not to do scripts/feeds/update too I guess. Jan 11 14:00:34 it should only get trashed if the feed source url changes Jan 11 14:00:47 else its a simple "git pull" after the initial clone Jan 11 14:01:35 hrm? how does a git pull help? where would I be pulling from? Jan 11 14:02:17 if you update a (git) feed for the first time it is clone from its source into feeds/feedname Jan 11 14:02:42 subsequent scripts/feeds update translate into "git pull" for each already present clone in feeds/feedname Jan 11 14:03:09 *unless* the source url for the feed named "feedname" changed since the last scripts/feeds update call Jan 11 14:03:36 so if you place untracked patches into feeds/luci/contrib/package/luci/patches/ they should be unaffected by "scripts/feeds update" Jan 11 14:04:21 right, except that they're just untracked files then. I've got my own openwrt fork for some board patches, but I can't put a patch for a feed package there and have it actually be available in a checkout for another user, Jan 11 14:04:49 ah Jan 11 14:05:12 yeah, there is no mechanism for applying patches on top of external feeds Jan 11 14:05:20 you need to fork them Jan 11 14:05:30 yeah, I didn't think so. was just wondering if there was some other mechanism I didn't know about. Jan 11 14:55:40 karlp: I don't know if this will help. If you don't already have a git server, have your patches on GitHUB and have them checkout the a different directory. Then, create each symlink file from the checkout directory to your feeds/luci/contrib/package/luci/patches directory? Jan 11 14:56:09 *checkout to a different directory* Jan 11 14:59:46 just going to have a fork of luci for a little while, shouldn't be too hard. Jan 11 15:00:03 already had a fork on github for submitting patches to luci anyway, Jan 11 15:00:10 ok. Jan 11 15:00:23 only need this until I get off my arse and finish moving forward to CC tree anyway :) Jan 11 15:00:38 IC. Jan 11 15:39:34 anyone knows about an alternative to pupnp-miniupnp ? Because I am looking at the code and it's really horrible code :( if there are no alternatives, which one would you recommend? Jan 11 15:40:09 * txomon has left out gupnp because it has glib deps Jan 11 15:45:30 depends what parts of upnp you want I guess? Jan 11 15:45:42 ita's all going to be pretty gross code though Jan 11 15:54:04 karlp: I want ssdp, which I had thought on reusing minissdp (although the api/code is pretty demonic), and the functions retrieval and execution Jan 11 15:54:34 the thing is that at the end I would need to have all the XML and SOAP stuff Jan 11 18:38:03 nbd r48201 trunk/package/ (6 files in 2 dirs) * openvpn: update to version 2.3.10 Jan 11 18:52:22 rmilecki r48202 trunk/package/network/services/hostapd/patches/150-nl80211-Report-disassociated-STA-lost-peer-for-the-c.patch * hostapd: fix disassociation with FullMAC drivers and multi-BSS Jan 11 20:13:52 nbd r48203 trunk/ (5 files in 2 dirs) * kernel: Update kernel 4.4 to 4.4.0 Jan 11 20:51:54 nbd r48204 trunk/package/firmware/linux-firmware/mediatek.mk * linux-firmware: fix mediatek/ralink package names Jan 11 22:09:11 rmilecki r48205 branches/chaos_calmer/package/network/services/hostapd/patches/150-nl80211-Report-disassociated-STA-lost-peer-for-the-c.patch * hostapd: fix disassociation with FullMAC drivers and multi-BSS Jan 11 23:11:44 nbd r48206 trunk/target/sdk/Makefile Jan 11 23:11:44 target/sdk: include modules.builtin, it is necessary for packaging kernel modules Jan 11 23:11:48 nbd r48207 trunk/include/kernel.mk * build: remove SDK special case for kernel module packages Jan 11 23:18:19 does anybody know the nickname of Daniel Dickinson from the mailing list? Jan 12 00:47:29 cshore, no? Jan 12 01:14:41 swalker ah, probably Jan 12 01:15:38 he did a good job proposing things and I want to thank him, but.. some things he does are funny :P Jan 12 01:17:09 did a lot of preinit work years ago iirc **** ENDING LOGGING AT Tue Jan 12 02:59:59 2016