[Freeipa-devel] Fedora 20 Release

[Rich Megginson]

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
>>>>>>>>>> 1.3.1.x
>>>>>>>>>> inevitably needs automated script which will purge two missing
>>>>>>>>>> plugins
>>>>>>>>>> from dse.ldif.
>>>>>>>>> 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
>>>>>>>>> downgrade
>>>>>>>>> 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
>>>>>>> we go
>>>>>>> to F21, we can remove the epoch.
>>>>>> No, and that's key here. Once Epoch is in place, it is forever.
>>>>> Why?
>>>> Because that's how RPM is built. When Epoch value is absent it is
>>>> assumed to be equal to 0.
>>>> 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1,
>>>> however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter
>>>> is equal to 0:1.3.2.8-1.
>>>>
>>>> Once epoch is there, it is to stay.
>>> Anyway, is it a real problem? Personally, I consider it like
>>> yet-another-version-number.
>>>
>>> On my Fedora 19:
>>> $ repoquery -qa | wc -l
>>> 46645
>>> (packages in total)
>>>
>>> $ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l
>>> 6581
>>> (packages with non-zero epoch)
>>>
>> No, not a real problem, but just one more hassle I'd rather not have to
>> deal with.
> 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 1.3.2.9 packages for F20 here: 
http://rmeggins.fedorapeople.org/rpms/

1.3.2.9 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: 
http://copr.fedoraproject.org/coprs/rmeggins/389-ds-base-testing/repo/fedora-20-x86_64/
but copr seems to be having some issues.

I also have a patch for 1:389-ds-base-1.3.1.16 for F20 ready to go - I 
tested upgrade from 1.3.2.7 on F20, works fine, disables whoami and 
syncrepl.

>
> Simo.
>
>