**** BEGIN LOGGING AT Fri Jul 27 03:00:01 2018 Jul 27 04:54:35 hi Jul 27 05:55:05 Hi Jul 27 06:22:34 any apu owners tried an lte module? I plan to put two LTE modules.. but from what I've seen online some routers (even with 2 mini pcie slots) are not able to supply enough juice Jul 27 06:22:58 I dont think this will be the case with the apus? given their higher quality Jul 27 07:06:04 abenz, bad idea, use USB LTE modems with USB powered hub Jul 27 07:09:44 or u need to power supply LTE modems independently, the are USB anyway Jul 27 07:23:35 stintel: ping Jul 27 07:26:20 nbd: https://patchwork.ozlabs.org/patch/944358/ looks clean enough code Jul 27 07:26:36 not sure about the feature set though, does look legit Jul 27 07:28:04 was ath79 ever in the 18.06 branch? Jul 27 07:28:24 for a short while, before -rc1 Jul 27 07:28:31 i had this whole idea that i was going to get rspro going with ath79 to use with 18.06 lol Jul 27 07:28:45 but always amrked as source-only, so never actually built Jul 27 07:28:50 i see, thanks Jul 27 07:29:47 and no, you definately don't want the version that has been removed from the 18.06 branch, if you want to look into ath79 (which is a good idea), you definately need to follow master; there have been lots of crucial bugfixes Jul 27 07:40:09 ds_shadof: I see. I had that in mind but was seeking a more elegant solution I suppose.. Jul 27 07:40:11 thanks Jul 27 07:46:29 abenz, or use more juicy DC like i'm here https://forum.lede-project.org/t/wr841n-v13-usb-mod/9098/5 Jul 27 08:41:21 m4t: not in this stable release Jul 27 08:42:03 blogic: are there any intentions of bringing back in for say 18.01.1? Jul 27 08:42:26 just curious, i'll probably go with master and ath79 for my rspro anyways. Jul 27 08:56:49 no plan to do so Jul 27 08:56:59 on the contrary plan is to not do so Jul 27 08:58:13 m4t: I also did think that they work, but I had mixed ath5k and ath9k, and ath5k didn't show any results after scaning. Then I checked klog and this is what poped up: Jul 27 08:58:16 [ 12.364631] irq: no irq domain found for /ahb/apb/pcie-controller@180c0000 ! Jul 27 08:58:19 [ 12.371725] PCI: Enabling device 0000:00:12.0 (0000 -> 0002) Jul 27 08:58:21 [ 13.960702] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xb0010000, irq=0 Jul 27 08:59:16 Unfortunately I'm not so savvy to solve this. Jul 27 09:00:16 tmn505: solve what exactly ? Jul 27 09:00:21 the missing irq domain ? Jul 27 09:00:30 is this ar71xx or ath79 ? Jul 27 09:00:40 it's ath79 Jul 27 09:01:09 all minipci slots have asigned zero irqs Jul 27 09:01:15 out of tree patch or all trunk ? Jul 27 09:01:28 need more info than what you posted Jul 27 09:01:33 this is based on trunk Jul 27 09:01:45 https://github.com/tmn505/source/commit/c1efafd6cf881932104b3354cb36d227fe838eeb Jul 27 09:03:30 tmn505: full bootlog please Jul 27 09:03:37 the pci driver registers a full irq domain Jul 27 09:04:50 blogic: https://paste.ee/p/KExNi Jul 27 09:05:56 this slightly older revision, but afaik there were no changes to ar7161 irq and pci driver since then Jul 27 09:08:03 blogic: this is ar71xx botlog after dirty port to 4.14: https://paste.ee/p/q9eKa Jul 27 09:11:30 hmmmm Jul 27 09:36:23 tmn505: i'm using my original .dts with your modifications to the .mk and base-files Jul 27 09:36:54 i kinda merged the two and defined define Device/ubnt_routerstation which both define Device/ubnt_rs and define Device/ubnt_rspro include Jul 27 09:48:46 m4t: great, does factory image work for You, and sysupgrade after that? Jul 27 09:48:55 i dunno, and i dunno :) Jul 27 09:49:03 i'm doing initramfs only until i get everything else working Jul 27 09:50:32 ok. Jul 27 09:51:53 did you try it? Jul 27 09:54:13 yes, it works fo me, but kernel partition has static size in the definition which must match the kernel partition size in dts, so watch out for that. Jul 27 09:54:54 * image definition Jul 27 09:56:42 yes i changed it Jul 27 09:56:45 rspro is smaller Jul 27 09:57:08 kernel is only 0x0140000 which is *tiny* Jul 27 09:58:58 well i simply picked double the size of ar71xx kernel + pad to simply not changing it after kernel grows again. Jul 27 09:59:37 oh i guess i could change that, maybe i'll have to Jul 27 09:59:51 on my desktop, my kernel is ~3MB and nearly everything is compiled as a module Jul 27 10:01:20 uhm, but redboot only reads that partition i think? as it's defined e.g. "fis list" https://paste.ee/p/d4wsV#d53e2UKSdnrXs3AGL4yRqS1SsWOM7v60 Jul 27 10:02:07 boot script is .. fis load -d -e kernel Jul 27 10:02:46 i suppose you could repartition in redboot Jul 27 10:04:06 yep that is correct, it is necessary for redboot where the kernel partition starts, then kernel takes over with wath's in dts. Would be nice if it could be done as in ar71xx where kernel autodetected the size of partitions, but I don't know if it's possible. Jul 27 10:04:58 *for redboot to know Jul 27 10:05:19 you can repartition from the bootloader Jul 27 10:05:32 "fis delete" and "fis create" Jul 27 10:06:15 keep your jtag handy lol Jul 27 10:06:51 didn't know about that, will have to look at it later Jul 27 10:07:23 yeah. but if it's to be merged to main repo, i think it'd have to remain as it is stock Jul 27 10:08:58 yeah, maybe except the boundary between kernel and rootfs Jul 27 10:10:37 hey, maybe a second reviewer (diizzyy was already happy with it) wants to give the final ok for this? https://github.com/openwrt/packages/pull/5563 Jul 27 10:10:54 won't redboot *only* read from start to end of what's defined in redboot fis? Jul 27 10:11:17 even if you wrote a kernel spanning the kernel/rootfs partitions, it'd only read up to the end of the kernel partition Jul 27 10:14:36 i don't see a way in the bootloader to facilitate that, even if you edited the boot script. "fis load" wants a named partition, and "load" seems to be network-only with no way of reading an arbitrary range in flash Jul 27 10:16:30 Oh yes now i remember, You're right redboot searches the name in fis table. Jul 27 10:17:04 you could probably repartition from userland by directly writing the fis directory Jul 27 10:17:14 if it's not marked read-only. still, risky :) Jul 27 10:19:58 It can't be mounted read only, otherwise sysupgrade won't work, I'll have to recheck later what sysupgrade does. Jul 27 10:20:38 well, kernel and rootfs could be r/w but why would fis/redboot config need to be? Jul 27 10:20:58 not could be, i mean they (kerne/rootfs) would need to be Jul 27 10:22:18 But as i vaguely remember mtd writes new kernel partition size to fis table during sysupgrade. Redboot config stays read-only. Jul 27 10:22:52 Will check later, in few hours. Jul 27 10:24:41 ah really? huh Jul 27 10:25:33 O now I see, this line: mtd -r $append -F$kernelpart:$kern_length:$CI_LDADR,rootfs write - $partitions in platform.sh Jul 27 10:25:42 oh mtd Jul 27 10:25:54 yeah i was just looking @ /package/system/mtd Jul 27 10:27:48 now that i think about it, that's "duh" Jul 27 10:28:01 it'd be a waste of space to have the kernel part *any* bigger than necessary Jul 27 10:29:48 yeah, mine's just about the size of the kernel i flashed to it Jul 27 10:30:18 having them statically defined in dts then seems kind of a pain... Jul 27 10:30:27 Yes but on ath79 kernel with dts doesn't detect the size of partitons, and I don't know how to workaround that. Jul 27 10:31:39 yeah Jul 27 10:32:04 did you try not defining any and just leaving the redboot partition support in kernel =y? Jul 27 10:33:05 Yes, but maybe I did not define it properly don't remeber. On ar71xx there are patches fot mtd subsystem for autodetection just can't figure it out how to wrap it togheter with dts. Jul 27 10:40:57 Documentation/devicetree/bindings/mtd/partition.txt suggests using that for systems that *don't* have a partition table like RedBoot Jul 27 10:41:03 fixed partitions that is Jul 27 10:56:36 tmn505: you need to do two things, a) add a compatible to the redboot-parser so it's available from devicetree (assuming it doesn't have one yet), b) use it for the partitions-node Jul 27 10:58:56 how would you get the mac address out of them then? sounds tricky :/ Jul 27 10:59:03 maybe a combination? Jul 27 11:19:33 FFS send help It's to hot here in the UK! Jul 27 11:46:30 * ldir is too busy melting :-) Jul 27 11:54:12 nbd: i'd like you to provide a proper description for the 311-ARM-BCM5301X-Add-power-button-for-Buffalo-WZR-1750DHP.patch [PATCH] ARM: BCM5301X: Add power button for Buffalo WZR-1750DHP Jul 27 11:54:19 nbd: i think we were talking about this few times Jul 27 11:54:31 nbd: otherwise I'd prefer to drop this patch Jul 27 11:54:46 nbd: can you look at that, please Jul 27 11:55:52 rmilecki: still no response from luka on https://github.com/openwrt/packages/pull/6460 Jul 27 11:56:04 DonkeyHotei: thanks for a ping Jul 27 11:56:19 let me test it... I'll try to handle that over weekend Jul 27 11:59:13 this should go in 18.06 Jul 27 11:59:53 DonkeyHotei: i know... but I'm working on other 18.06 fixes right now Jul 27 11:59:56 so both are important :( Jul 27 12:00:11 jow: can you remind me what's the plan for the 18.06? i'm still working on 2 regressions Jul 27 12:02:07 rmilecki: plan was to release today, but we can defer to next week if you prefer Jul 27 12:02:28 I'm also still working on a few luci regressions Jul 27 12:02:37 i'm going holidays on Tuesday Jul 27 12:02:47 so I'm planning to handle remaining regressions over weekend Jul 27 12:02:48 okay, so maybe monday? Jul 27 12:02:51 ok Jul 27 12:02:56 that would work for me Jul 27 12:03:00 thanks Jul 27 12:03:07 we can then publish on tuesdeay/wednesday Jul 27 12:05:17 ldir: hnng Jul 27 12:18:29 jow: if you'd like to save building an image, https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9b47aa93c76ba87b7d84dacd2c881cef6334e3f5 could be cherry-picked for 18.06 release ... it's really not a big deal though. Jul 27 12:21:13 fine with me. blogic ? Jul 27 12:22:00 8iss'][ Jul 27 12:22:55 oops Jul 27 12:28:03 the two devices are identical, the second (or rather: first) sata and the usb port are not populated on the "single" version. I've been running this "unified" snapshot for the last 10 days without any hitches. Jul 27 12:34:31 FYI, i've pushed a mac80211 update to my staging tree Jul 27 12:34:35 please help me test it Jul 27 12:37:28 nbd: signing up for checking it on mwlwifi Jul 27 13:10:16 when tag 18.06.0 ? Jul 27 13:10:43 nc_: monday or tuesday most likely Jul 27 13:13:12 this version looks great! Jul 27 13:14:55 nbd: please wait with backporting mac80211 to openwrt-18.06 until after the final release on monday Jul 27 13:15:02 in case you plan to backport it at all Jul 27 13:19:34 jow: i don't plan on backporting it any time soon Jul 27 13:19:46 it needs solid testing first Jul 27 13:20:42 what about dangole's commits for lantiq vectoring firmware? https://github.com/openwrt/openwrt/commits/master/package/kernel/lantiq Jul 27 13:22:08 do we want to update mac80211 for 18.06 at all? Jul 27 13:23:48 rmilecki: not before 18.06.1 I'd say Jul 27 13:24:32 nothing against updating mac80211 but now would be far too late, there's already too many regressions due to kernel 4.14 Jul 27 13:24:51 mmm Jul 27 13:25:03 can that vectoring firmware be loaded on even the older xrx200s? Jul 27 13:25:20 idk Jul 27 13:25:27 mmm Jul 27 13:25:41 maybe they're cpu dsp, in which case it feasible Jul 27 13:26:10 he hasn't been on irc to ask Jul 27 13:26:11 DonkeyHotei: looks too dangerous to me Jul 27 13:26:22 will not recieve enough test coverage until monday Jul 27 13:35:21 jow: DonkeyHotei: my 2ct, the vectoring firmware extractor fixes the issue at the wrong end and requires internet to work at all Jul 27 13:35:49 jwh: works with all xrx200 boards Jul 27 13:35:57 mkresin: ah so it is cpu dsp then? Jul 27 13:36:22 hm why does it need to be downloaded, can't redstribute? Jul 27 13:36:25 redistribute* Jul 27 13:36:52 jwh: no, dedicated arc chip which does the xdsl. and it's the same chip for all xrx200 boards Jul 27 13:37:03 ah Jul 27 13:37:17 jwh: correct, we are not allowed to redstribute the vectoring firmware Jul 27 13:37:41 jow: lantiq charges their customers with extra licence fees for the vectoring firmware Jul 27 13:37:51 um Jul 27 13:37:57 is it.... stolen? :D Jul 27 13:38:53 jwh: no really. vectoring firmware extractor downloads an image for the deutsche telekom speedport and unpacks the image to get the xdsl firmware binary Jul 27 13:39:02 aaah Jul 27 13:39:33 reminds a little bit on that msttcorefonts package that cab-extracted windows isntallers to obtain arial.ttf, verdana.ttf and a bunch of other fonts Jul 27 13:39:43 when technology meets legal Jul 27 13:39:46 since its dtag, is it isdn vdsl only? Jul 27 13:40:24 jwh: doesn't matter, the annex a/b differences doen't apply to vdsl Jul 27 13:40:51 yeah but delivery type does (pots vs isdn) Jul 27 13:41:03 or is the vectoring bit just generic? Jul 27 13:41:11 generic Jul 27 13:41:14 ah Jul 27 13:41:15 cool Jul 27 13:41:36 annex a/b only applies to ADSL Jul 27 13:42:47 jow: yeah, similar to msttcorefonts. just that you need a working network connection to download stuff required to establish the network connection Jul 27 13:42:51 yeah but there are still frequency differences for pots vs isdn Jul 27 13:43:02 thats why I was wondering if it was specific to that since its dtag Jul 27 13:43:50 although I guess since the lantiq stuff seems to be software controlled I guess that doesn't matter Jul 27 13:48:35 hm I wonder Jul 27 13:48:53 vectoring is the only thing I'm actually missing from xrx200 modems to get them approved by the access network Jul 27 13:49:12 (and thu remove a giant headache with dumbass blackbox modems) Jul 27 13:49:14 thus* Jul 27 13:53:11 mkresin: if you look into the G.993.2 spec, annex a/b/c/j still exists for VDSL, and IIRC dtag has some extra requirements to reduce the chance of interference of neighboring pots/ISDN lines Jul 27 14:01:42 always dtag who gotta be difficult, whats wrong with pots :D Jul 27 14:02:04 guess it made sense to be able to use existing infrastructure Jul 27 14:03:06 KanjiMonster: G993.2 is VDSL2 and the annexes are not the same as ADSL Jul 27 14:03:10 (also, there is no annex J) Jul 27 14:03:52 germany still love their isdn Jul 27 14:04:33 it's almost like they're conservative or something... Jul 27 14:04:49 :D Jul 27 14:05:09 iirc they stopped selling ISDN entirely here heh Jul 27 14:05:16 I'd say its rather a case of not investing money Jul 27 14:05:26 yeah Jul 27 14:05:30 and melking rotting infrastructure as long as possible Jul 27 14:05:33 Monkeh: right, but a/b/c still exist Jul 27 14:05:48 Yes.. but they do not imply remotely the same thing as those annexes in G992.3 Jul 27 14:06:02 since most of the existing infra was isdn it makes sense heh Jul 27 14:08:39 jwh: isdn focibly does in germany as well. existing contracts are going to be terminated and you are foced to do sip Jul 27 14:08:48 jwh: *dies Jul 27 14:08:57 ah Jul 27 14:09:10 good Jul 27 14:09:33 down with E1s! Jul 27 14:10:31 even germany seems to be leaving ISDN. DECT on the other hand, that still seems to be going strong. Jul 27 14:10:57 DECT is kinda useful though if you want working cordless phones Jul 27 14:11:05 yeah but 1&1 still sells ISDN as default "premium" option for all new 12 months contracts, they remove it on monthly contracts Jul 27 14:13:39 i think the main difference is that germany cares about land lines, something my friends from the US always joke about :) Jul 27 14:14:59 andy2244: considering the quality of mobile telephony in germany, I'm not surprised. Jul 27 14:15:09 same as several countries in europe, we just had better copper coverage (smaller, etc) Jul 27 14:15:37 heh is it that bad? Jul 27 14:16:11 jwh: well, it depends what you compare it with, of course. It's just that I am used to better. Jul 27 14:16:48 heh Jul 27 14:18:22 i think one of the main reasons is that mobile is expensive in germany. You still play like 5-7€ for 500MB-1GB data option... Jul 27 14:18:32 how do I refresh patches for all targets? Jul 27 14:19:02 andy2244: that isn't so bad, similar to here Jul 27 14:19:22 although I'm paying 15GBP/mo for 30G atm, so not so bad Jul 27 14:20:02 +5GBP on an adhoc basis for all I can eat (which it really is, I did about 260GB/mo 2 months in a row) Jul 27 14:21:09 roaming sucks though, no LTE but do get 13G/mo roaming included (also outside of europe which is nice) Jul 27 14:22:10 yeah i don't think those options even exists here for your normal user, there are like 30-60GB options for 50-70€/month Jul 27 14:23:43 what the tech savvy can do is try to get a contract with high 128-196kbit up/down rate after you exceeded your monthly volume Jul 27 14:24:13 heh Jul 27 14:27:23 in thailand they had 30 days 6 megabit/s unlimited GB for around 18EUR. It actually worked very well, I did 60GB or something in a month. Sweden doesn't really have any unlimited mobile data anymore. Jul 27 14:28:02 nice Jul 27 14:29:58 gninrom Jul 27 14:30:14 what a nice friday for release of 18.06 :-) Jul 27 14:38:08 18.06 has bin pushed back to next Monday Jul 27 14:38:36 there is 2 or 3 bugs that have to be fixt first. Jul 27 14:38:59 and we don't want to push out a build like a aaa game lol Jul 27 14:39:12 keep asking for releases Jul 27 14:39:14 :D Jul 27 14:49:33 jwh: ok, I will :-D Jul 27 16:32:18 KanjiMonster: m4t: Thanks, I'll try to poke around it during the weekend, but given my lack of knowing any programing language I don't forsee any progress in that regard. Jul 27 16:34:19 tmn505: best case it amounts to this https://github.com/openwrt/openwrt/blob/master/target/linux/brcm63xx/patches-4.14/122-mtd-bcm63xxpart-add-of_match_table.patch for the adding compatible part Jul 27 16:36:50 Thank You very much for the example this is good point to start. Jul 27 17:08:56 rain! YES! Jul 27 18:23:20 how do I refresh patches for all targets? Jul 27 18:28:12 I'd use the update_kernel script in maintainers git repo... and specify the current kernel version so it doesn't try a new kernel but just refreshes the patches. Jul 27 18:28:12 rmilecki: use update_kernel.sh from https://git.openwrt.org/?p=maintainer-tools.git;a=tree Jul 27 18:28:30 KanjiMonster: i'm looking at it Jul 27 18:28:52 I think there is no "just refresh the patches" mode, feel free to add one Jul 27 18:30:01 but then again, this would miss patches for non-default kernel versions Jul 27 18:57:02 Hello all Jul 27 19:17:41 hm Jul 27 19:18:03 is there a way to install init scripts but leave them disabled by default? Jul 27 19:26:29 patches-2.0/100-musl-compat.patch still fails Jul 27 19:27:59 jwh: kind of. You can install a default file (/etc/default/) and add a #PROGRAM_ENABLE=yes line and the init script can refuse to start if PROGRAM_ENABLE=yes is not set. Jul 27 19:28:21 ah hm Jul 27 19:28:34 how does enable/disable do it, same thing? Jul 27 19:29:13 jwh: and you can add a postinstall script to disable the autostart. But the install would start it anyway when the prog is fist installed. Probably it would be a dirty hack. Jul 27 19:29:23 yeah Jul 27 19:29:29 these are all built in anyway Jul 27 19:29:40 don't have any packages Jul 27 19:29:52 no, disable makes sure that the script is not added the the default runlevel. So it won't get autostarted. Jul 27 19:30:02 hm Jul 27 19:30:11 I like the PROGRAM_ENABLE thing Jul 27 19:30:13 wonder if I could do that during building Jul 27 19:30:13 hmmm the znc bump fails to build for me https://pastebin.com/up3xBMZJ as an FYI KanjiMonster Jul 27 19:36:59 ldir: I think I see why Jul 27 19:38:34 am happy to test a fix when you're ready Jul 27 19:39:23 ldir: between I build checked the original pr on my server, and downloaded the pr on my home vm to commit some cmake stuff crept in Jul 27 19:40:54 he he - yeah I've cross pollinated commits between machines myself :-) Jul 27 19:43:59 ldir: should be now fixed Jul 27 19:45:03 thank you - will give it a try Jul 27 19:45:38 jwh: the common way is having a uci option that defaults to disabled, and let the service check on start for it (that way the enabled/disabled state also survives sysupgrades) Jul 27 19:45:59 yeah I was thinking about that Jul 27 19:46:46 howwwwwwwwever, if its a generated option it may not start the service (similar to how the default shell script that checks uci doesn't have any effect during boot) Jul 27 19:47:16 err, the ttylogin bit Jul 27 19:47:50 there was something similar on the list a while back, where any delay in mounting the overlay causes weird behaviour Jul 27 19:48:40 KanjiMonster: yay - much happier :-) Jul 27 19:48:41 so its kinda unreliable doing it like that, sysupgrade reinits the overlay Jul 27 20:05:20 hi, probably since upgrading to 17.05 i get an error in the pppoe init phase Jul 27 20:05:22 daemon.notice netifd: wan (): Command failed: Permission denied Jul 27 20:05:39 how can i dig further? Jul 27 20:17:16 KanjiMonster: i'll have a request to you Jul 27 20:17:27 KanjiMonster: i noticed that brcm63xx has custom mtd patch Jul 27 20:17:29 for partitions Jul 27 20:17:45 i pushed upstream/generic patch to the "generic" and reverted it for brcm63xx Jul 27 20:17:58 KanjiMonster: could you rewrite brcm63xx to use the new/upstream/generic implementation? Jul 27 20:18:27 rmilecki: what's the upstream/generic implementation's difference? Jul 27 20:18:55 KanjiMonster: mtd_parse_part() call in add_mtd_partitions() was replaced Jul 27 20:19:10 KanjiMonster: it conflicts with your if (mtd_is_partition(master)) return -ENOENT; Jul 27 20:19:21 but it should be very similar I think Jul 27 20:19:45 rmilecki: I meant behaviour-wise from mtd - can I still assing parsers to single partitions? Jul 27 20:19:53 KanjiMonster: yes Jul 27 20:20:24 KanjiMonster: see the last 2 patches in the http://git.infradead.org/l2-mtd.git Jul 27 20:21:42 rmilecki: shouldn't that mean you could just drop my patches instead of reverting yours? Jul 27 20:22:16 there was a conflict and I didn't want to resolve it without having a hardware to test on Jul 27 20:22:32 ok im lost here... https://github.com/openwrt/packages/pull/5563/files shows samba4 being added to net/samba4 in packages.... yet https://github.com/openwrt/packages/tree/master/net/samba4 doesn't exist Jul 27 20:22:36 and i don't see any other commits that reference it Jul 27 20:22:51 anyway, bbl, trying to take a look at the moon ;) Jul 27 20:22:56 :) Jul 27 20:22:58 have fun! Jul 27 20:23:33 it's cloudy here dammit after days of clear nights Jul 27 20:23:59 also, mtr changes are no good Jul 27 20:24:00 root@rooter:~# mtr 10.10.10.10 Jul 27 20:24:00 mtr: Failure to start mtr-packet: Invalid argument Jul 27 20:26:10 ooh samba4 Jul 27 20:26:17 that is exactly what I was after the other day Jul 27 20:26:28 saves me installing broken ass debian crap on it :D Jul 27 20:33:23 mtr missing mtr-packet Jul 27 20:33:32 + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/mtr-packet $(1)/usr/sbin/ Jul 27 20:33:34 gonna see if that works Jul 27 20:34:23 still curious where the samab4 dir went off to Jul 27 20:36:13 ah that samba4 wasnt merged Jul 27 20:36:14 derp Jul 27 20:36:47 but the luci app for it was Jul 27 20:40:58 jow: https://bugs.openwrt.org/index.php?do=details&task_id=1688 fixed/closed Jul 27 20:41:06 onw more regression left (SPI controller driver) Jul 27 20:41:15 cc mamarley Jul 27 20:41:28 rmilecki: Thanks! Jul 27 20:41:32 :) Jul 27 20:54:25 also configured that this works: https://github.com/openwrt/packages/pull/6560 Jul 27 21:01:28 hmph, +libopenssl should be fine for depends, right? Jul 27 23:06:51 hm I don't quite understand this, I can build multiple targets with per device rootfs or whatever right? Jul 27 23:07:39 the env stuff is still relevant right? Jul 27 23:10:49 trying to figure out how to automate building with env switching but I don't quite get it Jul 27 23:44:09 jwh: per-device rootfs only helps you with building for multiple devices of the same target arch (e.g. ar71xx, ipq806x, etc.), you can not use it to build ar71xx and brcm47xx or lantiq in one go Jul 27 23:44:16 ah hm Jul 27 23:44:32 guess I should probably split targets up anyway Jul 27 23:44:50 I would just use buildbot btu I don't understand it :D Jul 27 23:45:26 it's still very useful to adapt the configuration for the different devices (e.g. ar71xx: tl-wr941ndv2, tl-wr1043ndv1, tl-wdr3600, tl-wdr4300) Jul 27 23:45:34 hm, yeah Jul 27 23:45:44 I'll probably find some use for that later on Jul 27 23:46:22 just use it from the start, even if you don't adapt the config for your individual devices yet ;) Jul 27 23:46:44 heh Jul 27 23:46:56 I was trying to figure out how to use the environment stuff as well to make it nicer Jul 27 23:47:11 CONFIG_TARGET_MULTI_PROFILE=y and CONFIG_TARGET_PER_DEVICE_ROOTFS=y is part of my common configuration Jul 27 23:47:15 guess that makes less sense for automation though Jul 27 23:47:25 mmk Jul 27 23:48:30 I need to figure out device profiles anyway at some point Jul 27 23:49:19 I puzzle together my config (to be expanded by make defconfig) from individual files, config.init for my common stuff, asterisk.init and strongswan.init as extention of that (for the targets where that makes sense) - and just the target specific stuff in ar71xx.init, ar71xx-tiny.init, ath79.init, brcm47xx-generic.init, brcm47xx-legacy.init, ipq806x.init, lantiq.init, lantiq-easybox.init Jul 27 23:49:58 as in: cat ipq806x.init config.init strongswan.init >/path/to/openwrt/.config Jul 27 23:50:15 make -j32 defconfig oldconfig download //done Jul 27 23:50:28 ah, pretty much atm the build script (still using jenkins coz thats the only thing I know), just echoing target stuff into .config, defconfig then make Jul 27 23:50:35 then rsync -ar --delete blah Jul 27 23:50:58 bin/targets/$arch, bin/packages/$arch Jul 27 23:51:05 or $target, $arch, rather Jul 27 23:52:08 pkgadd: hm, wonder if thats a better idea actually Jul 27 23:52:44 guess I could actually just chuck the initial bits into my repo at least, rather than having them in the build script Jul 27 23:54:35 pkgadd: how do you manage build keys? Jul 27 23:55:25 torn between just adding them to my repo, or copying them everytime something is built Jul 27 23:56:57 I don't, # CONFIG_PACKAGE_usign is not set Jul 27 23:57:09 a Jul 27 23:57:10 ah Jul 27 23:57:15 I basically don't use opkg on the devices at all Jul 27 23:57:46 I've got a trickery one where I'd like to have the full compliment of packages/tools available in the image, but on some targets (currently only lantiq) there just isn't room Jul 27 23:57:57 so for lantiq I have to make them =m, rather than =y Jul 27 23:58:01 it's all preconfigured as needed via TARGET_PER_DEVICE_ROOTFS - and if I need something in additin, I usually build a new image Jul 27 23:59:22 that's exactly where TARGET_PER_DEVICE_ROOTFS is useful, you enable them as =m in your generic config and add them to the devices that need them Jul 27 23:59:28 e.g. http://paste.debian.net/1035505/ Jul 28 00:00:24 ooh Jul 28 00:00:37 (look at -wpad-mini, to remove default packages) Jul 28 00:00:48 didn't know i could do that magic Jul 28 00:01:31 thats certainly better than mangling .mk, no changes required Jul 28 00:03:01 it's really convenient Jul 28 00:05:28 yeah Jul 28 00:05:39 renders a whole bunch of commits obsolete which is nice Jul 28 00:06:31 less deviation from upstream the better heh Jul 28 00:50:10 hm, may have to nuke these commits, coz still gonna cause conflicts when rebasing later **** ENDING LOGGING AT Sat Jul 28 02:59:59 2018