Is there a way to submit a one-shot update to an Aur package without becoming the maintainer?
Arch and Aur Folks, I updated https://aur.archlinux.org/packages/mongodb44 to build with the last 4.4.29 source and patched for boost 1.86. The package builds fine now against current Arch. I wanted to pass along the results of those efforts and update the Aur package, but didn't want to take on the maintainer role. Is there a way to provide an update for the package and bring in back into date without becoming the maintainer? I have a signed source package I'm happy to pass along if that is something the admins can do. There is about 8 hours of effort to that went to find and fix all the issues, I'd like to make that available to whoever may need the 4.4 version of mongodb. I didn't think I'd ever need it, but it is the last version that wasn't built requiring avx - so it is useful if you need it for those cases or need it in a VM, etc.. (note: some parts of a 3rd party package included along with the source will need a significant 'type' change to suppress the char8_t -Wc++20-compat type warning, but that's just something for the future, and there is one more -Wredundant-move I need to fix in src/mongo/db/matcher/expression_array.h that somehow got missed in the hundreds of thousands of lines of output) I've tried posting to aur-general, but my posts do not ever make it to the list. I don't mind picking up the maintainer role, but am hesitant to get caught be another large boost deprecation/removal during a busy week and not have time to devote to it. Is a one-shot update something that can be done for this package without becoming the maintainer? -- David C. Rankin, J.D.,P.E.
On 11/1/24 7:14 PM, David C. Rankin wrote:
Arch and Aur Folks,
I updated https://aur.archlinux.org/packages/mongodb44 to build with the last 4.4.29 source and patched for boost 1.86. The package builds fine now against current Arch.
I wanted to pass along the results of those efforts and update the Aur package, but didn't want to take on the maintainer role. Is there a way to provide an update for the package and bring in back into date without becoming the maintainer? I have a signed source package I'm happy to pass along if that is something the admins can do.
There is about 8 hours of effort to that went to find and fix all the issues, I'd like to make that available to whoever may need the 4.4 version of mongodb. I didn't think I'd ever need it, but it is the last version that wasn't built requiring avx - so it is useful if you need it for those cases or need it in a VM, etc..
(note: some parts of a 3rd party package included along with the source will need a significant 'type' change to suppress the char8_t - Wc++20-compat type warning, but that's just something for the future, and there is one more -Wredundant-move I need to fix in src/mongo/db/ matcher/expression_array.h that somehow got missed in the hundreds of thousands of lines of output)
I've tried posting to aur-general, but my posts do not ever make it to the list. I don't mind picking up the maintainer role, but am hesitant to get caught be another large boost deprecation/removal during a busy week and not have time to devote to it. Is a one-shot update something that can be done for this package without becoming the maintainer?
Hi, You can't update a package without being a maintainer / co-maintainer for it. However, since the package is currently orphaned, you can become the maintainer for it and push the update. If you don't feel like maintaining the package on the long run, you can simply disown it right after you pushed the update. The package will just be orphaned again, leaving the place for someone else to step up as the maintainer if desired. -- Regards, Robin Candau / Antiz
On 11/1/24 1:23 PM, Robin Candau wrote:
Hi,
You can't update a package without being a maintainer / co-maintainer for it. However, since the package is currently orphaned, you can become the maintainer for it and push the update.
If you don't feel like maintaining the package on the long run, you can simply disown it right after you pushed the update. The package will just be orphaned again, leaving the place for someone else to step up as the maintainer if desired.
Thank you Robin, I'll do that. I spent a few more hours today and cleaned up all (99.9%) of the warnings. It now builds clean without spewing a ton of preprocessor #warning messages and c++20-compat messages. You can actually see what is building. The package works really well. It's a shame the licensing caused Arch to drop the package. mongodb is an interesting document (as opposed to relational) database. I would have never looked into it had it not be a dependency for one of the eGroupware apps. -- David C. Rankin, J.D.,P.E.
On 11/1/24 1:23 PM, Robin Candau wrote:
You can't update a package without being a maintainer / co-maintainer for it. However, since the package is currently orphaned, you can become the maintainer for it and push the update.
Robin, I adopted the package as maintainer and pushed updates to https://aur.archlinux.org/packages/mongodb44. The package now builds cleanly allowing you to follow what is being built. Output is down to about 6,000 lines of build info with only a few stray warnings, down from well over 100,00 lines of continual warnings spew. The following patches are new: mongodb-4.4.29-boost-1.86.patch mongodb-4.4.29-fix-scons.patch mongodb-4.4.29-no-enterprise.patch mongodb-4.4.29-redudant-std-move.patch The database works well. I'd appreciate thoughts on anything else I should fix in the PKGBUILD. I am also unclear whether I should list debugedit as a build dependency -- it being somewhat of a generic dependency. Should it be included as well? (note: this is a BIG build and can take over an hour with link-time optimizations at -j4 or -j8, the source is about a 50M download from github) -- David C. Rankin, J.D.,P.E.
namcap both the resulting package and the PKGBUILD.
unclear whether I should list debugedit as a build dependency
https://wiki.archlinux.org/title/Arch_User_Repository#Prerequisites Martin On Sat, Nov 2, 2024 at 11:01 PM David C. Rankin <drankinatty@gmail.com> wrote:
On 11/1/24 1:23 PM, Robin Candau wrote:
You can't update a package without being a maintainer / co-maintainer for it. However, since the package is currently orphaned, you can become the maintainer for it and push the update.
Robin,
I adopted the package as maintainer and pushed updates to https://aur.archlinux.org/packages/mongodb44. The package now builds cleanly allowing you to follow what is being built. Output is down to about 6,000 lines of build info with only a few stray warnings, down from well over 100,00 lines of continual warnings spew. The following patches are new:
mongodb-4.4.29-boost-1.86.patch mongodb-4.4.29-fix-scons.patch mongodb-4.4.29-no-enterprise.patch mongodb-4.4.29-redudant-std-move.patch
The database works well.
I'd appreciate thoughts on anything else I should fix in the PKGBUILD. I am also unclear whether I should list debugedit as a build dependency -- it being somewhat of a generic dependency. Should it be included as well?
(note: this is a BIG build and can take over an hour with link-time optimizations at -j4 or -j8, the source is about a 50M download from github)
-- David C. Rankin, J.D.,P.E.
On 11/2/24 11:00 PM, David C. Rankin wrote:
On 11/1/24 1:23 PM, Robin Candau wrote:
You can't update a package without being a maintainer / co-maintainer for it. However, since the package is currently orphaned, you can become the maintainer for it and push the update.
Robin,
I adopted the package as maintainer and pushed updates to https:// aur.archlinux.org/packages/mongodb44. The package now builds cleanly allowing you to follow what is being built. Output is down to about 6,000 lines of build info with only a few stray warnings, down from well over 100,00 lines of continual warnings spew. The following patches are new:
mongodb-4.4.29-boost-1.86.patch mongodb-4.4.29-fix-scons.patch mongodb-4.4.29-no-enterprise.patch mongodb-4.4.29-redudant-std-move.patch
The database works well.
Thanks for this :)
I'd appreciate thoughts on anything else I should fix in the PKGBUILD. I am also unclear whether I should list debugedit as a build dependency -- it being somewhat of a generic dependency. Should it be included as well?
(note: this is a BIG build and can take over an hour with link-time optimizations at -j4 or -j8, the source is about a 50M download from github)
I haven't take a detailed look but, after a quick glance, the PKGBUILD looks generally good. Here are a few details I was able to spot: - "Previous Maintainer" should be listed as "Contributor" (e.g. `# Contributor: name <email>`) [1] - No reason to list the -bin variant of the `mongosh` package over the "regular" one in optional dependencies [2]. The former provides the latter already. - The source currently have a potentially conflicting / too generic name [3]. You should rename it to avoid potential name conflicts with other (packages) sources (e.g. `$pkgname-$pkgver.tar.gz::https://github.com/mongodb/mongo/archive/refs/tags/r$pkgver.tar.gz`). - Custom variables and functions should be prefixed with a underscore. So the `all-flag-vars()` & the `filter-flags()` functions [4][5] should be called `_all-flag-vars()` & `_filter-flags()` instead. - No need to `cd` to "${srcdir}" in the various functions (e.g. in [6]), every functions are already executed from that directory. - I would personally ensure installed binaries [7] are executable / have the correct permission mode by using `install -Dm 755` instead of `install -D`. As for debugedit, it is a part of the base-devel meta-package [8] and thus should *not* be included as make dependency (as base-devel is assumed installed when building packages with makepkg) [9]. [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n2 [2] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n17 [3] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n22 [4] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n71 [5] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n89 [6] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n98 [7] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mongodb44#n154 [8] https://archlinux.org/packages/core/any/base-devel/ [9] https://wiki.archlinux.org/title/PKGBUILD#makedepends -- Regards, Robin Candau / Antiz
On 11/2/24 5:49 PM, Robin Candau wrote:
I haven't take a detailed look but, after a quick glance, the PKGBUILD looks generally good. Here are a few details I was able to spot:
- "Previous Maintainer" should be listed as "Contributor" (e.g. `# Contributor: name <email>`) [1]
- No reason to list the -bin variant of the `mongosh` package over the "regular" one in optional dependencies [2]. The former provides the latter already.
- The source currently have a potentially conflicting / too generic name [3]. You should rename it to avoid potential name conflicts with other (packages) sources (e.g. `$pkgname-$pkgver.tar.gz::https://github.com/mongodb/mongo/ archive/refs/tags/r$pkgver.tar.gz`).
Yes, this has always been a git tag download curiosity. If you download from the desktop, it provides the mongo-... prefix, but if you pull the release from a build-script it comes in as simply ... That is a welcomed solution.
- Custom variables and functions should be prefixed with a underscore. So the `all-flag-vars()` & the `filter-flags()` functions [4][5] should be called `_all-flag-vars()` & `_filter-flags()` instead.
- No need to `cd` to "${srcdir}" in the various functions (e.g. in [6]), every functions are already executed from that directory.
- I would personally ensure installed binaries [7] are executable / have the correct permission mode by using `install -Dm 755` instead of `install -D`.
Thank you. I'll take care of all that in the -6 release. Just finished with the last redundant std::move() patch - all 1300+ lines of it... I'm pleased with the way it builds and works. -- David C. Rankin, J.D.,P.E.
While I'm sure fixing this is a great learning experience, keep in mind that the version is EOL, and as such has no security patches, meaning you should in no case be running it directly on a host system (bad idea to have services there in the first place if you can avoid it). I recommend you throw the DB in a Docker or Incus container. Or better yet, migrate whatever it is you need to something supported, should you have the time. Martin On Sun, Nov 3, 2024, 02:43 David C. Rankin <drankinatty@gmail.com> wrote:
On 11/2/24 5:49 PM, Robin Candau wrote:
I haven't take a detailed look but, after a quick glance, the PKGBUILD looks generally good. Here are a few details I was able to spot:
- "Previous Maintainer" should be listed as "Contributor" (e.g. `# Contributor: name <email>`) [1]
- No reason to list the -bin variant of the `mongosh` package over the "regular" one in optional dependencies [2]. The former provides the latter already.
- The source currently have a potentially conflicting / too generic name [3]. You should rename it to avoid potential name conflicts with other (packages) sources (e.g. `$pkgname-$pkgver.tar.gz:: https://github.com/mongodb/mongo/ archive/refs/tags/r$pkgver.tar.gz`).
Yes, this has always been a git tag download curiosity. If you download from the desktop, it provides the mongo-... prefix, but if you pull the release from a build-script it comes in as simply ...
That is a welcomed solution.
- Custom variables and functions should be prefixed with a underscore. So the `all-flag-vars()` & the `filter-flags()` functions [4][5] should be called `_all-flag-vars()` & `_filter-flags()` instead.
- No need to `cd` to "${srcdir}" in the various functions (e.g. in [6]), every functions are already executed from that directory.
- I would personally ensure installed binaries [7] are executable / have the correct permission mode by using `install -Dm 755` instead of `install -D`.
Thank you.
I'll take care of all that in the -6 release. Just finished with the last redundant std::move() patch - all 1300+ lines of it... I'm pleased with the way it builds and works.
-- David C. Rankin, J.D.,P.E.
On 11/3/24 8:49 AM, Martin Rys wrote:
I recommend you throw the DB in a Docker or Incus container.
Or better yet, migrate whatever it is you need to something supported, should you have the time.
Thanks Martin, That's basically where this is going. I stumbled across it as a dependency for eGroupware Rocketchat. I current have eGrouware installed in development mode (outside docker) for migrating tables from versions of eGroupware from nearly 20 years ago. eGroupware, despite being a docker app has difficulty running on Arch, so I'm taking app-by-app to understand why and fix it. The mongo 4.4 release is needed as it is the last release that doesn't require avx intrinsics. eGrouware devs keep suggesting Debian, but I run Arch. Where there is a will, there is a way... -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin
-
Martin Rys
-
Robin Candau