Package Details: mongodb 8.0.4-1

Git Clone URL: https://aur.archlinux.org/mongodb.git (read-only, click to copy)
Package Base: mongodb
Description: A high-performance, open source, schema-free document-oriented database
Upstream URL: https://www.mongodb.com/
Keywords: database document-oriented nosql
Licenses: SSPL-1.0
Provides: mongodb
Submitter: felixonmars
Maintainer: siavoshkc
Last Packager: siavoshkc
Votes: 36
Popularity: 0.098976
First Submitted: 2019-01-18 22:08 (UTC)
Last Updated: 2025-03-31 21:53 (UTC)

Sources (8)

Pinned Comments

JstKddng commented on 2022-08-03 23:28 (UTC)

Binary builds are available:

https://software.opensuse.org//download.html?project=home%3Ajustkidding%3Aarch&package=mongodb

JstKddng commented on 2022-08-03 23:28 (UTC)

If you have a pre-sandybridge CPU or an ARMv8 sbc, you can use mongodb44

If you'd like to stay in the V5.0 branch, you can use mongodb50

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 16 Next › Last »

azcn2503 commented on 2019-12-30 07:31 (UTC)

Attempting to upgrade from 4.2.1-1 to 4.2.2-1 and receiving the following error:

Creating 'build/opt/mongo/config.h'
/usr/bin/python src/mongo/base/generate_error_codes.py src/mongo/base/error_codes.err src/mongo/base/error_codes.tpl.h=build/opt/mongo/base/error_codes.h src/mongo/base/error_codes.tpl.cpp=build/opt/mongo/base/error_codes.cpp
Traceback (most recent call last):
  File "src/mongo/base/generate_error_codes.py", line 45, in <module>
    from Cheetah.Template import Template
ModuleNotFoundError: No module named 'Cheetah'

jamespharvey20 commented on 2019-12-23 08:18 (UTC)

@Hi-Angel - sorry for not having responded earlier. I can't reproduce your problem. mongodb.tmpfiles is used to create the /var/{lib,log}/mognodb directories, and appears to be working fine for me. I even tried removing the package, removing the directories, and installing the package without non-existent directory errors.

@jiri.one - mongodb used to be in the official repos, but was dropped because upstream made a license change that was unclear (at best) whether it could be redistributed prepackaged, so it was dropped to the AUR. So, sorry, but it doesn't look like it's a candidate for going back to an official package.

jiri.one commented on 2019-12-07 18:09 (UTC)

Hi,have someone repo for mongodb? I know mongodb-bin, but better will be real Arch build.

Hi-Angel commented on 2019-11-28 10:10 (UTC)

Please, add the following directories to the PKGBUILD:

/var/lib/mongodb
/var/log/mongodb

These two are written in the default mongodb.conf that is shipped, and without them mongod fails to start with "non-existent directory" errors.

jamespharvey20 commented on 2019-11-19 02:45 (UTC)

archer666 - It just compiled fine for me, so I do think this was probably an out of memory issue. You could try the following things: * Decreasing the number of cores you're allowing it to use while building which will decrease the amount of memory usage. * Create additional swap space, even if you remove it after building. (If you can use a swap file, that will let you avoid partitioning.) * Remove check() from the PKGBUILD. I generally think it's a very good idea to run this, but on current packages, it just passed tests for me, and I see that's the phase you ran out of memory in.

archer666 commented on 2019-11-18 19:19 (UTC)

4.2.1 - no good

scons: building terminated because of errors. build/opt/mongo/db/s/collection_range_deleter_test.o failed: Error 1 ==> ERROR: A failure occurred in check(). Aborting... ==> ERROR: Makepkg was unable to build mongodb.

g++: fatal error: Killed signal terminated program cc1plus

Looks like out of memory - 16GB machine, I terminated almost everything, 10GB RAM free at least.

jamespharvey20 commented on 2019-10-16 01:53 (UTC) (edited on 2019-10-22 01:16 (UTC) by jamespharvey20)

lsr, I opened a bugreport upstream at https://jira.mongodb.org/browse/SERVER-44038

I'm baffled at what I found. Removing the line that forces ggdb that you brought up reduces my makepkg (so, tests are still ran) build size from 259GB to 2.3GB, and reduces the build from 70 minutes to 44 minutes. For users with platter drives, I think it will have an even more dramatic reduction in build times.

I tried several ways to get -O2 optimization, with no success.

I'm wondering if there's an intentional reason why they're doing this on posix, so am being cautious and waiting to hear back from upstream before I release a new version. I mean, I'd have to assume they would have noticed at some point in the past performance significantly dropped and have found they were forcing debug builds and no optimization, right?..... The stripped binary size doesn't change, but maybe there's some quirk here we're not aware of.

jamespharvey20 commented on 2019-10-14 10:40 (UTC) (edited on 2019-10-14 10:43 (UTC) by jamespharvey20)

lsr, awesome catch. I'm baffled by this, and can't wait to see how much faster mongodb performs. I know version 4.0.6 (when mongodb was dropped from community) had a similar build time and size requirement. It will be interesting to know how/when/why this came about. I'll admit I never looked through the SConstruct file other than having to do with system library options, and just went off upstream's compilation instructions which of course don't mention this. I'll be running compilation size and time benchmarks as is, without the forcing of -ggdb you pointed out, and also without -ggdb and the release option for optimization. I'll be posting back here, and likely be filing a bugreport upstream. I'm hoping fixing this and using optimizations won't drastically increase compilation times, but my guess is it will, we'll see...

lsr commented on 2019-10-14 08:49 (UTC)

The SConstruct file seems to always enable debug symbol generation: "-ggdb" if not env.TargetOSIs('emscripten') else "-g",

Removing this line seems to reduce the build tree to a less insane 10GiB.

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 16 Next › Last »