Re: [Rpm-maint] [rpm-software-management/rpm] Run binary package generation via thread pools (#226)
I have now updated the patchset again, addressing the crashes with old gcc, and Jeff's comment above. And this time they should be rebased correctly :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/226#issuecomment-308014402___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make the default DB backend macro configurable (#157)
Commit e96fde8 doesn't quite cut it:
```
backend/dbi.c: In function ‘dbDetectBackend’:
backend/dbi.c:39:5: warning: not enough variable arguments to fit a sentinel
[-Wformat=]
char *db_backend = rpmExpand("%{?_db_backend}");
^~~~
```
Also I think software should honor configuration: if it's configured to use db
X then it shouldn't override that through auto-detection. Maybe more like,
autodetect if %_db_backend set to "auto" or undefined, otherwise do what the
configuration says even if it means erroring out of the situation?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/157#issuecomment-307781882___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)
After looking at current rpm.org sources, RPM still initializes with ts->dbmode = DB_RDONLY, and then reopens the rpmdb with O_RW in rpmtsSetup(). That opens a (minor and mostly irrelevant wrto RPM on OS X) race window. There is still the ability to disable fsync (or replace with fdatasync) within RPM sources. I would verify what setting you are using with RPM on OS X. What "works" on linux, may not work on OS X. BTW, what version of Berkeley DB are you using on OS X? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307766129___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)
Here are the patches in libdb-5.3.28-20: the patches are trackable to bug reports and appear to have been fixed by "upstream" `# License clarification patch # http://devel.trisquel.info/gitweb/?p=package-helpers.git;a=blob;f=helpers/DA TA/db4.8/007-mt19937db.c_license.patch;h=1036db4d337ce4c60984380b89afcaa63b2ef 88f;hb=df48d40d3544088338759e8bea2e7f832a564d48 Patch25: 007-mt19937db.c_license.patch #Adds missing constant to Optcodes.java and changes ClassReader.java to use it . This makes package to build with Java 8. Patch26: java8-fix.patch # memp_stat fix provided by upstream (rhbz#1211871) Patch27: db-5.3.21-memp_stat-upstream-fix.patch # fix for mutexes not being released provided by upstream (rhbz#1277887) Patch28: db-5.3.21-mutex_leak.patch # fix for overflowing hash variable inside bundled lemon Patch29: db-5.3.28-lemon_hash.patch ` Meanwhile, locking has not been shown to be a relevant issue to RPM on OS X. For starters, [https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307630055](url) is/was a buffer overrun while retrieving statistics for 389 directory services. That is likely irrelevant to RPM, which doesn't attempt to read MPOOL statistics. I would read& report on #1277887 but I am not authorized to access. Judging from the comment, "muteness not being released" is likelier to lead to a deadlock, not "corruption". Meanwhile its unclear whether any Fedora mutex patches are relevant on OS X: linux/glibc NPTL locking with futexes is likely irrelevant on OS X. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307761586___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)
There's an endless row of bugs where BDB environment getting corrupted, some of which have been BDB bugs (several found just in the last couple of years) that have been patched in Fedora/RHEL libdb but upstream BDB 5.x does not have, dunno about 6.x but there you run into the licensing side. So if you're running upstream BDB 5.x on Mac, you'll want to a check those Fedora/RHEL patches to libdb. Some of the more exotic bugs have been kernel VM, virtualization and whatnot. Fsync is only disabled on the first open of a newly created database (ie during fresh install), (iirc) never on existing database unless forced via configuration. After adding the .dbenv.lock to serialize rpmdb open and close a few years ago (to work around what seems like a BDB bug), I haven't been able to reproduce environment corruption from parallel access in my setup but doesn't mean it doesn't happen in some other setup, version mix and whoknowswhat. One possible workaround is to force use of private environment. That also means practically no locking, but at least it means queries will not corrupt anything (however queries themselves could return garbage if run in middle of write-operation). That's what happens if you run queries as non-privileged user, but since you can control permissions with sandboxing you can achieve the same by disallowing open of /var/lib/rpm/.dbenv.lock, which causes rpm to fall back to a private environment - meaning it wont open, much less write to those __db.* files. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307753745___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
