Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)
Note that we don't run db_recover unless we detect an issue. dcrpm works by trying to detect common issues and issue the nicest possible recovery - from db_recover to other finding held locks by bad actors to other things. -- 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-365508327___ 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)
@pmatilai: yup, DB_RECOVER requires configuring Berkeley DB when opening correctly in order to use. Hint: execing dbXY_recover on an idle database (already protected by an exclusive write lock) fixes stale locks. Performing that operation when needed, not every 15 minutes with a Facebook fork bomb, seems like a saner approach. -- 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-365353871___ 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)
> DB_RECOVER requires DB_INIT_TXN, which is incompatible with DB_INIT_CDB that > rpm.org still uses. And enabling TXN on BDB runs into all sorts of fun with > BDB log file paths across chroots, requires additional infra in the code etc > and whatnot. All solvable issues no doubt, but it piles up so it's not this > entirely trivial "just try reopen with a different flag" thing from the CDB > mode starting point. I suspect that this is where the "RPM ACID" stuff comes into play, @n3npq ? -- 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-365256671___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
The reluctancy is to add features that end up entirely unused. Oh, and features which don't really fit rpm design principles to begin with. Personally, I'd *love* to see Fedora get rid of the changelogs maintained in specs and happy to help with it from my behalf, but until somebody actually commits to driving such a project ... it's just a whole lot of talk, recurring year after year after year. -- 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/393#issuecomment-365242453___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
Of course some distributions found their way despite RPM upstream being reluctant to support this or similar feature. The #69 just proves that. I did not mentioned Fedora anywhere and I don't think that #69 was proposed by Fedora people. -- 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/393#issuecomment-365238932___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
https://github.com/rpm-software-management/rpm/pull/69 is related and has some relevant discussion of the caveats etc. -- 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/393#issuecomment-365225168___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
Yeah there are any number of ways to do it. Multiple distros are doing it via other tooling sitting on top of rpm, that's an entirely valid route and already proven route. Other options include having rpm execute some hook to pull data from an outside source into the spec (and yes putting that modified version of the spec into an src.rpm because that's what really was packaged). Etc. Lets just say that my motivation for implementing something special primarily for Fedora (because everybody else is already doing it one way or the other) is not sky-high because a) others clearly manage without rpm modifications b) Fedora is pathetically bad at implementing new rpm features anyway. -- 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/393#issuecomment-365216634___ 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)
On a related note... our fix-the-rpm-db program has been opensourced: https://github.com/facebookincubator/dcrpm We run it every 15 minutes as a pre-script to configuration management. -- 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-365214211___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
Well, one big advantage from the %include/%changelog way would be the possible opt-in. If you want to automate "slapping the changelog itself at the tail of the spec", then it means you have to actually change the build infrastructure to do it. TBH the biggest issue I see currently is that the SRPM changelog duplicates the .spec changelog. And these two might be possibly different. This should not happen. If I am thinking about the workflow how to obtain the log from SCM and get it into SRPM, I think that the "rpmbuild -bs" could call some macro to update the changelog. But at that moment, you probably don't want to modify the .spec file which as about to be packaged into SRPM. Modifying some changelog file would be more acceptable IMO. -- 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/393#issuecomment-365207843___ 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)
> I can also easily back port the core fix to the problem reported here, > implemented years ago @rpm5.org: > > when DB_RUNRECOVERY is returned opening a BDB dbenv, then do the recovery > by setting a flag, and repeating the open one time, thereby running recovery. DB_RECOVER requires DB_INIT_TXN, which is incompatible with DB_INIT_CDB that rpm.org still uses. And enabling TXN on BDB runs into all sorts of fun with BDB log file paths across chroots, requires additional infra in the code etc and whatnot. All solvable issues no doubt, but it piles up so it's not this entirely trivial "just try reopen with a different flag" thing from the CDB mode starting point. -- 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-365207745___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
Documentation says "for all installed packages that contained...", nowhere does it say installed in *this* transaction. The "obvious" reason(s) for the behavior is that when installing the package containing the trigger, you want to get it to do its thing on the packages that are already installed. And when the file containing the trigger is erased, it'll undo it's thing. On upgrades of the package containing the trigger you'd want to rerun the script because it might contain fixes / new behaviors that the old one did not. -- 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/386#issuecomment-365197422___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
> %transfiletriggerin: Executed once after transaction for all installed > packages that contained file(s) that matches prefix of this trigger. Also > executed after transaction if there was a package containing this file > trigger in that transaction and there is/are some files(s) matching prefix of > this trigger in rpmdb. Documentation explicitly says about installed packages in transaction. Not for those which are already installed. -- 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/386#issuecomment-365195342___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
Why would you run ldconfig (for example), if there was no library installed / changed during transaction? Just to be sure? -- 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/386#issuecomment-365195603___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
> and installed package set this doesn't make any sense for me... -- 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/386#issuecomment-365194798___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
Closed #386. -- 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/386#event-1471178645___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
Hmm, actually I don't think this is a bug afterall: file triggers match files from the current transaction *and* installed package set, just like regular triggers do. And prefix / happens to match all installed files. It'll seem more sensible with a more reasonable prefix. -- 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/386#issuecomment-365194090___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to accept filename. (#393)
Splitting spec into multiple pieces (whether %include or otherwise) tends to have all sorts of downsides, especially because it breaks long-standing expectations of specs being standalone entities. I'm not actually opposed to adding %changelog -f but I'm also not convinved it's be best way to deal with pulling changelogs from scm, because then you'd still need the silly one-liners in each spec. Yes you can automate that, but then you might just as well automate slapping the changelog itself at the tail of the spec, so that the spec ending up in src.rpm's remains standalone and by looking at the srpm you don't actually know the changelog came from outside. Which is probably what you'd want if you were to rebuild a distro package locally. -- 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/393#issuecomment-365181602___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
