02:25:31 was the boost stuff mostly serialization? 02:25:53 That question is not clear enough. 02:26:03 im trying to find the commits that removed boost, and so far my cursory github website search yields; https://github.com/monero-project/monero/commit/7175dcb1078abbdaa130a8c5f5fd2b93fa7b3086 02:26:31 There was a recent commit that replaced a good amount of boost serialization with monero serialization. 02:26:59 yeah, thats all i could find. 02:27:04 This leaves some that can't be reached from an adversary (which does not control your disk). It also still leaves most boost usage. 02:28:20 ah ok. i just remember always complaining about boost and whether we could do away with it, and I was told that removing boost needs to be done carefully 02:29:39 so to see it go so nonchalantly caught me off guard 07:31:29 I'm reading many comments from people that find unclear what went into the release. That's something that bugged me a bit as well, because there is no way that the average person has any idea of what is being added or changed. Also we don't link changes to pull requrest so people have to make the searches by themselves, but often the description in the release notes don't match the description in the PR. 07:31:52 I like a lot how matrix show their changes. See this release for example: https://github.com/matrix-org/synapse/releases/tag/v1.20.0rc1 07:32:20 they achieve that by using a "changelog" file, which is updated with each PR. 07:32:48 I'm not sure how that works, i will look it up, because i think it worth to integrate something like that. 07:35:12 To be clear: with "bugged me a bit", i mean that it's something i've been thinking about ways to improve that for a long time. Selsta's release notes improved the situation a bit, but i think we still have a lot to improve. The thing is to manage to do that without too much effort from the contributors/maintainers 07:38:09 ErCiccione[m]: one thing that I've noticed some projects do is to create an issue against PRs, and then reference the issue instead of the PRs 07:38:21 so "improved xxx (#3244)" 07:38:34 and if someone wants to learn more they can dig into issue #3244 07:38:53 which is also referenced in PRs, so you can see how it was solved 07:39:08 but it does require contributors to be a little more organised 07:39:21 and it raises the barrier to entry wrt contributing 07:39:49 Yeah that would be useful too and i think is the standard workflow for a platform like github, but i don't think it's necessary 07:39:57 and as you say, yes, it would require more effort 07:40:24 I'm reading matrix's way, and looks like easy enough: https://github.com/matrix-org/synapse/blob/v1.20.0rc1/CONTRIBUTING.md#changelog 07:43:14 ^ this would only require to add a file to a changelog.d folder with each pr. It's a thing more to do, but super easy to do 08:11:30 "Deterministic unlock times" was very unclear description. I had to go through PR code to figure out what it was. Turns out it was a fix for a very specific case when time-locked transactions use timestamp to unlock, and this timestamp is now calculated from blockchain data only. 08:12:45 *timestamp to compare to is calculated from blockchain data 14:53:49 anyone else getting a "404 Not Found [IP: 91.189.88.152 80]" when trying to build monero using the dockerized instructions? it used to work on the exact same setup / networkdoes this mean ubuntu repos are down? 14:54:01 to give more context```Err:1 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 libudev-dev amd64 229-4ubuntu21.28 404 Not Found [IP: 91.189.88.152 80]E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/s/systemd/libudev-dev_229-4ubuntu21.28_amd64.deb 404 Not Found [IP: 91.189.88.152 80]``` 15:11:28 alternatively if someone could confirm that building the latest monero works as of now / the last two hours that would already help because then I'd know the issue is on my end 15:16:26 The docker image is kinda unmaintained, most people build from source without it 15:16:47 is it because ubuntu xenial is EOL? 15:16:48 https://github.com/XMRto/monero 15:17:04 ^ is more maintained I think 15:17:20 http://archive.ubuntu.com/ubuntu/pool/main/s/systemd/libudev-dev_229-4ubuntu21.29_amd64.deb seems to be available so maybe just a matter of `sudo apt update` or `sudo apt clean && sudo apt update` 15:18:58 I was following these instructions which are listed at the very top, so I thought it was the recommended way https://github.com/monero-project/monero-gui#building-linux-static-binaries-with-docker-any-os 15:19:27 Oh this is GUI? 15:19:32 just to clarify I'm looking to run it natively, I just wanted to use the docker-based instructions for a more reliable / system independent build 15:19:57 Yes it's about monero-wallet-gui, am I in the wrong channel then? 15:20:19 yea gui should build fine with that docker file, or it did in the past 15:22:07 https://github.com/monero-project/monero-gui/blob/master/Dockerfile#L5 change that into `RUN apt clean && apt update` and try again. 15:22:33 Might work. ¯\_(ツ)_/¯ 15:24:40 dsc_ Did that and it's looking good as now the install of the buildtools within the docker container actually worked. It's still running now and I will report back whether this allows the build to complete fully 15:33:02 I need help with understanding monerod.exe 15:33:26 I'm syncing now. It is downloading the XMR blockchain. 15:36:22 The new top block candidate is 1505728 -> 2190170. What do these two numbers mean? 15:36:45 Your height, the peer's claimed height. 15:38:57 Those two numbers together mean you're almost halfway through syncing (though later parts of the blockchain might sync faster as there were algorithm and space efficiency improvements implemented) 15:39:05 *more than halfway 15:44:58 Synced 1513928/2190177 (69%, 676249 left) 15:45:17 When it is done which number should I have? 15:45:32 The numbers should be equal basically 15:45:42 So first number == second number 15:45:44 it will be done when it reaches 2190177 + the number of new blocks minted until you almost reach the finish line 15:47:50 you're essentially playing "catch up", but you're downloading probably hundreds of blocks per minute and there is about one new block every two minutes added to the second number - this means you're catching up much quicker than the chain is moving forward so you'll soon end up with the scenario dEBRUYNE explained 16:01:01 Thanks guys. That all helps me understand this better. 16:03:21 dsc_ I can happily report that your tip fixed the build procedure and I am now successfully running the latest version of monerod / monero-wallet-gui. Thank you! 16:08:13 weee 16:11:34 How do I determine the estimated file size of the monero blockchain? 16:15:17 Estimated from what ? 16:16:13 I don't know. 16:16:25 Then you can't :) 16:17:19 But, are you trying to change monero, or just trying to sync a chain and not actually hack on monero ? 16:22:04 moneromooo, I'm downloading the monero blockchain. Not hacking. By the way, I found my answer to the file size of the monero blockchain. ---> https://bitinfocharts.com/ 16:24:14 Right, then you're in the wrong channel, try #monero. 16:24:50 Okay.