13:25:45 <peach34> I just tried building Monero and got this error:
13:25:47 <peach34> [100%] Linking CXX executable ../../bin/monero-wallet-rpc/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libzmq.a(libzmq_la-gssapi_client.o): in function `zmq::gssapi_client_t::~gssapi_client_t()':(.text+0x5d): undefined reference to `gss_release_cred'/usr/bin/ld:
13:25:48 <peach34> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libzmq.a(libzmq_la-gssapi_client.o): in function `zmq::gssapi_client_t::process_next_token(zmq::msg_t*) [clone .part.0]':(.text+0x246): undefined reference to `gss_release_name'/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libzmq.a(libzmq_la-gssapi_client.o): in
13:25:48 <peach34> function `zmq::gssapi_client_t::~gssapi_client_t()':(.text+0x780): undefined reference to `gss_release_cred'/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libzmq.a(libzmq_la-gssapi_client.o): in function `zmq::gssapi_client_t::initialize_context()':(.text+0x7fd): undefined reference to `gss_init_sec_context'/usr/bin/ld:
13:25:49 <peach34> (.text+0x84d): undefined reference to `gss_import_name'/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libzmq.a(libzmq_la-gssapi_client.o): in function `zmq::gssapi_client_t::produce_next_token(zmq::msg_t*)':(.text+0x8a0): undefined reference to `gss_release_buffer'/usr/bin/ld: (.text+0x8c2): undefined reference to
13:25:49 <peach34> `gss_release_buffer'/usr/bin/ld: (.text+0x8ce): undefined reference to `gss_release_name'/usr/bin/ld: (.text+0x8e2): undefined reference to `gss_release_name'/usr/bin/ld: (.text+0x8f7): undefined reference to `gss_delete_sec_context'
13:26:05 <peach34> Does anyone know what is going on? This is Ubuntu 18/20 with fully up to date dependencies
13:26:21 <peach34> I think it's caused by the latest libzmq3-dev
13:27:07 <sethsimmons> What branch are you building against? I'm on Ubuntu 20.04 and can test.
13:27:23 <peach34>  Perhaps another version of gssapi is linked earlier in the chain and so the interface is different
13:27:30 <peach34> maybe needs another -lgssapi link or something
13:27:37 <peach34> master branch @seth
13:28:04 <peach34> here are all of the versions of my packages
13:28:08 <sethsimmons> Ok, building now.
13:28:24 <peach34> Note, selecting 'libunwind-dev' instead of 'libunwind8-dev'Note, selecting 'libreadline-dev' instead of 'libreadline6-dev'build-essential is already the newest version (12.8ubuntu1).cmake is already the newest version (3.16.3-1ubuntu1).libexpat1-dev is already the newest version (2.2.9-1build1).liblzma-dev is already the newest version
13:28:24 <peach34> (5.2.4-1).libreadline-dev is already the newest version (8.0-4).libsodium-dev is already the newest version (1.0.18-1).libssl-dev is already the newest version (1.1.1f-1ubuntu2).libunwind-dev is already the newest version (1.2.1-9build1).pkg-config is already the newest version (0.29.1-0ubuntu4).doxygen is already the newest version
13:28:25 <peach34> (1.8.17-0ubuntu2).graphviz is already the newest version (2.42.2-3build2).libboost-all-dev is already the newest version (1.71.0.0ubuntu2).libldns-dev is already the newest version (1.7.0-4.1ubuntu1).libpgm-dev is already the newest version (5.2.122~dfsg-3ubuntu1).libzmq3-dev is already the newest version (4.3.2-2ubuntu1).libunbound-dev is already
13:28:25 <peach34> the newest version (1.9.4-2ubuntu1.1).
13:32:20 <peach34> I tried compiling some other forks of Monero and I get the same
13:33:34 <sethsimmons> Worked perfectly for me from Master
13:35:28 <sethsimmons> `libzmq3-dev is already the newest version (4.3.2-2ubuntu1).`
13:36:07 <sethsimmons> gcc = 9.3.0
13:36:47 <peach34> Me too, 9.3
13:36:55 <sethsimmons> boost = 1.71
13:37:05 <peach34> Are you in vm ?
13:37:18 <sethsimmons> nope, bare metal
13:37:22 <peach34> We had no issues inside a vm, but a clean install of Ubuntu doesn't work
13:37:53 <peach34> can you try installing all of the dependencies with apt-get
13:37:59 <sethsimmons> Anything out of date/missing if you run this: `sudo apt update && sudo apt install build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev doxygen graphviz libpgm-dev qttools5-dev-tools libhidapi-dev libusb-dev libprotobuf-dev protobuf-compiler`
13:38:12 <peach34> sudo apt update && sudo apt install build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev doxygen graphviz libpgm-dev qttools5-dev-tools libhidapi-dev libusb-dev libprotobuf-dev protobuf-compiler
13:38:21 * sethsimmons sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/CLKTyIMzbDQPdEzTAaACpUom/message.txt >
13:38:29 <peach34> also please run sudo apt-get upgrade
13:38:34 <sethsimmons> I'm on Matrix, let me know if the above came through
13:38:38 <sethsimmons> I'm already up to date.
13:40:01 <moneromooo> It says: * sethsimmons sent a long message:  < https://matrix.org/_matrix/media/....
13:40:13 <moneromooo> So it's basically invisible unless somee goes see the link.
13:40:18 <peach34> thanks Seth will check those dependencies now
13:40:20 <sethsimmons> Good to know
13:40:26 <sethsimmons> Thanks moneromooo
13:40:29 <peach34> Nah I can see it all moneromooo
13:40:38 <sethsimmons> Always wondered how MD comes through from matrix
13:40:40 <peach34> oh sorry
13:40:44 <peach34> yeah following link i can see it
13:40:50 <sethsimmons> makes sense :)
13:41:30 <peach34> seth does it work for release-static-linux-x86_64
13:41:38 <peach34> that is what i'm trying
13:42:20 <sethsimmons> Oh I'm just building release
13:42:20 <sethsimmons> Not static
13:42:42 <sethsimmons> trying that now
13:42:49 <sethsimmons> I don't normally do static builds
13:43:06 <asymptotically> maybe the ubuntu version of libzmq is built to depend on some extra guff, that just works with the shared libs. but the static libs might not know about it since they don't say what they depend on
13:43:39 <moneromooo> I blame cmake, likely wouldn't happen with pkg-config.
13:43:56 <asymptotically> can't cmake read the zmq pkgconfig file?
13:44:04 <moneromooo> It can.
13:44:49 <peach34> The strangest thing is when I run inside of CLion IDE, and do a cmake-debug, It compiles fine
13:44:57 <moneromooo> But it likely doesn't. It relies on "recipes" that ship with cmake. Recipe for being old and inflexible.
13:45:26 <peach34> We have the same set of dependencies Seth
13:45:38 <moneromooo> It's like systemd. "I will rewrite it all just because it's fun, and then inflict misery on others".
13:45:59 <peach34> I didn't think that Monero had a zmq pkgconfig file
13:46:08 <asymptotically> looks like we just use find_library (just search paths for .a or .so) instead of find_package for their recipies
13:46:33 <moneromooo> Sorry, by "It" above, I meant "cmake".
13:46:44 <asymptotically> peach34: it comes with zmq. try looking through dpkg -L libzmq-dev
13:46:52 <moneromooo> Anyway, I'll butt out since I'm just complaining ^_^
13:48:40 <peach34> chris@chrispc:~/monero$ dpkg -L libzmq-devdpkg-query: package 'libzmq-dev' is not installedUse dpkg --contents (= dpkg-deb --contents) to list archive files contents.
13:48:54 <peach34> do i need the 3 after zmq
13:48:55 <asymptotically> peach34: as a hack you could try adding -DCMAKE_EXE_LINKER_FLAGS='-lgssapi' to the cmake arguments, or whatever else zmq wants
13:54:15 <peach34> sethsimmons I found it here: /usr/lib/x86_64-linux-gnu/pkgconfig/libzmq.pc
13:54:42 <peach34> Why is it that cmake-debug inside of the Clion IDE works and compiling from terminal doesn't?
13:54:45 <sethsimmons> static bbilt fine for me as well
13:55:09 <sethsimmons> *built
14:18:59 <peach34> I will try putting that line into the top level cmakelists.txt
14:21:06 <peach34> I'm wondering moneromooo if it works with CLion but not the terminal because CLion uses a different version of cmake that is bundled
14:21:51 <moneromooo> Could be. cmake uses those modules it ships itself, so is bound to be out of date all the time.
14:21:52 <sethsimmons> Did you see that mine built fine, peach34
14:22:17 <moneromooo> I guess you can compare the modules for that deal with 0mq and gss.
14:22:18 <peach34> Yeah thanks sethsimmons
14:22:18 <sethsimmons> `cmake version 3.16.3`
14:22:44 <moneromooo> Though IIRC the zmq stuff is from the monero tree...
14:23:22 <peach34> Clion uses cmake 3.17.3 and works
14:23:36 <moneromooo> Ah, it's manual. It just finds libraries. Might not be cmake's fault after all.
14:23:56 <moneromooo> Maybe add a gss line after:   find_library(NORM_LIBRARY norm)
14:24:18 <peach34> it built fine after linking to gssapi
14:24:25 <moneromooo> Probavly something like :find_libary(GSS_LIBRARY gss)   (assuming it has the usual name)
14:24:48 <moneromooo> Add add GSS_LIBRARY to the zmq libs
14:24:54 <moneromooo> Oh, good.
14:25:58 <peach34> shall I PR this ^
14:26:47 <moneromooo> Sure.
14:26:59 <peach34> just adding to the linker flags?
14:27:08 <peach34> Or what you suggested
14:27:15 <moneromooo> Whatever builds.
14:27:47 <peach34> Ok
14:27:58 <asymptotically> we could use pkgconfig to find zmq instead, the libzmq i have installed doesn't depend on any gssapi kerberos scary stuff
14:38:01 <peach34> Actually, I found that make -j4 works, but release-static doesn't
14:38:20 <peach34> I had put the code in another fork of Monero lol, two secs
14:43:10 <peach34> is this the right line?
14:43:12 <peach34> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lgssapi")
14:43:40 <peach34> I got an error that the linker couldn't find it
14:45:40 <peach34> same for gss
14:56:29 <peach34> sorry i dced
14:56:58 <peach34> Do I need more than the line
14:57:11 <peach34> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lgssapi") or gss, because the linker cant find it
14:57:50 <asymptotically> have a look at that package config file you found earlier. it might be named something else like '-lgssapi_krb5'
15:06:50 <peach34> should I include the name of the .pc file
15:07:04 <peach34> asymptotically
15:07:07 <peach34> chris@chrispc:~/electroneum$ locate gssapi | grep "pc"/usr/include/gssrpc/auth_gssapi.h/usr/include/mit-krb5/gssrpc/auth_gssapi.h/usr/lib/x86_64-linux-gnu/pkgconfig/krb5-gssapi.pc/usr/lib/x86_64-linux-gnu/pkgconfig/mit-krb5-gssapi.pc/usr/lib/x86_64-linux-gnu/pkgconfig/mit-krb5/krb5-gssapi.pc
15:07:24 <peach34> sorry bad formatting
15:07:54 <peach34> I get three .pc files with a similar name
15:08:40 <asymptotically> `pkg-config --static --libs libzmq` should spit them out
15:10:29 <peach34> thanks very much. why is it that we feed libzmq rather than libzmq3 into pkg-config?
15:11:07 <asymptotically> just because that's the name of the .pc file. 3 is just the name of the debian package, maybe you can choose between installing multiple versions
15:11:18 <peach34> Thanks
15:18:01 <peach34> Ok I've managed to do it with that thanks
15:33:32 <moneromooo> You want to detect libgssapi. It might not be present in some systems, and not needed. And electroneum is a scam if you did not know (no coders, just advertisers).
15:33:47 <moneromooo> And their miner didn't actually mine.
15:34:12 <moneromooo> Scams really need to die, and they won't until people stop buying them, making themselves complicit in the process.
15:43:14 <moneromooo> The really shitty thing is that regulation will come down hard on people trying to keep thier privacy, not on people helping scams. Fucked world.
16:07:31 <peach34> moneromooo they aren't a scam at all, just not as blockchain dev heavy
16:08:32 <peach34> They have built a custodial wallet system, a huge freelancing platform & have lots of real world adoption
16:09:19 <peach34> Fully regulated , KYC/AML compliant
16:09:53 <peach34> They have many coders and infrastructure guys I can assure you of that
16:11:00 <peach34> Scam is the opposite of what they are, honestly. Their mobile mining was marketing to get people interested yes, and they were open about that from the start
16:14:01 <moneromooo> Maybe they got coders since then, but at the start it was definitely no coders and a miner that didn't mine.
16:14:35 <moneromooo> I guess they'd have the money to get coders now, after the original scam :)
16:15:20 <moneromooo> Doesn't change the fact that whitewashing after the fact will incentivize scams if they can be forgiven later.
16:15:47 <peach34> Nah they were always open that it didn't mine, that it was simulated.
16:16:01 <moneromooo> For the same project anyway. If they were to start a different honest one, maybe.
16:16:18 <peach34> And originally they had many coders, but only one blockchain guy
16:16:53 <peach34> They are and have always been legitimate. The most legitimate out there believe it or not.
16:17:00 <moneromooo> While I have no inside info, I seriously doubt that. I remember one guy asking a quesiton, didn't even know how to use a compiler.
16:17:16 <moneromooo> The most ? Dude. You're doing yourself no favours here.
16:17:40 <peach34> Yeah I think they started off knowing very little about blockchain and c++
16:17:49 <moneromooo> < peach34> And originally they had many coders
16:18:07 <peach34> They mainly had PHP developers
16:18:08 <moneromooo> Well, I guess could be javsscript coders.
16:18:12 <moneromooo> o_O
16:18:12 <dsc_> current main repo resembles a ghost town
16:19:02 <peach34> lol well yeah, I just don't think they're as bad as you think they are
16:19:12 <moneromooo> Anyway, in my view, marketing heavy == scam anyway, regardless of whether they had an army of PHP coders.
16:19:14 <peach34> But I get it
16:19:40 <peach34> I understand why you'd be annoyed by them
16:20:22 <peach34> moneromooo for this zmq issue, what is the best way to detect the library
16:20:40 <peach34> I have my line find_library(GSSAPI gssapi_krb5)
16:20:43 <moneromooo> Same as the existing tests for pgm and.. er.. another.
16:20:54 <moneromooo> Looks like it, yes.
16:21:14 <moneromooo> And the link line (or the zmq libs line, can't recall) needs to reference this new var.
16:22:24 <peach34> I just used set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lgssapi_krb5")
16:22:26 <peach34> for the link line
16:22:45 <peach34> But it seems doing find_library(GSSAPI gssapi_krb5) does not find the library
16:23:03 <moneromooo> That'd change all the binaries. Not sure tha'ts what you want. Let me look now.
16:23:36 <peach34> I wrapped it in a conditional
16:23:45 <moneromooo> A bit after find_library, you see:
16:23:46 <moneromooo> if(NORM_LIBRARY) set(ZMQ_LIB "${ZMQ_LIB};${NORM_LIBRARY}")
16:23:46 <moneromooo> endif()
16:23:47 <peach34> if(GSSAPI) link
16:24:13 <moneromooo> Do the same. then anything that links aginst libzmq will also link against libgssapi_krb5 when found.
16:25:12 <peach34> got you
16:25:56 <peach34> So the colon separated ZMQ_LIB list means whenever lib zmq is found, link against norm, proto etc?
16:26:08 <peach34> semicolon seperated*
16:27:32 <moneromooo> It means: append the lib, if it was found. Done for each lib.
16:27:53 <moneromooo> So yes.
16:31:59 <peach34> Right, thanks.
16:38:22 <peach34> moneromooo are we not at risk of duplicate definitions for those without this issue by adding a gssapi link like this?
16:39:16 <moneromooo> I doubt it, unless you point out a particular reason why.
16:39:41 <moneromooo> You can tpyically use -lfoo several times, that's not a problem unless you're linking against different symbols with the same name.
16:39:56 <moneromooo> Which could happen if you link against two versions of libgss_krb5.
16:40:21 <peach34> You usually can, if you link in groups
16:40:51 <peach34> ^ exactly
16:40:58 <moneromooo> You can do what ? And I don't know what groups are in this context.
16:41:27 <peach34> You can usually link the same file more than once
16:42:30 <peach34> I guess here there is no chance of linking against two different libgss_krb5 right
16:43:38 <moneromooo> Right.
16:43:54 <moneromooo> For no == very small.
16:57:01 <peach34> yeah
17:31:15 -xmr-pr- grcasanova opened issue #6759: View-only wallet creation leads to an avalanche of warnings and errors
17:31:15 -xmr-pr- > https://github.com/monero-project/monero/issues/6759
19:29:03 <moneromooo> Oh, I have something for the fork :) I'd forgot, but someone wanted to make the coinbase amount so miners can't ask for less.
19:29:13 <moneromooo> Never did it, so I'll do it now. Trivial IIRC.
20:57:57 <hyc> why does the current code allow miners to ask for less? and why remove that ability?
21:00:36 <moneromooo> Because it made pre-rct coinbase txes sdmaller. Because it's not pointless and removes a potential fingerprinting vector.
21:00:44 <moneromooo> ffs
21:00:50 <moneromooo> Why do I always make this not/now typo...
21:01:01 <moneromooo> It's now pointless.
21:31:15 -xmr-pr- moneromooo-monero opened pull request #6760: enforce claiming maximum coinbase amount
21:31:15 -xmr-pr- > https://github.com/monero-project/monero/pull/6760
21:37:45 <hyc> ah ok makes sense
21:41:31 <moneromooo> hyc: btw you might want to check 6757, up your alley.
21:45:12 <hyc> ok
21:46:18 <hyc> bah. whatever changes github made recently to their site's JS scripts, no longer works in my browser
21:46:32 <hyc> no page updating, have to do manual reload on everything
21:46:52 <doktoro> exit
21:48:15 <hyc> huh, there's really code calling threadpool wait() with the wrong tpool? how?
21:49:03 <moneromooo> No. Just with no pool, which was useless.
21:49:10 <hyc> because of an exception handler?
21:49:35 <moneromooo> No, run would exit (due to the exception), so wait would hang waiting.
21:49:58 <moneromooo> The fix is the try/catch in run. The rest is armour plating just in case of other bug.
21:50:04 <hyc> ok
21:50:31 <endogenic> question- should ec_point in monero core not be declared as containing unsigned chars instead of just chars?
21:50:34 <hyc> oh I read the commits in reverse order
21:51:07 <moneromooo> I'd say whichever needs the fewest casts :)
21:51:38 <endogenic> fewest cats? nioc?
21:51:39 <moneromooo> I don't think anything really cares about signedness (ie, implicit promotion) outside the crypto-ops.c file, but that would need double checking.
21:51:47 <moneromooo> C casts.
21:51:51 <endogenic> i know :P
21:52:09 <moneromooo> rct uses the other signednes, which is a pain.
21:53:27 <moneromooo> I'd be surprised if this didn't need a number of cast changes tbh.
21:55:10 <endogenic> does it make any more or less sense to use a particular signedness in the remainder of the application code in any way?
21:55:47 <endogenic> (is the followup question i'd ask if i were working on that!)
21:55:57 <moneromooo> Typically user level code will see those as a black box really.
21:56:09 <moneromooo> So it doesn't really matter I think.
21:56:28 <endogenic> hrm *sits down* whatre best practices?
21:56:28 <moneromooo> I'd use whatever needs fewer casts to interface with whatever API I use.
21:56:43 <endogenic> yeah
21:56:45 <endogenic> the API
21:57:28 <endogenic> 🙏 thank you!
21:57:32 <endogenic> i mean
21:57:35 <endogenic> mooooooo
21:58:58 <hyc> bytes are bytes
21:59:42 <moneromooo> Even on PDP-11.
22:00:27 <moneromooo> Wait. Was that the one with 9 bit bytes ? I forget.
22:00:40 <moneromooo> 36 bit words. I think it was one of the PDPs.
22:01:32 <moneromooo> Ah, was the 9 and 10.
22:08:53 <hyc> yeah. and the DEC-10
22:40:47 <endogenic> hyc: but apis are non fungible