On 12/16/2013 01:14 PM, Simo Sorce wrote:
On Mon, 2013-12-16 at 10:16 -0700, Rich Megginson wrote:
On 12/16/2013 10:12 AM, Petr Spacek wrote:
On 16.12.2013 17:55, Alexander Bokovoy wrote:
On Mon, 16 Dec 2013, Rich Megginson wrote:
Simo thinks that this is a reason why 'downgrade package' with
inevitably needs automated script which will purge two missing
We have an upgrade/downgrade framework, it should be easy to
disable/remove these plugins.
Is that it? Are there any other problems found attempting to
1.3.2 to 1.3.1 in F20?
Packaging issue -- epoch will have to be increased and maintained
forever. It is weird but that's what it is.
Sure. But that's a one time thing. And, it's only for F20 - once
to F21, we can remove the epoch.
No, and that's key here. Once Epoch is in place, it is forever.
Because that's how RPM is built. When Epoch value is absent it is
assumed to be equal to 0.
220.127.116.11-1 will be equal to 0:18.104.22.168-1 and less than 22.214.171.124-1,
however, 1:126.96.36.199-1 will be greater than 188.8.131.52-1 because the latter
is equal to 0:184.108.40.206-1.
Once epoch is there, it is to stay.
Anyway, is it a real problem? Personally, I consider it like
On my Fedora 19:
$ repoquery -qa | wc -l
(packages in total)
$ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l
(packages with non-zero epoch)
No, not a real problem, but just one more hassle I'd rather not have to
Yes it is a real problem, it is extremely confusing to people, because
it is not in the rpm file name.
It should be avoided if at all possible, and it is an unremovable tattoo
once you have it on.
So a decision to add an epoch number should never be taken lightly.
If you do not understand why, you should probably not set epochs.
Ok. We're going to try to fix the bugs in 1.3.2 ASAP, and do some
testing in F20.
I have some 220.127.116.11 packages for F20 here:
18.104.22.168 fixes the following issues:
- Ticket #47631 objectclass may, must lists skip rest of objectclass
once first is found in sup
-- NOTE: this is the schema issue
- Ticket 47627 - Fix replication logging
- Ticket #47313 - Indexed search with filter containing '&' and "!" with
attribute subtypes gives wrong result
-- NOTE: this is one of the crashing issues (not the crash that appears
to be syncrepl related)
- Ticket 47613 - Issues setting allowed mechanisms
- Ticket 47617 - allow configuring changelog trim interval
- Ticket 47601 - Plugin library path validation prevents intentional
loading of out-of-tree modules
- Ticket 47627 - changelog iteration should ignore cleaned rids when
getting the minCSN
- Ticket #47623 fix memleak caused by 47347
- Ticket 47622 - Automember betxnpreoperation - transaction not aborted
when group entry does not exist
- Ticket 47620 - 389-ds rejects nsds5ReplicaProtocolTimeout attribute
I'm trying to use copr to set up a repo:
but copr seems to be having some issues.
I also have a patch for 1:389-ds-base-22.214.171.124 for F20 ready to go - I
tested upgrade from 126.96.36.199 on F20, works fine, disables whoami and
Freeipa-devel mailing list