Spec URL: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec SRPM URL: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.0.0-1.fc11.src.rpm Description: Mongo (from "humongous") is a high-performance, open source, schema-free document-oriented database. MongoDB is written in C++ and offers the following features: * Collection oriented storage: easy storage of object/JSON -style data * Dynamic queries * Full index support, including on inner objects and embedded arrays * Query profiling * Replication and fail-over support * Efficient storage of binary data including large objects (e.g. photos and videos) * Auto-sharding for cloud-level scalability (currently in alpha) * Commercial Support Available A key goal of MongoDB is to bridge the gap between key/value stores (which are fast and highly scalable) and traditional RDBMS systems (which are deep in functionality). $ rpmlint mongodb-* mongodb.i586: W: non-standard-uid /var/log/mongodb mongodb mongodb.i586: W: non-standard-uid /var/lib/mongodb mongodb mongodb.i586: W: incoherent-subsys /etc/rc.d/init.d/mongodb $prog mongodb-debuginfo.i586: E: empty-debuginfo-package mongodb-devel.i586: W: no-documentation 3 packages and 0 specfiles checked; 1 errors, 4 warnings. I'm not a packager yet, but I have a sponsor, so please review! :) I'm especially concerned with the empty-debuginfo-package error. Should I disable the debuginfo-package altogether? This package depends on unittest: https://bugzilla.redhat.com/show_bug.cgi?id=526564 Prebuilt rpms are available here: http://mapleoin.fedorapeople.org/pkgs/unittest/
your package is in a good shape, someone will sponsor you and review your package soon.
[this is not a full review] Package builds and includes a static library and doesn't meet the guidelines on static libraries. $ rpmlint mongodb-1.0.0-1.fc11.src.rpm mongodb.src:78: E: hardcoded-library-path in %{buildroot}/lib 1 packages and 0 specfiles checked; 1 errors, 0 warnings.
> Package builds and includes a static library and doesn't meet the guidelines on > static libraries. Thanks for pointing this out. That file is the C++ driver. I've added a virtual Provides for it in the -devel package. $ rpmlint mongodb-1.0.0-1.fc11.src.rpm mongodb.src:78: E: hardcoded-library-path in %{buildroot}/lib 1 packages and 0 specfiles checked; 1 errors, 0 warnings. That seems to be a rpmlint error since it comes from this line in the spec file: mv %{buildroot}/lib %{buildroot}/bin %{buildroot}/include %{buildroot}%{_prefix}
Sorry, I forgot to link to the new files: SPEC: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec.1 SRPM: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.0.0-2.fc11.src.rpm * Thu Oct 1 2009 Ionuț Arțăriși <mapleoin> - 1.0.0-2 - added virtual -static package
> mongodb.src:78: E: hardcoded-library-path in %{buildroot}/lib It's not a failure in rpmlint. The package will fail to build for 64-bit multi-arch targets where %_libdir is /usr/lib64 instead of /usr/lib You move %{buildroot}/lib to %{buildroot}%{_prefix}, but you don't include any files in %{buildroot}%{_prefix}/lib (!) but %{buildroot}%{_libdir} which is not the same. Needs a fix. Read up on how to do scratch-builds with koji (the Fedora Build System).
Fixed. This one was a bit more subtle. Thanks! I previously thought I needed to be a packager to use koji. I tried a few scratch builds today, but the problem with this package is that it has unittest as a dependency and I haven't figured a way to send dependencies to koji. http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.0.0-3.fc11.src.rpm http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec.3 * Fri Oct 2 2009 Ionuț Arțăriși <mapleoin> - 1.0.0-3 - fixed libpath issue for 64bit systems
I think it will be built fine without unittest in my machine worked, what are the koji scratch build ?
https://koji.fedoraproject.org/koji/taskinfo?taskID=1724587
has any progress been made on this?
An updated spec if anyone is interested: http://github.com/silas/rpms/blob/master/mongodb/mongodb.spec
FYI: 10gen now maintains their own RPM/repo for Fedora and CentOS. http://www.mongodb.org/display/DOCS/CentOS+and+Fedora+Packages http://github.com/mongodb/mongo/tree/master/rpm/ It doesn't meet the Fedora packaging requirements, but it works and is kept up to date.
With the current traction NoSQL is gaining in the web developer community, Fedora kinda needs this package bad. I think it is preferable to have native packages in our own repositories instead of telling our users to go to mongodb.org and use theirs. Having Fedora built packages would make them carry Fedora GPG signatures, would be much more convenient for our users and would make them available for more archs and Fedora releases than there are now. Even though I'm not a real big MongoDB user, nor a C++ guru, I'm volunteering some of my time to package MongoDB for Fedora. I see Ionuț hasn't responded to this thread for over half a year, so I'd say this bug is *STALLED* [1]. (But then again, I don't even see a real, full review attached to this review request.) Ionuț, please respond to this bug. I'm willing to take this over if you cannot pursue MongoDB's inclusion in Fedora anymore. [1] http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
Hey, Maxim. I'd still like to package this, too, but I've been waiting for a reviewer. I'll try to update this to the latest version in the next few days.
Are you waiting for a sponsor, a reviewer or both? You mentioned you already have a sponsor, so can't your sponsor review you package? It's a sponsor's job to do that. The Package Review Process document states that '[...] If it is the first package of a Contributor, the Reviewer must be a Sponsor.' If you have a sponsor, why not ping him or her to review your package? If you do not have a sponsor, set the FE-NEEDSPONSOR block, as per [1]. I am not a sponsor, so I cannot help you here. If I can assist you with anything else, let me know. I'll try my best. [1] http://fedoraproject.org/wiki/Package_Review_Process
I just need a reviewer. I've been sponsored since I opened this ticket and had removed the FE-NEEDSPONSOR [1]. Here's the updated package if anyone would like to review: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.4.3-1.fc13.src.rpm http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec [1] https://bugzilla.redhat.com/show_activity.cgi?id=526567
I'll review it. First, I would like o say that I'll very reluctantly approve application with static libraries. I'll take a closer look at the package later.
Hi. I rebuild this RPM on F13 and I got this warning when I started the mongo client: [mallen@netbook init]$ mongo MongoDB shell version: 1.4.3 url: test Sat Jun 5 08:23:06 *** warning: spider monkey build without utf8 support. consider rebuilding with utf8 support connecting to: test type "help" for help I'm not sure what spidermonkey is, but I do know the db is utf-8 throughout so this is maybe something that should be fixed in the spec file.
(In reply to comment #18) > Hi. > > I rebuild this RPM on F13 and I got this warning when I started the mongo > client: > > [mallen@netbook init]$ mongo > MongoDB shell version: 1.4.3 > url: test > Sat Jun 5 08:23:06 *** warning: spider monkey build without utf8 support. > consider rebuilding with utf8 support > connecting to: test > type "help" for help > > I'm not sure what spidermonkey is, but I do know the db is utf-8 throughout so > this is maybe something that should be fixed in the spec file. from uname -a Linux netbook 2.6.33.5-112.fc13.i686 #1 SMP Thu May 27 03:11:56 UTC 2010 i686 i686 i386 GNU/Linux
Spidermonkey is the mozilla C++ javascript engine. it's in the js package. I'm not sure how it's being used in mongodb but if a fix is needed, it's probably needed in the js package.
The js issue seems to have been fixed now [1]. I changed the naming some more. So here's what I think: The daemon is to be named mongod, and the initscript will be called the same. Everything else (logs, locks, confs, dirs etc.) will be named mongodb. This produces a rpmlint error however: W: incoherent-init-script-name mongod ('mongodb', 'mongodbd') The init script name should be the same as the package name in lower case, or one with 'd' appended if it invokes a process by that name. I think we can ignore this as mongod is the actual upstream's name for the daemon and also what other distributions are calling it (and mongodbd is ugly). One solution would be renaming the package, but (as per the Naming Guidelines), the tarball is called mongodb and there are already other distributions which have packaged it under this name [2], [3]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=576585 [2] http://packages.ubuntu.com/lucid/mongodb [3] http://www.freshports.org/databases/mongodb/ http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.4.3-2.fc13.src.rpm
Where is this at? Is this in the package maintainer's hands? or the reviewers?
I updated the package to 1.6.0 and added a new -server subpackage. http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.6.0-1.fc13.src.rpm http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec Upstream are creating a binary json library (BSON) that's included in the mongodb package. I wouldn't really consider it a bundled lib yet. It's only available with the mongodb sources and it seems it's in the process of breaking away and becoming a stand-alone project [1]. Peter, are you still reviewing this? [1] http://bsonspec.org/#/implementation
Sorry for long-delayed REVIEW: Legend: + = PASSED, - = FAILED, 0 = Not Applicable + rpmlint is almost silent work ~/Desktop: rpmlint mongodb-* mongodb.i686: W: spelling-error %description -l en_US sharding -> sharing, shading, sharping mongodb.i686: W: no-manual-page-for-binary bsondump Error checking signature of mongodb-debuginfo-1.6.0-1.fc13.i686.rpm: mongodb-debuginfo-1.6.0-1.fc13.i686.rpm: sha1 MD5 NOT OK mongodb-devel.i686: W: no-documentation mongodb-server.i686: W: spelling-error Summary(en_US) sharding -> sharing, shading, sharping mongodb-server.i686: W: spelling-error %description -l en_US sharding -> sharing, shading, sharping mongodb-server.i686: E: incoherent-logrotate-file /etc/logrotate.d/mongodb mongodb-server.i686: W: non-standard-uid /var/log/mongodb mongodb mongodb-server.i686: W: non-standard-uid /var/lib/mongodb mongodb mongodb-server.i686: W: incoherent-init-script-name mongod ('mongodb-server', 'mongodb-serverd') 4 packages and 0 specfiles checked; 1 errors, 8 warnings. work ~/Desktop: All these messages are either bogus or already explained by Ionuț. + The package is named according to the Package Naming Guidelines. + The spec file name matches the base package %{name}, in the format %{name}.spec. -/+ The package doesn't fully meet the Packaging Guidelines. It doesn't use Fedora-specific CFLAGS/CXXFLAGS. This must be fixed. + The package is licensed with a Fedora approved license and meets the Licensing Guidelines. + The License field in the package spec file matches the actual license. + The file, containing the text of the license(s) for the package, is included in %doc. + The spec file is written in American English. + The spec file for the package is legible. + The sources used to build the package matches the upstream source: Sulaco ~/rpmbuild/SOURCES: sha256sum mongodb-src-r1.6.0.tar.gz* a81cb6445e003d6e73a983336855ddadf0ae4334d49f3a5ce6757d1261bd4c77 mongodb-src-r1.6.0.tar.gz a81cb6445e003d6e73a983336855ddadf0ae4334d49f3a5ce6757d1261bd4c77 mongodb-src-r1.6.0.tar.gz.1 Sulaco ~/rpmbuild/SOURCES: + The package successfully compiles and builds into binary rpms on at least one primary architecture. http://koji.fedoraproject.org/koji/taskinfo?taskID=2437186 + All build dependencies are listed in BuildRequires. 0 No need to handle locales. 0 No subpackages which stores shared library files (not just symlinks) in any of the dynamic linker's default paths. + The package does NOT bundle copies of system libraries (also see Ionuț's note about bson above). 0 The package isn't designed to be relocatable. + The package owns all directories that it creates. + The package does not list a file more than once in the spec file's %files listings. + Permissions on files are set properly. - The package must consistently use macros while you're currently mixing macros instead of core utilities somewhere and real names. Namely I mean %{__sed} and %{__chmod} macros. I suggest you to use plain sed and chmod instead. + The package contains code, or permissible content. 0 No extremely large documentation files. + Everything, the package includes as %doc, does not affect the runtime of the application. + Header files are in a -devel package. +/- Static libraries must be in a -static package as stated in Fedora Packaging Guidelines. However I'm not sure here since this package doesn't have any shared libraries at all. So I believe that adding necessary Provides is enough. 0 No libraries files with a suffix (e.g. libfoo.so.1.1). +/- The devel sub-package requires the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Again I'm not sure here because I don't know much about mongodb and its environment for developers, but I'm suspecting that main package isn't required for development. Anyway, adding one excessive explicit requirement doesn't break anything. + The package does NOT contain any .la libtool archives. 0 Not a GUI application. + The packages does not own files or directories already owned by other packages. + All filenames in the packages are valid UTF-8. Ok, summarizing things: * Please, fix scons-makefiles to use Fedora-specific CFLAGC/CXXFLAGC. * Consider removing useless macros such for sed and chmod * Version 1.6.1 is available. Consider upgrading. * Do you plan to provide rpm for EL-5? If yes, then, please, uncomment the only string in the %clean section. I don't see any other issues, so, please, comment these notes, and I'll continue.
Thanks a lot for the review, Peter! I think I got everything. Here are the updated files: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.6.1-1.fc13.src.rpm
Ok, I don't see any other packaging issues, so this package is APPROVED.
1.# change dbpath sed -i 's|/data/db/|%{_sharedstatedir}/mongodb/|' db/pdfile.cpp db/db.cpp I suggest to send this change to upstream because this hack changes mongodb behavior slightly. 2. Why the logfile path included in the initscript is different with the path included in mogodb.conf?
Thank you for pointing those out, Chen Lei. I've removed the sed patch after setting dbpath in the config file and using the config file options in the init file. I've also fixed the logfile path in the config. Thank you, Peter! I changed a few more things after talking to upstream and updated to the latest version so I'll wait a bit more before doing a CVS request. Here's what the package looks like now and the latest changes: http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb-1.6.2-1.fc13.src.rpm http://mapleoin.fedorapeople.org/pkgs/mongodb/mongodb.spec * Fri Sep 3 2010 Ionuț C. Arțăriși <mapleoin> - 1.6.2-1 - new upstream release 1.6.2 - send mongod the USR1 signal when doing logrotate - use config options when starting the daemon from the initfile - removed dbpath patch: rely on config - added pid directory to config file and created the dir in the spec - made the init script use options from the config file - changed logpath in mongodb.conf
Looks good for me. Please, proceed with SCM request.
New Package SCM Request ======================= Package Name: mongodb Short Description: high-performance, open source, schema-free document-oriented database Owners: mapleoin Branches: f12 f13 f14 el5 el6 InitialCC:
Git done (by process-git-requests).
mongodb-1.6.2-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/mongodb-1.6.2-1.fc13
mongodb-1.6.2-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mongodb'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mongodb-1.6.2-2.fc13
mongodb-1.6.2-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
What is the reason for the ppc/ppc64 ExcludeArch?
Upstream limitation: """ The MongoDB server (mongod) must run on a little-endian CPU, so if you are using a PPC OS X machine, mongod will not work. """ http://www.mongodb.org/downloads From that note it's possible that the mongo shell and any other utilities not in the mongodb-server subpackage could be compiled on ppc and we'd just want to conditionalize that subpackage. I'm not sure how the upstream buildscripts will handle that, though (I have just looked at the docs, not the package). I have no information on whether upstream would be receptive to a patch that fixes issues on big-endian architectures.
The package build process is broken, because it gets built twice, during bvoth %build and %install and the second time without the right CFLAGS. Also is the explicit "Requires: js" needed? See https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires
(In reply to comment #36) > Upstream limitation: > > """ > The MongoDB server (mongod) must run on a little-endian CPU, so if you are > using a PPC OS X machine, mongod will not work. > """ I don't like crippled software :-( In fact it builds fine even on s390/s390x ... Conditionalizing the server subpackage makes sense or we could start with an ExclusiveArch for this package, because there are 3 big-endian arches in secondary status The built-twice issue can be solved with passing the --cppflags also in the install run. And "-fno-strict-aliasing" should be added.
(In reply to comment #38) > I don't like crippled software :-( Dan, please, open separate ticket dedicated to this particular issue. There are more than dozen of people subscribed to that ticket and I'm sure they doesn't interested of issues regarding support for dying (or even almost dead) architectures (I'm also a ppc user so nothing personal here).
(In reply to comment #39) > (In reply to comment #38) > > > I don't like crippled software :-( > > Dan, please, open separate ticket dedicated to this particular issue. There are > more than dozen of people subscribed to that ticket and I'm sure they doesn't > interested of issues regarding support for dying (or even almost dead) > architectures (I'm also a ppc user so nothing personal here). the little endian only issue is tracked in bug #637262