On 01/09/2015 13:03, cov...@ccs.covici.com wrote:
> Alan McKinnon <alan.mckin...@gmail.com> wrote:
> 
>> On 01/09/2015 02:12, cov...@ccs.covici.com wrote:
>>> Alan McKinnon <alan.mckin...@gmail.com> wrote:
>>>
>>>> On 31/08/2015 18:54, cov...@ccs.covici.com wrote:
>>>>>> The words make sense, the meaning doesn't :-)
>>>>>>>
>>>>>>> It looks like fail2ban wants systemd without python support, but the
>>>>>>> true reason is still hidden. The fail2ban ebuild has this:
>>>>>>>
>>>>>>> RDEPEND="
>>>>>>>         ...
>>>>>>>         systemd? ( $(python_gen_cond_dep '|| (
>>>>>>>                 dev-python/python-systemd[${PYTHON_USEDEP}]
>>>>>>>                 sys-apps/systemd[python(-),${PYTHON_USEDEP}]
>>>>>>>
>>>>>>>
>>>>>>> I'm thinking maybe you have a specific portage entry that's getting in
>>>>>>> the way. What are your results for:
>>>>>>>
>>>>>>> emerge --info
>>>>>>> grep -r python /etc/portage
>>>>>>> grep -r systemd /etc/portage
>>>>> Just to let you know, most of the python entries were mandated by
>>>>> portage, certainly the systemd one.
>>>>
>>>>
>>>> I'm having a hard time figuring out what is making portage do this.
>>>> I also figure you're OK with a downgraded systemd meanwhile, but just
>>>> for kicks, lets test my theory: If you run this, does portage offer to
>>>> upgrade systemd?
>>>>
>>>>
>>>> USE="-python" emerge -pv systemd
>>>
>>> Well, here is what I got
>>> [ebuild     U  ] sys-apps/systemd-225:0/2::gentoo [219_p112:0/2::gentoo]
>>> USE="acl kdbus* kmod lz4 pam policykit seccomp ssl -apparmor -audit
>>> -cryptsetup -curl -elfutils -gcrypt -gnuefi% -http -idn -importd -lzma
>>> -nat -qrcode (-selinux) -sysv-utils {-test} -vanilla -xkb (-doc%*)
>>> (-gudev%) (-introspection%*) (-python%*)
>>> (-terminal%)" ABI_X86="32 (64) (-x32)"
>>> PYTHON_SINGLE_TARGET="(-python2_7%*) (-python3_3%) (-python3_4%)"
>>> PYTHON_TARGETS="(-python2_7%*) (-python3_3%) (-python3_4%*)" 3,788 KiB
>>>
>>> Total: 1 package (1 upgrade), Size of downloads: 3,788 KiB
>>>
>>> !!! Multiple package instances within a single package slot have been
>>>     pulled
>>> !!! into the dependency graph, resulting in a slot conflict:
>>>
>>> sys-apps/systemd:0
>>>
>>>   (sys-apps/systemd-225:0/2::gentoo, ebuild scheduled for merge) pulled
>>>   in by
>>>     sys-apps/systemd (Argument)
>>>
>>>   (sys-apps/systemd-219_p112:0/2::gentoo, installed) pulled in by
>>>     
>>> sys-apps/systemd[python(-),python_targets_python2_7(-)?,python_single_target_python2_7(+)?,python_targets_python3_3(-)?,python_single_target_python3_3(+)?,python_targets_python3_4(-)?,python_single_target_python3_4(+)?]
>>>     required by (net-analyzer/fail2ban-0.9.3:0/0::gentoo, installed)
>>
>>
>>
>> Got it, finally :-)
>>
>> fail2ban wants sys-apps/systemd[python(-)], and systemd-219_p112 is the
>> highest version with an explicit python USE flag. All later versions do
>> not have the flag at all.
>>
>> Your choices are either to have fail2ban fixed to deal with recent
>> systemd USE, and tolerate the systemd downgrade meanwhile; or to replace
>> fail2ban with something equivalent
> 
> I do need fail2ban, so should I file a bug against it?


Yes, definitely. There's a problem with fail2ban, or with portage's
resolver, or with our ability to read portage operators, I'm not sure
which :-)

The package maintainer is in a position to help out here.


-- 
Alan McKinnon
alan.mckin...@gmail.com


Reply via email to