**** BEGIN LOGGING AT Tue May 14 02:59:57 2019
May 14 08:05:24 <xback> ldir: very busy with my regular work .. so the bumps wll appear at a bit slower pace currently :)
May 14 08:26:38 <ldir> xback: he he - you do a bloody good job so me exercising a bit of patience isn't a problem  :-)
May 14 08:31:18 <ynezz> and I don't need to recompile that often :)
May 14 08:35:34 <ldir> I build on a very regular basis
May 14 09:15:49 <ldir> has anyone seen/heard Felix recently?
May 14 09:16:29 <nbd> i'm here
May 14 09:16:55 * ldir breaths sigh of relief
May 14 09:17:48 <ldir> I'm having some troubles building openwrt with kernel 4.19 on macos - your 'enable kernel testing version' patch is great.
May 14 09:19:06 <nbd> i'll take a look
May 14 09:19:21 <ldir> any out of tree modules are failing for me.  And I don't know if it's my setup or well what? :-)
May 14 09:19:23 <nbd> didn't get around to responding since i don't have that much time/energy for openwrt at the moment
May 14 09:22:57 <ldir> likewise - sorry to nag - you're the only one I know who also tries to build on macos - the sort of stuff I'm seeing https://pastebin.com/M4uihTP6
May 14 09:24:56 <nbd> no problem
May 14 09:25:04 <nbd> started a build, will see if it shows up on my machine
May 14 09:26:35 <nbd> just tested with an x86 build and it worked for me
May 14 09:26:58 <karlp> 90 second bnuilds. I could get used to that :)
May 14 09:27:24 <nbd> ldir: did you try a clean build?
May 14 09:27:54 <aparcar[m]> jow ping
May 14 09:28:07 <ldir> certainly did
May 14 09:28:31 <ldir> did a make dirclean - and even a distclean. and removed the ./tmp dir
May 14 09:29:04 <ldir> humour me...can you try enabling 'iproute-tc'
May 14 09:32:10 <ldir> the objtool build gets selected if you have 'libelf' installed...and libelf is a dependency on iproute2-tc
May 14 09:32:30 <ldir> it's a wild guess
May 14 09:39:12 <nbd> will try taht
May 14 09:41:07 <ldir> well I'm trying a clean build without those features selected....but it's going to take me longer than 90 seconds :-)
May 14 09:41:31 <nbd> ldir: yep, reproduced the issue
May 14 09:43:28 <ldir> ok so my wild stab in the dark guesses are getting better :-) I have NOOO idea how to fix.
May 14 09:48:39 <nbd> i have a theory
May 14 09:48:43 <nbd> the issue is this:
May 14 09:48:59 <nbd> libelf is availble during out-of-tree build (because of it being built by a package)
May 14 09:49:02 <nbd> but not for the main kernel build
May 14 09:49:15 <nbd> so the main kernel build doesn't build objtool (because of missing lib)
May 14 09:49:26 <nbd> but the out of tree build assumes it's there (because the check passes now)
May 14 09:49:34 <nbd> solution would be to move libelf to tools/
May 14 09:49:43 <nbd> so that it gets installed to staging_dir/host
May 14 09:49:47 <nbd> does that make sense?
May 14 09:50:40 <ldir> I thought it was something along those lines 'libelf available because of package'
May 14 09:51:25 <nbd> i think you understand more about this stuff than you give yourself credit for
May 14 09:52:17 <nbd> may not always find the way to the solution by yourself, but a lot of steps are there :)
May 14 09:52:32 <ldir> I fall over on how to fix.
May 14 09:53:14 <nbd> with my description of the approach, would you like to attempt to fix it yourself?
May 14 09:53:20 <nbd> or rather let me take care of it
May 14 09:54:54 <ldir> can I test the solution you come up with? :-)  I'm supposed to be doing my business bookwork.
May 14 09:56:10 <ldir> libelf *is* in tools.
May 14 10:02:17 <ldir> and I'm not sure that libelf is the whole story because my build failed after a 'make clean' and ensuring libelf wasn't selected.
May 14 10:02:28 <nbd> oh, so something else is missing then
May 14 10:02:31 <nbd> will look again
May 14 10:03:06 <nbd> so libelf is there, but it needs elfutils or something like that
May 14 10:06:25 <ldir> oops - my mistake - it turns out I hadn't disabled libelf - let me make clean & try again - to be sure.
May 14 10:07:28 <ldir> but tools/libelf does exist and it does get built.
May 14 10:14:08 <nbd> tools/libelf is a different lib
May 14 10:14:33 <nbd> will need to check what it was added for
May 14 10:14:43 <nbd> it probably needs to be replaced with the elfutils variant of it
May 14 10:14:47 <nbd> which is built by packages
May 14 10:16:38 <ldir> sorry Felix - I'm renowned in my audio work for finding 'corner cases'
May 14 10:17:00 <nbd> don't be sorry about that
May 14 10:17:09 <nbd> i find that very useful
May 14 10:19:15 <ldir> one guy calls me 'pain the ass' to my face...but he claims in a good way - I spot stuff that nobody else does, and ask questions that nobody thinks about or wants to have to answer.  :-)
May 14 10:25:13 <nbd> so elfutils won't build on macos
May 14 10:25:33 <nbd> i guess we have to pick the fallback option of disabling the failing feature
May 14 10:30:15 <KanjiMonster> nbd: I haven't looked too deeply yet, but it seems to me objtool/libelf doesn't seem to be required, just used if present/detected. so maybe we need a way to force it to not being used?
May 14 10:31:16 <nbd> my current try is to disable CONFIG_STACK_VALIDATION on non-linux systems
May 14 10:31:26 <nbd> that would force it to not get used
May 14 10:34:40 <karlp> non linux? or non x86?
May 14 10:35:32 <nbd> non-linux
May 14 10:35:47 <nbd> hm, it seems to me that theoretically it should work with the libelf library as well
May 14 10:35:55 <nbd> maybe it's a matter of missing ldflags
May 14 10:40:32 <KanjiMonster> probably - at least the tryrun that checks for a libelf doen't use any HOST_*_FLAGS - https://elixir.bootlin.com/linux/latest/source/Makefile#L959
May 14 10:40:48 <nbd> yes
May 14 10:41:59 <nbd> seems that tool will require event more fixing
May 14 10:42:07 <nbd> includes linux headers
May 14 10:42:28 <KanjiMonster> yeah, it also uses pkg-config without any way of overriding it, which we need to do as well
May 14 10:42:56 <KanjiMonster> (overriding which one to use)
May 14 10:49:40 <ldir> I don't really want to say this 'cos it's a total pain in the backside for me...are things getting to a point where building on linux is the only supported option?  A question for the meeting?
May 14 10:52:27 <karlp> these problems normally ocme up when it comes to the linux core tooling, not the openwrt portions of it.
May 14 10:52:56 <karlp> isn't it?
May 14 10:53:10 <ynezz> seems so
May 14 10:54:12 <KanjiMonster> ldir: no, it's currently "okay, it should work in theory, so how can we fix it properly in a way we can also push the fix upstream", as it's (IMO) clearly a cross-compile issue
May 14 10:56:02 <ldir> ok - if it *should* work and upstream broke it, then our effort to fix it isn't wasted :-)
May 14 10:56:59 <ldir> I didn't want to have stumbled across a problem, 'demanded' it be fixed and then openwrt has to put effort in and carry a patch till end of days.
May 14 10:57:50 <KanjiMonster> ldir: they didn't break it, it already was added pre-broken (for cross-compilation on non-linux systems) ;)
May 14 10:58:28 <ldir> lol
May 14 10:59:17 <karlp> which seems to be fairly standard for upstream :)
May 14 11:00:52 <ldir> that's the problem with mono cultures - and why I didn't really want to suggest 'do we have to stop support for macos'
May 14 11:02:48 <KanjiMonster> admittedly, getting cross-compile support right isn't easy unless you have (extensive) knowledge
May 14 11:03:38 * ldir wears cotton but doesn't understand how it works :)
May 14 11:11:24 <ldir> https://allblackadderscripts.blogspot.com/2012/12/blackadder-iii-episode-5-amy-and.html - search for 'industrialists' and then read the next 10 lines
May 14 11:12:31 <ldir> Also I've just received an election campaign from "The Brexit Party" - I have of course burned it - I need to keep working with Europe, my router depends on it.
May 14 11:18:36 <KanjiMonster> xback: when you push the kernel update also to 18.06: https://git.lede-project.org/3611cfe73d5f9680d387ef14632431fac30bbd9b
May 14 12:09:14 <ynezz> ldir: usually it's enough to just report it upstream, they're mostly just don't aware
May 14 12:09:54 <ynezz> nobody breaks things intentionally, just me :)
May 14 12:25:43 <xback> KanjiMonster: noted
May 14 12:25:47 <xback> thanks
May 14 13:35:43 <ynezz> does anyone has tmomas's email address?
May 14 13:42:23 <ynezz> tmo26 (at) gmx (dot) de ?
May 14 13:42:25 <DonkeyHotei> i think you can get the forum to send him an e-mail
May 14 13:44:54 <ynezz> I want to Cc him in the email reply
May 14 15:06:41 <brucethompson> I just checked a version of libc.so with symbols and for some reason it is missing __memcpy_check
May 14 15:06:54 <brucethompson> __memcpy_check is a required function for libc
May 14 15:07:26 <brucethompson> Is it just me?
May 14 15:08:33 <karlp> you've been harrassing the pynacl folks the whole time with how broken all this is right?
May 14 15:08:37 <aparcar[m]> ynezz hey, thanks for your responses regarding the procd format style. could we quickly brainstorm what style would fit (most people)?
May 14 15:09:19 <aparcar[m]> ynezz regarding enforcing, I'm working on a test and ci infrastructure for some openwrt components, it would also validate the code format and error on bad style
May 14 15:10:03 <brucethompson> I am the pynacl guy
May 14 15:10:29 <brucethompson> PyNacl has never been ported to OpenWrt
May 14 15:10:43 <brucethompson> Its me thats doing it.
May 14 15:11:04 <karlp> was I right in reading that libsodium was already ported and working?
May 14 15:11:27 <brucethompson> I got a version of libsodium with symbols to work with pynacl
May 14 15:11:30 <aparcar[m]> jow I don't understand why opkg doesn't show the license once the package is installed, the raw data is stored in /usr/lib/opkg/info/<pkgname>.control
May 14 15:11:44 <brucethompson> Now I am missing symbols in libc.so
May 14 15:12:06 <brucethompson> Sorry. I have a version of libc.so with symbols
May 14 15:12:22 <brucethompson> Libsodium uses __memcpy() in libc.
May 14 15:12:39 <brucethompson> I can't find it in the OpenWrt version of libc.so
May 14 15:12:44 <brucethompson> I don't know why.
May 14 15:13:06 <brucethompson> Sorry. __memcpy_chk()
May 14 15:14:30 <brucethompson> memcpy() and wmemcpy() are there. memcpy_chk() is missing.
May 14 15:16:43 <jeffsf> ath79: Chasing down `ar7200-usb-phy usb-phy: phy reset is missing` on a new port -- DTS looks OK (qca956x.dtsi)
May 14 15:16:57 <jeffsf> Some mention that this is "normal" -- https://forum.openwrt.org/t/porting-guide-ar71xx-to-ath79/13013/788
May 14 15:17:12 <jeffsf> Should I keep beating on this or move on?
May 14 15:17:27 <jeffsf> USB seems to work as xpected
May 14 15:20:39 <olmari> AFAIK not every (if even most) usb phy has "reset" capability...
May 14 15:23:05 <hsp> How to set up freedns.afraid.org on openwrt, is there a howto for that? I am a newbie
May 14 15:25:22 <jeffsf> hsp: If you have LuCI installed, that is the simplest. File-config at https://openwrt.org/docs/guide-user/base-system/dhcp -- More help at https://forum.openwrt.org/
May 14 15:29:46 <hsp> jeffsf_, i mean ddns
May 14 15:30:41 <jeffsf> hsp: https://openwrt.org/docs/guide-user/services/ddns/client
May 14 15:46:16 <hsp> jeffsf, works. thanks a lot
May 14 16:11:09 <brucethompson> One more ping before I give up.
May 14 16:14:53 <brucethompson> Is there a version of libc available for OpenWrt that contains a complete set of libc functions? Example: __memcpy_chk()
May 14 16:15:20 <brucethompson> https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libc---memcpy-chk-1.html
May 14 16:16:24 <ldir> brucethompson: sorry Bruce, I don't understand the questions and have no experience in the areas you mention.
May 14 16:17:50 <ldir> your best bets are a) try to attract the attention of a 'core' dev and get them to buy in to your problem.  b) Have a look at what arch linux does, 'cos sometimes that's applicable due to the use of musl libc.
May 14 16:18:47 <ldir> I take it you've tried emailing openwrt-devel@lists.openwrt.org ?
May 14 16:19:35 <ldir> I know it can be very frustrating and down-heartening and like bashing head against brick wall... have been there myself.
May 14 16:20:34 <ldir> not everyone is on IRC so email may attract a different crowd.
May 14 16:20:42 <brucethompson> Thanks ldir
May 14 16:20:49 <brucethompson> I will try everything you say.
May 14 16:21:08 <brucethompson> It it likely my ignorance
May 14 16:21:11 <brucethompson> It is
May 14 16:22:08 <brucethompson> Thanks for the mailing list reference
May 14 16:22:12 <brucethompson> I have not tried it.
May 14 16:23:06 <ldir> It is also a bit quieter in here of late, with some of my core reference 'gods' less active.
May 14 16:23:10 <KanjiMonster> brucethompson: you can select to build with glibc (there are no binaries though, you need to build yourself)
May 14 16:23:34 <brucethompson> Is it under feeds?
May 14 16:23:40 <KanjiMonster> no
May 14 16:24:05 <brucethompson> I need to go from source?
May 14 16:24:41 <KanjiMonster> it's ... "Advanced configuration options (for developers)" -> "Toolchain Options" -> "C Library implementation (Use glibc)"
May 14 16:24:42 <KanjiMonster> yes
May 14 16:24:55 <brucethompson> Give me a minute
May 14 16:25:01 <brucethompson> Will try now
May 14 16:27:20 <brucethompson> I don't know why, but I can't select anything under  "Advanced configuration options (for developers)"
May 14 16:28:19 <ldir> you're hitting space bar on that selection to select the option right?
May 14 16:29:15 <ldir> spacebar or 'y' -  the end of the line should turn from ----  to ----->
May 14 16:31:47 <cotequeiroz> brucethompson: I think your problem is that libsodium is being host-build, and then target-linked.  You'd get errors like that.  You should be tellinc pynacl to use the "system" libsodium.
May 14 16:32:04 <cotequeiroz> *telling
May 14 16:32:16 <brucethompson> Can't do that
May 14 16:32:30 <brucethompson> pynacl needs libsodium with symbols
May 14 16:32:41 <brucethompson> system libsodium is striped.
May 14 16:32:49 <brucethompson> But I got around that problem.
May 14 16:32:59 <brucethompson> Now I have a libsodium with symbols.
May 14 16:33:11 <brucethompson> Problem is now with libc.
May 14 16:33:15 <cotequeiroz> Can you pastebin your relevant packages Makefile.  Perhaps I can try them here.
May 14 16:33:57 <brucethompson> I am up to 15 new packages now.
May 14 16:34:08 <brucethompson> I don't think pynacl needs them all though.
May 14 16:34:27 <brucethompson> Just needs libsodium I think.
May 14 16:34:44 <brucethompson> And the package builods just fine.
May 14 16:34:54 <brucethompson> I am getting a run time error now.
May 14 16:35:07 <cotequeiroz> Send 'em; if I need more I'll ask you.  I'll be running in a WRT3200ACM.
May 14 16:35:34 <brucethompson> OK. You want me to send the Makefile for pynacl?
May 14 16:35:39 <cotequeiroz> Please.
May 14 16:35:41 <brucethompson> OK.
May 14 16:36:03 <brucethompson> Just FYI. It uses the system libsodium.
May 14 16:36:09 <cotequeiroz> OK
May 14 16:36:44 <brucethompson> I hacked around that problem by putting a non system libsodium into the install dir after I installed the python-pynacl package.
May 14 16:37:07 <brucethompson> Its just a hack to see where the other errors.
May 14 16:37:14 <brucethompson> That' how I got to the libc problem
May 14 16:37:30 <brucethompson> But I'll send you the Makefile
May 14 16:37:34 <brucethompson> It will build.
May 14 16:37:40 <brucethompson> Then try this:
May 14 16:37:50 <brucethompson> run python
May 14 16:38:40 <karlp> is this all because pynacl is trying to dynamically figure out what to export? rather than just knowing what apis it's exporting?
May 14 16:38:54 <karlp> and it tries to do that by expecting the symbols to be available?
May 14 16:39:59 <brucethompson> Yes. I believe so.
May 14 16:40:13 <brucethompson> in python try this statement:
May 14 16:40:34 <brucethompson> import pynacl.secret
May 14 16:40:40 <brucethompson> OK. Now the Makefile
May 14 16:40:51 <brucethompson> It's very easy to reproduce
May 14 16:41:04 <karlp> could pynacl perhaps just export apis instead of trying to look for symbols?
May 14 16:41:45 <brucethompson> It's python (not pynacl) that's looking for the symbols ASAIK
May 14 16:41:50 <brucethompson> AFAIK
May 14 16:42:04 <karlp> did you ever try SODIUM_INSTALL=system ?
May 14 16:42:08 <brucethompson> Yes
May 14 16:42:28 <brucethompson> That's how I got it to build
May 14 16:42:44 <brucethompson> But let me send makefile
May 14 16:47:48 <KanjiMonster> brucethompson: both pynacl and lobsodium seem to be available for alpine linux, and alpine uses musl, you could check their sources to find out why it work for them/how they do it
May 14 16:48:32 <brucethompson> Here's the Makefile: https://paste2.org/4f759FA6
May 14 16:49:03 <brucethompson> OK
May 14 16:49:21 <brucethompson> ]  <KanjiMonster>	OK
May 14 16:57:04 <brucethompson> <ldir>	spacebar or 'y' -  the end of the line should turn from ----  to ----->
May 14 16:58:10 <brucethompson> 	<ldir>  spacebar or 'y' - does nothing
May 14 16:58:32 <brucethompson> Maybe a hand edit to .config?
May 14 17:01:36 <brucethompson> Ugh. I did something stupid in menuconfig
May 14 17:01:41 <brucethompson> Now I got it
May 14 17:22:46 <cotequeiroz> I got the error.  I don't think building the library with symbols is going to help.  ld can't find some functions. If you try ldd /usr/lib/python2.7/site-packages/nacl/_sodium.so, you'll see a list of them.  Are they being disabled in libsodium?
May 14 17:23:38 <cotequeiroz> I'm rebuilding without LIBSODIUM_MINIMAL, to see what happens.
May 14 17:25:11 <brucethompson> You got the error in python??
May 14 17:25:57 <brucethompson> I used a libsodium built with debug options enabled.
May 14 17:26:16 <brucethompson> That got around the symbol errors in libsodium itself
May 14 17:26:33 <brucethompson> The missing symbol is crypto_pwhash*, correct?
May 14 17:28:14 <cotequeiroz> Yes.  They are defined in libsodium sources.  Perhaps they are not being built there.  I'll check that now.
May 14 17:28:40 <cotequeiroz> crypto_pwhash_scryptsalsa208sha256_memlimit_interactive is in src/libsodium/crypto_pwhash/scryptsalsa208sha256/pwhash_scryptsalsa208sha256.c
May 14 17:29:53 <brucethompson> If you build libsodium with debug info, the symbols will be there
May 14 17:30:37 <brucethompson> I had to do make menuconfig, turn on the debug option, and rebuild libsodium
May 14 17:35:51 <brucethompson> Just looked again. The version of libsodium I built with debug turned on has the crypto_pwhash_scryptsalsa208sha256_memlimit_interactive defined.
May 14 17:37:10 <cotequeiroz> I've got it.  You must buind libsodium without LIBSODIUM_MINIMAL
May 14 17:37:31 <cotequeiroz> No need to change debugging or stripping.
May 14 17:38:21 <brucethompson> Really??
May 14 17:38:35 <brucethompson> OK. You are a god.
May 14 17:38:52 <cotequeiroz> At least import nacl.secret works now.
May 14 17:39:04 <brucethompson> What's the magic?
May 14 17:39:44 <brucethompson> So you changed the Makefile for pynacl or libsodium?
May 14 17:40:55 <cotequeiroz> No, In menuconfig, go to Libraries, libsodium, Configuration, and unselect Compile only what is required.....
May 14 17:41:13 <brucethompson> Let me try that
May 14 17:42:04 <brucethompson> I think I may know how I got into trouble with libc now.
May 14 17:42:30 <brucethompson> I ended up using a version of libsodium that I think was built with glibc instead of musl
May 14 17:42:34 <brucethompson> I think
May 14 17:52:31 <brucethompson> I have to rebuild the toolchain so everything is back to musl
May 14 18:27:10 <cotequeiroz> One more thing.  You'll need to change your "Default" DEPENDS line to DEPENDS+=libsodium @!LIBSODIUM_MINIMAL.  Your package will only be visible if you unselect that option.
May 14 18:32:05 <cotequeiroz> The src package will still show, though, which is undesirable.  I'd negotiate a change to LIBSODIUM_MINIMAL default, or change it to LIBSODIUM_FULL, and then you can use +libsodium +@LIBSODIUM_FULL, and avoid the src package problem.
May 14 18:50:40 <brucethompson> OK. I could not repeat what you did.
May 14 18:52:17 <cotequeiroz> At what point did it fail?
May 14 18:52:20 <brucethompson> I built libsodium with LIBSODIUM_MINIMAL removed (via menuconfig
May 14 18:52:28 <brucethompson> It has all the symbols
May 14 18:52:36 <brucethompson> Except init_sodium
May 14 18:53:05 <brucethompson> Then I rebuilt python-pynacl.
May 14 18:54:07 <brucethompson> The _sodium.so in that package has init_sodium defined but the crypto_pwhash* symbols are listed as undefined (U in nm)
May 14 18:54:14 <cotequeiroz> Did you reinstall libsodium in the router?
May 14 18:54:21 <brucethompson> No....
May 14 18:54:35 <cotequeiroz> Then the library there will still not have those symbols.
May 14 18:54:48 <brucethompson> Let me try that.
May 14 18:55:13 <brucethompson> Oh wait. I did reinstall libsodium onthe router
May 14 18:55:19 <cotequeiroz> Use ldd /usr/lib/python2.7/site-packages/nacl/_sodium.so to test it.  Is should come up without errors.
May 14 18:55:20 <brucethompson> But I will try again.
May 14 18:57:34 <cotequeiroz> Check the sizes of the library.  I had done the same thing here.  I was sure I had it reinstalled, but I still had the minimal library.  Explaining to you I figured out what went wrong:
May 14 18:58:23 <cotequeiroz> The original repo had a higher precedence so opkg was always picking it up instead of the newly built one.  I copied manually and it worked.
May 14 18:59:47 <brucethompson> Just worked forme
May 14 19:00:00 <brucethompson> I uninstalled and reinstalled both packages and now it works
May 14 19:00:01 <cotequeiroz> Good :)
May 14 19:00:37 <brucethompson> So now I need to change pynacl Makefile, right?
May 14 19:01:47 <brucethompson> OK. Now I think I understand the Makefile change
May 14 19:01:52 <cotequeiroz> You need to change your dendencies so that pynacl will not build with LIBSODIUM_MINIMAL selected.
May 14 19:01:59 <brucethompson> Understand.
May 14 19:02:15 <brucethompson> So there's no automated build for packages then?
May 14 19:02:51 <cotequeiroz> I would rather have LIBSODIUM_MINIMAL be changed in libsodium Makefile to a LIBSODIUM_FULL, so you can select it in your package.
May 14 19:03:03 <cotequeiroz> You are correct.  It won't build it by default.
May 14 19:13:13 <brucethompson> I have a LOT to learn...
May 14 19:13:37 <brucethompson> Thank you SO much
May 14 19:13:57 <brucethompson>   <cotequeiroz>	Thank you SO much
May 14 19:36:32 <jeffsf> With an upstream Linux patch series with 1/3,2/3,3/3 all interrelated, should that be backported as three commits to OpenWrt or just one?
May 14 19:37:56 <jeffsf> ("They" wanted my GigaDevice NAND-support patch split into basically each of the files it impacts)
May 14 19:52:36 <cotequeiroz> brucethompson: You're welcome.
May 14 19:53:03 <brucethompson> AND. Tahoe-LAFS (the big project) just came up on OpenWrt!!!!
May 14 19:53:43 <brucethompson> You helped me with the last obstacle to getting Tahoe-LAFS up and running. There may be more bugs but it comes up!!!
May 14 19:54:22 <brucethompson> I ended up porting 15 new python package to OpenWrt to get Tahoe-LAFS to run.
May 14 19:54:51 <brucethompson> The toughest package by far was puthon-pynacl. Thanks greatly for your help on that.
May 14 20:01:46 <KevinDB> brucethompson: looks like it's progressed nicely judging by the comments.
May 14 20:17:47 <brucethompson> I think so.
May 14 20:17:57 <brucethompson> It was a huge amount of work.
May 14 20:18:18 <brucethompson> I'm running in a VM right now. Will try an OpenWrt device later.
May 14 20:18:43 <brucethompson> <ldir> Thanks for all your help as well.
May 14 20:20:27 <ldir> brucethompson: not sure what I did other than wave some arms about :-)
May 14 20:23:22 <jeffsf> git send-email -- How do I get [PATCH v2 1/3] in the messages? Neither `-v2` nor `--subject-prefix="PATCH v2"` seem to work for me
May 14 20:24:45 <ldir> jeffsf: I'd have thought -v2 would do it, it's what I use.  Erm, what happens if you use git format-patch instead ?
May 14 20:30:42 <jeffsf> (looks like a git 2.11.0 problem -- dealing wit stretch-backports now)
May 14 20:32:05 <ldir> oohh nooo - how will they send patches to fix it?  :-)
May 14 20:32:49 <Hauke> jeffsf: I use the --subject-prefix=
May 14 20:33:17 <Hauke> in the git format-patch
May 14 20:33:47 <jeffsf> Thanks Hauke: Upgrading to git 2.20.1 since it didn't seem to be present in 2.11.0
May 14 20:33:58 <jeffsf> at least in git send-email
May 14 20:34:28 <jeffsf> ah -- when I format the patch!
May 14 20:35:08 <Hauke> there is not also "-v 2"
May 14 20:35:12 <Hauke> *now
May 14 20:35:50 <jeffsf> Yeah, the joys of old docs ;) -- thanks for the hint of doing it in git format-patch
May 14 20:37:25 <Hauke> I started using git some years ago and they added new features into new versions and it takes some time till I find them
May 14 20:37:57 <jeffsf> Not quite as bad as the mind shift from SVN to git, thankfully
May 14 20:44:05 <ldir> hmm, there are some 'fun' patches in the latest kernel releases - CVE stew
May 14 20:47:26 <Hauke> ldir: yes a new bug in some Intel CPUs was published
May 14 21:02:54 <KanjiMonster> jeffsf: while too late, the "old" way would have been --subject="PATCH v2"
May 14 21:03:20 <jeffsf> Thanks! No doubt I'll be bitten by an old version of git again...
May 14 22:01:22 <ynezz> aparcar[m]: well, I'm not in position to enforce any coding style on anything, as I don't contribute much code (if any) to those projects (fw3, procd for example), so I think, that it would be better to just wait a little bit for a feedback from particular repository maintainer
May 14 22:03:41 <ynezz> aparcar[m]: I've just tried to provide you with the feedback, that you should be aware, that clang-format's output is not consistent between versions, so you probably can't simply enforce/convert it with any available version on hand, you usually need to use specific version of clang-format
May 14 22:07:00 <ynezz> aparcar[m]: so to sum it up, nobody is probably going to object against some whitespace consolidation/fixes, but this clang-format code reformat is quite invasive/harsh so to speak
May 14 22:45:23 <KanjiMonster> aparcar[m]: to pile onto, it would make more sense to tweak the .clang-format so it matches the existing code style, not some arbitrary different one (and then use clang-format to find/fix inconsistencies)
**** BEGIN LOGGING AT Wed May 15 01:31:44 2019
**** BEGIN LOGGING AT Wed May 15 01:41:18 2019
**** BEGIN LOGGING AT Wed May 15 01:51:55 2019
**** BEGIN LOGGING AT Wed May 15 02:01:27 2019
**** ENDING LOGGING AT Wed May 15 02:59:57 2019