Package Details: mongodb 4.2.8-1

Git Clone URL: (read-only, click to copy)
Package Base: mongodb
Description: A high-performance, open source, schema-free document-oriented database
Upstream URL:
Keywords: database document-oriented
Licenses: custom:SSPL
Submitter: felixonmars
Maintainer: jamespharvey20 (chrbayer)
Last Packager: chrbayer
Votes: 26
Popularity: 0.000413
First Submitted: 2019-01-18 22:08
Last Updated: 2020-08-20 22:41

Pinned Comments

jamespharvey20 commented on 2019-08-21 22:40

READ ME - 4.2.0 is here - The good, the bad, and the ugly

Good! 4.2.0 finally supports python3. The dependency on aur/python2-scons is no longer needed.

Bad! 4.2.0 breaks having aur/wiredtiger as a separate package, so it is no longer needed. Upstream may fix this some day, but advised for now they can't be separate. When mongodb is being built, it recognizes it's not using a separate wiredtiger package and compiles wiredtiger's source into part of mongodb, so it's still there, just not separate. This increases the space required to about 260GB. The combined amount of time it takes to build shouldn't change.

Mixed! 4.2.0 breaks most of the tests performed in check() under devtools. Previously, only 8 tests couldn't run within devtools due to systemd-nspawn banning mlock(). Now, it appears hundreds of them require mlock(). It's no longer feasible to discover and disable all of them, and maintain this list between versions, so if devtools is detected, check() does nothing. In my opinion, that's bad news, because I'd like to run the tests. Many users will probably greatly welcome this change, because most of the space and time required to build mongodb is in check().

So, users of devtools will only need 20GB available to build this, and it will complete in about 30% of the time it used to, due to check() not doing anything.

But, direct users of makepkg (including probably most AUR helpers) will now need about 260GB available just to build this.

jamespharvey20 commented on 2019-02-22 03:50

READ ME - Manual intervention potentially required upgrading to or past 4.0.6-2

If you never modified /etc/mongodb.conf, there is nothing you need to do, as pacman will install the new configuration file for you.

If pacman alerts you that a new configuration file is saved at /etc/mongodb.conf.pacnew, you must switch to it, or at least modify your existing one to enable forking.

Among other cleanups, 4.0.6-2 switches to:

  1. Upstream's systemd service file, which uses a systemd service type of forking, versus the old Arch-specific type of simple.

  2. Upstream's configuration file, which uses the YAML format introduced back in 2.6, versus the old Arch-specific configuration file using the 2.4 format.

If you had modified /etc/mongodb.conf, pacman will install the new one to /etc/mongodb.conf.pacnew. So, you will either need to: switch to the new one, and duplicate changes you made to the old one that you still need, considering the new file is now in the YAML format; or modify your existing one to enable forking. (Using the old 2.4 file format, adding fork: true should be what is needed.)

jamespharvey20 commented on 2019-02-15 09:58

READ ME - This is quite the package to build

If you use makepkg or an AUR helper you should have 260GB available just to build this. If you use devtools, you will only need 20GB available, because check() is skipped.

It takes a lot of time to build this. Using makepkg, a user reported it took 6.5 hours on an Intel i7. 32 Xeon cores with a high-end NVMe takes an hour.

How much memory you need to build this is untested, but I'd guess having a low amount of memory could cause compilation errors.

If you have compilation problems, please use makepkg, or extra-x86_64-build from devtools, as AUR helpers are not officially supported.

Alternatively, there is the mongodb-bin package, which converts the pre-compiled Ubuntu package into one for Arch. Note Ubuntu's package may use different compilation options.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

gazro commented on 2019-08-09 13:29

line 909

print( "python version: " + " ".join( [ `i` for i in sys.version_info ] ) )


SyntaxError: invalid syntax

==> ERROR: A failure occurred in build(). Aborting...

gonciarz commented on 2019-08-08 11:11

I cannot build a package. Those are logs: ==> Making package: mongodb 4.0.11-1 (Thu 08 Aug 2019 13:06:49 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting build()... scons: Reading SConscript files ... File "/home/rob/.cache/yay/mongodb/src/mongodb-src-r4.0.11/SConstruct", line 909

print( "python version: " + " ".join( [ `i` for i in sys.version_info ] ) )


SyntaxError: invalid syntax

jokke commented on 2019-08-07 22:10

Fails to build:

scons: Reading SConscript files ...
  File "/build/mongodb/src/mongodb-src-r4.0.11/SConstruct", line 909

    print( "python version: " + " ".join( [ `i` for i in sys.version_info ] ) )


SyntaxError: invalid syntax

yaron commented on 2019-05-22 11:47

RequestsDependencyWarning: urllib3 (1.25.2) or chardet (3.0.4) doesn't match a supported version!

Failed :(

jamespharvey20 commented on 2019-03-30 23:45

Please keep all comments on this package about mongodb only, not the mongodb-bin variant or upstream tarballs. Questions specifically about those need to go elsewhere, like on the mongodb-bin package.

I'm having a bit of a hard time following the last 3 comments, in part because I can't see the original non-edited question. But, I think other than build diskspace usage, that all other discussion was really regarding upstream's tarballs and the mongodb-bin package. In case I'm wrong, please let me know. This mongodb package should build and install /usr/share/man/man1/mongo{d,s}.1.gz. If it doesn't, please say how you're building it. I'm using devtools.

Regarding why this needs 180GB of diskspace, that's only to build it, not install it. As for why, you'd want to ask upstream. There's been a thread discussing this here:!searchin/mongodb-user/space%7Csort:date/mongodb-user/cHMbYPyD6f0/2dhGXqxsBwAJ

The majority of the time and space usage is in check(). They appear to be using an awful lot of data during their tests. If you don't run these tests, on my 32 Xeon cores, it finishes in 15 minutes instead of 60, and uses 10GB of diskspace instead of 165GB. I can't advocate skipping the tests, but I will note that if you install mongodb-bin, you're only getting testing on upstream's machine with its dependencies, not yours. So, maybe skipping the tests here is the same thing, since I always run them before pushing an updated version. But, I still recommend running them, as it's a database and integrity is paramount.

fkl commented on 2019-03-28 12:47

[Original Message Timestamp: 2019-03-28 07:39] I failed to build this thing because of the disk space requirement. Before I take another stab at trying to build, does this AUR package or come with (i.e. installs) the manpages? I had no issues with installing the community server (mongodb-linux-x86_64-4.0.7.tgz) but this tarball does not ship with manpages.

Can someone briefly explain why this thing needs 180GB of diskspace?

Note: the [X] "Delete comment" deletes w/o asking for confirmation. The webmaster needs to fix this feature.

fkl commented on 2019-03-28 12:04

@navarroaxel Thank you for the quick response. This is actually my first-ever AUR package-building attempt, and it was a rough one. Can we ask the maintainers of this AUR to use a non-'all' build? (unless there is a real reason for 'all')

I think I will just go with the mongodb-bin option for now.

navarroaxel commented on 2019-03-28 11:46

Hi @fkl, Sounds like this package is using the 'all' build variant. That will build everything in the source tree. The mongodb-bin package comes with man pages, you can use the command man mongo or man mongod. You should not use the Linux legacy tgz package from mongodb website because of this:

jamespharvey20 commented on 2019-03-26 21:42

I wouldn't use 4.0.7-1. It doesn't require wiredtiger commit db5942dc, as upstream expects. See

As separate packages, mongodb and wiredtiger almost always need to be upgraded at the same time.

I'm wondering if it makes continued sense for mongodb to have wiredtiger as a separate dependency. By default, it pulls in its dependencies' source by the specified commit in its mongodb git repo. Haivng it use the system wiredtiger is from when they were in community.

Some if its dependencies can be specified to use the system-installed packages, but can't, because they either require older versions than Arch has, or have their own in-repo patches they didn't submit upstream. Like, asio, icu, boost, and strangely even mongo-c.

Since if you're going to use mongodb, you have to have wiredtiger by one of these methods, and wiredtiger isn't used for anything other than mongodb, having them separate seems like it's just adding extra steps for users to build. (mongodb-3.4 does of course depend on wiredtiger, but that conflicts with this package, and I'm not sure it's safe for it to be given the commit that current stable mongodb requires anyway.)

EDIT: I'm now leaning toward keeping wiredtiger separate. Statically building it in-tree doesn't provide the files wiredtiger does, and users could be using its headers and libraries. Additionally, we'd have to look into the other wiredtiger configure options (leveldb, lz4, tcmalloc, builtin zlib) can/should be added when building within mongo. Probably not worth investing time in, easier for the 3 involved maintainers to just become maintainers of both packages.

jamespharvey20 commented on 2019-02-25 01:05

@chrbayer, I think there's either something off with your DNS configuration, or there's something off with MongoDB's DNS entries.

How do you have DNS setup? I use systemd-resolved, /etc/resolv/confis a symlink to /run/systemd/resolve/resolv.conf, and I'm using DNS server

What are you using to build?

The failure you're having is in mongo/client/mongo_uri_test, specifically in its subtest srvRecordTest. I originally was wondering if they had just messed up their DNS records, but I just re-built 4.0.6-3, and check() passes, including on this test.

Starting with 4.0.6-2, check() is required to pass. Community 3.6.0-1 through 4.0.5-1, and AUR 4.0.6-1 included || warning "Tests failed" in check(), on the line that runs the unittests suite. This meant 3.6.0-1 through 4.0.6-1 ran the unittests suite, but if it errored, it would print a warning and continue. Because MongoDB's test suites are setup so when a single test fails, the rest are skipped, that seems to me like that suite may as well not have been run. In 3.6.0-1, this was changed because some tests required mlock(), which fails within systemd-nspawn, part of the devtools build process. So, in 4.0.6-2, I took a different approach of checking if it's running under systemd-nspawn, and if so, disable all the tests that use mlock(). So, I'm now not thinking they messed up their DNS records, but that this test was failing for you in the past, but it continued building the package. (Or, you're running through devtools, and it was failing on an earlier test and never getting to this one.)

Anyways, your error message looks like this test is attempting to resolve a DNS entry and failing. I found an upstream bugreport indicating these tests require working name resolution at:

I think it's trying to resolve or I know enough about DNS to get by, but their records are confusing me a bit. Running dig <either .cc>, I only get back a SOA record with or It doesn't contain anything really useful, like an IP resolution, but I guess maybe it's still considered a valid response. Except in this case of testing a lookup but not wanting anyone to do something with it, I doubt only giving back an SOA record happens often.

If you're using a different DNS resolving method, it's possible there's a bug where only having an SOA record trips it up. Once I know what you're using, I'll try to reproduce.