**** BEGIN LOGGING AT Thu May 07 02:59:57 2020 May 07 06:43:21 zx2c4: mangix: what about that Wireguard version bump for 19.07? https://patchwork.ozlabs.org/project/openwrt/list/?series=169538 May 07 06:49:29 ynezz: mangix you might consider a yet newer version, that i posted today May 07 06:51:34 zx2c4: thanks, will do May 07 06:52:41 ynezz: https://patchwork.ozlabs.org/project/openwrt/patch/20200506222246.1348177-1-Jason@zx2c4.com/ May 07 07:05:03 zx2c4: just merged it into my tree, BTW there was similar backport request for 18.06 stable release, but I've rejected it as it seemed too much for that stable release, so whats your view on this? May 07 07:05:52 19.07 has 4.14 kernel, 18.06 has 4.9 and 4.14 kernels May 07 07:06:48 ynezz: my view is that for a long time wireguard was in development at a very rapid pace, and it was really cool of openwrt to take wireguard on during its early stages. recently wireguard has stabilized and become integrated into the linux kernel, where the churn and immaturity is a thing of the past. with the upstreaming, we're now squashing interesting bugs from the wider array of testers. this leads me to think that everything May 07 07:06:48 before now was utterly broken buggy garbage, and that what's being released now finally has some polish to it. therefore, i'd strongly encourage you to backport the latest to all the stable releases May 07 07:07:38 zx2c4: ok, will do May 07 07:07:44 cool thanks May 07 07:17:29 :) May 07 08:36:38 ynezz: did you look at the fuzz link I sent a while back? May 07 08:36:52 we could add `ubus` as a start and see how google tries to break it May 07 08:43:33 aparcar[m]: feel free to do so May 07 08:48:08 I'm aware about that foss fuzzing since I've started adding fuzzing to OpenWrt C projects, but there is still much more work needed May 07 08:49:32 ynezz: I'm curious so I'd look into it. They require a gmail address to access their dashboard, I'd just create openwrt-ubus@gmail.com for that purpose and share the creds with you? May 07 08:51:08 I'm not interested in this, I would rather spent that time on improving amount of fuzzed projects/code May 07 08:51:30 why ubus? it has just a basic fuzzing IIRC May 07 08:52:00 libubox has better fuzzing coverage as it is library May 07 08:54:02 there are other (~30?) projects which still need at least CI build testing, static analyzer, (unit) tests, fuzz... May 07 08:59:03 1. need to write some docs about the CI 2. create some (wiki?) page with the status matrix for the projects, something like https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix May 07 09:00:24 some test/fuzz code coverage would be nice as well, currently we're flying blind May 07 09:09:45 ynezz : sth like armbian does like https://dl.armbian.com/_test-reports/ ? or boot-test from baylibre for kernel-ci ? May 07 09:15:55 ynezz: okay good to know, I though it's good to have some free computing and more eyes on the project. Will you write that docs? I can create the matrix stuff at some point May 07 09:16:59 ynezz: could that benefit from some CI resources at OSUOSL? May 07 09:18:00 zorun: I could^^ May 07 09:18:07 aparcar[m]: it's on my TODO list, yes May 07 09:18:10 :D May 07 09:18:37 ynezz: nice :) May 07 09:18:51 zorun: can it run gitlab runners? May 07 09:18:58 btw thanks for the docker fix May 07 09:19:06 aparcar[m]: I guess so? May 07 09:19:26 it's just VMs with public IP addresses May 07 09:20:48 zorun: almost every CI provider currently offer generous resources for free, this is not an issue May 07 09:20:52 zorun: you're welcome May 07 09:20:59 zorun: I would rather use those VMs for buildbots May 07 09:21:30 zorun: some students would be more welcome :] May 07 09:22:03 zorun: yes send some students to ping ynezz May 07 09:22:19 we could probably try to find some funding for them once we finish that SPI->SFC transition May 07 09:22:19 will do :D May 07 09:22:46 OpenWrt Summer Of Code :p May 07 09:23:13 ynezz: btw I implemented the staging builds via buildbot but from my point of view it is not really... nice. It is way more messy than using gitlab for that purpose May 07 09:23:14 for now it's hard for them to dive into the code May 07 09:23:20 but I hope it will get better May 07 09:23:38 ynezz: ok, fine with me (I'm surprised gitlab offers that much resources, the imagebuilder docker images look really large) May 07 09:23:45 imagebuilder + sdk May 07 09:23:52 gitlab.com, that is May 07 09:25:09 I remember build timeouts when using free runners, they only have two cores and don't finish an uncached openwrt build in less than 3 hours May 07 09:26:04 well those docker images are not built from scratch, it's "just" repackaging of rootfs produced by buildbots May 07 09:28:22 and the stuff is stored on hub.docker.com May 07 09:28:23 not on gitlab May 07 09:29:22 ah, right May 07 09:34:37 plntyk: yep, but more like having badges/status (OK/KO) for CI build status, % of code test coverage etc. May 07 13:05:29 bah May 07 13:05:43 tried to order a macchiatobin double shot from farnell but "We do not have authorization from supplier to export this" May 07 13:05:43 ] May 07 13:14:19 stintel, i think i can help you with that ;) May 07 13:14:52 farnell probably knows you are always exporting to iran May 07 13:15:22 stintel: where do you live? May 07 13:15:24 and open source means open information to anyone ^^ May 07 13:15:26 Bulgaria May 07 13:16:04 I asked for a reason, and if there's a way to get this authorization somehow. we'll see May 07 13:16:27 yeah bulgaria is very dangerous - its even in EU May 07 13:16:31 stintel, i can buy it here May 07 13:16:33 indeed :P May 07 13:16:44 outside of Schengen, I suspect that is the reason. May 07 13:16:44 no restrictions May 07 13:16:51 nitroshift: same here (FR) May 07 13:17:03 f00b4r0, i'm from romania May 07 13:17:05 > ' This part is missing US re-export authorisation known as CCATS, we have requested this from the supplier however unfortunately until CCATS has been received we cannot export this product.' May 07 13:17:37 I can add it to my basket, finish the order, but got a mail afterwards May 07 13:17:37 stintel: O_o. Which farnell site did you use? May 07 13:17:38 shouldnt de.farnell.com deliver to EU countries ? May 07 13:17:46 bg.farnell.com May 07 13:17:50 lol May 07 13:17:57 stintel, 27 in UK stock May 07 13:18:00 ^ May 07 13:18:03 nitroshift: same stock on the bg site May 07 13:18:06 ro.farnell.com May 07 13:18:10 I am forced to go to the bg site May 07 13:18:25 stintel, go to the belgium one ;) May 07 13:18:54 well if someone can invoice it to me, feel free to try and order May 07 13:18:58 looks like a nice piece of kit May 07 13:19:41 I have feeling you will get the same mail that I have, after ordering May 07 13:19:48 de.farnell.com limts only to germany and cites "export fees and security" as reason May 07 13:20:00 although the stock number did go down since I looked at initially May 07 13:20:22 plntyk: yes, that's what I meant with "I am forced to use the bg site" May 07 13:24:10 you probably should write to EU trading or sth because they might be violating single market rule and maybe later they will be fined for that May 07 13:24:32 meaning european commission May 07 14:19:28 pkgadd: they’re downstream? do they use ImageBuilder or what? May 07 16:31:06 Could someone help me with a uci problem/issue please? If I have a file /etc/config/foo that contains 'config foo' and then a series of options below it.... May 07 16:31:48 say 'option bar 'wibble' option baz 'wobble' May 07 16:32:04 How do I access those parameters in an init script? May 07 16:32:57 I'd anticipate 'config_load foo' but access to bar and baz is eluding me. May 07 16:34:15 handle_foo() { local bar baz; config_get bar "$1" bar; config_get baz "$1" baz; echo "bar=$bar baz=$baz"; }; config_load foo; config_foreach handle_foo foo May 07 16:34:24 https://openwrt.org/docs/guide-developer/config-scripting#iterating_config_foreach May 07 16:35:00 I have a weird thing with config_foreach May 07 16:35:06 oh I need to do a config_foreach May 07 16:35:12 it tries to load an instance ::data that isn't defined anywhere May 07 16:35:17 I wonder what's up with that May 07 16:35:18 or you give your section a name May 07 16:35:39 config foo thefoo; config_load foo; config_get bar thefoo bar; echo $bar May 07 16:36:08 also, local is not valid posix, I completely skipped the use of local in the last init script I wrote May 07 16:36:54 ok, that explains why I could get it to work if gave the section a name but was looking at other configs without names and wondering 'how does that work!' May 07 16:37:15 thank you! May 07 16:38:53 so I have this script: https://github.com/stintel/lede-wip/blob/master/readsb/files/readsb.init with this config: https://github.com/stintel/lede-wip/blob/master/readsb/files/readsb.config May 07 16:39:20 if I (re)start it, I always get this in logread: Thu May 7 16:39:06 2020 daemon.info procd: Not starting instance readsb::data, command not set May 07 16:39:47 if anyone could explain me where that comes from, would be nice :) May 07 16:51:59 stintel: just a guess but maybe try a procd_close_instance May 07 16:54:05 oh, did I really miss that May 07 16:54:42 jow: awesome, thanks May 07 16:55:11 now I need to clean up that mess of params with a helper function like for the booleans and I can submit it to packages feed May 07 17:27:44 stintel: the macchiatobin is a dual use good and they ahve to take care of export controll to compy with the Wassenaar Arrangement May 07 17:27:58 you also have to do this inside the EU May 07 17:28:12 It would be diffeernt if you could by this in a normal store May 07 17:28:15 and now in English? :P May 07 17:29:11 > Dual use goods are products and technologies normally used for civilian purposes but which may have military applications. May 07 17:29:22 I see May 07 17:39:56 Like toilet paper. Soldiers use it too. May 07 17:40:43 so just a big load of political bullcrap May 07 17:48:12 wtf :P May 07 17:49:09 stintel: well, not necessarily. high precision GPS is useful in surveying and construction. also useful in making smart ground-to-air ordnance… May 07 17:51:18 what's so special about something like a macchiatobin though? May 07 17:52:41 dual MultiGbE ports May 07 17:52:49 or was it just dual 10GbE May 07 17:53:05 or you mean, why it is dual use goods ? May 07 17:54:02 yeah. May 07 17:54:07 -ENOCLUE May 07 17:54:09 the latter May 07 18:01:07 they support strong encryption May 07 18:01:12 AES in HW is a dual use good May 07 18:01:53 to export something which can do AES in wahreware you need to ask for export permission which is normally granted May 07 18:02:14 when you can buy this in normal stores you do not need this export license May 07 18:02:23 it is like parts for nuclear reactors May 07 18:02:33 this law is from the cold war May 07 18:03:06 we do export compliance paperwork when exporting stuff from Germany to Austria May 07 18:03:30 like prototypes May 07 18:04:27 isnt AES in HW in pretty much most of the things tho (like phone level SoCs, even microcontrollers, etc etc) May 07 18:05:15 yes, therfore you can often deactivate it in hardware to sell to bad contries like russia ;-) May 07 18:05:51 Hauke: ok, thanks May 07 18:05:55 but as long as it is sold in normal stores or something similar you do not need export controll any more as far as I understood May 07 18:06:25 this is the US perspective from the cold war, so russia is very bad ;-) May 07 18:07:15 some sort of fiveroptics are also a dual use good in German law May 07 18:07:28 *foiber optics May 07 18:08:31 russia is bad, let's not kid ourselves :P May 07 18:09:12 but to work around those restrictions, couldn't you just go into a store abroad (say russians in germany), buy those things off the shelf, then take them to russia? May 07 18:09:32 what are the chances of it getting intercepted at the airport or at the border May 07 18:09:35 i reckon rather slim May 07 18:09:49 then again, would one bother if they needed it in quantities. May 07 18:10:11 well I just need 1 :P May 07 18:10:14 yes, there is an exception in the export control laws as far as I understood so when you can buy it in normal stores you can easily export it May 07 18:10:35 I might get a 2nd one if the thing works well, but seems I can't even get my hands on a 1st May 07 18:10:44 the macchiatobin? May 07 18:39:28 Borromini: https://upload.wikimedia.org/wikipedia/commons/9/96/Munitions_T-shirt_%28front%29.jpg May 07 18:57:41 Hauke: lol. May 07 18:59:11 Seems like the css code from dvd May 07 18:59:27 Which can be printed onto tshirts as color code May 07 19:31:52 mangix: I would prefer not to update gcc8 in 19.07, we still have some problems with gcc 8.4 in master anyway May 07 19:33:45 I thought it is common practise to not bump (major) toolchain versions in release branches May 07 19:33:53 this can lead to all sorts of issues May 07 19:36:35 jow: me too May 07 19:37:21 is anyone here using per-device rootfs? May 07 19:38:06 the buildbots are, aren't they? May 07 19:38:08 i am seeing something quirky here, but i haven't drilled it down to it being that setting yet, although switching from single to multi device configs makes sysupgrade choke and even the recovery flash :-/ May 07 19:40:11 adrianschmutzler: CONFIG_TARGET_PER_DEVICE_ROOTFS ? May 07 19:40:16 that's not enabled by default afaik. May 07 19:40:25 depends on target May 07 19:40:32 mt7621 May 07 19:40:45 I'd expect it there May 07 19:40:49 it's to get a custom rootfs per device within a single target May 07 19:41:18 otherwise, you wouldn't get per-device packages IIRC May 07 19:41:39 no, that's defined in the makefiles already? May 07 19:41:42 CONFIG_TARGET_PER_DEVICE_ROOTFS=y May 07 19:41:52 ok. so it's on in the buildbots? May 07 19:42:01 that's from config.buildinfo on snapshot downloads May 07 19:42:25 and this is necessary if you want DEVICE_PACKAGES to be evaluated when CONFIG_TARGET_MULTI_PROFILE=y is set May 07 19:42:27 thanks. will have to dig deeper then. something else that broke here then. May 07 19:42:42 the DEVICE_PACKAGES defined in the makefiles you mean? May 07 19:42:48 yes May 07 19:43:00 ok, makes sense. Never gave it much thought. May 07 19:43:12 occasionally people don't set it and report strange issues in device support PRs then May 07 19:43:40 don't know how this is treated when building for a single device without CONFIG_TARGET_MULTI_PROFILE May 07 19:43:49 probably something got fudged in my .config, has been a while since i started with a fresh master tree May 07 19:43:52 good to know, thanks. May 07 19:44:51 the package thing is logical if you know it, but hard to find out in the first place May 07 19:45:29 another dev pointed me to the PER_DEVICE_ROOTFS thing at some point, a few years ago :) May 07 19:45:46 really helped before there was tiny and generic on ar71xx/ath79 e.g. May 07 19:48:21 actually, on these targets with a multitude of devices, I can't image how it should work without May 07 19:48:51 image->imagine May 07 19:51:35 it used to, before 4 MB got to be an issue :) May 07 19:52:30 would someone here kindly have a look or even review the kirkwood kernel config to modules changes here: May 07 19:52:34 https://github.com/openwrt/openwrt/pull/2979/commits May 07 19:53:10 would be quite hard for me, but might be easy for someone used to that stuff May 07 21:50:11 jow: GCC 8.3 > 8.4 is a minor release, no? May 07 21:51:04 in any case, buildbots build everything for 19.07 currently. **** ENDING LOGGING AT Thu May 07 22:58:43 2020 **** BEGIN LOGGING AT Thu May 07 23:00:15 2020 May 08 00:09:39 mangix: thanks for reviewing readsb May 08 00:23:24 np May 08 00:27:34 mangix: cifsd is now ksmbd-tools ? May 08 00:27:56 I'll take the PR that drops samba36 - it's about time we drop that dinosaur May 08 00:32:34 stintel: kind of. ksmbd-tools is the userspace stuff May 08 00:32:41 ksmbd is the kernelspace stuff May 08 00:32:42 ok May 08 00:32:44 good enough May 08 00:33:39 * mangix checks sizes again May 08 00:34:39 945.4 KB vs 59.1 KB + 36.8 May 08 00:34:49 not bad May 08 00:35:29 kmsbd-tools can be smaller with the no-glib2 patch. upstream doesn't like it though May 08 00:35:30 mangix: git.openwrt.org/73fa1aba looks good to you ? May 08 00:35:36 mangix: https://git.openwrt.org/73fa1aba looks good to you ? May 08 00:36:46 I still see cifsd in the description. Otherwise seems fine. May 08 00:36:59 Ah never mind May 08 00:37:02 ;) May 08 00:37:08 ok there goes! May 08 00:37:37 note that this will break luci-app-samba. That needs to be deleted as well May 08 00:38:02 I know that there's a packages-abandoned repo, but I don't know if it's applicable here. May 08 00:38:14 samba doesn't belong in base anyway May 08 00:39:52 mangix: do you have a luci fork / local clone to make a PR to drop that? May 08 00:40:05 I do not. I don't touch luci May 08 00:40:54 k May 08 00:43:31 https://github.com/openwrt/luci/pull/4032 May 08 00:54:01 great May 08 00:55:54 * mangix checks his other PRs May 08 00:55:58 none on github. cool. May 08 00:58:57 feel free to look at readsb again, I addressed or countered your comments May 08 00:59:07 and I'm checking lldp May 08 01:03:13 looks fairly good. the codeload thing bothers me. May 08 01:05:19 ~/d/packages > git grep URL | grep codeload | wc -l May 08 01:05:19 159 May 08 01:05:19 ~/d/packages > git grep URL | grep github | grep archive | wc -l May 08 01:05:19 14 May 08 01:05:43 No idea how the latter ones made it in. May 08 01:06:12 I'm all for consistency, but is there any reasonable explanation why codeload should be used over github.com/foo/bar/archive ? May 08 01:07:16 lack of redirects May 08 01:07:37 the archive URL redirects to codeload May 08 01:08:36 there was a similar change made for pypi packages May 08 01:08:54 where pypi.org was abandoned in favor of files.pythonhosted May 08 01:14:43 lol May 08 01:14:44 https://stackoverflow.com/questions/60188254/how-is-codeload-github-com-different-to-api-github-com May 08 01:14:52 here they say not to use codeload directly May 08 01:20:43 according to that description, it makes a difference with private repos, which are not used. May 08 01:23:22 image size from 12124957 to 12059421 just because of static linking May 08 01:23:25 hmmmmmmmm May 08 01:53:58 sigh. back to yak shaving. build failure in libssh2 which isn't even enabled in my .config May 08 02:12:27 stintel: a different user was reporting a similar thing May 08 02:12:59 https://github.com/openwrt/packages/issues/11796 May 08 02:14:30 do you have mc enabled? May 08 02:15:33 # CONFIG_PACKAGE_mc is not set May 08 02:16:10 mangix: FYI: https://github.com/openwrt/packages/issues/12108 May 08 02:17:58 how about aria2? May 08 02:19:25 https://github.com/openwrt/packages/pull/11623 May 08 02:19:29 second to last post May 08 02:21:21 neither May 08 02:24:23 ....wow. gerbera 1.5.0 looks amazing **** ENDING LOGGING AT Fri May 08 02:59:59 2020